OmniAICreator/Qiita-1.07M huggingface dataset:
AWS Lambdaのレプリカって？

## はじめに

AWS Lambdaの気になる機能調べてみた記事３つ目です。

今回も画面左側に表示されているメニューの`レプリカ`について調べてみます。
![スクリーンショット 2025-01-06 3.58.27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/c78a2c39-4539-44e5-0ed4-2bc9807604ab.png)

## Lambda@Edgeが各リージョンにコピーされたもの。

結論は、Lambda@Edgeが各リージョンにコピーされたものでした。

下記の説明の通り、Lambda@Edgeはバージニア北部のリージョンで作成されたものが、各リージョン（＋エッジロケーション）にコピーされ、ユーザに近いロケーションで実行されるためです。

>Lambda@Edge は、Amazon CloudFrontの機能で、アプリケーションのユーザーに近いロケーションでコードを実行できるため、パフォーマンスが向上し、待ち時間が短縮されます。Lambda@Edge では、世界中の複数のロケーションでインフラストラクチャをプロビジョニングまたは管理する必要はありません。課金は実際に使用したコンピューティング時間に対してのみ発生し、コードが実行されていないときには料金も発生しません。

https://aws.amazon.com/jp/lambda/edge/

## 作ってみる。

### Lambdaの準備

:::note warn
バージニア北部リージョンで作成する必要があります！
:::

node.jsでレスポンスヘッダを加工するソースを用意しました。

```javascript
export const handler = async (event, context) => {
  const response = event.Records[0].cf.response;
  const request = event.Records[0].cf.request;

  // セキュリティヘッダーを追加
  response.headers['strict-transport-security'] = [{
      key: 'Strict-Transport-Security',
      value: 'max-age=31536000; includeSubdomains'
  }];
  
  response.headers['x-content-type-options'] = [{
      key: 'X-Content-Type-Options',
      value: 'nosniff'
  }];

  // キャッシュ制御
  response.headers['cache-control'] = [{
      key: 'Cache-Control',
      value: 'public, max-age=86400'  // 24時間
  }];

  return response;
};
```

また、Lambda@Edgeとして動作させるため、Lambdaの実行ロールの信頼関係に`edgelambda.amazonaws.com`を追加しておきます。

```diff_json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
+                    "edgelambda.amazonaws.com",
                    "lambda.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
```

### CloudFrontへの紐付け

CloudFrontへの紐付けをしていきます。

作成したLambdaの`+ トリガーを追加`を選択します。

![スクリーンショット 2025-01-05 5.31.46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/185a1460-edcd-3e0d-d0ec-94a9f67691ab.png)

CloudFrontを選択し、`Lamdba@Edgeへのデプロイ`を選択します。

![スクリーンショット 2025-01-05 5.25.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/10e24548-9e48-6097-04db-ce0d5edbcbf5.png)

任意のCloudFrontディストリビューションを選択し、`デプロイ`を選択します。

![スクリーンショット 2025-01-05 5.26.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/dddbea02-6fa3-5dee-4095-e7607cfdf56e.png)

なお、`Lambda@Edgeへのデプロイを確認`のチェックボックスは外すとエラーになる模様です。（必要なのかこれは、、）

![スクリーンショット 2025-01-05 5.33.47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/40d74819-3399-328e-17f7-c7d45308d8b3.png)

### レプリカに表示された！

デプロイが完了すると、レプリカにも無事表示されるようになりました。

![スクリーンショット 2025-01-05 5.35.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/f88bef89-c9d4-0282-97f7-6fe393c52bd3.png)


## 余談

2025/01時点では、インフォパネルの説明が誤ってそうです。
（一つ上のメニューである、Lambdaレイヤーになってる）

![スクリーンショット 2025-01-06 4.05.34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/cb3768bd-674d-e178-a8bf-78e71b85a648.png)

## 最後に

今まではCloudFront Functionsで事足りてたため、Lambda@Edgeを触ることがなかったのですが、Lambda@Edgeの作り方を知ることができてよかったです！

これでメニューに表示されている一通りの疑問点は解消できたかな？
【JavaScript】日付をYYYY-MM-DDの文字列にする

# 結論

変換方法としては、以下の３種類があります。

1. `toLocaleDateString('ja-JP')`から`/`を`-`に置換する
1. `toLocaleDateString("sv-SE")`を利用する
1. 独自実装を利用

## 1. `toLocaleDateString('ja-JP')`から`/`を`-`に置換する

`toLocaleDateString('ja-JP')`でYYYY/MM/DDの文字列に変換されることを利用します。

```javascript
const formatedDateString = date.toLocaleDateString('ja-JP').replaceAll('/','-');
```

`-`の箇所を空文字にしてYYYYMMDDの文字列にすることも可能です。
個人的には一番読みやすい実装だと思います。

## 2. `toLocaleDateString('sv-SE')`を利用する

`'sv-SE'`はスウェーデンのフォーマットです。

`toLocaleDateString('sv-SE')`→YYYY-MM-DD
`toLocaleString('sv-SE')`　→　YYYY-MM-DD HH:MM:SS

と変換されるらしいです。

```javascript
const formatedDateString = date.toLocaleDateString('sv-SE'); // YYYY-MM-DDに変換
```

一つだけの関数で明瞭ですが、チームでの開発であればコメントで補足した方が良いかと思います。

## 3. 独自実装

昔から良くあるやつです。古い環境で上記メソッドが使えない場合に活用するかと思います。
`date.getFullYear()` `date.getMonth()` `date.getDate()`をこね回します。
※試しにChatGPTに書かせてみました。

```javascript
function formatDate(date) {
  var year = date.getFullYear();
  var month = date.getMonth() + 1;  // getMonth()は0から始まるので1を足す
  var day = date.getDate();

  // 月と日が1桁の場合、先頭に0を追加
  if (month < 10) {
    month = '0' + month;
  }
  if (day < 10) {
    day = '0' + day;
  }

  return year + '-' + month + '-' + day;
}
```

# 最後に

お読みいただきありがとうございました。
より良い方法等がありましたらコメントいただけますと幸いです。
2025/1/6主にITとかセキュリティの記事

BRIは、データを保護するための違法なAPKインストールを避けるよう国民に促します(1/3)
https://voi.id/ja/keizai/447807

サイバーセキュリティ企業が予想する、2025年の脅威や業界トレンド(1/4)
https://japan.zdnet.com/article/35227677/

BeyondTrust重大脆弱性で米財務省がサイバー攻撃被害 – クラウド版は即座に対策、セルフホスト版に課題(1/4)
https://innovatopia.jp/cyber-security/cyber-security-news/46010/

激増するスマホへの攻撃　AndroidもiOSも全ユーザーが行なうべき安全性チェック(1/4)
https://forbesjapan.com/articles/detail/76238

犯罪者専用メッセンジャー「Sky ECC」の暗号化が解除され約1万人が逮捕された裏側(1/4)
https://gigazine.net/news/20250104-crime-messenger/

Integrity Technology Group制裁：米財務省、26万台規模のボットネットで中国企業に制裁発動(1/4)
https://innovatopia.jp/cyber-security/cyber-security-news/46013/

中国のサイバー企業に制裁　米、ハッキングに関与(1/4)
https://topics.smt.docomo.ne.jp/amp/article/kyodo_nor/world/kyodo_nor-2025010401000145
https://nordot.app/1248022802081530731?c=110564226228225532

ハーレーダビッドソンアラミデータ漏洩、合計66,700人の顧客が脅かされました(1/3)
https://voi.id/ja/motor/447794

イタリア データ保護庁 ラジオ、テレビ、新聞、インターネット上で6か月間の組織的な広報キャンペーンと15百万ユーロ（23億円強）の罰金を命じる(1/4)
http://maruyama-mitsuhiko.cocolog-nifty.com/security/2025/01/post-cc5806.html

OECD 経済見通し 2024, 2025, 2026の見通し (2024.12.04)(1/4)
http://maruyama-mitsuhiko.cocolog-nifty.com/security/2025/01/post-390fc8.html

欧州議会 EUと中国との比較や関係 (2024.12.16)(1/4)
http://maruyama-mitsuhiko.cocolog-nifty.com/security/2025/01/post-7558c2.html

米国 人工知能に関する超党派下院小委員会報告書 米国が責任あるAIイノベーションを継続的に世界に提供するための指針、将来を見据えた提言、政策提言 (2024.12.17)(1/4)
http://maruyama-mitsuhiko.cocolog-nifty.com/security/2025/01/post-4b22fe.html

「パスワードの自動入力」とは？GoogleパスワードマネージャーとiCloudキーチェーンの便利な使い方(1/4)
https://dime.jp/genre/1873412/

ブラウザ保存より断然に安全！ パスワードの自動入力と暗号化保存デバイス(1/4)
https://ascii.jp/elem/000/004/242/4242887/?rss

ビジネスコミュニケーションを円滑にする「メール転送」の目的と仕組み(1/4)
https://dime.jp/genre/1872758/

あなたのPCにも潜んでるかも!? ユーザーを地味に邪魔する「グレーウェア」ってなに？(1/4)
https://ascii.jp/elem/000/004/243/4243824/?rss

AIを使わない日本人、注目の技術“自律型AI”で利用は広がるか(1/4)
https://topics.smt.docomo.ne.jp/article/ntv_news24/nation/ntv_news24-2025010409364234

なぜ英国は量子時計を開発しているのか(1/3)
https://ja.futuroprossimo.it/2025/01/perche-il-regno-unito-sta-sviluppando-un-orologio-quantistico/

英語で“話す”のはなぜ難しい？｜ビジネス英語の鬼が語る、話すための「脳の使い方」(1/4)
https://studyhacker.net/english-speaking-tokiyoshi

《各地でマイナ保険証パニック!?》「どう登録する？」「紛失したら？」などの疑問・簡単登録法について専門家が徹底解説(1/4)
https://j7p.jp/?p=129047

身近になったサイバー攻撃、それは誰でも攻撃者に！　～ランサムウェアに取って代わるDDoS攻撃？～(1/4)
https://news.yahoo.co.jp/expert/articles/c4d2b428cb6b954d1deed9eb2064862468cba888
Python_datetimeフォーマット


# Pythonの日時フォーマット指定子

`datetime.strftime()` と `datetime.strptime()` で使用できるフォーマット指定子の一覧です。これらを使って、日時を文字列に変換したり、文字列を日時に変換したりできます。

---

