OmniAICreator/Qiita-1.07M huggingface dataset:
GitHub Pagesを使ってサイトを公開する方法

# はじめに
GitHub Pagesって何？
最初は名前を聞いた時、何がどうやってこうなっているのか理解で来ていませんでしたが、
やはりこの道で勉強している方たちのブログは本当に有益なものばかりで、あっという間に解決することができました。私がGithub Pagesを使ってサイトを公開するときに使用した参考文献を下記に添付いたします。

---
# 参考文献
[GitHubnの使い方まとめ](https://qiita.com/snow_swallow/items/631bbceabbb953da2646)

---


## 6. Github Pagesの公開設定をする
Settingタブを選択します。
![スクリーンショット 2024-12-09 10.39.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3869837/fc85cb46-f9a4-cbc2-31d0-d20f5ab62782.png)


左サイドバーの `Pages` を選択。
![スクリーンショット 2024-12-09 10.41.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3869837/7441e08b-8a9a-bbe2-1c21-08977e3fa88f.png)

Noneを選択し、公開用ブランチを選択し`Save`を選択。
![スクリーンショット 2024-12-09 10.42.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3869837/fa4fd89e-14b4-0bb9-96e8-7bfdd0f3d1b1.png)

しばらく待つと、公開したWebページのURLが表示されサイトを公開できるようになる。

# もし作成したファイルを削除してしまった場合

もし一度作成したURLを削除してしまった場合は一度`main`で`Save`していたものを
`None`で`Save`する必要があります。
スクラムQAのいろいろなスタイル

今日はエッセイです。

スクラムにおけるQAフェーズは、いろいろなパターンが考えられますが、
自分の経験のなかでは、
- QAテストと開発テストを同時に行う場合
- 開発終了してからテストスプリントが入る場合
- 開発が行うテストをQAとしている場合

などがありました。
ここでは、それぞれのパターンでどういう特徴があったか
ご紹介したいとおもいます。


![QABIG.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/156898/390eb722-0756-d678-dd8c-e67f132131bc.gif)



## QAテストと開発テストを同時に行う場合
スクラムチームにQAが入り込んでテストを行うスタイルです。
- メリット：　仕様を同時に把握するため、
- デメリット：　
仕様変更などのコントロール業務が発生し、QAとしての時間効率疑問が落ちやすい
テスターにスキル的バックグラウンドの要求が高い

## 開発終了してからテストスプリントが入る場合
テストの形式としては、ウォーターフォールと同じく、実装がひとまず完了してから
テストを始めるスタイルです。
- メリット：　仕様が固まっているので、テストが作りやすいこと
- デメリット：　開発終了からテストを書くと、スケジュール的な無理が発生しやすい

などです。このため、どうやって仕様を開発とQAで共有するかが、課題になりやすい
特徴があります。

## 開発が行うテストをQAとしている場合
QAが入らない場合の普通のスクラムです。


## まとめ
いずれのスタイルも、一長一短、というところですが、チームにあってるやり方が
どれになるか考えながら、すすめることになると思います。
Render.comで独自ドメイン（Xserver）を設定したらSSL更新でつまづいた件

# はじめに
- Render.comを利用して、Nuxt3で作成したWebアプリをデプロイ
- Xserverで取得した独自ドメイン（無料SSL化済）を設定
- しばらく正常に動作していたが、突然Xserver側から「SSL更新に失敗した」との通知を受け取る
- 手動でSSLを更新しても失敗した
:::note warn
- 私は趣味でWEB開発を行っている超素人です。
- そのためプロにとってはかなり初歩的な内容、また誤った情報が含まれる場合がございます。
- その際は暖かく指摘いただけると、嬉しいです。
:::
# 結論
:::note info
__結論__
- Render.comでデプロイする場合は、Xserver側でSSL化する必要はない
:::
# 確認したこと
[Custom Domains on Render
|Rener.com](https://render.com/docs/custom-domains)
上記記事を参考に、Render.comの独自ドメイン設定の見直しとXserverのドメイン設定の見直しを行いましたが解決せず...

`nslookup [ドメイン名]`をターミナルで叩くと実際に設定されているDNSなどが見られるようなので実行。

なんのこっちゃわかりませんが、結果を見る限り正しく設定されているよう。
(GPTもそう言ってた）

# Render.comでは、勝手にSSLされることを知らなかった
ここで下記の記事を発見。

[Renderで独自ドメインを使用したら、1日くらい待ってTLS/SSL証明書が発行される](https://giwanote.hatenablog.jp/entry/2023/07/18/205648)

これによると
>お名前.comで独自ドメイン取って、Renderのドキュメントに従って設定した。
"You get free TLS certificates for the onrender.com subdomain for your service, as well as the custom domains you add to it, including wildcard domains."
この記述の通り、無料のTLS証明書がonrender.comのサブドメインにも発行される。

とあり「もしやSSLできるのドメイン会社だけではない？」という超初歩的なことに気づく。（基礎学習大事ですね。）

ブラウザの鍵マークから発行者を調べると、発行元が`Google Trust Services`となっているのを確認。
所有しているXserver独自ドメインが設定されている別のサイトを確認すると、こちらは`Let's Encrypt`とある。

__こ　れ　や__

# まとめ
基礎学習が大事なんだろうと認識しました...
趣味とはいえ、基本情報とか勉強したほうが体系的に学べるのかなぁ

本記事が誰かの役に立つと嬉しいです。

# 参考記事
[Renderで独自ドメインを使用したら、1日くらい待ってTLS/SSL証明書が発行される](https://giwanote.hatenablog.jp/entry/2023/07/18/205648)
PythonのRequestsで認証付きプロキシを使う方法を複数紹介

PythonのRequestsライブラリで認証付きプロキシを使う方法は複数あります。
状況によって使い分けが必要なので今回の記事でまとめました。

## URLに認証情報を入れる方法

一番オーソドックスな方法です。

ただ、Basic認証をサポートしているプロキシサーバのみで可能で、Digest認証などでは別の方法を選ぶ必要があります。

```python
import requests
proxies = {
  "http": "http://user:pass@proxy.example.com:8080",
  "https": "http://user:pass@proxy.example.com:8080",
}
response = requests.get("http://example.com", proxies=proxies)
print(response.text)
```

## HTTPヘッダーに認証情報を入れる方法

HTTPリクエストヘッダーの方に認証情報を入れる方法です。
この方法ではBasic認証だけでなく、Digest認証などセキュリティが高い方法を選択することもできます。

### Basic認証

Basic認証の情報をHTTPヘッダーに含める必要がある場合は下記のようにします。
ただ、この方法はUnicode文字が認証情報含まれている場合うまく動きません。
その場合は、後述する「自力でHTTPヘッダーに認証情報を入れる方法」を検討してください。

```python
import requests
from requests.auth import HTTPProxyAuth

proxies = {
  "http": "http://proxy.example.com:8080",
  "https": "http://proxy.example.com:8080",
}
auth = HTTPProxyAuth("user", "pass")

response = requests.get("http://example.com", proxies=proxies, auth=auth)
print(response.text)
```

### Digest認証

Digest認証はBasic認証に比べて認証情報をハッシュ化するのでセキュリティが向上した方式です。
こちらの認証方法を行う必要がある場合は以下のようにします。

```python
import requests
from requests.auth import HTTPDigestAuth

proxies = {
  "http": "http://proxy.example.com:8080",
  "https": "http://proxy.example.com:8080",
}
auth = HTTPDigestAuth("user", "pass")

response = requests.get("http://example.com", proxies=proxies, auth=auth)
print(response.text)
```

ほかにRequestsではBearer認証などにも対応しています。


## 自力でHTTPヘッダーに認証情報を入れる方法

Requestsでは認証情報にUnicode文字が含まれている場合エラーになります。
その場合、認証ヘッダーを自力で構築する必要があります。

```python
import requests
import base64

proxies = {
  "http": "http://proxy.example.com:8080",
  "https": "http://proxy.example.com:8080",
}

auth = "user:pass"
encoded_auth = base64.b64encode(s.encode()).decode()
headers = {
  "Proxy-Authorization": f"Basic {encoded_auth}",
}

response = requests.get("http://example.com", proxies=proxies, headers=headers)
print(response.text)
```
grdcの表示色を変更出来る様にした話

# grdcとは
grdc(6) grand digital clock はターミナル上に大きなデジタル・クロックを表示出来る curses アプリケーションです、以前は /usr/games 以下にあった様なのですがいつの頃からか /usr/bin に標準でインストールされる様になった様です。
# 経緯
そのままターミナル上で grdc と実行するとデカイ(笑)デジタル・クロックが赤で表示されます。

![2024-12-09_8.47.57.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3584428/e4902fc8-f2c0-a78c-20c5-6ec082de6294.png)

ただ man でも確認しましたが表示は赤表示のみで表示色を変更する様なオプションは無い様です、赤表示って言うとエンジニアとしてはどうもエラー表示の様で何と無く気持ちが悪いので何とかならないかと探してみると、やはり頼りになるのはソースファイルと言う事で /usr/src/usr.bin/grdc 以下の grdc.c を眺めてみると、
```grdc.cから一部抜粋
    if(hascolor) {
                start_color();
                init_pair(1, COLOR_BLACK, COLOR_RED);
                init_pair(2, COLOR_RED, COLOR_BLACK);
                init_pair(3, COLOR_WHITE, COLOR_BLACK);
                attrset(COLOR_PAIR(2));
     }
```
と言う箇所で foreground color, background color をハードコードで設定している事が判りました 、ダメじゃん (^_^）。

と言う事で設定箇所は判りました init_pair() に渡しているパラメータを変更すれば表示色を変える事が出来る事は判ったので COLOR_RED を適当な値に設定すれば良いのですが、先々ターミナルの環境を変更した場合 (筆者は黒バックで使っています) に再度ビルドすると言うのもアレなので環境変数から表示色を変更出来る様に以下のパッチを作成しました。

+ パッチへのリンク
[grdc-patch.txt](https://github.com/tika5210/grdc-patch/blob/5f6b239d6bf4045a434aeec4c66921143d60cbca/grdc-patch.txt)

# ビルド方法
適当なサブディレクトリを作成して、上記パッチのダウンロードとオリジナルソースをコピーする。
```
$ mkdir my-grdc
$ cd my-grdc
$ cp /usr/src/usr.bin/grdc/grdc.c .
$ cp somewhere/grdc-patch.txt .
# ソースにパッチを適用する
$ patch -p0 <grdc-patch.txt
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /usr/src/usr.bin/grdc/grdc.c	2023-12-02 20:06:31.413163000 +0900
|+++ grdc.c	2024-09-05 11:45:10.260641000 +0900
--------------------------
Patching file grdc.c using Plan A...
Hunk #1 succeeded at 18.
Hunk #2 succeeded at 44.
Hunk #3 succeeded at 111.
Hunk #4 succeeded at 279.
done
# エラーが無ければOK
$ cc -O2 grdc.c -lncursesw -o my-grdc
# エラーが無ければOK
```

# 実行してみる
```
$ GRDC_COLOR=cyan ./my-grdc
```

![2024-12-09_8.50.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3584428/a53d43ae-244c-70e4-e6ea-a87b765c02e4.png)

いちいち環境変数を指定するのは面倒だと言う場合は .shrc 等で環境変数に設定しておくか alias 等を設定しておくのが良いのでは無いかと思います。

環境変数 GRDC_COLOR が設定されていない場合はオリジナルと同じ様にデフォルトで赤表示となります。

# 最後に
grdc はかなり昔からあったアプリケーションの様ですが /usr/games 以下にあった為にソースを展開する事があまり無かったので、その存在を全く知りませんでした (筆者の個人的な感想です)、/usr/bin 以下のアプリケーションを探していて偶然に発見しました他にも普段は気が付かない同様のアプリケーションがあるかも知れません、UNIX系OSは奥が深いです...。
WindowsでlabelImgが起動しない場合の対処法

# ■実行環境
Windows11

# ■経緯
3ヶ月ぶりに`labelImg`でアノテーションを行なおうとしたが、起動せず。3か月前はコマンドプロンプトで`labelimg`コマンドを打てば起動できたはずだが、今回は下図のようなエラーとなり、起動しなかった。

```Traceback (most recent call last):
  File "C:\Python312\Lib\site-packages\labelImg\labelImg.py", line 5, in <module>
    import distutils.spawn
ModuleNotFoundError: No module named 'distutils'
```
要は`distutils`がないことによるエラーだった。

# ■原因と解決方法
原因はPython3.12以降、`distutils`が廃止されたことである。
`setuptools`をインストールすれば`distutils`がインポート可能となる。
`setuptools`をインストールには下記のコマンドを実行。
```
pip install setuptools
```

あとは、`labelImg`を起動するには下記のコマンドを実行するのみ。
```
labelImg
```

無事に`labelImg`が起動できました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3665553/60bb51ee-5097-5dbb-4c10-9e4da205b2c3.png)

# ■参考記事
`distutils`に関連するエラーを検索したところ、下記の記事を拝見し、解決できました。有り難うございました🙏
[@pitao【inshellisense】ModuleNotFoundError: No module named 'distutils' の対処法](https://qiita.com/pitao/items/1740a62ddee797aed807)
LightGBM, XGBoost, CatBoostの違いと使い分け

機械学習の中でも、勾配ブースティングは非常に人気の高いアルゴリズムです。その中でも特に有名な**LightGBM、XGBoost、CatBoost**は、さまざまなシーンで使用されています。この記事では、それぞれの特徴や得意分野、どのような場合にどのアルゴリズムを使うべきかを解説します。
※この記事は、ChatGPTの出力を基に作られています。

---

## **1. LightGBM（Light Gradient Boosting Machine）**
### 特徴
LightGBMは、Microsoftが開発した勾配ブースティングアルゴリズムです。その名前の通り「軽量」で高速なモデルが特徴です。

- **高速で効率的**：大規模データや高次元データの処理が得意で、計算速度が非常に速い。
- **Leaf-wise Growth（リーフ分岐型）**：一番誤差が大きいリーフを優先して分岐するため、計算が効率的。
- **GPU対応**：並列計算を活用してさらなる高速化が可能。

### 利用シーン
1. **大規模データセット**：
   - 数十万～数百万件のデータを高速に処理可能。
   - 例：検索エンジンのランキング、クリック率予測。
   
2. **高次元データ**：
   - 特徴量が100以上ある場合でも効率的に学習可能。
   - 例：遺伝子解析、金融リスクモデリング。

3. **リアルタイム予測**：
   - モデルの学習・推論速度が重要なシステム。
   - 例：オンライン広告のクリック予測。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3457746/036c8494-ff4d-f90e-54e5-545e8a266e35.png)
---

## **2. XGBoost（Extreme Gradient Boosting）**
### 特徴
XGBoostは、勾配ブースティングアルゴリズムのパイオニアとして知られ、多くの機械学習コンペで使用されています。

- **汎用性が高い**：小～中規模データセットで高い性能を発揮。
- **安定性**：初期設定でも高い性能を出せる。
- **ドキュメントが豊富**：多くの研究論文やオンラインリソースで情報を得やすい。

### 利用シーン
1. **小～中規模データセット**：
   - 数千～数十万件のデータで精度重視の場合。
   - 例：医療データ分析、不動産価格予測。

2. **複雑な非線形データ**：
   - 特徴量間の相互作用が多いデータ。
   - 例：詐欺検出、マーケティングのターゲット予測。

3. **信頼性が重視されるプロジェクト**：
   - 初期設定で高い精度が得られるため、プロトタイプ開発や実用化に適している。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3457746/e4466ae1-6f2e-ec60-21ba-e7f46ed33a69.png)
---

## **3. CatBoost（Categorical Boosting）**
### 特徴
CatBoostは、Yandex（ロシアの検索エンジン）が開発したアルゴリズムで、カテゴリ変数の扱いが特に得意です。

- **カテゴリ変数の自動処理**：エンコードなしで学習可能。
- **過学習に強い**：Ordered Boostingという手法でデータの偏りに対して堅牢。
- **解釈性が高い**：SHAP値や特徴量の重要度解析を簡単に実行可能。

### 利用シーン
1. **カテゴリ変数が多いデータ**：
   - データ前処理の手間を減らしたい場合。
   - 例：eコマースのユーザーデータ分析、保険リスク評価。

2. **小～中規模データセット**：
   - 数千～数十万件のデータに対して高い精度。
   - 例：顧客離脱予測、医療データの分析。

3. **過学習を防ぎたい場合**：
   - データのバイアスが大きい場合でも強い。
   - 例：金融や医療の慎重さが求められる領域。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3457746/e94e6aa1-4ed0-773c-7474-a5ff5b7a9205.png)
---

## **アルゴリズム選択のガイド**
以下は、どのアルゴリズムを選ぶべきかを簡単にまとめた表です。

| 特徴                     | LightGBM                         | XGBoost                          | CatBoost                      |
|--------------------------|----------------------------------|----------------------------------|-------------------------------|
| **データサイズ**          | 大規模データ向け                  | 小～中規模向け                    | 小～中規模向け                 |
| **カテゴリ変数の扱い**     | △                                | △                                | ◎                             |
| **学習速度**              | 非常に速い                        | 中速                             | やや遅い                      |
| **過学習耐性**            | 正則化次第（要調整）               | 中程度                           | 非常に高い                    |
| **ドキュメントや実績**     | 多い                              | 非常に多い                        | 少ない（ただし実用性は高い）   |

---

## **まとめ**
- **LightGBM**：大規模データや高速性が求められるタスクに最適。
- **XGBoost**：安定性と汎用性を重視するプロジェクトにおすすめ。
- **CatBoost**：カテゴリ変数が多い場合や、過学習が懸念される場合に強力。

それぞれのアルゴリズムは長所と短所があり、データの特性やプロジェクトの要件に応じて最適なものを選ぶことが重要です。まずは小さなデータセットで試し、パフォーマンスを比較することで、より良い選択ができるでしょう。

---

勾配ブースティングは今後も多くの分野で活躍が期待される技術です。これらのアルゴリズムを使いこなして、データ分析や予測の精度をさらに高めていきましょう！
Redmine作業履歴を「思考の増幅器」へ！FlowiseでAIアシスタントを爆誕させる

# はじめに
Redmineを作業履歴のメモ代わりに使っていると、時々、思いがけないアイデアが湧いてくることがあります。しかし、いざWikiにまとめようとすると、思考が途絶えてしまう。ああ、あの時の閃きは何処へ？そんな経験、あなたにもありませんか？

考えてみれば、入力場所は広大な方が良い。そして、その思考をキャッチして、まるで優秀な秘書のように、後のタスク処理を代行してくれるAIがいたら最高じゃないですか？

ソフトバンクの孫正義さんのように、寝起きの閃きをすぐに特許出願できる体制を、AIで実現できるなら、それはもう「革命」と呼べるでしょう。

[孫正義氏が予測する「知のゴールドラッシュ」](https://logmi.jp/main/technology/331143)

### なぜRedmineの作業履歴が「思考の増幅器」になるのか？

私のRedmineは、完全に日記帳状態です。ここに書きなぐった思考の断片が、全てボタン一つで、隅々まで指示伝達できる。そんな夢みたいな日が来たら、どれほど気楽な毎日になるだろうか。

以前は「AIに指示されたい」なんて人間失格なことを言っていた私ですが、今は少し考えが変わりました。AIは指示されるべき存在ではなく、良きパートナーであるべきだと。

### GUIベースのLLM開発ツールとの出会い

そんな中、GUIベースのLLM開発ツールに出会いました。[Flowise](https://flowiseai.com/)、[LangFlow](https://www.langflow.org/)、[LlamaIndex UI](https://docs.cloud.llamaindex.ai/llamacloud/guides/ui)… これらのツールは、ドラッグ＆ドロップで高度なAIシステムを構築できるというのです。

特に私が注目したのは、Flowiseです。これはまさに、私が目指していた「思考から実行へのシームレスな橋渡し」を実現できる可能性を秘めています。

### Flowiseがもたらす「思考の自由」と「実行の確実さ」

Flowiseを使えば、Redmineの作業履歴をチャットボットに流し込み、そこからアイデアを抽出して自動的にタスク化する。そんなフローを、プログラミングではなく、視覚的に組み立てられるのです。

これまで埋め込み技術の調査で培った知識と、これらのGUIツールを組み合わせれば、理想とする「思考の自由さ」と「実行の確実さ」を両立できるかもしれません。

作業履歴に書きなぐった文章から、AIが重要なポイントを拾い上げ、適切なタスクに分解し、必要に応じてwikiも更新してくれる。

これは単なる自動化ツールではなく、「思考の増幅器」とでも呼ぶべきものになるのではないでしょうか。

### AIとの理想的な協働

アイデアが湧いたとき、それを捕まえて形にする。そして、実行可能な形に整理する。その過程を、AIが支援してくれる。

もしかしたら、これこそが私が求めていた「AIとの理想的な協働」なのかもしれません。AIに指示されるのではなく、AIを使いつぶすのでもなく。互いの得意分野を活かしながら、より良いものを作り上げていく。そんな関係性が見えてきた気がします。

### 次のステップ：Flowiseでプロトタイプ作成へ

次は、実際にFlowiseでプロトタイプを作ってみようと思います。まずは小さく、作業履歴からアイデアを抽出して整理するところから始めてみます。そこから徐々に、タスク生成や文書化の自動化へと発展させていければ。

### まとめ：テクノロジーは人間の可能性を広げる

結局のところ、テクノロジーは人間の可能性を広げるためにある。今回の発見も、そんな可能性の一つを示してくれたように思います。

さて、この構想もRedmineの作業履歴に記録されたわけですが、これを読んだAIくん、さっそく整理してタスク化してくれないかな。（笑）

---

### 関連リンク

- [PythonからREDMINEのWIKIにアクセスする方法の検討](https://qiita.com/EasyCording/items/123be275d5c12e7c49f6)
-- [仕事で使うREDMINEに関する考察(6)](https://qiita.com/EasyCording/items/c2c3a5850941f45d1317)
- [次世代プロジェクト管理ツールの構想を練る（４）](https://qiita.com/EasyCording/items/7c2e51031b818b94b283)
- [CMSって　Redmine、Wordpress、还是什么？](https://qiita.com/EasyCording/items/76e24ef14a3b59d4183f)
- [仕事で使うREDMINEに関する考察(2)](https://qiita.com/EasyCording/items/7f8fbba0553635a7421d)
[VBA]FunctionでExcelで使えるオリジナル関数を作る

## VBAでオリジナル関数が作れるだって…！？
Functionプロシージャを使えばExcelでも使用できるオリジナル関数を作ることができます。

初めは複雑かもしれませんが、真似して作ってみると慣れていきますよ！
今回は「JAN」「FEB」（月の英語表記）...と入力されているデータを1、2...と数字に変更していきます。

標準モジュールに書けばExcelでも使用することができます。
ぜひ試してみてください。

https://indoor-nekura.work/vba_function/
学生ハッカソンのチーム開発で失敗した経験を振り返る

# はじめに
こんにちは。しろさんと申します。
普段参加しているVRChat近況報告会で[アドベントカレンダー](https://qiita.com/advent-calendar/2024/vrchat-status-update-event)を作成するということで、せっかくなので参加させていただいています。

2024年も残り1ヶ月、今までの振り返りを兼ねて**短期間のチーム開発**をテーマに記事を作成しました。

# チーム開発、沢山経験しました
直近の2年間、ハッカソンやインターン含め、合計8回ほど短期間のチーム開発を経験しました。
また、多くの失敗も経験しました。この記事では
- **ハッカソンでのチーム開発失敗談**
- **学生ハッカソンならではの難しさ**
- **ハッカソンの開発をスムーズに進めるために意識していること**

について書きたいと思います。
今回は、技術的な課題や開発物の完成度に関する内容は記載せず、**コミュニケーション問題にフォーカスして**書いていきます。
また、**学生の視点で記事を書いている**ため、社会人ハッカソンでは事情が違うところがあるかもしれませんが、ご了承ください。

# チーム開発の失敗談
失敗した経験は山ほどありますが、大きく3つのカテゴリに分けてご紹介します。
- ## BE/FEの連携で停滞
初めて参加したハッカソンでは、フロントエンドとバックエンドで分担して開発を進めた結果、**双方の情報共有が全く出来ておらず**、APIの繋ぎこみで苦労しました。
バックエンドが作成したAPIの仕様を、フロントエンドに共有せずに実装を進めてしまったのが原因です。
また、３回目のハッカソンでもフロントエンドとバックエンド、**互いの技術領域に対する理解不足**により、繋ぎ込みに想定以上の時間を費やすことになりました。

- ## 熱量の違いで仲間割れ
３回目のハッカソンでは、非常に熱量の高いメンバー１人が他メンバーを牽引しながら開発を進めました。
熱量の高い１人がリードして開発物の仕様を決め、UIを設計し、開発を指揮しました。
結果、開発途中で**メンバー同士の認識齟齬が生じ**、一部設計をやり直すことになりました。
また、**熱量が高いメンバーだけが多くの作業をこなしている状況**になっていたため、その不満による口論が度々発生する状態になっていました。

- ## 知識不足で開発に参加できない
4回目のハッカソンでは、技術力の高いメンバーに混ざって開発を行いました。
企画から設計、実装まで、皆協力し話し合いを定期的に挟みながら開発を進めました。
しかし、私の**知識不足・技術不足によって、話し合いの内容を深く理解できず**、序盤は開発にも殆ど参加できませんでした。
8回目のハッカソンでは、**技術力の高い１人だけが開発のほぼ全てを担当している状況**に陥っているチームがありました。

# なぜ学生ハッカソンが難しいのか？
失敗経験を振り返ってみると、その内容は下記の通りです。
- **企画・開発途中の情報共有不足**
- **業務の振り分けが不適切**
- **メンバーの技術力を踏まえた動きが出来ていない**

具体例でいうと、「互いの業務内容や遂行状況を把握できていない」「実行すべきタスクを明確に文書化出来ていない」「メンバーの能力に応じた適切な業務を割り振れていない」といった内容が挙げられます。
自分なりに、**このような問題が発生していた原因**を集約したものが次の内容です。

- **開発チームの運営（マネジメント）に割くリソースが不十分である**

開発の進め方の策定や役割分担など、**開発を上手く進めるために必要な要素を考え、実行する時間と意識**が足りていませんでした。

企業であれば、開発をマネジメントする方がいて、メンバー全員の様子を見ながらスケジュール管理やタスク管理を行っていると思います。
学生のみのハッカソンの場合、企画・開発・プレゼンのような、**本来分業して行うような作業を、短期間のうちに、チームのメンバーだけで全て行わなければなりません。チーム開発を管理してくれるマネージャもいません。**
その結果、**実装ばかりに気を取られて他に気が回らず失敗する**パターンが多かったように感じます。

# ハッカソンの開発をスムーズに進めるために
チーム開発の壁に直面した頃から、どうすれば問題を解決できるか考え、試行錯誤を続けています。
現状、私が実践（しようと）している解決策は次の通りです。

- ハッカソンで**解決したい課題とその背景、課題解決後の理想状態、解決策、ユーザー像について**ドキュメントにまとめ、**全員でそれを確認しながら不明点や問題点を指摘する**
- **定期的なミーティングの場を設け、それぞれが抱えているタスクと進行状況を共有する**
- **最低限必要な機能と、それを実装する期限を定め**、計画を立てて実装を進める

このように、**メンバー全員の考えや状況を共有する機会**と、**些細な問題を素早く発見し対処する環境**を作ることを意識してチーム開発を進めています。
実際に、これら全てをハッカソンで実行し、チーム開発が上手くいった経験もあります。
（詰まるところ、ハッカソンにもマネージャのような立ち回りをする人が必要かもしれません）
ただ、ハッカソンの期間によっては、ほんの数日でこれら全てを十分に意識しながら開発を進めるということが難しく、まだまだ課題があると感じています。

# でも結局ハッカソンは楽しい
失敗した経験ばかりを挙げてきましたが、困難を乗り越えて作品が完成した時は、何事にも代えがたい感動があります。
また、「**失敗を経て解決策を考え実践していく**」「**チームで協力して物事を成し遂げる**」「**自分たちの力で**、**この世に無いものを生み出す**」等、ハッカソンを通して得られる貴重な経験が沢山あります。
みなさんも是非！ハッカソンやりましょう！

# おわりに
クリスマス感を出すために、最後にダンシングツリーの3Dモデルを作成します。
![スクリーンショット 2024-12-08 205758.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3457210/1d84dbe3-bdb8-14d6-0e58-6e4796b652d0.png)
出来ました。
2025年も良い1年になりますように。*Merry Christmas!*
Let's Encryptのdns-route53プラグインを複数のAWSアカウントで利用する

# はじめに

1つのリバースプロキシ上で複数のドメインを管理するというケースはよくあると思います。また、それぞれのドメインをLet's Encryptを利用してHTTPS対応することも当たり前のようにあることかと思います。

Let's Encryptには、Route53によるDNSレコード認証と証明書発行を自動的に行うdns-route53プラグインというものが存在します。このプラグインを利用することで、証明書の発行と更新が自動化され、証明書管理にかかる手間が軽減されます。

## 複数のAWSアカウントへの対応

dns-route53プラグインは、デフォルトでは`~/.aws/`ディレクトリ以下で管理されるconfigおよびcredentialsの`default`プロファイルを参照して動作します。企業においてはAWSアカウントが部門やプロジェクトごとに存在し、これらを複数のプロファイルを管理しているケースも当たり前のようにあるかと思います。

また、部門やプロジェクトごとにドメインあるいはサブドメインを各AWSアカウント配下のRoute 53で管理しているケースもあるかと思いますし、1つのリバースプロキシ内で異なる部門やプロジェクトのドメインをホストしているケースもあると思います。

しかし、通常のcertbotコマンドの実行方法は、デフォルトのプロファイルとして設定されたAWSアカウントを対象していますので、そのままでは他のAWSアカウントで管理されているドメイン向けの証明書発行・更新を行うことが出来ません。

他のAWSアカウント（プロファイル）で管理されているドメインに対する証明書発行・更新は、次の手順をもとに進めることで対応することが出来ます。

# 手順

## 1. プロファイルを追加する

`~/.aws/config` `~/.aws/credentials` へそれぞれプロファイルを追加します。

### 例

ここでは、`testdrive` というプロファイルを新たに追加しています。

```ini:~/.aws/config
[default]
region = ap-northeast-1
output = json

[testdrive]
region = ap-northeast-1
output = json
```

```ini:~/.aws/credentials
[default]
aws_access_key_id = AKIAXXXXXXXXXXXXXXXX
aws_secret_access_key = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

[testdrive]
aws_access_key_id = AKIAXXXXXXXXXXXXXXXX
aws_secret_access_key = YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
```

## 2. certbotコマンドを実行する
`AWS_PROFILE`変数をセットした状態で、certbotコマンドを実行します。

```shell
AWS_PROFILE=testdrive \
certbot certonly \
--dns-route53 \
-d '*.example.net' \
-d 'example.net' \
--email admin@example.net \
-n --agree-tos \
--key-type rsa \
--rsa-key-size 2048
```

２を実行すると証明書が発行されますので、発行された証明書をWebサーバあるいはリバースプロキシの対応するドメインに対して設定します。
Koebiten: TinyGoで楽しむ小さなゲームエンジン

## はじめに

この記事では、@sago35 さんが作成した `Miniten` から影響されたゲームエンジン「Koebiten」について紹介します。
まずKoebitenは、[Ebitengine](https://ebitengine.org/) という、2Dゲームエンジンをベースにしたもので、こちらは商用利用もされています。
今回はTinyGo Keebの活動に参加し、得た知見とともにご紹介できればと思います。

## Koebitenとは？

Koebitenという名前は、keeb初回の打ち上げの席で @sago35さんが考えておられた「小海老天」から来ています。「簡単に作れるなら作ってみるか」という気持ちで開発したのが、今回の「Jampin Gopher」です。

![cb958d1d3cff13f7a5c94e439e1c6de9.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/59290/4e667a1c-5650-6060-8b79-cc87102728df.png)
※画像は何も関係ありません。

初期には「FlappyGopher」というゲームがあり、その絶妙な難しさが面白かったですが、
私たちレトロファミコン世代には `床` が必要だと感じ、床を設置しました。
さらに、壁を避ける要素を雲に変えることで、小さい子どもでも楽しめるようにしました。
※要は難易度を下げただけ

### ゲーム画面
実際のゲーム画面
![jumpingopher.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/59290/b6d7fe95-0875-9a50-d22f-ff8b2ce7676c.jpeg)
右から左へ雲が飛んでくるので、ジャンプで避けるだけのゲームです。

### 床の実装

Gopherくんの下限に当たり判定をつけることで、自由落下状態を解消しました。

```go
for _, platform := range platforms {
    if hitPlatformRect(int(y), int(x), int(y)+22, int(x)+22, platform.pY, 0, platform.pY+22, 128) {
        isOnPlatform = true
    }
}
```

これによって、画面内で落下せずに進むゲームが完成しました。

### 障害物の工夫

障害物は夢のある雲にし、ジャンプで避けることで遊びやすくしました。クラウド（雲）を描画するコードはシンプルです。

```go
func drawCloud(c *cloud) {
    koebiten.DrawImageFS(nil, fsys, "cloud.png", c.cloudX, c.holeY-cloudHeight)
}
```

これだけでゲームが完成し、雲を避けるたびにスコアがカウントされます。まさに王道ですね！

## どうやったら遊べるの？
https://github.com/sago35/koebiten

ここで、Getできます。


## まとめ

今回の記事では、TinyGoとKoebitenを使って簡単にゲームを作る方法をご紹介しました。小学生の頃、無限に時間を費やしたクソゲーとは違い、現代ではこれほど簡単にゲームが作れるようになりました。

TinyGo Keebでは全国ツアーを行っています。
来年もまだまだ、各地を巡る予定です。

[TinyGo Keeb Tour 2025](https://tinygo-keeb.connpass.com/)

来年も多くの方々と出会えることを楽しみにしています。
また、TinyGo Confが開催できれば素晴らしいですね。

以上、QiitaのTinyGoアドベントカレンダー11日目の記事でした。
ブロックコメントと行コメントを組み合わせたSQLコード切り替えの小技

手で流すSQLの記述を、ときどき切り替えたいという場合があります。メンテナンス用にいろいろ用意してあるスクリプトレット、そのうち例えば、

- **いつもは前日まで7日分を対象に処理したいが、例外的に期間を指定したくなることもある**

そういうとき、スクリプトレットが自分だけのもので単純なものなら書き換える場所はすぐわかりますし簡単ですが、チームで共有していたり複雑だったりすると、どこを書き換えていいか一目でわからなかったり、わかるけどここだけ書き換えればいいのか自信がもてなかったりします。

さてそういうとき、書き換え用のコードを最初からコメントアウトして埋め込んでおいたりしますよね。しません⋯？　ええ、しますよね！

その際の小技。コメントアウトを外すとき、先頭と末尾を両方外さないといけないし現行コードの両側にもコメント記号を入れてコメントアウトするという4段階の手間がある面倒さ、その面倒さと操作ミスリスクがブロックコメントと行コメントの組み合わせで解消できます。

```sql
between /* date'2024-12-02' --*/ current_date() - interval '7' day
    and /* date'2024-12-08' --*/ current_date() - interval '1' day
```

このコメントアウトは、先頭の `/*` をはずすだけで

```sql
between date'2024-12-02' --*/ current_date() - interval '7' day
    and /* date'2024-12-08' --*/ current_date() - interval '1' day
```

こう！  
手軽かつ安全にコードを切り替えられました。

さて、ブロックコメントと行コメントを組み合わせる書き方はSQLに限らずできるわけです。C系のシンタックスの言語なら
```c
p = /* 3.0 //*/ Math.PI;
```
みたいに書けるわけですが、ただ、プログラミング言語の場合は動作やパラメータを切り替えるための方法はもっとましなものがいくらでもありますからね。この小技を使う機会があるのはSQLスクリプトレットであることがほとんどなんではないかなと。
ユニリサーチで素早くインタビューしてみた

この記事は [株式会社TRAILBLAZER Advent Calendar 2024](https://qiita.com/advent-calendar/2024/trail-blazer) の11日目の記事です。


### **はじめに**
こんにちは。TRAILBLAZERのソリューション事業部でUXデザインを担当している水原です。
現在はJR西日本のアプリWESTERの開発や新規サービスの企画・改善を行い、
より良い体験設計に邁進しています。

今回は、新サービス開発において、ユーザーインタビューの中でも時間がかかるモニター（インタビュー被験者）を募集する作業をユニリサーチというサービスで素早く行なったお話をします。

https://unii-research.com/business/

---
### **目次**
- 目的
- 契約
- 募集
- 応募・日程調整
- インタビュー

---
### **目的**
新サービス開発におけるユーザーの需要性をはかるため、また新たな発想を得るために、想定ペルソナに対応したモニターを集め、ZOOMでインタビューを行うことを目的としました。
今回は想定ペルソナが多かったため、１０名のモニターを募集することにしました。

---
### **契約**
支払いについてはクレジットカード払いと請求書払いに対応していて、
今回は請求書払いとしました。請求書払いには認証等の手続きが必要なのですが、
 TRAILBLAZERにはIT担当がおり、素早く社内も含めて手続きをしてくれました。

---
### **募集**
募集はすごく簡単で、ユニリサーチのWEBに従い、
「募集タイトル」「募集条件」を記入して、そ時間や謝礼金、ツールなどを指定するだけです。
条件等を先に検討メンバーと決めていたので、すぐに入力して募集をかけることができました。

---
### **応募・日程調整**
びっくりするぐらいすぐに応募がきます。３日募集をかけたのですが、１日で充分かと思うぐらい来ました。
リストの中から、インタビューしたい相手に対してのみ日程調整をします。
WEB上でわかりやすく全てが完結しました。
日程調整後にZOOMのIDと PASSを連絡し、当日を待つだけです。

---
### **インタビュー**
インタビュー自体は、募集時に選んだZOOMで行いました。
ZOOMを１０分前くらいから事前に立ち上げ、
事前に作っておいた提示資料やシナリオを準備しました。
モニターは遅れる方がいなく、スムーズに始めることができました。
また、事前にスクリーニングもしているので、想定通りの方々でした。
時間内にインタビュー実施が終わったら、完了報告をユニリサーチにWEB上でするだけです。

---
### **まとめ**
今回は、ユニリサーチというサービスを使いインタビューのモニター募集をしたことを書いてみました。
あっという間に募集が出来て、インタビューもスムーズに行えました。
是非、皆さんもユニリサーチを使ってインタビュー行なってみてください。


https://hrmos.co/pages/trail-blazer
gridレイアウトの基礎知識と活用法

## はじめに
学んだことを忘れないように備忘録として残しています

## gridレイアウトとは
CSSで提供されるレイアウトシステムの一つで、レイアウトを効率的に作成するためのものです。
gridレイアウトは親要素（コンテナ）と子要素（アイテム）の関係で構成されます。

【gridコンテナ】
gridレイアウトを適用する要素

display: grid;を指定します。

【gridアイテム】
gridコンテナの直接の子要素が対象となります。

## 主要なプロパティ
#### grid-template-rows / grid-template-columns
行と列のサイズを定義します。(rows,columnsと複数系なので要注意！）

```css
 .container {
    display: grid;
    
    grid-template-columns: 100px 200px auto;
    
    grid-template-rows: 50px auto; 
}

```
#### grid-template
行と列のサイズを一括指定します。
 例）grid-template:  rowの値 rowの値 / columnsの値　columnsの値;


```css
    .container {
        display: grid;
        
        grid-template:  50px auto / 100px 200px auto;
    }

```
### 単位fr（エフアール）

frとは、CSSのグリッドレイアウトで使用する単位。
フラクションの略で日本語だと、分数という意味。

グリッドコンテナー内の利用可能な空間の割合を表します。﻿
例えば、3行の中身の幅を 1:1:1 にしたい場合は下記のように指定します。

```css
    .container {
        display: grid;
        grid-template-columns:  1fr 1fr 1fr;
    }
```
pxなどの固定幅と組み合わせることも可能です！

## grid itemの配置方法
### デフォルト配置
グリッドアイテムは通常、コンテナ内のグリッドラインに沿って左上から順に配置されます。
しかし、**grid-area;**を活用することで、画面幅やデバイスによって配置を変えたいなど、作成したアイテムに名前をつけて自由に配置することができます。

### gri-areaで自由配置
#### 例）ヘッダー、フッター付きの２カラムレイアウトを組む
【使用手順】
1.コンテナにグリッドエリアを定義


行（row）と列（column）のサイズも同時に設定できます。

ヘッダー (header) が全幅を占有。
サイドバー (sidebar) とメインコンテンツ (main) が左右に分割。
フッター (footer) が全幅を占有。

```css
.container {
    display: grid;
    grid-template-areas: 
        "header header"
        "sidebar main"
        "footer footer";
    grid-template-rows: 100px 1fr 100px; /* 行の高さ */
    grid-template-columns: 200px 1fr; /* 列の幅 */
}
```


②アイテムとエリアの紐付けをする
```css
.header {
    grid-area: header;
}
.sidebar {
    grid-area: sidebar;
}
.main {
    grid-area: main;
}
.footer {
    grid-area: footer;
}
```






## gridレイアウトとFlexbox

【Flexboxが適している場合】
1次元のレイアウト（行または列のどちらか一方向）
- 例：ナビゲーションバー、ボタンの横並び
- 要素サイズが可変で、順番が重要な場合

【gridが適している場合】
2次元のレイアウト（行と列を組み合わせた複雑な配置）
- 例：ウェブページ全体の構造、ダッシュボード
- レイアウトが複雑で、特定のアイテムを指定位置に配置したい場合


単純な並びや1方向ならFlexbox。
複雑なレイアウトや2次元構成ならGridが最適。

## まとめ
gridレイアウトは、ウェブページの効率的な2次元構造を実現する強力なCSSツールです。
一方、Flexboxは1次元レイアウトに適しており、それぞれの特性を理解して使い分けることが重要です。
Nerves公式にNerves Systems のドキュメントが追加されました


## はじめに

Nerves プロジェクトの公式ドキュメントに、[`nerves_systems` リポジトリ][nerves_systems]を使った Nerves システムの構築方法が新しく追加されました。

Nerves を使った開発をさらに深めたい方にとって、役立つ内容になっています。

この記事では、そのドキュメントの内容や背景について紹介します。

## 新ドキュメント作成の背景

2023年、私は #NervesJP Advent Calendar 2023 にて [「Nerves Systems ビルダーを使ってソースコードからビルドする」][qiita_article] という記事を執筆しました。この中で [`nerves_systems` リポジトリ][nerves_systems] を活用してカスタムビルドを行う方法を紹介しました。

https://qiita.com/mnishiguchi/items/206961699345ee8cf528

先日、この情報を公式ドキュメントに反映させるべく、Nerves のコアリポジトリに新しいドキュメントを追加する [Pull Request][pr_1028] を提出しました。

上記の Pull Request は、近日中に予定されている Nerves パッケージの新バージョンリリース時に反映される見込みです。

この新ドキュメントの公開によって、Nerves ユーザーがより簡単に `nerves_systems` を活用できるようになることを期待しています。

## `nerves_systems` の魅力

Nerves の公式リポジトリで、システムビルダーを利用してカスタムの Nerves システムを構築するための強力で柔軟なツールです。

このリポジトリを利用することで、以下のような幅広い可能性が広がります。

### プレリリース版の機能を試せる

[Nerves プロジェクトのリリースページ][releases] を参照すれば、新しい機能や改善が頻繁に追加されていることがわかります。公式のリリースを待たずにプレリリース版を試せることは、開発者にとって大きなアドバンテージです。特に、新しい機能が必要なプロジェクトやフィードバックを提供したい場合に役立ちます。

### 独自のカスタムシステムを構築

[`nerves_systems`][nerves_systems] を活用すると、特定のハードウェアや用途に最適化したシステムを構築できます。たとえば、以下のようなケースに対応できます:
- 特定のハードウェアデバイス向けにカスタマイズ。
- プロジェクト固有のドライバやライブラリを統合。
- 軽量化や特定機能の無効化によるリソース最適化。

公式のカスタマイズ手順は [HexDocs のガイド][hexdocs_customizing] にも詳細が記載されています。

### 柔軟な開発体験

オープンソースの強みを活かし、プロジェクトに必要な機能を自由に追加・修正することが可能です。
開発者のニーズに合わせたフレキシブルなシステム設計をサポートします。

## さいごに

ぜひ`nerves_systems` を活用して、Nerves を使った開発の幅を広げてください。

何か氣づいた点や改善提案があれば、コメントで共有していただけると嬉しいです。

![toukon-qiita-macbook_20230912_091808.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82804/fd5c55ec-4fe0-8af6-59bc-bab1ef3d182b.jpeg)

<!--- begin-reusable-links --->

[nerves_systems]: https://github.com/nerves-project/nerves_systems
[qiita_article]: https://qiita.com/mnishiguchi/items/206961699345ee8cf528
[pr_1028]: https://github.com/nerves-project/nerves/pull/1028
[releases]: https://github.com/nerves-project/nerves_systems/releases
[hexdocs_advanced]: https://hexdocs.pm/nerves/advanced-configuration.html#content
[hexdocs_customizing]: https://hexdocs.pm/nerves/customizing-systems.html#content
[hexdocs_overview]: https://hexdocs.pm/nerves/overview.html
[nerves_project]: https://github.com/nerves-project


<!--- end-reusable-links --->
インターネット上のパケットDSCP値を追跡せよ

# はじめに

音声やビデオ関連のネットワーク設定でお馴染みの方も多いかと思いますが、QoSの設定におけるDSCPは、ネットワークのトラフィック優先順位を制御する上で重要なファクタですよね。このブログでは、ThousandEyesではこのDSCPがネットワーク上でどのように取り扱われているのかを調査する方法や利用例をご紹介します。



# 念の為、DSCPやThousandEyesとは？

DSCPはIPヘッダに含まれるコードで、通信データの優先順位を示します。例えば、音声やビデオ通信など、優先されるべきトラフィックにDSCPを適用することで、該当パケットがネットワーク上で優先的に処理されます。

ThousandEyes はシスコ社が提供する、ネットワークやサーバ、アプリケーションパフォーマンスをアクティブに監視するソリューションです。その特徴は、ネットワーク機器のヘルシーチェックに留まらず、エンドツーエンドでユーザー目線のインフラ監視を行う点にあります。

# ThousandEyesでDSCPを追跡

ThousandEyesのテストでは、管轄外のネットワークでDSCPがどのように扱われているかを確認できます。たとえば、DSCP値が不適切に書き換えられている場合でも、それを検知して把握することが可能です。これは、特にインターネットやクラウドを活用する音声やビデオツールの運用において、重要なポイントと言えるでしょう。

## 調査例

ここでは、ThousandEyesを使ってDSCPを調査する方法について簡単な例をご紹介します。

ThousandEyesのテストビュー画面では、エージェントからターゲットまでのネットワークパス上でDSCP値が書き換えられた場合、その情報が「info」として表示されます。この機能はあまり目立たないかもしれませんが、特に音声系トラブルの原因特定に役立つ重要なポイントです。

![Pasted Graphic 1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3937614/8b074002-5ddc-6961-912e-bea53c81048f.png)



さらに、マウスを該当ハイライトされたリンクに当てると、DSCP値がどのように変わったかとの情報が確認できます。

![Pasted Graphic 2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3937614/2655f745-c3cc-2a0c-29fe-8abc1fa808af.png)

## アラートも設定可能

DSCP 値を条件にアラートを設定し、問題が起きた際にいち早く問題把握しましょう。
![Pasted image 20241208172059.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3937614/a1d17f24-5a15-acc0-2e97-b76fb98f0f74.png)

# ThousandEyesによるDSCP調査の利点

インターネットや管轄外のネットワークで、何らかの理由で本来守られるべきDSCPの値がリセットされてしまうと、いくらLAN側でQoS設定をしても意味がなくなり、ビデオや音声の品質に影響が出やすくなるのは言うまでもありません。その結果、原因が特定できないまま迷宮入りしてしまう障害ケースも多いのではないでしょうか。

ThousandEyesのアクティブ監視を使えば、End-to-Endでネットワークをチェックできて、経路の問題をすぐに見つけられます。この機能を活用して、音声系の障害が発生したときのトラブルシューティングに役立てていただけたら嬉しいです！
アリババクラウド、オープンソースAI推論モデル「QwQ」と新画像編集ツールを発表

> 本記事は[こちらのブログ](https://www.alibabacloud.com/blog/alibaba-cloud-unveils-open-source-ai-reasoning-model-qwq-and-new-image-editing-tool_601813?spm=a2c65.11461433.0.0.4ee35355XQLlto)を参考にしています。
> 翻訳にはアリババクラウドの[ModelStudio](https://www.alibabacloud.com/en/product/modelstudio)([Qwen](https://www.alibabacloud.com/en/solutions/generative-ai/qwen))を使用しております。

## 理解モデルへの関心が高まる中、アリババクラウドがQwen QwQを発表

最近、問題解決や意思決定のために人間の推理をシミュレートすることを目的としたAIシステムである推理モデルへの注目が増大しています。このトレンドは、AI需要がモデルの学習から推論への徐々なシフトと一致しており、運行情況でのモデルの追加処理時間を割いて、出力コンテンツの信頼性と感受性を向上させるために行われるテスト時計算（推論計算とも呼ばれます）に関する議論が拡大していることを反映しています。

![2](https://yqintl.alicdn.com/cfb86f441519449a1922211a52f6d8ed076d7d5f.png)
*注：QwQの発音は/kwju:/であり、「クィル」と似ています。*

この背景において、アリババクラウドは最近、推理AIモデル「QwQ（Qwen with Questions）」を発表しました。公表されたバージョンである[QwQ-32B-Preview](https://qwenlm.github.io/blog/qwq-32b-preview/)は、320億パラメータを持つオープンソースの実験的調査モデルであり、優れた分析能力を示しています。現在プレビュー段階にあるこのAIモデルは、最大3万2千トークンの長さのプロンプトを処理できるようになっています。数学やプログラミングにおける複雑な問題解決に秀でており、MATH-500（500の数学テストケースからなる包括的なセット）やアメリカ招待数学検定（AIME）などのベンチマークで最尖端（SOTA）モデルを上回り、驚くべき数学スキルと問題解決力を発揮しています。

![3](https://yqintl.alicdn.com/36872e5560bddab065ad618b951dfb51d3a0b15a.png)
*QwQは印象的な分析能力を披露しています*

モデルがプロンプトに対して示す応答からは、複数ステップの推理を行うことができ、複雑な思考プロセスを構築する能力が明らかになります。これは、自身の仮説を問い直す深い自己反省、熟考に基づいた自己対話、推理の各ステップを分析するなど、深い内省も含まれます。これらの進歩にもかかわらず、依然として重要な課題があります。研究チームは論文中で、モデルが数学やコーディングにおいて優れた成績を収めている一方で、常識的な推理や微妙な言語理解などの分野でのさらなる開発が必要であることを指摘しています。モデルは[Huggingface](https://huggingface.co/Qwen/QwQ-32B-Preview)と[ModelScope](https://modelscope.cn/models/Qwen/QwQ-32B-Preview)で利用可能です。

マルチモーダルの分野では、アリババクラウドはまた、画像生成や編集を含む様々な視覚生成タスクをサポートする統一された基礎モデルフレームワークである[ACE（全方位クリエイターエディター）](https://ali-vilab.github.io/ace-page/)を発表しました。これにより、複雑で精密な編集リクエストが多回転のインタラクションを通じて簡単に達成できるようになりました。この機能強化を支援するために、研究チームは、多モーダル入力をサポートし、長期的な文脈条件を取り入れて理解度を向上させるための統一された条件フォーマット「Long-context Condition Unit（LCU）」を開発しました。さらに、チームは様々な生成および編集タスクの訓練を改善するための新しいトランスフォーマーベースのディフュージョンモデルを提案しました。

![4](https://yqintl.alicdn.com/982e8aa8b166283e216d1598ddd17353f8b90dd2.png)
*ACEによってサポートされる様々な画像生成と編集タスク*

この記事は元々、Selina Zhang氏によって[Alizila](https://www.alizila.com/news-roundup-key-developments-in-ai-black-friday-kick-off-and-accessibility-initiatives/)で発行されました。
LangGraphとNode-REDによるマルチエージェントシステム

## AIマルチエージェントシステム
現代のAIシステムにおいて、複数のエージェントを効果的に連携させることは、ますます重要な研究課題となっています。本稿では、複数のAIエージェントを連携させるための最新技術と、その可能性について詳説します。

### LangGraphの役割と可能性
LangGraphは、複数のAIエージェントの相互作用を管理するための先進的なフレームワークです。従来のAIシステムが単一のモデルに依存していたのに対し、LangGraphは複数のエージェントが協調的に動作するための柔軟な仕組みを提供します。

#### エージェント間の動的な相互作用
LangGraphの最大の特徴は、エージェント間の動的な状態遷移と対話です。各エージェントは、共通の目標に向けて独自の役割を果たしながら、リアルタイムで情報を交換し、タスクを進行させることができます。これは、単なるシーケンシャルな処理ではなく、より柔軟で知的な協調メカニズムを意味します。

#### タスク分割と最適化
複雑なタスクに直面した際、LangGraphは以下のプロセスを可能にします：

- ユーザーの指示を包括的に分析
- タスクを論理的なサブタスクに分解
- 各エージェントの得意分野に応じたタスク割り当て
- リアルタイムでの進捗追跡と調整

#### 大規模言語モデル（LLM）の役割

大規模言語モデルは、このエージェント連携システムにおいて、以下の重要な機能を担っています：

- タスクの意図解釈
- 文脈の理解と保持
- エージェント間の橋渡し
- 自然言語処理と推論

#### エージェント間通信のアーキテクチャ

エージェント間の効果的な通信には、共通の文脈を維持することが不可欠です。現在の先進的なアプローチでは、以下の要素が重要視されています：

- 共有メモリ空間
- 動的なコンテキストアップデート
- 履歴トラッキング
- 一貫性維持のためのプロトコル

#### 制約とガイドライン

複数エージェントシステムの信頼性を確保するため、以下のメカニズムが導入されています：

- 明確な役割定義
- 倫理的ガイドラインの実装
- エラー検出と修正のメカニズム
- 過度な推論の防止

### 実装における課題

現実の複数エージェントシステムには、依然として多くの課題が存在します：

- 一貫性の維持
- リソース管理
- 予期せぬ相互作用の制御
- プライバシーとセキュリティの確保

### 将来の展望

研究は急速に進んでおり、以下のイノベーションが期待されています：

- よりスマートなコンテキスト理解
- エージェント間の自律的な交渉能力
- リアルタイムでの学習と適応
- より複雑なタスクへの対応

### Node-REDの活用

Node-REDは、このようなマルチエージェントシステムのプロトタイピングに有用なツールとして注目されています。複数のエージェントが協調して判断した結果に基づいて実行するタスクをあらかじめビジュアルプログラミングで実装できます：

- タスクフローの直感的な設計
- 異なるサービスやエージェントの迅速な統合
- プロトタイプの迅速な検証

### まとめ

複数AIエージェントの連携技術は、まだ発展途上にあります。LangGraphを中心とする最新のアプローチは、従来の限界を超え、より知的で柔軟なAIシステムの実現に向けて大きな可能性を秘めています。

研究者やエンジニアは、技術的挑戦を克服しながら、より洗練された協調的AIシステムの開発に取り組んでいます。今後数年で、この分野では劇的なイノベーションが期待されていま
社内でデータ分析教育をした話

この記事は[Hacobu Advent Calendar 2024](https://qiita.com/advent-calendar/2024/hacobu)の9日目の記事です。

## Introduction

株式会社Hacobu テクノロジー本部のTKです。データチームに所属しており、社内におけるデータの利活用を促進することをミッションとしています。

本記事では、社内で実施したデータ分析教育の内容と、そこで得られた成果と学びを共有したいと思います！

## きっかけ

弊社では[「Data-Driven Logisticsが社会課題を解決する」というBelief ](https://hacobu.jp/company/mission/) を掲げています。
そして社内では、営業・CS・人事・バックオフィスなど、様々な組織でデータに基づく意思決定を行う風土があります。

しかし、以下の2点が課題となっていました。

- 個人スキルの不足：データの取り扱いやアクションへの結びつけが難しい
- 専門人材の不足：アナリストの人数が限られており、分析ニーズ増加への対応が難しい

## ２つのアプローチ

そこで、２つのアプローチを通して、データに基づく意思決定を促進させることにしました！

- 個別レクチャー：1on1形式で、深く学びたいしたい人にしっかりレクチャー
- 教育プログラム：講座形式で、最初の一歩を踏み出したい人に広く浅くレクチャー

6ヶ月という期間を設定し、具体的に以下のような取り組みを実施しました。

- 個別レクチャー：
    - 目的：スキルアップ（データ集計・分析・可視化に挑戦）＋チームへの貢献（学びをチームで共有し、データ駆動型文化を醸成）
    - 期間：６週間（週１回の1on1＋αでやり切れるボリューム）
    - テーマ：データが関係すれば何でもOK
        - LookerStudioダッシュボードでの人事データ分析、Excelを用いた顧客データ解析、自社SaaSデータによる業界別の動向分析、etc
    - 参加者：合計10名
- 教育プログラム：
    - 目的：データに触れてみる機会創出
    - 内容：60分の講座をオンラインで実施（＋アーカイブ）
    - テーマ：データ分析＆ダッシュボード利用に関するもの（計７講座）
        - LookerStudio体験会、自社サービス用ダッシュボード入門、Excel関数の始め方、提案時の分析（ROI算出編）、etc
    - 参加者：延べ30名以上

また、コンテンツを作る時には「みんなに刺さるものを作ろうとした結果、誰にも刺さらないものになってしまう」を避けたかったので、、「誰か１名に深く刺さるコンテンツ」を意識して作成していました（万人受けは狙わず、社内の特定の人をペルソナとした）。

## 得られた成果

結果として、以下のような成果を得ることができました！

- 営業：案件の受注に繋がった（学んだExcel関数を活用し、簡易なカスタマイズを含めた提案を実施）
- BizOps：ダッシュボードの使い方を学び、自身でメンテナンスを含めて作業できるようになった
- カスタマーサクセス：ダッシュボードを活用して、お客さんの把握できていなかった課題をデータから見つけられた
- 広報：[広報コンテンツ](https://x.com/MHacobu/status/1839498750605291664)として活用できた

また、成果を定量的に把握するために実施後アンケートも実施しました。
結果、NPS平均値9.34となり、非常に高評価を得ることができました。

## 今後に向けた課題

とはいえ、学んだ内容の活用は個人に留まっている部分もあり、組織としてもっとスケールできる可能性があると感じています。

そして、社内のデータ利用が進むほど、データチームへの問い合わせや新規データセット利用の相談なども増えてきており（いたちごっこのような状況）、、、


今後のアクションとしては、今回実施したような教育プログラムを実施しつつ、
- データカタログの整備
- データ分析の認定制度
- 簡易に使えるダッシュボードの提供拡大

など、データ分析をしたいと思った人が自走しやすい環境を作ることも並行して進めていこうと思っています。

これら施策により、
- 個人のスキルアップと
- 仕組みとしてのフォローアップ

の両面を実現し、データに基づく意思決定をよりスムーズに実現していきたいと思います！

## 最後に

好評だったら、より具体的な話や、別のデータに関する取り組みも発信したいと思っています。

- この記事が役に立ったと感じた方は、ぜひいいねとフォローをお願いします！
- 質問などありましたら、お気軽にコメントください！
VSCode　インデント変更方法

VSCodeでインデントが細かくなっていて、既定のタブサイズに変更したいときの方法です。参考までにどうぞ！

インデントの幅が狭く、既定のサイズに戻したい！↓
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3680938/4ce9d213-b840-0f31-5f5c-d07855fb6737.png)


<h1>変更方法</h1>
１．右下のスペース押下

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3680938/e8845a2a-2b61-8a27-0838-9185ac3f97f8.png)

２．Indent Using Spacesを選択

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3680938/ba5a3ebf-c352-0dbe-8970-ce785deb935a.png)

３．4を選択して完了

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3680938/809b467f-3180-775b-46fc-286b25251dbd.png)
クリエーションラインって何している会社？

**「クリエーションラインは何をやっている会社ですか？」**

営業として交流イベントや新規問合せを頂いた際に、弊社を知らないお客様から頂く質問です。

どの業界の人でも自分の働いている会社をわかりやすく一言で説明するのは意外と難しいものです。SI会社に勤める人は親戚や知り合いに質問されて困った経験は一度はあると思います。

相手がIT業界の人なら伝えるのは専門用語を並べて何となく伝わりますが、魅力的に伝えることはさらにハードルが一段上がります。
　
クリエーションラインの説明として、アジャイル開発やクラウドネイティブ開発、さらにはAI駆動開発など技術領域で言うと答えることが出来ますが、其々の領域で見ると専門にしている会社があり、どうしても、全体としてもやっとした感が漂います。
   
 <br>
  
**そもそもクリエーションの支援とは？**
  
クリエーションラインは、少し抽象度が高いですが、ソフトウェア開発を通じてイノベーションの創出と事業価値を高めていく支援をしています。
そのためには、「技術」に加えて、「文化」、「人材」、「環境」の4つの変革が求められていると考えています。これは、弊社に出資頂いているデンソー様を始めとした大手の企業様の支援を通じて弊社自体も学び、社内の仕組みとして取り入れているものになります。


例えば、文化の側面では、弊社がフルリモートでの働き方のため、一層オープンなコミュニケーションを意識しています。お客様プロジェクトの機密情報や人事の個人情報以外は社長の打合せ議事録含めてオープンになっています。また、毎週月曜朝のWeekly 朝会では毎回ではありませんが、会社の経営状態の発表の後にグループに分かれての雑談タイムが設けられており感想を共有し合いながら、普段仕事上でやり取りがないメンバー同士で交流を深めています。

その他にもDOJOという技術力向上のため取組を行っており、技術勉強会や読書会が自然発生的に開催されて誰でも参加が可能な形になっています。社内でも文化や人の側面を大切にしている一例となります。

 <br>
 
![スクリーンショット 2024-12-09 101033.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3951006/ed74df0b-2714-f224-a13f-3eaee24b4d02.png)


 <br>
 
そんなクリエーションラインの支援のコンセプトは

**Co-Creation Sherpa -お客様との共創**
＝先端IT技術、文化、人材、環境の側面から包括的に伴走

お客様の真のイノベーションと事業価値の創出を実現するため、4つの重要な要素に焦点をあてた包括的なコンサルティング及び技術支援サービスを提供しています。


4つの要素とは具体的に何か？

**技術：最先端技術の導入と活用**
・AI技術の戦略的導入によるビジネスプロセスの最適化支援（AI駆動開発）
・クラウドネイティブ技術による柔軟かつな迅速なシステム構築
・データ駆動型意思決定を可能にする高度なデータ分析・活用支援

   
**文化：イノベーティブな組織文化の醸成**
・オープンコミュニケーションを促進する組織改革プログラム
・部門間の壁を取り払い、アイデアの自由な交換するワークショップ運営

  
**人：人材育成と知識共有の促進**
・最新技術スキルの習得を支援する教育プログラムの提供
・組織内での知識共有を活性化する施策立案及び実行支援

  
**環境：開発環境とプロセスのモダナイゼーション**
・最新のDevOpsツールとプラクティスの導入支援
・アジャイル開発手法の導入によるユーザー部門との密な開発支援

 <br>
具体的なお問い合わせの例でいうと、お客様が内製開発チームを立ち上げるため支援をしてほしい、とご相談頂いたケースをでは、システムとして何を創りたいかだけでなく、それ以外の要素にも踏み込んでお話させて頂きます。例えば、経営層からの期待値や内製開発チームの組成により達成したゴールなど大元の所を言語化することで、お客様が本当に達成したいことが見えてきます。そういった会話を重ねることで、クリエーションラインとして価値を出せる部分も踏まえてご提案しながら支援を進めていきます。

 <br>

決められたサービスに合わせてご提案を進めるのではなく、お客様の課題に応じてその都度カスタムメイドで支援内容を作りこんでいます。SaaSサービスのように見えるものがなくプロダクトアウトでないところが、冒頭の質問を頂いた際に一言で説明するのが難しい理由になります。（一言にすると、お客様課題に伴走する会社です、と抽象度が高く伝わらない事が多々ありました。）

 <br>
お客様に説明する資料もご紹介します。こちらの方がイメージがつくかもしれません。
 
 <br>
 
![スクリーンショット 2024-12-09 101055.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3951006/dde2cef0-81c8-055d-064c-dc0f596490f5.png)


 <br>
来年度は4つの側面を通じたお客様と共創をより発展させて、

 <br>
    
**Co-Creation Value - お客様のビジネス価値創造**
＝お客様と一緒にソフトウェアプロダクトと事業を創っていく支援にチャレンジしていきます。


これはプロダクトやサービス開発のコンセプト策定など初期段階から関わり事業にコミットしていきたい、という思いによるものです。今年から特定のお客様と「Co-Creation Value」というサービスで先行的に開始しており、活動としてより広げていく計画となります。
 <br>
 
https://www.creationline.com/services/co-creation-value/

 <br>
 

最後に、
「クリエーションラインは何をやっている会社ですか？」
この質問への答えは、

**「Co-Creation Sherpa ＆Co-Creation Valueです！」**


クリエーションラインの支援に興味を持っていただいた方はお気軽にご連絡下さい。貴社の方向性や課題に沿った支援を検討させて頂きます！


 <br>
 <br>

**あとがき - 少し補足**
技術支援の内容として少し補足させて頂くと、弊社の技術チームは領域に応じて其々のエキスパートが在籍しています。

・AI CoE チーム
・Agile CoEチーム
・クラウドネイティブ開発チーム
・アプリケーション開発チーム
・データ基盤チーム
・製品＆ソリューションサポートチーム
[翻訳] Apache Sparkにおけるパーティションサイズ設定の理解

[Understanding and Configuring Partition Size in Apache Spark \| by VivekR \| Medium](https://vivekjadhavr.medium.com/understanding-and-configuring-partition-size-in-apache-spark-3889ecb5259a)の翻訳です。

:::note warn
本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
:::

![](https://miro.medium.com/v2/resize:fit:720/format:webp/1*DohY0CBo7-nYO9Txw3-b7w.png)
*Apache Sparkにおけるパーティション ソース: [ProjectPro](https://www.projectpro.io/article/how-data-partitioning-in-spark-helps-achieve-more-parallelism/297)*

Apache Sparkの分散処理において、パーティショニングは重要な役割を担います。それぞれのパーティションのサイズは、Sparkジョブの効率性やパフォーマンスに影響を与えます。本書では、Apache Sparkにおいて、4つの鍵となる要素を考慮することで、パーティションサイズがどのように決定されるのかを探索します。これらの要素を理解することで、パフォーマンス改善のためにあなたのSparkアプリケーションを最適化する助けとなることでしょう。

1. **クラスターのコア数:** クラスターで利用できるコアの数は、パーティショニングに影響を与える主要な要素の一つです。デフォルトでは、Sparkはエグゼキューターで利用できるコアの数に基づいてパーティションを作成しようとします。コアを追加することで同時処理を可能にし、クラスター全体での効率的な並列性を実現します。
1. **データセットのサイズ:** 処理されるデータセットのサイズもまた重要な要素となります。Sparkはバランスの取れたワークロードの分散を実現するため、パーティションに対してデータを均等に分配しようとします。データセットが大きい場合、Sparkは効率的な処理を行えるように自動でパーティションの数を増加させます。逆に、小規模なデータセットでは、オーバーヘッドを最小化するために少ないパーティション数になることがあります。
1. **maxPartitionBytes:** `maxPartitionBytes`パラメータは、それぞれのパーティションの最大サイズをバイトで指定する設定可能なセッティングです。パーティションのサイズをコントロールするための上限値を指定し、過度に大きい、あるい極端に小さいパーティションを回避します。デフォルトでは、値は128 MB(134217728バイト)に設定され知ます。このパラメーターを調整することで、特定のワークロード特性やクラスターリソースに基づいてパーティショニングを最適化する助けとなります。
1. **openCostInBytes:** `openCostInBytes`パラメータは、計算処理の過程で新規パーティションをオープンする際のコストをバイトで定義します。パーティションのオープンや処理に関係するオーバーヘッドを表現します。デフォルトの値は4 MB(4194304バイト)に設定されています。このパラメーターを考慮することで、Sparkはデータセットのサイズや処理の要件に基づいて、最適なパーティション数をインテリジェントに推定します。

**例:** パーティショニングのプロセスを説明するための例を考えてみましょう。**8コア**のクラスターと**1 GB**のデータセットがあるとしましょう。デフォルトでは、Sparkは利用可能なコア数に基づいてパーティションを作成する場合があり、8パーティションが作成されます。しかし、`maxPartitionBytes`が**256 MB**に設定され、`openCostInBytes`が**2 MB**に設定されると、指定された`maxPartitionBytes`の制限に従い、`openCostInBytes`のオーバーヘッドを考慮することで、それぞれのパーティションサイズが約**128 MB**になるようなパーティションを作成するでしょう。

最終的なパーティション数を計算するには、以下の数式を使うことができます:

パーティション数 = データセットのサイズ / (パーティションサイズ + `openCostInBytes`)

パーティション数 = 1 GB / (128 MB + 2 MB)

パーティション数 = 1 GB / 130 MB

パーティション数 ≈ 7.69

パーティション数は整数値である必要があるため、Sparkは近い整数値に切り上げます。おのため、この例での最終的なパーティション数は8になります。

パーティショニングは、Apache Sparkのパフォーマンスの最適化における重要な側面です。コア数、データセットのサイズ、`maxPartitionBytes`や`openCostInBytes`を考慮することで、あなたのSparkアプリケーションのパーティショニング戦略をファインチューンすることができます。パーティションサイズがどのように決定されるのかを理解することで、優れたワークロード分布、並列どの最大化、全体的なパフォーマンスの改善が可能となります。
javascript の文字列の i 文字目と j 文字目を入れ替えるメソッド

javascript で文字列の
i 文字目と j 文字目を入れ替える処理を書くのに
時間をかけたくないため
メソッドにして公開します。

```javascript:i 文字目と j 文字目を入れ替えるコード
    function shiftString(targetString, i, j) {
        if(i < j) {
            return targetString.substring(0, i) + targetString.charAt(j) + targetString.substring(i + 1, j) + targetString.charAt(i) + targetString.substring(j + 1);
        } else if(j < i) {
            return targetString.substring(0, j) + targetString.charAt(i) + targetString.substring(j + 1, i) + targetString.charAt(j) + targetString.substring(i + 1);
        } else {
            return targetString;
        }
    }
```

シンプルに substring と chatAt で
文字列の i 番目と j 番目を入れ替えています。

簡単な処理ですが
地味に実装に時間がかかったため
皆さんにこの処理を実装するための
無駄な時間を取って欲しくないため
今回公開する事にしました。

短いですがこの記事はここまで。

この記事が皆さんがこの処理を実装するための
無駄な時間を削る事ができたならば嬉しいです。

閲覧ありがとうございます。

***

追記

コメント欄にて
もっとスマートな方法を提示頂きました。

そちらの方が完全に良さそうです。
i 文字目と j 文字目を入れ替えたい場合は
是非そちらをご利用いただければと思います。
AWSコンピューティングリソースの割引制度

AWSのコンピューティングリソースって、割引プランあるやん。

**リザーブドインスタンス** 、**スポットインスタンス** まではわかるねん。

でもな、**Savings Plans** ってなんやねん？！
リザーブドインスタンスとちゃうんか？！かぶっとるやん？！
なんでいきなり出てきたん？って思わんかった？

これらは全部「AWSをもっとお得に使おう！」っちゅう割引プランやけど、それぞれ性格が違うんや。

ほんじゃ説明していくで！

## リザーブドインスタンス（RI）

- 性格: 「予約席を取っとく感じ」
    - AWSのEC2とかRDSで、「このインスタンスを1年とか3年使う！」って予約することで安くなるんや

- 特徴:
    - 決まったインスタンス（例: t3.medium）を、決まったリージョンで使う
    - 使うか使わんかに関わらず、予約した分のお金は払わなあかん
    - 割引率はめっちゃ高い（最大72%オフとか）

- 向いてる人:
    - 「これから3年間、絶対このインスタンス使う！」って決まってる人
    - 飲み放題サブスクに入って、「毎日ビール飲むから元取ったる！」みたいな感じや

## スポットインスタンス

- 性格: 「空いてる席、安くゲットする感じ」
    - AWSの「使ってない余り物のインスタンス」をオークション形式で安く借りるねん

- 特徴:
    - めっちゃ安い（最大90%オフ）
    - いつ奪われるかわからん（AWSが急にインスタンス返せって言う）
    - バッチ処理やサーバーレスなジョブ向き

- 向いてる人:
    - 「安くても途中で止まってもええ仕事」に使う人
        - たとえば、一時的なデータ処理とか機械学習のトレーニングとか
    - ホテルの「空室があったら当日割引で入れる」プランやけど、宿泊途中で「部屋返して！」って言われるかもみたいな（んなことあるかい）

## Savings Plans

- 性格: 「ざっくりした節約プラン」
    - EC2やLambdaみたいなサービスの使う金額を1年とか3年で予約するプランやねん

- 特徴:
    - サービスやインスタンスの種類に縛られへん（柔軟！）
    - 毎時間の使用量に対して割引が適用される
    - 割引率はリザーブドインスタンスほど高くはない（最大66%オフぐらい）
    - インスタンスサイズを変えても適用される

- 向いてる人:
    - 「インスタンスの種類やリージョンは変わるけど、毎月これぐらいAWS使うな～」っていう人
    - 「月にどれぐらい食べるかだけ決めて契約する、定額ランチパス」みたいなもんや
        - 毎月「ランチ代を1万円以内に収めるわ！」って決めて、このパスを買うねん
        - 毎回のメニューはどれ選んでもええねん

## まとめ

| **項目**             | **リザーブドインスタンス（RI）** | **スポットインスタンス**       | **Savings Plans**       |
|----------------------|--------------------------------|----------------------------|--------------------------|
| **性格**             | 固定プラン                    | あまり物セール              | 柔軟な定額割引           |
| **コストの割引率**   | 最大72%オフ                   | 最大90%オフ                 | 最大66%オフ              |
| **制約**             | インスタンスとリージョン固定    | 突然止まる可能性あり         | 使うサービスは自由        |
| **向いているケース**   | 長期利用が確定してる場合        | 一時的な軽い仕事に使う       | ある程度使用量が安定している場合 |


- リザーブドインスタンスは「ガチガチ固定」
- スポットインスタンスは「超安いけど途中で切れるリスクあり」
- Savings Plansは「柔軟だけどそこそこ安い」

「とにかく柔軟に安くしたいならSavings Plans、長期でがっつり使うならRIや！」って感じやな！

ほな！
ある日突然Enterprize COBOLを使うことになった話

この記事は [**セゾンテクノロジー Advent Calendar 2024**](https://qiita.com/advent-calendar/2024/saison-tech) X日目の記事です。
シリーズ2は [**HULFT10**](https://www.hulft.com/software/hulft-10) のエンジニアによる投稿をお届けします。


はじめまして。
セゾンテクノロジーの清水です。
IBMのz/OSなどで開発を行っています。

今回は、開発であった体験（勘違い）からの学びを記事にしようと思います。

まず自分について前提をお話します。
- 古いCOBOLソースを開発維持している（30年くらい前のソース）
- コンパイラも古いものを引継がれ利用
- COBOLは、COBOL85とか古いものであるはず

Enterprize COBOLについて、自分はほとんど知らない状態でした（とても浅い知識）。
- z/OSのCOBOLは「Enterprize COBOL」っていうんだな
- かっこいい名前だ、機能もすごそう
- 前任から引き継いだCOBOLコンパイラで動いているので、意識をしたことはあまりない

# ある日突然
    「新z/OSあるから、新API呼んでEnterprize COBOL ソース書いてください」
自分（？）

      自分「あのう・・・古いCOBOLならわかるんですけど、Enterprizeがよくわからないんですが…」
      
      相談役「COBOL開発、できますよね？」
      
      自分  「はい・・・ですが、Enterprizeですよ？
         　　サンプルソース見ても知らないセクションとかあるし、まさかの小文字だし…」
      
      相談役「EnterprizeもCOBOL85もCOBOLですよ？」

  自分（あれ・そうだよな・・・自分はものすごく勘違いをしているのだろうか）


# やってみた①
サンプルソース（小文字）を元に自分の知っている命令でコーディングした（APIも呼ぶ）
驚くほどにすんなり完成
↓
出来た！
でも小文字が見づらくて、新しい技術を触っている感覚が抜けない（今後管理出来るのだろうか）
↓
試しに全部大文字にしてみた
コンパイル通った！しかも動いた！
しかも大文字になったので見やすい（MFのソースは大文字が当たり前）
見やすさが倍増、これなら管理できそう！（体感）


# やってみた②
試しに、最も古い（だろう）COBOLソース（リスト出力）をEnterprize COBOLでコンパイルしてみた
↓
LOADはできたなあ…
でも動くのかなあ…
↓
動いた！驚くほどにすんなりリスト出る

# まとめ
Enterprize という名前に気おくれして、「大きく機能差のある違うもの」だと思い込んでいた
そもそも、z/OS製品には旧互換があるという大前提が頭から抜けてた

# 学び・教訓
自分の知っている技術なのに、名称変更すると違うものだと誤認していたことに、気が付いた
自社製品であり、他社製品であり、名前が与える影響の大きさを知った、
また、名前変更をしたとしても実際はどうなのかを正しく理解しなければ、
せっかくのチャンスを逃がしてしまう可能性があることを身をもって知った、
正しくHPやマニュアルを読む必要がある

という体験を記事にさせていただきました。


最後まで読んでいただきありがとうございました。
Vite+Reactの環境構築を、nodebrewの導入からやってみた（Routerの導入まで）

## はじめに
二年目の竹村です。
最近、Reactを触り始めまして、今回は自宅のPCに色々と試せる環境を作ってみました。
参考となるサイトもあるので、比較的容易にできたのかなと思っています。
OSはUbuntu Studio 22.04なのですが、バージョンの管理がやりやすいnodejsのディストリビューションのnodebrewの導入から、初期構築、ページとURLを対応させるrouterの導入までやってみました。

## homebrewのインストール
https://brew.sh/ja/

homebrewが入っていない場合は、こちらの公式サイトから導入してください。
コマンド実施後、「==> Next steps:」に出てくるコマンドまで実施する必要があります。
ubuntuのインストール例はこちら。かなり丁寧に説明されています。
https://qiita.com/dev-cho/items/7a75e3852c4074a7db63

## nodebrewのインストール
https://formulae.brew.sh/formula/nodebrew#default

このページのコマンドを実行するとインストールできます。
基本的にはコマンド叩くだけでいいのですが、
私の環境では、パスを通す必要がありました。
nodeは既存のnodeのパスと紐付いていて、npmコマンドなどは使えない状態でした。
`nano ~/.bashrc`
を実行して、一番下の行に次の1行を追加して保存。
`export PATH=$HOME/.nodebrew/current/bin:$PATH`
下記コマンドで反映させました。
`source ~/.bashrc`
これら、問題なくパスがるようになりました！！
ChatGPTさんありがとう。
ただし、環境によっては不具合が出る可能性もあるので、すでにnodeを使っている場合なんかは気をつける必要がありそうです。
こんな形で出てきたら大丈夫です。
```
$ which node
/home/XXXXXX/.nodebrew/current/bin/node
$ which npm
/home/XXXXXX/.nodebrew/current/bin/npm
$ which npx
/home/XXXXXX/.nodebrew/current/bin/npx
```
nodebrewはプロジェクトごとに使用するnodeのバージョンが違っていても、容易にバージョンを切り替えることができるのがメリットです。



## ViteとReactの導入
https://monotein.com/blog/react-vite-how-to-use

こちらのページを参考としました。
言語選択のところでは、TypeScript+SWCを選びました。
npm installは結構時間がかかり、何回か私は取り消しして再度コマンド実行しました。
もしかしたら、気長に待つべきだったのかもしれません。
npm installを実施してnode_modulesディレクトリまで作られた状態で、VSCodeで開いてみました。
キャプチャはサンプルが記載されているページです。App.tsxにサンプルは記載されています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3946784/af0b91ac-cd3f-f796-9edd-ba35807f9cd9.png)
`node run dev`で起動させてブラウザで表示するとこんな感じです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3946784/7ccca84f-f197-fa70-8bea-ee0195ba2195.png)
ひとまず、今回はクリーンアップの前のところまで実施しました。

## react routerの導入
https://qiita.com/TMDM/items/0939ff52ab5b459303d7

react-router-domは、URLと呼び出されるクラスの対応づけを行うライブラリです。

App.jsがまずは呼び出されるのですが、そのApp.jsの中に分岐処理のように、URLと対応させたいページのクラスを記述することで、ページに対応するURLを設定できます。
今回は、App.tsxに記載されていたサンプルをHomeに移植し、`/home`と対応づけてみました。
また、複数のページが正しくルーティングさせるか確認するため、`/sample1`に対応した、Sample1クラス（こちらは、サンプルのカウントアップを押されるたびに2倍されるように書き換えただけ）を用意し、アクセスしてみました。
簡単に、ルーティングできますね。
App.tsxのコードはこんな感じです。
```
import './App.css'
import { BrowserRouter, Route, Routes } from 'react-router-dom'
import Home from './pages/home'
import Sample1 from './pages/Sample1'

function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/home" element={<Home />} />
        <Route path="/sample1" element={<Sample1 />} />
      </Routes>
    </BrowserRouter>
  )
}

export default App
```

画像だと見にくいですが、pagesというディレクトリを用意して、ページを増やしています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3946784/4c1dc5db-6f86-e00c-c7dc-99123717a219.png)
URLの末尾をhomeにするとこのようにHomeクラスの内容が表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3946784/722d5881-39c8-7531-7e40-6ebb4779a886.png)



## 今後の使い道
今回、ルーティングまで作成したので、今後は随時ページを追加してライブラリやロジックなどを試す環境として使用して行きたいと思っています。
以前、メディアアート系のP5.jsやサウンド系のTone.js触っていたので、その辺りも試してみたいですね。