## 日付に関する指定子
| 指定子    | 説明                                     | 例                     |
|-----------|------------------------------------------|------------------------|
| `%Y`      | 西暦4桁                                  | `2023`                 |
| `%y`      | 西暦下2桁                                | `23`                   |
| `%m`      | 月（ゼロ埋め、01～12）                    | `01`（1月）            |
| `%B`      | 月名（英語）                              | `January`              |
| `%b`      | 月名の略称（英語）                        | `Jan`                  |
| `%d`      | 日（ゼロ埋め、01～31）                    | `05`                   |
| `%j`      | 年内の通算日（001～366）                  | `005`（1月5日）        |
| `%w`      | 曜日番号（0:日曜日～6:土曜日）             | `0`                    |
| `%A`      | 曜日名（英語）                            | `Sunday`               |
| `%a`      | 曜日名の略称（英語）                      | `Sun`                  |

---

## 時刻に関する指定子
| 指定子    | 説明                                     | 例                     |
|-----------|------------------------------------------|------------------------|
| `%H`      | 時間（24時間制、ゼロ埋め、00～23）        | `14`                   |
| `%I`      | 時間（12時間制、ゼロ埋め、01～12）        | `02`                   |
| `%p`      | 午前/午後（英語、ロケール依存）           | `AM` / `PM`            |
| `%M`      | 分（ゼロ埋め、00～59）                    | `30`                   |
| `%S`      | 秒（ゼロ埋め、00～59）                    | `45`                   |
| `%f`      | マイクロ秒（6桁、ゼロ埋め）               | `123456`               |
| `%Z`      | タイムゾーン名                           | `UTC` / `JST`          |
| `%z`      | UTCオフセット（±HHMM形式）               | `+0900`                |

---

## その他の指定子
| 指定子    | 説明                                     | 例                     |
|-----------|------------------------------------------|------------------------|
| `%c`      | ロケールに依存する日時表現               | `Tue Jan 3 14:30:45 2023` |
| `%x`      | ロケールに依存する日付表現               | `01/03/23`（英語圏）   |
| `%X`      | ロケールに依存する時刻表現               | `14:30:45`             |
| `%%`      | リテラルの`%`                            | `%`                    |

---

## 使用例

### 日時を文字列に変換（`strftime`）
```python
from datetime import datetime

now = datetime(2023, 1, 5, 14, 30, 45)

# フォーマットを適用
formatted = now.strftime("%Y-%m-%d %H:%M:%S")
print(formatted)  # 出力: 2023-01-05 14:30:45
```

### 文字列を日時に変換（`strptime`）
```python
from datetime import datetime

# 日時文字列
date_string = "2023-01-05 14:30:45"

# フォーマットに基づいて変換
parsed_date = datetime.strptime(date_string, "%Y-%m-%d %H:%M:%S")
print(parsed_date)  # 出力: 2023-01-05 14:30:45
```

---

これらのフォーマット指定子を利用することで、柔軟に日付や時刻を操作できます！
VRCでモデルを扱いたい初心者の為のUnityHubインストール(by初心者)

# 概要
virtualrealitychat(以下VRC)にて希望のモデルを改変・作成する場合、「Unity」を使用する事が多いのはこのページに来た人なら分かるだろう。
で、そのUnityを扱うためにはまずUnityをインストールしなければならない。
そしてUnityをインストールするにはUnityHubという各を管理するソフトをインストールする必要がある。
つまる所、「VRCでモデルを扱うにはUnityHubをインストールしなければならない」のだ。

# Unityはどこにあるのか
Unityは「Unity Technologies」が開発、配布しているソフトである。つまりUnity Technologiesのホームページに行けば入手できるのだ

## 具体的探索(Windows編)
1. まずはサイトを探す。GoogleでもBingでもDuckDuckGoでもなんでも良い、とにかく目の前の検索エンジンに「Unity」でも「ユニティ」とでも入力してみよう。すると下図のような検索結果が出てくるだろう。
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3978427/9a6a4b12-2441-7185-34a6-aafd072f6259.png)
 [この一番上にあるサイト](https://unity.com/ja)に移動するのだ。

２. 上記のサイトに移動するとこのような画面に移るだろう。そこで「Go Greate」の下にある「ダウンロード」をクリックしよう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3978427/46497dec-a169-9980-5ff2-3be5f8669884.png)
すると今度は[ダウンロードページ](https://unity.com/ja/download)へと飛ばされる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3978427/f17a4fe5-a75b-c6c2-8758-1c3c81ccde86.png)
我々初心者は素直に「ダウンロード」を選ぼう。我々が待ちに待ったUnityHubSetup.exeがついにPCにダウンロードされる。
「その他のUNITYプランを見る」には学生向けや大企業向けなど様々な面白いものが沢山並んでいるが、とてもじゃないが初心者には扱いきれないのでおいおい。

# UnityHubはどうインストールするのか
UnityHubをダウンロードしたからと言って、すぐにUnityが使える訳ではない。
昔の.zipなら無茶すればダウンロードしただけでもある程度動いたが、こいつは.exeなのだ。つまりこいつを動かさぬ限りUnityは我々のPCには現れぬのだ。

## 具体的インストール(Windows編)
1. まずPCのダウンロードフォルダを探そう。先程ダウンロードしてきた.exeが転がっているはずだ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3978427/35e182e5-9df1-ea96-4d09-05bf5714633b.png)
2. 次にこのUnityHubSetup.exeをクリックしよう。PCからのセキュリティ警告の後に、Unityのライセンス契約書が表示される。この契約書を**必ず頭から尻尾まで読んだ上で**「同意する」を押そう。読まずに被害を負っても誰も助けてくれない。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3978427/f4144ae9-8044-3228-e2fb-ec8abc0919e4.png)
3. 次にインストール先を選択しよう。このUnityというソフト、中々に容量を必要とする(3Dを処理するのだから当たり前か)。オオキイ=ストレージを有してる人や「フォルダ？ﾎｹﾞ-」という人はそのままインストールを押そう。そうでない人は、「参照」を押した上でお好きな場所に移しておこう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3978427/89d07277-a3fa-b76e-fb06-5f4201807936.png)
4. 後は自動でUnityHubSetup.exeがインストールしてくれる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3978427/0e0be369-cee5-c2e7-1abd-e82339600765.png)

# 完成
上記の事を一通り行い最終的に下のような画面が出たら大成功である。後は「完了」を押して念願のUnityを始めるのみだ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3978427/6af3559e-703f-4ea6-96ba-0cd022255d57.png)
インド・東南アジアIT企業から学ぶ、グローバル案件獲得のための戦略と実践

近年、日本のIT業界において興味深い変化が起きています。円安の影響もあり、日本のエンジニアの人件費が国際市場で「相対的に魅力的」と評価され始めているのです。そこで今回は、長年グローバル案件を獲得してきたインドや東南アジアの戦略を紐解きながら、日本企業が採るべき施策について考察していきます。

## なぜインド・東南アジア企業は米国案件を獲得できるのか

インドやベトナム、フィリピンなどの企業が欧米案件を継続的に獲得できている背景には、以下のような要因があります：

### 1. 20年以上の実績に基づく信頼性
これらの地域は1990年代後半から、欧米企業向けのオフショア開発拠点としての地位を確立してきました。長年の実績は、新規顧客獲得における大きな強みとなっています。

### 2. 高い英語コミュニケーション能力
・英語教育が社会に根付いている
・プロジェクトの要件定義から日常的なやり取りまで、英語でスムーズに対応
・時差を考慮したコミュニケーション体制の確立

### 3. コスト競争力とスケーラビリティ
大手IT企業では、数千人規模のエンジニアを柔軟にアサインできる体制を持っています。これにより、大規模プロジェクトにも即座に対応可能です。

## 日本企業が今すべきこと

### 1. グローバルスタンダードの開発プロセス導入
アジャイル開発やDevOpsの導入は必須です。ただし、日本の強みである品質管理との両立を図ることで、独自の価値を創出できます。

### 2. 言語とコミュニケーションの壁を超える
・バイリンガルPMの育成
・英語ドキュメントの標準化
・時差を考慮した勤務体制の整備

### 3. 差別化戦略の確立
コスト競争だけではなく、以下の強みを活かした戦略が有効です：
・緻密な品質管理
・確実な納期遵守
・丁寧なドキュメント作成

## 具体的なアクションプラン

1. 小規模案件からの実績作り
   - クラウドソーシングプラットフォームの活用
   - 英語でのケーススタディ作成
   - LinkedInやClutchでの情報発信

2. 営業・マーケティング体制の整備
   - 海外向けSNSの積極活用
   - オンラインイベントへの参加
   - 現地拠点の段階的な設立

3. 技術力の見える化
   - AIやIoT分野での独自技術開発
   - 研究機関との連携
   - 特許取得による技術力のアピール

今後、日本企業がグローバル市場で存在感を高めていくためには、これらの要素を総合的に強化していく必要があります。特に、日本の品質重視の文化と、グローバルスタンダードの開発手法を融合させることで、独自の競争力を築けるはずです。

#オフショア開発 #グローバル展開
オセロの盤面を認識し、可能な手を現実に投影してみた

# はじめに
12月に、私の所属する団体で、ピクシブさん協賛の部内ハッカソンが開催されました。
そこで私たちの作った"ボドゲアシスト"が、**学生メンター最優秀賞**、会場の全員が投票できる**アイデア賞**をいただきました。
この記事では、作成したモノの概要や使用技術について簡単に紹介をします。

# 動機
2024年10月、ニンテンドーミュージアムがオープンしました。
そこには、花札で遊べるこのような施設があります。
![nintendo_hanafuda.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3978344/3f5f30c9-50d4-4b47-bb58-2025ef2f836d.png)

https://museum.nintendo.com/exhibition/index.html

私はこれを見て、アナログゲームをアナログのまま遊びやすくする良い方法だと感じ、花札以外でもやりたいと思い、作ってみることにしました。
最初は認識もルールもシンプルなオセロでやってみることにしました。

# 概要
実際に遊んでいる動画です。

https://twitter.com/c0demattari/status/1871195143304598009

やっていることは、

1. カメラで盤面を撮影
1. OpenCVで盤面を認識
1. アシスト(次の手,裏返す石)の位置を計算
1. プロジェクターで投影

と、シンプルです。

ソースコードはこちら。

https://github.com/81-28/BoardGameAssistant

# 盤面認識
自分で方法を考えながら、こちらの記事を参考にしつつ、盤面を認識する方法を実装しました。

https://qiita.com/tanaka-a/items/fe6b95ae922b684021cc

色々模索するも、ほとんどこの記事と同じ方法でやったので、大きな違いのみを簡潔に述べます。

### 石の位置の特定
上記記事では、切り取った正方形のうち、緑色以外の場所を石とみなしていました。
その方法だと白と黒で認識精度に差が生まれてしまったので、私は白と黒を分けて処理して石の位置を特定しました。
ソースコードの97-114行あたり。

https://github.com/81-28/BoardGameAssistant/blob/2cbe94ca8692607be56cd8c513f122dad152bb62/opcv.cpp#L97-L114

### 石の色の特定
上記記事では、中心の周囲が狭い,広い場合でチェックしていました。
私は反射をある程度無視できる良い環境でやることを前提に、固定の四角形内の明るさのみで判断をしました。
(今考えると、これも白黒を分けた状態で処理してもよかった気もする。)

# オセロの処理
認識した盤面でオセロをするだけの簡単な処理、では不十分なんです。
画像認識が常に正しくできるとは限らない、手などのノイズも入るのでできない前提で、**遷移可能な盤面にしか進めない**ようにしています。
これもあり画像認識を少し簡易的に行っています。

具体的には、理想盤面を常に持っており、以下のような流れで処理をしています。

1. 最初の盤面を取得
1. 可能な手を表示
1. 置ける位置に石が置かれた時、その場合の理想盤面に更新
1. 現在盤面と理想盤面のと差分を表示
1. 理想盤面になったら、2に戻る

上記動画では分からないが、

- 置けない場合は自動でパス
- 両者置けない場合はゲーム終了

の処理も実装してあります。

# 課題
- 手やその影などがノイズとなって認識が難しい時がある
    - 上記の通り正しいオセロ以外は認めていないが、それでも誤認識してしまう時があるので石以外を弾きたい
    - (箸等でプレイすれば、最低限のノイズを実現できた)
- 同じ色の石が1つも無いと正しく認識できない
    - 相対的な面積で石を認識しているので、絶対的な面積で判断したい
    - 円の検出で石を認識できなかったので、円でも上手くやりたい

# おわりに
アナログとデジタルを融合させた、実際に触って楽しい作品を作ることができ、その上賞もいただいたので、たいへん充実したハッカソンとなりました。
ですが、今回OpenCVを初めて使用したのもあって、全体的な流れの計画や仕事の割り振りを上手くできず、すごく悔しく思っています。
今後このような機会があれば、そこで生かせるよう精進して参ります。

最後までお読みいただきありがとうございました。
DH鍵共有のシンプルな具体例

アリスとボブが秘密の暗号鍵を共有したい！でも、誰かに盗み見られる可能性のある通信路しかない...

そんな時に使えるのが、DH鍵共有です。

まず、アリスとボブは2つの数字pとgを決めます。これは公開情報なので、誰でも見ることができます。（ただし、pは大きな素数、gは g^x mod p が生成する値が十分に多い必要があります）

次に、アリスとボブはそれぞれ秘密の数字を選びます：
- アリスは数字a（これは誰にも教えません）
- ボブは数字b（これも誰にも教えません）

そして、それぞれが計算をします：
アリス：A = g^a mod p （この結果だけを公開します）
ボブ：B = g^b mod p （この結果だけを公開します）

アリスは受け取ったBを使って：K = B^a mod p を計算
ボブは受け取ったAを使って：K = A^b mod p を計算

すると、なんと！二人とも同じ数字K = g^(ab) mod p を手に入れることができます。

この数字Kこそが、二人だけが知っている共有の秘密鍵になるのです。

でも、なぜこれは安全なのでしょうか？

その秘密は「離散対数問題」という数学的な特徴にあります：
1. g^xという計算は簡単にできます（コンピュータでも高速に計算可能）
2. でも、g^xの結果からxを求めるのは、途方もなく難しいのです
   （現代のスーパーコンピュータを使っても、非現実的な時間がかかります）

つまり、通信を盗み見た人は：
- 公開値p, g
- アリスの計算結果A = g^a mod p
- ボブの計算結果B = g^b mod p
これらすべてを見ることができますが、それでも共有鍵K = g^(ab) mod pを求めることはできないのです！

この方法により、アリスとボブは誰かに盗み見られる可能性のある通信路でも、安全に秘密の鍵を共有することができます。現代のインターネットセキュリティの重要な基盤となっているのです。
LLMの未来展望：特化型と汎用型の共存シナリオを考える

# LLMの未来展望：特化型と汎用型の共存シナリオを考える

近年、人工知能の世界では様々な特化型LLMが次々と登場し、それぞれが独自の強みを持って市場に参入しています。その一方で、OpenAIやGoogle、Metaといった大手企業が提供する汎用LLMも着実に進化を遂げ、APIの整備やプラグイン機構の充実により、複数のLLMを状況に応じて使い分けることが容易になってきました。

## 現状分析

### 大規模LLMの進化
GPT-4やPaLM 2、Claudeといった大規模モデルは、膨大な学習済みパラメータと学習データを活用し、多岐にわたるタスクで高いパフォーマンスを発揮しています。特筆すべきは、プロンプトチューニングやLoRA（低ランク近似）などの技術により、限られた計算リソースでも特定用途向けに最適化できるようになったことです。

### 特化型LLMの立ち位置
医療や法律、金融など、規制の厳しい業界向けの特化型LLMは、独自の価値を保ち続けています。これは、学習データやファインチューニングの方針が一般的な大規模LLMとは本質的に異なるためです。また、オープンソースモデルは、研究や実験での自由度の高さが魅力ですが、対話品質などの面では大規模LLMとの差が顕著です。

## 技術的課題

### 処理効率とコスト
特化型LLMの最大の利点は、特定タスクに最適化されたモデルサイズによる効率的な推論処理です。一方、汎用LLMは柔軟性と引き換えに、モデルサイズの肥大化による計算コストと電力消費の増大が避けられません。ただし、クラウドインフラの発展により、この問題はAPIコストという形で抽象化されつつあります。

## 将来の展望

今後は、基盤となる大規模LLMの上で、企業独自のカスタマイズや特化機能の追加が主流となっていくでしょう。ただし、オンプレミスでの運用や特定の制約がある環境では、小型で効率的な特化型モデルが重要な役割を果たし続けると考えられます。

実務的な観点からは、「数社の大手が提供する汎用LLMをベースに、必要に応じて特化型モデルをAPI連携で組み合わせる」というアプローチが主流となっていく可能性が高いでしょう。

#LLM #AI技術動向
【Go言語入門】-メソッド編-

## はじめに
今回はメソッドについてまとめて見たいと思います。

## メソッド
ドットで呼び出せるものをメソッドという
```
type Test struct {
	X, Y int
}

func (v Test) capa() int {
	return v.X + v.Y
}

func main() {
	v := Test{2, 4}
	fmt.Println(v.capa())
}

// 出力結果
6
```

## コンストラクタ

```
type Test struct {
	x, y int
}

func New(x, y int) *Test{
return &Test{x,y}

}

func (v Test) Scale() int{
	return v.x * v.y
}

func main() {
	v := New(2,4)
	fmt.Println(v.Scale())
}

// 出力結果
8
```

##  Embedded
継承的な使い方ができる
```
type Test struct {
	x, y int
}

type Test2 struct {
	Test
	z int
}

func New(x, y, z int) *Test2{
return &Test2{Test{x,y},z}

}

func (v Test2) Scale() int{
	return v.x * v.y *v.z
}

func main() {
	v := New(2,4,5)
	fmt.Println(v.Scale())
}

// 出力結果
40
```

## interface

```
type People interface {
	Test()
}

type Person struct {
	Age int
}

func (p Person) Test() {
	fmt.Println(p.Age)
}

func main() {
	var taro People = Person{11}
	taro.Test()
}

// 出力結果
11
```

## タイプアサーションとSwitch Type文
```
func do(i interface{}) {
	switch v := i.(type) {
	case int:
		fmt.Println(2 * v)
	case string:
		fmt.Println("Hello" + v)
	case bool:
		fmt.Println(!v)
	default:
		fmt.Println(v)
	}
}

func main() {
	do(1)
	do("World")
	do(false)
}

// 出力結果
2
HelloWorld
true
```
エンジニアが選ぶデスクチェア

## はじめに
最近デスクチェアを購入。庶民派なので20-30万するものを選ぶのも気が引けて色々調べて購入したので記事にしようかなと。ブレイクタイムに読んでいただければ幸いです。

## 購入者(私)の希望
できるだけ安いやつがいいけど、腰痛持ちなので前傾チルトとかランバーサポートが欲しい

# 調べたブランドの感想(個人の感想です。)

## ハーマンミラー
値段が高いが性能が良くアーロンチェアの代表格
価格帯は8-30万程度
セイルチェアとかは結構魅力的...!

https://www.google.com/search?q=%E3%83%8F%E3%83%BC%E3%83%9E%E3%83%B3%E3%83%9F%E3%83%A9%E3%83%BC&oq=%E3%83%8F%E3%83%BC%E3%83%9E%E3%83%B3%E3%83%9F%E3%83%A9%E3%83%BC&gs_lcrp=EgZjaHJvbWUyCQgAEEUYORiABDIHCAEQABiABDIKCAIQABixAxiABDIHCAMQABiABDIHCAQQABiABDIHCAUQABiABDIHCAYQABiABDIHCAcQABiABDIHCAgQABiPAjIHCAkQABiPAtIBCDU0MTBqMGo3qAIAsAIA&sourceid=chrome&ie=UTF-8

## エルゴヒューマン
ハーマンミラーよりも値段が安い
価格帯は5-20万程度

https://www.ergohuman.jp/


## オカムラ
日本版のハーマンミラーって感じ
価格帯は8-30万程度

https://product.okamura.co.jp/ext/DispCate.do?volumeName=00001&hc=C&h1=%E3%83%81%E3%82%A7%E3%82%A2

## SHIHOO
中華チェア
価格帯は5-10万程度
値段安めだけど性能評価は結構いいイメージ

https://sihoooffice.co.jp/collections/all?campaignid=21305238648&adtype=&adgroupid=&keyword=&device=c&gad_source=1&gclid=CjwKCAiA-Oi7BhA1EiwA2rIu25NOYvleXwgbB1elGUHlF_rP9QutCMaiKPOLWzG_B-h5GcfTJSAiiRoCy3cQAvD_BwE

## COFO
SNS強めのチェアのイメージ
価格帯は4-10万程度

https://cofochair.jp/?_gl=1*a3u15v*_gcl_aw*R0NMLjE3MzYwOTE4NzEuQ2p3S0NBaUEtT2k3QmhBMUVpd0Eyckl1MjdJSENHdm5CSUwxeWN5NUp0YkQ1eXpoOGhBeHhkQTR6VlNhR1REWEwwSGo1cE1mQV9Ma3hSb0NJMTBRQXZEX0J3RQ..*_gcl_au*OTk4OTM5MTUxLjE3MzYwOTE4NzE.*_ga*MTU1NDczMDMwOC4xNzM2MDkxODcx*_ga_9M4KSGDWKN*MTczNjA5MTg3MS4xLjAuMTczNjA5MTg3MS4wLjAuMA..&_ga=2.239362563.1402405607.1736091871-1554730308.1736091871&_gac=1.250252916.1736091871.CjwKCAiA-Oi7BhA1EiwA2rIu27IHCGvnBIL1ycy5JtbD5yzh8hAxxdA4zVSaGTDXL0Hj5pMfA_LkxRoCI10QAvD_BwE


## FLEXISPOT
アメリカチェア
サポート充実してるイメージ
価格帯は2-10万

https://www.flexispot.jp/category/chair-all?gad_source=1&gclid=CjwKCAiA1eO7BhATEiwAm0Ee-D4z98ksin_GsJX3VCTWoBKPElstoSdCGh1mIgzxYKYNI7nEF4-lMRoC2LEQAvD_BwE

# まとめ
## 高級
ハーマンミラー
オカムラ
## ちょい高級
エルゴヒューマン
## 中価格
COFO
SHIHOO
FLEXISPOT

こんなイメージ。。今回はFLEXISPOTのC7 Proを選択しました。
理由は簡易的な前傾チルトとランバーサポートがついて6万程度だったからです

上記に挙げた物の中で悩みましたが、結局20-30万イスにお金かけるものか迷ってしまって。。。会社の椅子はハーマンミラーなので、届いたらそこと比較してみようと思います〜。

記事見た方のおすすめの椅子等も教えてくださいmm
ファイル命名規則から考えるコードベースの管理と探索性

# ファイル命名規則から考えるコードベースの管理と探索性

## はじめに

大規模なReactプロジェクトでは、数百のコンポーネントファイルを効率的に管理する必要があります。開発者は日々、これらのファイルを視覚的に認識し、その情報を解釈して意味を理解します。適切なファイル命名規則は、この課題を解決する重要な要素となります。

## Reactプロジェクトにおけるファイル命名の実践

### コンポーネントファイルの命名

Reactプロジェクトでは、コンポーネントファイルに特有の命名パターンが存在します。最も代表的な例が `.tsx` 拡張子の使用です。これは TypeScript と JSX の機能を組み合わせた特殊なファイル形式を示しています。

```typescript
// 推奨されるディレクトリ構造
src/
  components/
    Button/
      Button.tsx         // メインコンポーネント
      Button.test.tsx    // テストファイル
      Button.stories.tsx // Storybookファイル
```

### Storybookとの統合

Storybookを使用する場合、コンポーネントのストーリーファイルには `.stories.tsx` という拡張子を使用します。この命名規則により、以下の3つの情報が明確に示されます：

```typescript
// Button.stories.tsx
export default {
  title: 'Components/Button',
  component: Button,
} as Meta<typeof Button>;

export const Primary = {
  args: {
    variant: 'primary',
    children: 'Click me',
  },
};
```

## システマティックなファイル管理と探索

### プログラマティックな探索の実現

プロジェクトが大規模化すると、コマンドラインインターフェースを使用して特定のファイルを検索したり、一括で処理を行ったりする必要性が高まります。

```bash
# Storybookファイルの検索
find ./src -name "*.stories.tsx"

# テストファイルの一括実行
find ./src -name "*.test.tsx" -exec yarn test {} \;
```

### マシンリーダブルな命名規則の利点

ファイル名にタグのような意味を持つ情報を含めることで、以下のような利点が生まれます：

1. CI/CDパイプラインでの自動化
```yaml
# .github/workflows/component-checks.yml
name: Component Checks
jobs:
  verify-components:
    steps:
      - name: Test Storybook Files
        run: find . -name "*.stories.tsx" -exec yarn test-storybook {} \;
```

2. リンターでの命名規則チェック
```javascript
// .eslintrc.js
module.exports = {
  rules: {
    'filename-naming-convention': [
      'error',
      {
        'src/components/**/*.tsx': 'PascalCase',
        'src/components/**/*.stories.tsx': 'PascalCase.stories'
      }
    ]
  }
};
```

### セキュリティ考慮事項

ファイル命名時には、以下のセキュリティ考慮事項に注意が必要です：

- APIキーやパスワードなどの機密情報を含めない
- 内部的なビジネスロジックを示唆する名前を避ける
- 公開リポジトリでの社内コードネームの使用を避ける

## まとめ

適切なファイル命名規則は、開発者の理解しやすさだけでなく、プログラマティックな処理のしやすさにも大きく影響します。特に大規模なプロジェクトでは、こうした規則の重要性がより顕著となります。

### 実践のためのステップ

1. 既存プロジェクトのファイル命名パターンを分析する
2. チーム内で命名規則のガイドラインを作成する
3. リンターやCIでの自動チェックを導入する
4. 定期的なレビューと改善を行う

P.S.
この記事はボイスレコーダーに録音したものをClaudeに整形、意味の抽出、文章化してみた内容を試してみたものになっています。
【AWS SAP】SageMaker ノートブックインスタンスとは

# SageMaker ノートブックインスタンスとは
**SageMakerノートブックインスタンス**は、AWS上で機械学習モデルを開発・実験するための管理された**Jupyter環境**です。

:::note
**Jupyter環境**とは、コード、テキスト、グラフを統合的に扱える対話型で、データ分析や機械学習に活用されます。Pythonなど複数言語に対応したブラウザ上で動作する対話型のアプリケーションサーバです。
:::
【問題解決】ビジネスマン必須の考え方、仮説思考とゼロベース思考について理解する

今の時代、「問題解決」というのはエンジニアのみならず、ビジネスマンとして必須のスキルです。
問題解決をするにあたってどのように考えればよいのか、有名な方法を2つ紹介しようと思います。
その2つとは
・**仮説思考**
・**ゼロベース思考**
です。

この2つの考え方について「理解する」だけではなく「実践できる」ようになるため説明していこうと思います。
参考書籍は「問題解決プロフェッショナル」です。
# 仮説思考
``仮説思考``とは、限られた時間、情報しかなくとも、必ずその時点での結論を持ち、実行に移すということです。
現代の変化する速度は依然と比べて圧倒的に速いため、念入りに分析をして精度の高い結論を導き出すよりも、ざっくりでもいいので短時間である程度の結論を導き出すことが重要であるといわれています。
そんな``仮説思考``をするにあたって重要なポイントは以下の3つです。
* アクションに結び付く結論を常に持つ
* 結論に導く背後の理由やメカニズムを考える
* 「ベスト」を考えるよりも「ベター」を実行する

## アクションに結び付く結論を常に持つ
仮説思考をするにあたり、肝要なことはとにかく、**何がなんでも結論を出すこと**です。
そこで出した結論に対してなぜなぜ分析を繰り返すことで具体的にどのようなアクションを取ればよいのかという結論まで思考します。
始めは的を外してしまっても、常にアクションに結び付く結論を持つことで必ず精度が上がるようになります。

## 結論に導く背後の理由やメカニズムを考える
「背後の理由やメカニズム」とは問題となっている、あるいは将来問題になるだろうと思われる現象を作り出す、仕組みや構造のことです。
なぜなぜ分析を繰り返してアクションに結び付く結論を出すように心がけていると、結果的に背後の理由やメカニズムについて把握できるようになっています。
これはどういうことかといいますと、常にその場での結論を出そうとすると、その問題にどのような背景やメカニズムがあるのかを自然に考えてるようになるということです。
そのため、もし結論が間違っていたとしても、問題の背景やメカニズムが理解できているため、軌道修正は容易に出来るようになります。

## 「ベスト」を考えるよりも「ベター」を実行する
前述した2つのことから背後の問題やメカニズムについて把握、理解しながら結論を出すということは理解できたと思います。
しかし、この結論とは果たして一体どの時点での結論なのか疑問に思う人も少なくないと思います。
結論は**実行でに移せるレベルの結論**が出た時点です。
現代社会は冒頭でも述べました通り、目まぐるしく変化します。
そのためスピードが何よりも大事です。
「ベスト」な結論のために時間を費やし、何もできないよりかは現状に対して少しでも「ベター」な状況を想定し、実行に移すことが大切です。
繰り返しにはなりますが、その時点でのベターな結論に対し、問題があった都度軌道修正していけばいいのです。

# ゼロベース思考
``ゼロベース思考``とは「既成の枠」を取り外して考えるということです。
環境の変化が激しい昨今、「既成の枠」の中で問題解決につながる解はないと考えたほうが良いです。
そのゼロベース思考におけるポイントは2つあります。
* 自分の狭い枠の中で否定に走らない
* 顧客にとっての価値を考える
## 自分の狭い枠の中で否定に走らない
ビジネスの世界において複雑にいろいろなことが絡み合っているため、初めから全体像が見えていないことが多いです。
その時に現状の「既成の枠」に収束させる（解決が難しいと決めつける）のか、自分の狭い枠にとらわれず、「この課題を解決するための具体策は存在する」という前提で考えるのかでは雲泥の差があります。
## 顧客にとっての価値を考える
知らず知らずのうちに自分の立場や自部門の立場、あるいは自社での立場から考える習慣がついてしまっていると「既成のタガ」から抜けられなくなってしまっていることが多いです。
そこで大切になってくるのが「顧客にとっての価値を考える」ということです。
「顧客第一で考えるようにしている」という人も多いかもしれませんが顧客ファーストで実行できていなければ意味がないのです。
考えた結論を実行に移して初めて問題が解決する、解決に近づくということを覚えておきましょう。
ロジカルライティングの学びを整理

### **はじめに**
最近、『ロジカルライティング』という本を読みました。  
文章を書くとき、どうすれば読み手にしっかり伝わるか、そのために何を意識すべきかが具体的に書かれていて、とても勉強になりました。

この記事では、本で学んだ内容を自分なりに整理してまとめています。自分のための備忘録ですが、誰かの参考になれば幸いです。

---

### **ロジカルライティングとは？**
本の中では、ロジカルライティングを「論理的にわかりやすく書くスキル」と定義していました。  
言われてみれば当たり前ですが、意識していないと「何が言いたいのかわからない文章」になりがちです。例えば：

- **主張が曖昧**：「この商品は良いです」と言われても根拠がない  
- **根拠が不十分**：「なぜそう言えるのか？」が説明されていない  
- **読みづらい**：長すぎたり、話が飛びすぎて混乱する  

ロジカルライティングは、これらの問題を解決して「分かりやすく、主張の伝わる文章」を作るための技術です。

---

### **学んだ5つの基本ルール**
本を読んで、特に重要だと感じた5つのルールをまとめていきます。

#### **1. MECE（漏れなく、重複なく）**
MECE（Mutually Exclusive, Collectively Exhaustive）は、「漏れなく、重複なく」情報を整理するための考え方です。  

**仕事のタスクを整理する場合**  
- 緊急かつ重要なタスク  
- 緊急ではないが重要なタスク  
- 緊急だが重要ではないタスク  
- 緊急でも重要でもないタスク  

こうした整理をすると、次に何をするべきかが明確になる、という話です。

---

#### **2. Why so? / So what? の連鎖**
「Why so?（なぜそうなの？）」と「So what?（だから何？）」を繰り返して文章を確認すると、論理の飛躍を防げるという話が印象的でした。

**Why so? / So what? を使って文章を強化する**  
主張：「この商品は売れています。」  
- **Why so?**：「なぜ売れているのか？」→「低価格で品質が高いから」  
- **So what?**：「だから何？」→「市場で他商品と差別化でき、顧客満足度も高い」  

こうやって論理をチェックすることで、説得力のある文章が作れるようになります。

---

#### **3. 曖昧な言葉を避ける**
曖昧な表現は、読み手によって解釈が異なるため、なるべく具体的に書くことが大切だと学びました。

**【例】曖昧な表現を具体化する**  
- **Before**：「多くの人に支持されています」  
- **After**：「ユーザーの90%が満足していると回答しています」  

具体性があると、読み手に「なるほど、そうなんだ」と納得してもらいやすくなります。

---

#### **4. 具体的な言葉で説明する**
本では、抽象的な表現を避け、具体的に書くことで説得力が増すと説明されていました。

**【例】具体的な言葉を使う**  
- Before：「この機能は便利です」  
- After：「この機能を使うと、月末の報告書作成時間を50%短縮できます」  

数字や具体例を使うと、読者にメリットが伝わりやすくなります。

---

#### **5. 読者の問いに答える**
最後に大切だと感じたのが、「文章は読み手のために書く」という考え方です。  
「この文章が本当に読み手の知りたいことに答えているか？」を考えることが重要だと学びました。

**読者の疑問に答える**  
- 読者の問い：「この商品の利点は？」  
- 答え：「業務効率を30%向上させ、コストを20%削減できます。」  

## **コミュニケーション設計の重要性**
本の中で特に印象的だったのが、「文章を書く前に、どんなコミュニケーションを設計するかを考えるべき」という話でした。以下の4つのポイントが挙げられていました。

#### **1. 伝えたいメッセージを明確にする**
書く前に、「この記事で何を伝えたいのか」を一言で表現する。  
「このツールを使えば、業務効率が30%アップします！」というようにシンプルにまとめます。

#### **2. 読者に期待する反応を考える**
「読者にどう行動してほしいか？」も事前に考える。  
「商品の購入を検討してほしい」「無料お試しに登録してほしい」など。

#### **3. 読者の背景を考える**
読者がどんな立場で、何を求めているのかを考えることも重要です。  
例えば、忙しいビジネスパーソンなら、「短時間で読める」「ポイントを簡潔にまとめる」工夫が必要です。

#### **4. 書き手の立場を明確にする**
自分がどんな立場で文章を書いているかを意識することで、説得力や信頼感が増すという話も印象的でした。

## **文章を書くときのステップ**


1. **目的を明確にする**  
   - 誰に何を伝えるかを最初に決める。
2. **主張を先に書く**  
   - 結論を先に述べ、その理由や根拠を具体的に説明する。
3. **読者の目線で見直す**  
   - 「この文章で読者が疑問に思うことはないか？」をチェック。
4. **簡潔にする**  
   - 冗長な表現を削り、シンプルにまとめる。

## まとめ
今回、『ロジカルライティング』を読んで学んだことをまとめてみました。  
文章を書く際に、以下のポイントを意識すると、読み手に伝わりやすくなると感じました。

- MECEで情報を整理する  
- Why so? / So what? で論理をチェックする  
- 曖昧な言葉を避け、具体的に書く  
- 読者の疑問に答える  

文章を書くたびに試行錯誤が必要ですが、この本で学んだことを活かしながら、少しずつ改善していきたいと思います。

## 参考文献

https://www.amazon.co.jp/%E3%83%AD%E3%82%B8%E3%82%AB%E3%83%AB%E3%83%BB%E3%83%A9%E3%82%A4%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0-SOLUTION%E2%80%95LOGICAL-COMMUNICATION-SKILL-TRAINING/dp/4492555544
Dockerが応答しない・Docker Desktopが立ち上げられない時に試すこと

最近、dockerのコマンドを打っても突如応答しなくなることがあります。
それでdocker desktopを立ち上げ直そうと思っても、なぜか立ち上がらない…。

Macの再起動をすると正常に起動するのですが、結構な頻度で起こるのでそれも面倒。

私は1の方法で解決しましたが、他にもいくつか解決策見つけることができたので、引用で共有させていただきます。

## 方法1: アクティビティモニタからDockerを削除

強制終了には表示されない、バックグラウンドで動いてしまっているアプリもアクティビティモニタから強制終了できます。引用元とは違って応答なしの状態ではなかったのですが、同様の方法で解決しました。本当にありがとうございます！

https://qiita.com/chanchanco/items/bf0fe8b8e8c0cbf43732

## 方法2: Reset to factory defaults

よくこの状況になるけど今はdockerアプリを開けているよという人向け。設定画面でReset to factory defaultsのボタンを押すことで解決したとのこと。

このボタンがどこにあるのか、現在のバージョンでは分かりづらかったですが、右上の虫のようなマークを押すと出てきます。

![スクリーンショット 2025-01-05 21.27.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3902283/0615ac1b-591c-e586-cc72-1d58cd7a2347.png)


https://dev.classmethod.jp/articles/docker-desktop-for-mac-wont-start/

## 方法3: 容量を圧迫しているコンテナやイメージを削除してみる

自分の記事ですが、削除方法についてまとめてあるのでよろしければご覧ください。

https://qiita.com/helveticacode/items/29fc209399d8a81f1b23


同じような状況の方がいずれかの方法でうまくいくことを願います！
既存のリポジトリ構造でのReactプロジェクトをセットアップしたい

## はじめに

開発プロジェクトを進める中で、既存のリポジトリ構造に新しくReactプロジェクトを追加したい場合があります。この記事では、そのような状況での正しいセットアップ方法について説明します。

## 一般的な間違い

多くの開発者が陥りがちな間違いは、以下のようなコマンドを実行することです：

```bash
npx create-react-app my-app
```

このコマンドを実行すると、以下のような望ましくない二重のディレクトリ構造が作成されてしまいます：

```
your-repo/
└── my-app/
    └── my-app/
```

## 正しいセットアップ方法

### 1. プロジェクト構造の確認

まず、現在の作業ディレクトリ構造を確認します。例えば：

```bash
your-projects/
├── project-a/
├── project-b/
└── project-c/
```

### 2. 対象ディレクトリへの移動

新しいReactプロジェクトを作成したいディレクトリに移動します：

```bash
cd project-c
```

### 3. Reactプロジェクトの作成

現在のディレクトリに直接プロジェクトを作成するために、ドット（.）を使用します：

```bash
npx create-react-app .
```

または、Viteを使用する場合：

```bash
npx create-vite . --template react
```

### 注意点

- 対象ディレクトリは空である必要があります
- .gitフォルダーなどが既に存在する場合は、先に削除するか、別の方法を検討する必要があります
- プロジェクト作成後は、通常通り依存関係のインストールと開発サーバーの起動が必要です：

```bash
npm install
npm start  # create-react-appの場合
# または
npm run dev  # Viteの場合
```

## 結果として得られる構造

正しくセットアップされた場合、以下のような構造となります：

```
your-projects/
├── project-a/
├── project-b/
└── project-c/
    ├── node_modules/
    ├── public/
    ├── src/
    ├── package.json
    └── その他のReactプロジェクトファイル
```

## まとめ

既存のリポジトリ構造にReactプロジェクトを追加する際は、ドット（.）を使用して現在のディレクトリに直接プロジェクトを作成することで、不要なサブディレクトリの作成を防ぐことができます。これにより、クリーンで管理しやすいプロジェクト構造を維持することができます。
【Mac】ターミナルからObsidianのノートを開く方法

## `open`コマンドを使用する

`open`コマンドでObsidianのノートを開くにはObsidian URIを使用して以下のように実行します。

```terminal
open "obsidian://open?path=ノートへの絶対パス"
```

ノートのタイトルのみで開く場合にはvaultを指定します。

```terminal
open obsidian://open?vault=vault名&file=ノートタイトル
```

Obsidian URIの詳細については以下のページをご参照ください。

https://help.obsidian.md/Extending+Obsidian/Obsidian+URI

## `obsidian-cli`を使用する

まずは`obsidian-cli`をインストールします。

```terminal
brew tap yakitrak/yakitrak && brew install yakitrak/yakitrak/obsidian-cli
```

以下のコマンドを実行し、デフォルトのvaultを設定します。

```terminal
obsidian-cli set-default "{vault-name}"
```

設定が完了すると以下のコマンドでノートが開けるようになります。

```terminal
obsidian-cli open "{note-name}"
```

また、ノートのあいまい検索もできます。

```terminal
obsidian-cli search 
```

https://github.com/Yakitrak/obsidian-cli
ついに来た！新モデルAmazon Novaとは

先日AmazonBedrockの新しいモデルとして、re:Invent 2024 でAmazonNovaが発表されたので概要と試した結果を記載しようと思います！

# 概要
今回6つのモデルが発表されました。

・Nova Pro
・Nova Lite
・Nova Micro
・Nova Premier
・Nova Canvas
・Nova Real

### Nova Pro
精度、速度、コストのバランス重視

### Nova Lite
高速処理

### Nova Micro
テキスト処理に特化

### Nova Premier
複雑な推論タスクに特化（2025年第1四半期にリリース予定）

### Nova Canvas
画像生成に特化

### Nova Real
動画生成に特化

Amazon Novaモデルは現在、米国東部（バージニア北部）リージョンで利用可能で、Amazon Nova Micro、Lite、Proモデルは、米国西部（オレゴン）および米国東部（オハイオ）リージョンでもクロスリージョン推論を通じて利用できます。

## 料金
・テキスト生成モデルのオンデマンドおよびバッチ価格設定↓
![スクリーンショット 2024-12-19 15.39.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3840107/095cfc3e-fcc5-43c3-2a4b-336bc83e65a3.png)

・モデルのカスタマイズ（微調整）の価格↓
![スクリーンショット 2024-12-19 15.40.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3840107/442fcf57-7ab9-d70e-b45e-9816aa0f8700.png)


# 実際に試してみる
Amazon Bedrockのplaygroundを使用して実際に精度比較をしてみようと思います！
今回は、Nova Pro、Nova Lite、Nova Microで検証します。

パラメータは温度0.7、topP0.9で設定しています。

![スクリーンショット 2024-12-19 16.44.09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3840107/f1215ddb-881f-e0bb-cc19-603b30c39a41.png)

NovaProはできるだけ短く、なおかつ章ごとに題名をつけて起承転結わかりやすく桃太郎のシナリオを記載しています。
NovaLiteはできるだけ短くと命令していますが、だいぶ長い文章で返答があったので返答内容をこちらに記載します。
もちろんです。以下は日本民話「桃太郎」のシナリオを簡潔にまとめたものです。

```
**タイトル：桃太郎**

**登場人物：**
- 桃太郎
- 犬（黄色）
- 猿（赤）
- 雉（鶏）（青）
- 鬼（悪役）

**あらすじ：**

1. **出発：**
   - 高齢の夫婦が、川で見つけた大きな桃を食べる。すると、中から小さな男の子が現れる。
   - 夫婦は桃太郎と名付け、育てる。

2. **成長：**
   - 桃太郎は若くして勇敢な男に成長する。

3. **出発：**
   - 鬼が村を襲っていることを知り、桃太郎は鬼退治に向かう決意をする。

4. **仲間たち：**
   - 旅の途中で、犬、猿、雉と出会い、友となる。

5. **鬼ヶ島へ：**
   - 仲間たちと共に鬼ヶ島へ向かい、鬼たちと戦う。

6. **勝利：**
   - 桃太郎たちは鬼たちを倒し、宝を奪還する。

7. **帰郷：**
   - 桃太郎は育ての親と仲間たちと共に、平和を取り戻した村に帰る。

このシナリオは、桃太郎の冒険を簡潔にまとめたものです。伝統的な物語の要素はそのままに、エピソードを短くしています。
```
だいぶ長く記載してくれていますね。。。Proと同じく章ごとに題名を記載していますが、こちらとしては短い文章を期待していたので少し微妙な気がしますね。
ただ、生成速度としては1番早かったので、**高速で返答が欲しい際にはおすすめ**です。


Microは章立てもなく、愚直に説明文を記載しています。
ただ、結末のシーンが記載されていないこともあり、Proと比較すると物足りなさを感じます。

# 感想
最新のモデルを使用する時は、一度精度比較を実施してみてから、使用シーンに合わせてモデル選択をすることをお勧めします！
料理レシピ作成

<h1>料理レシピ作成LLM</h1>
Difyというオリジナルの生成AI作成に挑戦してみました。
Difyとは、プロンプトエンジニアリングからコーディングまで生成AIの柵瀬可能なツールです。

Dify: https://dify.ai/

<h2>行ったこと</h2>
・文字の入力設定
・生成AIの設定
・プロンプトエンジニアリング

<h3>プロジェクト作成</h3>

本記事では、ユーザーが設定を容易にできる「ワークフロー」にします。また、アプリ名は「FoodRecipe_LLM」にします。
<img src="https://ptera-publish.topaz.dev/project/01JGJEX2EC57MX7QGWJAZFTMH1.png">

プロジェクト画面です。
<img src="https://ptera-publish.topaz.dev/project/01JGJF74S8D8VM525Q1PB1M648.png">

<h3>文字の入力設定</h3>
プロジェクト画面の「開始」ブロックをクリックして、入力の設定を行います。
右側の「入力フィールド」の「＋」ボタンを押します。
<img src="https://ptera-publish.topaz.dev/project/01JGJFBNVCNHBWXWFKFE4CRX07.png">

入力フィールドの追加では、入力される変数名および文字の長さを設定できます。
<img src="https://ptera-publish.topaz.dev/project/01JGJFDA4G4XPJ6EWR78THDY5J.png">

<h3>生成AIの設定とプロンプトエンジニアリング</h3>
次、「開始」ブロックの横にある青い＋ボタンから、LLMを選択し、生成AIの設定を行います。ここでは、GPT4と設定し、入力するプロンプトの設定を行います。
今回作る生成AIは、料理のレシピに趣を向けているので、以下のように設定します。

#料理の名前

#料理の材料

#料理の作り方

#料理の楽しみかた


※料理の名前の下は、開始フィールドからの変数を使います。

<img src="https://ptera-publish.topaz.dev/project/01JGJFFR7E9QRNWRZ9NXXFNQQD.png">

<h3>結果の出力</h3>
最後、LLMからの答えを出すための設定を行います。
出力変数のところで変数名を設定し、出力内容をLLMからの返答にします。
<img src="https://ptera-publish.topaz.dev/project/01JGJFS1B0SX532AF3Y2Z4FT11.png">

<h3>LLMのテスト</h3>
「公開する」を押して、公開してアプリを実行してみましょう。
<img src="https://ptera-publish.topaz.dev/project/01JGJGH0WBYT3Z6KYYFWBZVKBC.png">

オムライスと試しに入力してみます。
![image](https://ptera-publish.topaz.dev/project/01JGJGKRDNT317DW4W8BQJKJGG.png)

そうすると、無事にレシピを作ってくれました。
右側が出力内容です。
![image](https://ptera-publish.topaz.dev/project/01JGJGMXWNPFT631EZ4BG1CEBF.png)


<h2>まとめ</h2>
正直、ChatGPTやClaudeで行ったプロンプトエンジニアリングで今まで解決してた内容を簡易的な状態で作りました。
また、料理の中でもアレルギーや独自の手順などこだわりを持った状態で作ることができると考えられます。
Oracle SQLの実行計画のオペレーションとは？（桃太郎に学ぶ抽象編）

## はじめに
この記事で説明すること：
- Oracle SQLのインデックスや実行計画に出てくるオペレーションの種類（データ探索方法）について概要を掴むための、ごく初歩的な説明
- 物理的なディスクI/Oに着目した、データ探索オペレーションの比較

説明しないこと：
- 実行計画そのものの表示の仕方
- 探索アルゴリズム周りの論理構造

以下の説明が分かりにくいな、もっと具体的な話を知りたいなと思った場合、具体編も併せて参照してください。

## 昔話をしましょう
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469936/e2002ec6-63eb-d961-9190-302f0dc73b8e.png)

昔々あるところに、インデックススキャン・シングルブロックREADおじいさんと、フルスキャン・マルチブロックREADおばあさんがいました。
シングルブロックREADおじいさんは、川から家までデータブロック…もとい「桃」を、一度にひとつしか運べません。一般的な老人です。
対してマルチブロックREADおばあさんは、桃を一度に8つ[^1]運べます。健康寿命が長いのは良いことです。

包丁は家にしかないので、川で拾った桃をその場で割って確かめることはできません。
桃を8つ持っているおばあさんの方が、桃をひとつしか持たないおじいさんより、川から家までの歩行速度は若干遅いですが、おじいさんが8往復するよりはうんと速いでしょう。

では、川を流れる桃が100個あったとして、以下の場合、おじいさんとおばあさんのどちらがより早く桃太郎（兄弟がいる場合はその全員）を見つけることができるのでしょうか？
- 桃すべてに桃太郎がいる場合（桃次郎、桃三郎…桃百郎までの兄弟なのでしょうか。あるいは、桃の中に双子や三つ子の桃太郎が入っているケースもあります。桃はレコード単体ではなくデータブロックを表すので、桃ひとつの中に複数レコードが存在する想定です。つまり、桃太郎は100人以上いるかもしれませんね）
- 桃ひとつに桃太郎ひとりがいる場合
    - どれに桃太郎が入っているか知っている場合
    - どれに桃太郎が入っているか分からない場合

### 桃すべてに桃太郎がいる場合（フルスキャンが有利）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469936/2813fb35-adbf-d927-1eb8-8a6cd908cc2b.png)

フルスキャン・マルチブロックREADおばあさんの桃太郎探索方法は、まず、100個の桃を川から家まで運びます。その上ですべての桃を包丁でパカパカ開けてみて、桃太郎の有無を判別します。
一度に8運べるおばあさんが100の桃を運び切るまでのI/O回数は13回ですね。一回一回の桃運び時間も重たそうです。特に、桃太郎が1人しかいない場合、「一度全部桃を家まで運び切る」という方法はかなり馬鹿げて聞こえますね。
でも、100の桃すべてが目当ての桃であれば、最初に全部運び切ってパカパカ開いていく方法は、効率的ですよね？
一方この場合におじいさんに桃太郎探索をお願いしてしまうと、おじいさんは一度にひとつしか桃を運べないため、100回のI/Oが発生してしまいます。

### 桃ひとつに桃太郎がいる、かつ、どれに桃太郎が入っているか知っている場合（インデックススキャンが有利）
インデックスがある場合、インデックススキャン・シングルブロックREADおじいさんは、家からすぐ川には行きません。一度別の川に行きます。その川にはこんな桃がピンポイントで流れています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469936/34b47b4d-facd-6a63-7bd6-433db6a0664f.png)

これを元に、おじいさんは桃太郎川へ行き、100の桃の中からピンポイントで桃太郎のいる桃（データブロック）を把握し、その桃だけを家に持ち帰るのです。
インデックス（索引）は、表領域とは異なる川（セグメント、あるいはデータファイルの集まり）に存在しますが、テーブルアクセスよりかなり高速なアクセスが可能です。また、おじいさんは桃をひとつしか家に持って帰らないため、運び切るまでのI/O回数は1回となり、とても効率的に桃太郎を探索することができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469936/eb264fea-6038-a012-c14f-5ca8c651ad41.png)

しかし、データに対して適切なインデックスを貼っていない場合、検索結果が1件にも関わらずフルスキャンが発生してしまう場合もあります。
どれに桃太郎が入っているか分からない場合がそれにあたります。実にもったいないですね。
おじいさんやおばあさんに無駄働きをさせないよう、インデックスを有効活用してください。

[^1]: なお、実際のマルチブロックREADで参照されるパラメータはDB_FILE_MULTIBLOCK_READ_COUNTです。デフォルト値や最大I/Oサイズはプラットフォームによって異なります。
https://docs.oracle.com/cd/E16338_01/server.112/b56311/initparams056.htm
【Go言語入門】-構造体編-

## はじめに
今回は簡単ですが構造体についてまとめておこうと思います。

## struct

```
type Test struct {
	name string
	age  int
}

func main() {
	v := Test{name: "Taro", age: 18}
	fmt.Println(v)
}

// 出力結果
{Taro 18}
```

個別にアクセス
```
fmt.Println(v.name)

// 出力結果
Taro
```

値の書き換え
```
v.age = 20
fmt.Println(v.age)

// 出力結果
20
```

型の順番通りなら明示的に記述しなくてもよい
```
type Test struct {
	name string
	age  int
}

func main() {
	v := Test{"Taro", 18}
	fmt.Println(v)
}

// 出力結果
{Taro 18}
```
Sakana AI が実現する進化的モデルマージ技術とその革新性

# Sakana AI が実現する進化的モデルマージ技術とその革新性

## はじめに

Sakana AIは、日本発のAIスタートアップとして、独自の「進化的モデルマージ」技術を用いた革新的なアプローチで注目を集めています。本記事では、この技術の詳細と、それによって実現される新しいAIモデル開発の可能性について解説します。

## 進化的モデルマージとは

### 技術概要

進化的モデルマージは、既存の複数のAIモデルを組み合わせて新しい基盤モデルを生成する革新的な手法です。この技術は以下の2つの主要なアプローチを組み合わせています：

1. レイヤーレベルでのモデルマージ
   - 複数モデルのレイヤー構造を進化的アルゴリズムで最適化
   - 人間の直感では発見できない効果的な組み合わせを自動探索
   - レイヤー間の相互作用を考慮した構造最適化

2. 重みレベルでのモデルマージ
   - モデルの重みパラメータを数値的に混合
   - 各レイヤーで異なる混合比率を適用可能
   - 進化的アルゴリズムによる最適な混合比の自動探索

### 技術的特徴

- 勾配ベースの訓練が不要
- 比較的少ない計算リソースで新モデルを生成可能
- 既存モデルの長所を効果的に組み合わせ

## 開発されたモデルと実績

### EvoLLM-JP
- 日本語特化型の大規模言語モデル
- パラメータ数：7B
- 日本語LLMベンチマークで最高性能を達成
- 70Bパラメータモデルの性能を上回る結果

### EvoVLM-JP
- 日本語対応の画像言語モデル
- 日本文化特有の知識への対応
- 日本語・画像ベンチマークでトップ性能

### EvoSDXL-JP
- 高速日本語画像生成モデル
- 4ステップの推論で画像生成
- 日本特有のスタイル対応

## 日本文化との融合

### Evo-Ukiyoe
- 浮世絵風画像生成モデル
- 伝統的な日本画の特徴を反映
- 桜、富士山、着物などの要素を表現

### Evo-Nishikie
- 墨絵の錦絵風カラー化モデル
- 古典資料の現代的な視覚化
- 伝統的な色彩表現の再現

## 技術の意義と今後の展望

### AIモデル開発の効率化
- 従来の訓練手法と比べて大幅なリソース削減
- 既存モデルの知識を効果的に活用
- モデル開発の民主化への貢献

### 応用分野の拡大
- 医療分野での画像診断支援
- 教育分野での個別指導支援
- エンターテインメントでの創造的表現

### グローバル展開
- 日本発の技術としての独自性
- 国際市場での競争力
- オープンソースによる技術普及

## まとめ

Sakana AIの進化的モデルマージ技術は、AIモデル開発に新しいパラダイムをもたらす可能性を秘めています。特に、効率的なモデル生成と日本文化との融合という特徴は、今後のAI開発において重要な示唆を与えるものと考えられます。

#sakana_ai #artificial_intelligence
AWS AIFとAWS MLAに合格までの学習記録

AWS Certified AI Practitioner（以降AIF）とAWS Certified Machine Learning Engineer - Associate（以降MLA）に合格してから大分時間が経ってしまっていますが、新資格なのでこれから受験される方と私自身の学習記録の意味も込めて残しておきたいと思います。

# 試験結果
先に試験結果を記載します。合格日から判断できる方もいるかもしれませんが両資格ともβ版のうちに合格しています。合格条件は後にありますがβ版でも通常と変わりませんでした。

### AIF
　合格日：2024年9月1日
 　スコア：725

### MLA
　合格日：2024年9月16日
 　スコア：729

どちらも合格点ギリギリでした。当時は受験者によるブログなどの事例に学習教材も少ないので適切な試験対策が取れていない。私自身が業務でAIを使っていないので深い知識を身に着けられていなかった。にもかかわらず勉強時間が少なかったのが原因かなと思っています。

# 概要
両資格の概要をまとめておきます。

### AIF
　概要：人工知能 (AI)、機械学習 (ML)、生成 AI の概念とユースケースに関する需要の高い知識を実証します。(サイト抜粋）
　試験時間：90分
　出題数：65問
　合格点：700点
　サイト：https://aws.amazon.com/jp/certification/certified-ai-practitioner/
 
### MLA
　概要：本番環境に ML を実装して運用可能にする技術的能力を実証するものです。(サイト抜粋）
　試験時間：130分
　出題数：65問
　合格点：720点
　サイト：https://aws.amazon.com/jp/certification/certified-machine-learning-engineer-associate/

# 勉強方法
どの様に勉強したか書いておきます。

### 共通
* サイトからDLできる試験ガイドを読み、出題範囲のドメインと対象AWSサービスを理解する。
* AWS Skill Builderにある模擬試験を解き、自身の理解度を把握する。また、解説を読んで理解する。
* SNSやブログで先に合格した方の投稿を読み、出題内容を想像して勉強内容の参考とする。
* 試験ガイドや模擬試験で明記された用語などについて、Googleスプレッドシートに表形式で整理して、隙間時間に繰り返し読み直して知識習得と暗記をする。

### AIF
試験ガイドの範囲にあるAWS公式ドキュメントを熟読する。下記の範囲に関連するドキュメントをよく読んでいました。
* タスクステートメント 1.3: ML 開発ライフサイクルについて説明する
* 第2分野: 生成AIの基礎
* 第4分野: 責任あるAIに関するガイドライン
* 第5分野: AIソリューションのセキュリティ、コンプライアンス、ガバナンス

### MLA
* Amazon SageMakerの公式ドキュメントを熟読する。
* Amazon SageMakerの学習目的で[実践-AWSデータサイエンス-―エンドツーエンドのMLOpsパイプライン実装-](https://amzn.to/407jd6W)をさらっと一読する。模擬試験で解けなかった、理解が浅いと感じた章は熟読する。
* Amazon Bedrockの学習目的で[Amazon Bedrock 生成AIアプリ開発入門 [AWS深掘りガイド] ](https://amzn.to/4g1EW6t)を前項と同じ要領で読む。

### 勉強時間
　AIF：10時間未満
　MLA：30時間未満

# 所感
AIF、MLA共に少ない勉強時間で合格できたのは日々AIのキャッチアップをしてつぎはぎでも知識をため込んでいたのが良かったのかなと思います。勉強開始時点で試験ガイドや模擬試験で何を問われるのか、単語の意味をある程度理解できていたので勉強時間の短縮になりました。とはいえ、なんとか合格できた程度なので今後も自己研鑽を通じて、より深く理解できるようにしていきます！！

両資格とも、2025 Japan AWS All Certifications Engineersの条件に含まれているので、目指している方に向けて参考になれば幸いです。
[2025 Japan AWS All Certifications Engineers クライテリアのお知らせ](https://aws.amazon.com/jp/blogs/psa/2025-japan-aws-all-certifications-engineers-criteria/)
日本のIT企業が海外案件を獲得するためのグローバル戦略 - コスト競争力と品質の両立

# 日本のIT企業が海外案件を獲得するためのグローバル戦略 - コスト競争力と品質の両立

近年、日本とアメリカのITエンジニアの賃金格差が話題になっています。この記事では、その格差を逆手に取り、日本の中規模IT企業が海外で競争力を確立するための具体的な戦略について解説します。

## はじめに

アメリカのシリコンバレーでは、ソフトウェアエンジニアの年収が1,000万円から2,000万円以上になることも珍しくありません。一方、日本の同等スキルのエンジニアの年収は、その半分から3分の1程度にとどまることが多いのが現状です。

## 日本企業の競争優位性

### 1. コストメリットと品質の両立
- 日本のエンジニア人件費は相対的に割安
- 高品質な開発・運用体制
- きめ細やかな顧客対応

### 2. 特定領域での専門性
- 工場向けIoTソリューション
- ヘルスケアSaaS
- AIを活用した画像解析
- セキュリティ重視の企業向けソリューション

## グローバル展開のための具体的戦略

### 1. アジャイル開発の導入
- ウォーターフォールとのハイブリッド運用
- 小規模チームでの実験的プロジェクト
- 迅速なフィードバックサイクル

### 2. グローバル人材の確保
- バイリンガルPM・エンジニアの採用
- リモートワークを活用した海外人材の活用
- 多様性を重視した組織作り

### 3. サブスクリプションモデルの展開
- 継続的な収益構造の確立
- 顧客との長期的な関係構築
- データ分析に基づく改善サイクル

## 実践的なアプローチ

1. まずは国内で実績を積む
2. 小規模な海外案件から着手
3. 段階的に規模を拡大
4. パートナーシップの構築

## まとめ

日本のIT企業は、「高品質×コスト優位」という強みを活かしつつ、アジャイル開発やグローバル人材の活用を進めることで、海外市場での競争力を確立できます。特に製造業やセキュリティ重視の分野では、日本企業の強みが活きる可能性が高いと考えられます。

#グローバル戦略 #IT企業
【JavaGold】その他

# その他
### ListとSetの違い
#### List
* 要素の重複を許す。

#### Set
* 要素の重複を許さない。

### 抽象クラスとインタフェースの違い
#### 抽象クラス
* インスタンスフィールドを定義できる。
* protectedなメソッド定義可。
* privateなメソッド定義可。


#### インタフェース
* インスタンスフィールドを定義できない。
* protectedなメソッド定義不可。
* public、private、staticなメソッド、抽象メソッド、デフォルトメソッドは定義可。
* finalで修飾されたオーバーライドできないメソッドは定義できない。

#### Listについて
* java.util.Listインタフェースに定義されている、List型のインスタンスをへの参照を戻すstaticメソッドは、すべて「変更不可能なリスト」を生成している。

```java:実装例
List<Integer> a = new ArrayList<>();
a.add(1);
List b = List.copyOf(a);
b.add(2);
```
```:実行結果
実行時に例外がスローされる
```

#### オートボクシングについて
プリミテイブ型からラッパークラスへ変換。
※ボクシングができるのは、ラッパークラス型とプリミティブ型の間だけ。

#### プリミティブ型
boolean, char, byte, short, int, long, float, doubleの8つ

#### ラッパークラス型
Boolean, Character, Byte, Short, Integer, Long, Float, Double

#### replaceAll(UnaryOperator<E> operator)
実装メソッド内の引数としてList内の要素を一つずつ受け取り、戻り値で上書き。

* Listの全ての要素に文字列を追加したい。
* Listの全ての要素の値を二倍にしたい
こういったリスト内の全ての要素の値を変更したい場合はreplaceAllメソッドを利用。

```java:実装例
public class Main {
	public static void main(String[] args) {
		List<Integer> List = new ArrayList<>(Arrays.asList(1,2,3,4,5,6,7,8,9,10));
		List.replaceAll(i -> i * 2 );
		System.out.println(List);
    }
}
```
```:実行結果
2, 4, 6, 8, 10, 12, 14, 16, 18, 20
```

### java.lang.System
#### in
* 標準入力を扱うInputStream型のstaticなフィールド。
* System.inは、標準入力ストリームである。このストリームは常に開いている。

#### out
PrintStream型のstaticなフィールド。

#### setIn
ストリームを置き換えることができる
【JavaScript】分割代入について

# 分割代入とは
ある配列やオブジェクトの要素を変数として抽出すること。

# 例
**配列**
```main.js
const [a, b, c] = ["配列1", "配列2", "配列3"];
console.log(a);
//配列1
console.log(c);
//配列3
```
:::note info
配列の場合は、要素の順番ごとに変数を宣言する。
:::

**オブジェクト**
```main.js
const {x, z} = { x: "オブジェクト1", y: "オブジェクト2", z: "オブジェクト3" };
console.log(x);
//オブジェクト1
console.log(z);
//オブジェクト3
```
:::note info
オブジェクトの場合は、宣言する名前がそれぞれのプロパティ名に対応する。よって宣言する順番は関係ない。
:::

# 関数を組み合わせた例
**配列**
```main.js
const array = ["Japan", "Tokyo", "Shinjuku"];
const fnArray = ([country, state, city]) => {
    console.log('country: ${country}');
    console.log('state: ${state}');
    console.log('city: ${city}');
};
fnArray(array);
//country: Japan
//state: Tokyo
//city: Shinjyuku
```

**オブジェクト**
```main.js
const obj = { country: "Japan", state: "Tokyo", city: "Shinjuku"};
const fnObj = ({ country, state, city }) => {
    console.log('country: ${country}');
    console.log('state: ${state}');
    console.log('city: ${city}');
};
fnObj(obj);
//country: Japan
//state: Tokyo
//city: Shinjyuku
```

**終わり**
Rails 8: strong parametersの新しい`params.expect`の使い方を読んだのでアウトプットをする

## 背景

- Rails8が登場して`params.expect`を使用する機会があったので、色々調べたアウトプットをします

## `params.expect`とは

Rails7では`params.require`や`params.permit`を使用して、ストロングパラメータの実装を行なっていましたが、`params.expect`はそれよりコード短いし、セキュリティ的にも良さげだよ

というメソッドです

## 使い方

従来のRailsでは、ストロングパラメータをコントローラの中で定義するときに下記の感じで書いてました

```users_controller.rb
  def create
    @user = User.new(user_params)

    if @user.save
      redirect_to users_path
    else
      render :new, status: :unprocessable_entity
    end
  end

  private

  def users_params
    params.require(:user).permit(:name, :email)
  end
```

Rails8ではこんな感じでかけます

```users_controller.rb
  def create
    @user = User.new(user_params)

    if @user.save
      redirect_to users_path
    else
      render :new, status: :unprocessable_entity
    end
  end

  def update
    # 省略
  end

  private

  def users_params
    params.expect(user: [:name, :email])
  end
```

短いすね

## なぜ`expect`の方が良いのか

### 1.パラメータを改ざんされた時、返すエラーが違う

従来通り`params.require`や`params.permit`を使用した場合

```ruby
  def users_params
    params.require(:user).permit(:name, :email)
  end
```

パラメータを少しいじって、こんな感じのリクエストをサーバーに送信したとします。

```
# 更新
PATCH /user/1?user=hoge
```

`"500 Internal Server Error"`が返ってきます

Rails8から出た`params.expect`の場合は

```ruby
  def users_params
    params.expect(user: [:name, :email])
  end
```

`400 Bad Request`を返します。

#### 400と500どっちもエラーなのに、500はなぜゆえダメなのか

- 500エラーがダメな理由

1. **ユーザー体験の低下**: サーバー内部の問題を示すため、クライアントに対して具体的なエラーメッセージを提供されない。どこで何が起きてるかわからなくなる
2. **セキュリティリスク**: サーバー内部の問題を示すため、悪いやつがその脆弱性を攻撃してくるかも

- 400エラーが良い理由

1. **ユーザー体験の向上**: 具体的にどこが悪いのか教えてくれる。どうすれば解決するのかがわかる状態
2. **セキュリティの向上**: クライアントのリクエストが不正なので、サーバー側の問題が露呈しにくい

※ `permit require`と`expect`を比較した時の話です

### 2.パタメータの型チェックをしてくれる

従来の`params.permit`では型のチェックをしてくれませんでした

仮に`users_params`を下記に設定したとします。

```ruby
  def users_params
    params.permit(user: [:name])
  end
```

意図としては、`:name`は配列のみを許可したい感じです。

しかし、これだと

```ruby
@user = User.new(user: { name: 'hoge' })
```

これでも通ってしまいます。

ではRails8の`params.expect`では

```ruby
  def users_params
    params.expect(user: [[:name]])
  end
```

「二重配列」構文で明示的に配列のみを指定することで、配列だけを許可するという書き方ができます。

仮に

```ruby
@user = User.new(user: { name: 'hoge' })
```

を渡してあげると`"400 Bad Request"`が出るようになります。

## 感想

- 短いコードかつ、セキュリティが高くなる方が良いに決まっているので、こっち使おうと思った。
- 意外と知らないことがたくさんあったのでボリュームあった

## 参考
https://techracho.bpsinc.jp/hachi8833/2024_11_12/146280

https://railsguides.jp/v8.0/action_controller_overview.html#strong-parameters

https://qiita.com/maabow/items/3dc6afc8813c43bab429
Hugging Face上で急増するAIモデル数の背景を探る

# Hugging Face上で急増するAIモデル数の背景を探る

## はじめに

Hugging Faceは、AIモデルやデータセットを共有・活用するためのオープンソースプラットフォームとして、特に自然言語処理（NLP）の分野で重要な役割を果たしています。2024年9月時点で、実に100万を超えるAIモデルが公開されており、その数は今なお急速に増加を続けています。

本記事では、なぜこれほど多くのモデルが公開されているのか、その背景要因を詳しく探ってみたいと思います。

## AIモデル増加の主要因

### 1. オープンソースコミュニティの活発な活動

Hugging Faceの特徴は、AI研究者や開発者が自由にモデルやデータセットを公開・共有できる環境を提供していることです。このオープンな環境が、以下のような効果をもたらしています：

- 研究成果の迅速な共有と検証が可能
- コミュニティ間での知見の共有が活発
- 新しいアイデアの実装と公開が容易

### 2. モデルのファインチューニングによる特化型モデルの増加

事前学習済みの大規模言語モデル（LLM）を基にして、特定のタスクやドメインに適応させるファインチューニングが広く行われています。

例えば：
- 特定の産業分野（医療、法律など）に特化したモデル
- 特定の言語や方言に最適化されたモデル
- 特定のタスク（要約、翻訳など）に特化したモデル

これらの特化型モデルが、全体のモデル数の増加に大きく寄与しています。

### 3. モデルマージによる新しいモデルの創出

既存のモデルを組み合わせることで、新たな特性を持つモデルを生成する「モデルマージ」という手法も、モデル数増加の要因となっています。

モデルマージのメリット：
- 異なるモデルの強みを組み合わせられる
- 新規モデルの開発コストを削減できる
- 既存モデルの知識を効率的に活用できる

### 4. 機械学習分野の急速な発展

AI技術の進展に伴い、研究機関や企業が次々と新しいモデルを開発・公開しています。Hugging Faceは、これらのモデルを集約・提供するプラットフォームとして機能しており、結果としてモデル数の増加を加速させています。

## 今後の展望

このように多様なモデルが公開されている状況は、AI開発者にとって以下のようなメリットをもたらします：

- 目的に応じた最適なモデルの選択が可能
- 既存モデルを活用した効率的な開発
- 様々なアプローチの比較検討が容易

一方で、これだけ多くのモデルが存在することで、適切なモデルの選択が難しくなるという課題も出てきています。今後は、モデルの評価や比較を効率的に行うための仕組みづくりも重要になってくるでしょう。

## まとめ

Hugging Face上でのAIモデル数の急増は、オープンソースコミュニティの活性化、ファインチューニングの普及、モデルマージ技術の発展、そして機械学習分野全体の急速な進歩という複数の要因が組み合わさった結果といえます。

この傾向は今後も続くと予想され、より多様で高性能なモデルが次々と公開されていくことでしょう。開発者は、これらのリソースを効果的に活用することで、AIプロジェクトの効率化や性能向上を図ることができます。

#huggingface #機械学習