OmniAICreator/Qiita-1.07M huggingface dataset:
上流工程のながれ

## はじめに
　本記事は、上流工程のながれについてざっとまとめてます。
 実務において、上流工程に携わった経験はないですが、プログラマー目線でみても設計は以下の理由で大切だと感じます。
 * この仕様どうだっけっていうときに、いつでも確認できる
 * 基本的に、チームで開発することがほとんどなので途中参加の人でも仕様を追える
 * 設計がしっかりしていると、コードの品質を高められる
 * プロジェクトに参加している人同士での意思疎通

## 企画
　それではまず、企画。お客様から「これでいきましょう～」という承認を得るためのフェーズです。
* お客様が抱えている現状の問題を明確し、この企画の「なぜ」必要かを理解する
* 「なに」をめざすのか、ゴールを明確にする
* 現状の問題を解決し、ゴールを達成するために、どんなプロダクトを作るか、それによってどんな成果が得られるかを明確にする

## 要件定義
　プロダクトを使う利用者のニーズを把握することで、システム開発に求められる要件を明確にするフェーズです。
* モデリング
    * 完成イメージを図を使って描きながら整理していくことで、解決すべき課題や細かなルールを洗い出し、それを全員で共有していくことがモデリングの目的。
    * ユースケース図→誰が、どういう操作を行うのかを明確化
    * アクティビティ図→具体的な運用プロセスの把握
    * 状態遷移図→システム内部で管理している状態の明確化
    * ドメインモデル→システムに登場する人や物を洗い出す
* システム開発の達成条件
* システム開発のスケジュール感

## 基本設計
ビジネス側とエンジニア側とで共通認識をつくるフェーズです。
* 画面設計
    * ユースケース図やドメインモデルから各画面でなにができるのかなどを画面遷移図を描いて整理していく。細かなデザインはデザイナーさんにおまかせ
* 機能設計
    * あるユースケースを実行する画面において、裏側で走る処理をまとめ、その処理に関連するデータをドメインモデルから洗い出す
* データベース設計
    * ER図→データベースに保存するためのデータ構造を表現（ドメインモデルをテーブル形式として定義しなおす）

## 詳細設計
エンジニア（プログラマー）に詳細な実装方法を伝えるフェーズです。
* ロバスト図→責務ごとに適切なクラスを割り当てる
* シーケンス図→割り当てられたクラスの中でどういう処理が実行されるかを考える
* クラス図→各クラスがもつ属性、メソッド、クラス同士の依存関係などを整理する

## おわりに
こうみると、抽象的だった要件定義から基本設計をふんで、より実装レベルに近い詳細設計へと落とし込んでいく流れが感じとれて面白いですね。
以上です。
CmBacktraceにおけるcall stack情報取得方法

## 1. はじめに

デバッグ時、特に例外等が発生した時に役に立つのが、関数呼び出しの階層(call stack)表示機能です。Cortex-M系では実行時にcall stackの情報取得はできないと思っていました(下記リンク先参照)。

https://www.miraxia.com/engineers-blog/arm-stackframe-based-backtrace/

最近Arduno Uno R4について調べていたところ、以下のファアイルを見つけました。

C:\Users\\%USERNAME%\AppData\Local\Arduino15\packages\arduino\hardware\renesas_uno\1.0.5\cores\arduino\cm_backtrace\cm_backtrace.c

オリジナルは、githubにありました。

https://github.com/armink/CmBacktrace

CmBacktraceでは、どのようにcall stack情報を取得しているかを調べてみました。


## 2. CmBacktraceにおけるcall stack情報取得方法

ソースを調べたところ、以下の処理を行っていることがわかりました。
1. 指定されたアドレス(SPの値)から、割り当てられたスタック領域の中で、最下位ビットが1になっているuint32_tの値を見つける。これはBL命令などを使ってThumb(T32)コードから関数を呼び出した時、LRには戻りアドレスの最下位ビットをセットした値が入るので、戻りアドレス値の候補となります。
2. 戻りアドレスがコード領域に入っていることを確認する。
3. 戻りアドレスの直前の命令が、関数呼び出しを行うBL命令あるいはBLX命令かをチェックする。もしそうであれば、それを順番に配列に格納する。

上記の処理はCortex-Mの関数呼び出し処理の性質を利用した方法なので、他のアーキテクチャでは利用できませんが、よく考えられていると感じました。

## 3. 最後に
このような方法でcall stackが取得できるんですね。機会があったら使ってみたいと思います。
1分でReactプロジェクトのImport Sortを導入する

## 概要
Reactでインポート文のソートをしたい！
そんな時にeslintやPrettierでソートすると思うけど、色々なプラグインがある。
[prettier-plugin-sort-import](https://github.com/trivago/prettier-plugin-sort-imports), [eslint-plugin-simple-import-sort](https://github.com/lydell/eslint-plugin-simple-import-sort), [eslint-plugin-import](https://github.com/import-js/eslint-plugin-import), [sort-imports](https://eslint.org/docs/latest/rules/sort-imports)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3491081/b1ea1049-ccca-9bdf-578f-147dea58980d.png)

一番人気でカスタマイズできるのは[eslint-plugin-import](https://github.com/import-js/eslint-plugin-import)だと思います。
しかし、今回はそんなカスタマイズする必要なく、早く導入したいと思ったので、[eslint-plugin-simple-import-sort](https://github.com/lydell/eslint-plugin-simple-import-sort)を使います！


https://github.com/lydell/eslint-plugin-simple-import-sort


## インストール

```bash
npm install --save-dev eslint-plugin-simple-import-sort
```

## 導入

`.eslintrc.json`

```json
{
    "plugins": ["@typescript-eslint", "react", "simple-import-sort"],
    "rules": {
        "simple-import-sort/imports": ["error"],
    }
}
```

グループでカスタマイズしたい場合

```json
{
    "plugins": ["@typescript-eslint", "react", "simple-import-sort"],
    "rules": {
        "simple-import-sort/imports": [
            "error",
            {
                "groups": [["^react"], ["^@?\\w"], ["@/(.*)"], ["^[./]"]]
            }
        ],
    }
}
```

こういう順番になる
1. react, react-dom, react-routerなど
2. パッケージやサードパーティーのインポート
3. Project alias import
4. Relative import


そうすると赤線が出てくるのでVscode上やセーブしたら自動でソートされます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3491081/0b3388b4-c7b2-606a-c566-4516c39b613f.png)

これで完成！
AtCoderで入茶&入緑しました！！　～競プロに取り組んだ4年間を振り返る～

# 0. はじめに
こんにちは、Shuntaです。
<font color="brown">**ABC268**</font>にて<font color="brown">**入茶**</font>し、<font color="green">**ABC332**</font>にて<font color="green">**入緑**</font>しました！！
入茶記事を書いていなかったのでそれと併せて書くことにしました。

![green.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1923849/723734be-e8f3-fa9a-9cdf-dab9af0065b2.png)

競プロ界隈では、Xに色変投稿すると数多くの方からいいねやお祝いコメントを頂けるので嬉しいですね！

https://x.com/bmd_SHUNTA/status/1733852574217027995?s=20

# 1. スペック（入緑時）
- 情報系の大学3年
- 数学検定準1級、基本情報技術者を保有
- 競プロはPythonがメイン

# 2. 2019年：AtCoderを始めたきっかけ
AtCoderを始めたのは2019年8月24日です。

一般的に友人や先輩、先生からの紹介でAtCoderを始めると思いますが、私の場合は特殊でした。数学が好きだったのでXで数学をやっている人と繋がっていました。

数学界隈のTLに競プロの話が流れてくるようになり、どんなものなのか気になって始めました。とはいえ、プログラミングのプさえ知らない状態だったので独学でPythonの勉強をすることにしました。

当時のABSで提出したPythonの[コード](https://atcoder.jp/contests/abs/submissions/7098148)を見てみましょう。
```python
a = input("please number")
b, c = map(int, input().split())
s = input("please word")

sum = int(a) + b + c

print({} {}.format(sum, s))
```

標準入力でわざわざ`please number`と聞いているのが可愛いですねw
本当にプログラミングのプさえ知らない状態でした。

やはり、難しいと感じたからなのか半年程度でやめてしまいましたが、それから3年後に再開するとは思いませんでした。

# 3. 2022年上半期：AtCoderを再開したきっかけ
私が大学2年の頃に学科内でも競プロが認知されるようになり再開しました。運の良いことに学科内での競プロ勉強会も開催され、モチベーション向上に繋がりました。

大学1年の頃に授業でJavaを勉強したこともあって、2019年の頃に比べるとプログラミングの知識は身についていました。やはり、基本って大切ですね。

# 4. 2022年下半期：入茶！！
入茶するために必要なことはプログラミングの基本を身につけることと、AtCoderに慣れる（参加回数を増やす）ことだと思います。特に、C問題を解けるようになることが重要だと思います。

# 5. 2023年上半期：アルゴリズムの勉強
入茶してからは、アルゴリズム力がないと厳しい問題に遭遇することが多くなりました。
アルゴリズムを勉強する上で、けんちょんさんの[鹿本](https://www.amazon.co.jp/dp/404604408X)は良かったです。

### 入緑までに身につけたアルゴリズム（習熟度は省略）
- bit全探索
- 二分探索
- BFS(幅優先探索)
- DFS(深さ優先探索)
- 累積和
- DP(動的計画法)
- 素数判定

# 6. 2023年下半期：入緑！！
入緑するために必要なことはABC3問の早解きか、ABCD4問を解けるようになることだと思います。そのために次のことを心がけました。

- A問題やB問題を沢山解く
- コンテスト終了後に自分の解法をXに投稿する
- 周りにいる競プロerと解法についてアウトプットし合う
    - 競プロ勉強会に参加

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1923849/23b65525-8d73-ef74-f0c5-54725c7595ea.png)

# 7. AtCoderに取り組んだ結果、起きたこと
## 7.1 他言語に触れ始める
入茶してからHaskellなど関数型言語を中心に様々なプログラミング言語に触れるようになりました。他人のコードを見たり、公式解説のコードを見たりしているとどうしても他言語を学びたくなります。

提出数が100を超えている言語を挙げると次の通りです。
- C++
- Haskell
- Java
- PHP
- Python

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1923849/9c8594ca-a223-e07c-d8f6-ba655139bfe3.png)

## 7.2 コードを書く習慣が定着する
ABCコンテストは基本的に毎週土曜日に開催されているためコードを書く習慣が身につきやすいです。次第に毎週土曜日だけではなく、毎日書くようになりました。以下の画像を見てみると157日連続取り組んでいることが読み取れます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1923849/3194f96e-1114-6393-c724-5800cfa56672.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1923849/6b0343c2-3eeb-91b8-4fbe-6e5ad6683318.png)

## 7.3 アウトプットするようになる

次のような記事を書きました。

https://qiita.com/NAVYSHUNTA/items/6c984d64c7dc7316f679

## 7.4 物事に対する考え方が変わる
競プロで養われたアルゴリズムそのものが直接役に立つ場面は少ないかもしれませんが、間接的にはめちゃくちゃ役に立つと感じています。物事に対する考え方が柔軟なものになったように感じます。

# 8. 今後について
学生のうちに入水を目指します。そのために必要なことは以下の3つを意識することだと思います。

- アルゴリズム力
- 早解き力
- 数学力

# 9. 最後に
競プロは楽しいぞ！！AtCoder最高！
最後までお読みいただきありがとうございました！
古いMagicKeyboardとMagicMouseのペアリング/アンペアリングをコマンド一発でやろう

## 経緯

Magic Keyboard(A1644) と Magic Mouse 2(A1657) を格安で購入したが、同時に1台のMacbookとしかペアリングできなかった...

これじゃあ会社のmacと私用のmacでいちいちペアリングとアンペアリングを繰り返さないと使えないよ！

## やること
`blueutil`というツールでコマンドラインからbluetoothを操作して複数のMacbook間でMagicKeyboardとMagicMouseのペアリング/アンペアリングをコマンド一発でできるようにする

## やり方

私用のPC -> PC1
会社のPC -> PC2
とします

### 1. PC1にMagicKeyboardとMagicMouseを接続する

接続したら設定.appとかでわかりやすく名前をつけておくといいです

![スクリーンショット 2023-12-15 19.26.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/679599/460efebe-7342-a275-cb7e-ec6933df16bc.png)

### 2. PC1で`blueutil`の設定

blueutilをhomebrewでインストールします

```zsh
brew install blueutil
```

ペアリングされたデバイスの一覧を確認してMACアドレスを控えます
（`**-**-**-**-**-**`の部分です）

```zsh
blueutil --paired

address: **-**-**-**-**-**, connected (master, 0 dBm), not favourite, paired, name: "まじっくきーぼーど", recent access date: 2023-12-15 10:25:40 +0000
address: **-**-**-**-**-**, connected (master, -61 dBm), not favourite, paired, name: "まじっくまうすに", recent access date: 2023-12-15 10:25:40 +0000
```

`~/.zshrc`とかでエイリアスを張ります
`**-**-**-**-**-**`をキーボードとマウスのものに置き換えて使用してください

```zsh
# magickeyboard, magicmouseの切断
alias 仕事の時間だ！！='blueutil --unpair **-**-**-**-**-** && blueutil --unpair **-**-**-**-**-**'
# magickeyboard, magicmouseの接続
alias ただいま='blueutil --connect **-**-**-**-**-** && blueutil --connect **-**-**-**-**-**'
```

`仕事の時間だ！！`でアンペアリングして、`ただいま`でペアリングします。
仕事の時間になったらPC1から切断してPC2の方で接続する感じです。

### 3. PC2でも同じことをする

PC2でも同様にblueutilをインストールしてください。
MACアドレスはデバイスに割り当てられているので同じものを使用できます。

エイリアスもいい感じに設定します。
```zsh
# magickeyboard, magicmouseの切断
alias お疲れ様です='blueutil --unpair **-**-**-**-**-** && blueutil --unpair **-**-**-**-**-**'
# magickeyboard, magicmouseの接続
alias おはようございます='blueutil --connect **-**-**-**-**-** && blueutil --connect **-**-**-**-**-**'
```

## 便利です

始業前に私用PCで`仕事の時間だ！！`、会社PCで`おはようございます`
終業時に会社PCで`お疲れ様です`、私用PCで`ただいま`
のように運用します。

これでリモートワークでも上手に気持ちを切り替えられますね。挨拶って素晴らしいです。


昔の機器でも工夫次第で安く買えて楽に使えるのでいいですね

（「エイリアス日本語でいけるんか...」という気持ちになった）
【iOS】個人アプリの大改修に立ち向かってみた。

# はじめに
この記事では、過去に開発したiOSアプリの大規模アップデートについての経験を共有します。特に、なぜこのタイミングでアップデートを行うことに決めたのか、開発プロセス、アップデートのリリースとその影響について焦点を当てています。自分の直面した課題とその解決策について詳述し、同様の状況に直面するかもしれない読者の方の参考となれば幸いです。
# 背景
## 改修前のプロダクト情報
### 開発環境
- 初回リリース：2018年
- 最終アップデート：2020年9月
- Minimum iOS Version：11.0
- プロダクトの規模感：小さい

### **改修を決意した理由**
リリース時に使用した広告SDKバージョンのサポート終了により、アップデートが必要となり、大規模な改修を決意しました。

# 改修方針
継続的なアップデートを行うための環境を整えることを目指し、以下の改修方針を決定しました。

### アーキテクチャ
- **MVVM**
    - 選定理由
        - 継続的なアップデートを行うため、責務分離を行いたい。
        - 自分自身がMVVMを少し勉強していた。
        - 他アーキテクチャに挑戦することも検討したが、プロダクト規模が大きくない
        - 継続的なアップデートを安定的に行いたいという理由で、挑戦的なアーキテクチャの採用は行わなかった。


### UIフレームワーク
- **SwiftUI**
    - 選定理由
        - 複雑なレイアウトは実装しない。
        - 少ないコード量で実装できる。

### サポートOS
- **iOS 15以上**
    - 選定理由
        - SwiftUIの機能制限がiOS15以前と比べて少なく、スムーズに開発を進めることができる。
        - 過去30日間のアクティブユーザーの中で、iOS15未満のユーザーが1%に満たなかったため。

### パッケージ管理
- **SwiftPackageManagerを使用**
    - 選定理由
        - 使用していたライブラリが全てSwiftPackageManagerでのインストールが可能だったため。

### ブランチ戦略
- **mainブランチをリリース可能な状態に保つ**
    - アップデートまでは、replace用のブランチを作成し、このブランチをデフォルトブランチとして設定してSwiftUIへの置き換えを進める。

このような方針で開発を進めることにしました。

# 改修後アップデートまでの道のり

### 1. プロジェクトファイルの捜索
プロジェクトデータの所在不明により、ファイルの捜索に時間を要しました。

### 2. ビルドが通らない
3年前のプロジェクトのBuildが一発で通るはずがありません。仕方なくコードを読み、Buildできる状態まで進めました。

### 3. GitHubのリポジトリが見つからない
GitHub上にリポジトリを作成していませんでした。そのため、このタイミングでGitHubにリポジトリを作成しました。

### 4. 改修後の初回アップデート
今回のアップデートでは、以下の機能を追加しました。これらの機能は、ユーザー体験への影響を最小限に抑えつつ、アプリの開発効率を向上させることを目的としています。

- **強制アップデートアラートの実装**
    - 目的
        - 古いバージョンの不具合による問題を避け、全ユーザーが最新版に移行することを保証するため。
- **ATT（App Tracking Transparency）の承諾率向上のための事前説明ダイアログ**
    - 目的
        -  ATTの重要性とユーザーへの影響を明確に提示することで、承諾率を高め、広告の効果的な配信を確保するため。
- **ATTダイアログ・強制アップデートアラートのローカライズ対応**
    - 目的
        - 本アプリは日本以外のユーザーも多いため、主要言語へのローカライズ対応を行なった。
- **GDPR同意ダイアログの設置**
    -  目的
        - EEAと英国のデータ保護規則に準拠しパーソナライズされた広告のためのユーザーデータ収集に同意を得るため。
- **Firebase Crashlyticsの導入**
    - 目的
        - アップデート後のアプリの安定性を監視し、迅速な問題対応を可能にするため。
- **Google Analyticsを用いたイベントロギングの追加**
    - 目的
        - ユーザー行動のデータを収集し、将来の機能改善やアップデートの計画に活用するため。


### アップデート配信後の影響
アップデート後のユーザー行動の分析により、アクティブユーザー数に大幅な減少は見られず、目標達成を確認することができました。

### 今後の展望
大規模な改修を経て、アプリの内部実装を更新し、機能改善と新機能の実装に向けた基盤を整えることができました。今後はこの基盤を生かして、アプリの規模を拡大できればと思います。

## 最後に
この記事で、長期間アップデートされていなかった古いプロダクトの改修の経験を共有しました。同じ課題に直面するかもしれない方々にとって、一つの参考になれば幸いです。

## 参考文献
https://zenn.dev/kamimi01/articles/handle_att_in_my_personal_projects#app-tracking-transparency-%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6

https://note.com/sociolego/n/n7803fe82fe53

https://support.google.com/admob/answer/10114014?hl=ja
自己証明書を利用しているHarborにイメージをプッシュする


学んだことや苦労したことを書いていきます。\
本記事は個人的な見解であり、筆者の所属するいかなる団体にも関係ございません。

# 0. はじめに
何かアプリケーションをテストする際に、よく自己証明書を利用すると思います。
例にもれず、自分もHarborを自己証明書を利用してテストしました。
コマンドで証明書の検証をスキップできれば良いですが、個別に設定ファイル等で設定が必要のものもあり、個別の対応は大変なので、今回は自己証明書をルート証明書として登録することにしました。

## 環境
### Harborサーバー
OS:Ubuntu20.04
k3sバージョン:v1.26.5+k3s1

### イメージpush実行サーバー
OS:Ubuntu20.04
Dockerバージョン:24.0.5

# 1. Harborのデプロイ
今回HarborはHelmを利用してデプロイしました。
本題ではないので、簡単な手順だけ載せておきます。
```
helm repo add harbor https://helm.goharbor.io
helm repo update
helm show values harbor/harbor > values.yml
vi values.yml　　　#適当に編集
helm install harbor harbor/harbor -f values.yml
```

# 2. イメージpush試行
Harborにイメージをデプロイする際には、docker loginコマンドを利用してHarborにログインしてプッシュします。
```
docker login https://harbor.example.com
Username:[ユーザー名]
Password:[パスワード]
Error response from daemon: Get "https://harbor.example.com/v2/": 
tls: failed to verify certificate: x509: certificate signed by unknown authority
```
証明書エラーがでましたね。
Dockerで証明書の検証をスキップするだけなら設定ファイルに記載でいいのですが、今後Kubernetesでイメージを利用することも考えて、OSにHarborの自己証明書をルート証明書として登録します。

# 3. 自己証明書の取得
HelmでHarborをデプロイした場合、`harbor-ingress`というSecretにca.crtが保存されています。
Secretなのでbase64エンコードもされているので、デコードが必要です。
```
kubectl get secret
harbor-core                    Opaque               8      
harbor-database                Opaque               1      
harbor-ingress                 kubernetes.io/tls    3  # これ
harbor-jobservice              Opaque               2     
harbor-registry                Opaque               2      
harbor-registry-htpasswd       Opaque               1      
harbor-registryctl             Opaque               0      
harbor-trivy                   Opaque               2      

kubectl get secret harbor-ingress -o jsonpath="{.data.ca\.crt}" | base64 --decode > ca.crt
```
これで自己証明書が取得できます。

# 4. 自己証明書をルート証明書として登録
取得した自己証明書を、イメージをpushするサーバーに登録します。
簡単な手段として、catで中身を表示してコピーします。

Harborサーバー
```
cat ca.crt
```
イメージをpushするサーバー
```
vi /etc/ssl/certs/harbor-private.crt
sudo update-ca-certificates
```
これで証明書が登録されました。

# 5. Harborにログイン、イメージをプッシュ
再度ログインを試行します。
```
docker login https://harbor.example.com
Username:[ユーザー名]
Password:[パスワード]

Login Succeeded
```
無事ログインできました。
ログインさえできれば、イメージのプッシュは通常のプッシュと変わりません。
```
docker push harbor.example.com/[プロジェクト名]/[リポジトリ名]:[タグ]
0fb012d45c76: Pushed 
1ad27bdd166b: Layer already exists 
[タグ]: digest: sha256:d8885a73e8a5fcfea3a89770e641069dd207082ce381a58571fc833a9adc3f0e size: 735
```
プッシュもできましたね。

# 6. まとめ
検証で自己証明書はよく使われますが、証明書の検証をスキップできないコマンドもあり、操作によっては設定ファイルの書き換えが発生するので、ルート証明書として登録してしまうと非常に楽です。
iOSのE2Eテストを並列で動かし、リリースサイクルを高速化した話

こんにちは、ソーシャル経済メディア「NewsPicks」の呉です。
この記事は [NewsPicks アドベントカレンダー 2023](https://qiita.com/advent-calendar/2023/newspicks) の17日目の記事です。
昨日は同じチームの西薗さんによる『[QAエンジニアが「開発者になる」と自動テスト運用は上手くいく - Uzabase for Engineers](https://tech.uzabase.com/draft/entry/fjkslIfcVRnLHizjc6BsuknsHSg)』でした！

---------
Qiita初ブログなので、まず簡単な自己紹介をさせてください。
普段はQAエンジニアをやっています。仕様のレビュー、テストの設計・管理・実行はもちろん、自動テストを書いたりもします。品質保証に関わる分野で幅広く関わっています。

今日の記事はiOSのE2Eテストの改善をテーマにした話です。

## 背景

NewsPicksではサーバーリリース時に自動E2Eテストを回しています。E2Eテストが失敗すると、テストの再実行を試み、あるいは手動テストで確認し、OKでしたらリリースを全適用するという流れになっています。そのため、E2Eテストの安定性と実行時間はリリースサイクルに大きく関わっています。


## 課題

約1年前、「[Firebase Test Labで動かしていたiOSのE2Eテストを実機で動かして安定化させたら開発者の喜びが爆上がりした話](https://tech.uzabase.com/entry/2022/12/14/181006)」で紹介されましたが、リリースサイクルを高速化するために実機iPhoneでの安定したE2Eテストを実行する取り組みが行われました。その後、リリース時にFirebase Test Labと実機で並行してE2Eテストの実行が行われ、どちらかが成功するとリリースを全適用するという手順となりました。
※E2Eテストの具体的な仕組みについては上記の記事にて詳しく紹介されておりますので、ご興味があれば是非あわせて読んでみてください。

平均的なテスト実行時間について実機は16分、Firebase Test Labは20分がかかります。確かに実機のほうが早く完了しています。
しかし、WebのE2Eテストの平均実行時間は現在7分となっており、そちらと比較すると倍以上かかっています。

さらに、もしテストが失敗すると、再実行してさらに（最低でも）16分が必要ということになります。
（テスト失敗時はテストを最初から再度実行するという直列の状態仕組みになっていました）

開発組織としては、より効率的に品質を担保するためにはさらにE2Eテストのケースを増やしたいという意向があります。
しかし、現状でもWebのE2Eテストと比較すると実行時間が長く、ケースを増やすとさらに実行時間が増えてしまうという大きな課題に直面していました。


## 取り組み

E2Eテストのテストケースを増やしてもリリースサイクルに影響しないには、まず実行時間を短縮しなければいけない。そのために、テストファイルの分割を考えました。今まで直列で動いていたE2Eのテストケースを依存関係のない3つのグループに分け、並列でFirebase Test Labで動かす仕組みに変えてしてみました。分割したE2Eテストは全て同じタイミングでスタートするため、理論上早く終わると考えられます。

実行時間の短縮と安定性が確認されるまでには実機で直列で動くE2Eテストもそのまま残して、分割したE2Eテストとの比較検証をしました。

## 検証結果
分割したE2Eテストが実際にサーバーリリース時に動くように適用されてすぐ、社内から「爆速！」「早い！」という嬉しい声が集まりました。

その後約1ヶ月間、障害やテストケースの不備が原因で不安定となった実行結果を除いて、計30回の実行結果を集計しました。
以下の表が分割されたA、B、Cと分割されていない実機のE2Eテスト、それぞれの所要時間と成功率をまとめた結果です。

| テストグループ | 実行終了までの平均所用時間 | 成功率|
|:-----------|:------------:|:------------:|
| A    | 8分36秒        | 96.7%         |
| B    |    10分22秒     | 96.7%         |
| C    |    ９分30秒     | 100%         |
| ALL(実機)    |    16分50秒     | 66.7%       |

実機と比べると、分割されたケースの方が６分以上も早く終わっていることが分かります。また、テストが失敗した場合の再実行もより早く終わります。
さらに、分割して実行することによって、E2Eテストの成功率が大幅に上がったことが分かりました。直列での実行より、ある程度依存関係のないグループに小分けしたほうが安定性が上がります。

その後もしばらくE2Eテストの実行結果を監視していましたが、やはりTest Labでの並列実行が実機の直列実行に比べて
- 成功率が高い
- テスト時間が短い
- 再実行が早い

という点に変わりがなかったので、iOSアプリの実機E2Eテストを廃止しました。
サーバールームに長く寂しく置かれていたiPhoneちゃん、遂に役目を終え、今度はテスト検証端末として生まれかわるのです。

## おわりに
今回はアプリのE2Eテストの実行に関する結果検証について話しましたが、次回はQAエンジニアになってから勉強したテスト設計ネタを書きたいと思います。

明日は@kirihataによる「Brazeでメール配信の最適化」の話のようです。お楽しみに〜
【Docker】エラー「copy file range failed: no space left on device」の原因と解決方法

# 概要

ローカル環境でテストのためにDockerコンテナ起動したり閉じたりを繰り返していたら、以下のエラーに。こちらの原因と解決方法を紹介します。

```
failed to solve: failed to copy files: copy file range failed: no space left on device
```

## 原因
デバイスにスペースがないよ、と言われていますね。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2710373/7f213ecc-6186-9589-8403-0998535fdbfa.png)

まずはDockerの利用状況を確認。

```
$ docker system df  
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          60        0         34.78GB   34.78GB (100%)
Containers      0         0         0B        0B
Local Volumes   11        0         1.211GB   1.211GB (100%)
Build Cache     565       0         20.95GB   20.95GB
```

Docker Desktopのextension「Desk usage」でも確認できます
(なぜかTotal Sizeにずれがあるけどタイムラグがあるのだろうか...updateしたら治りそう)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2710373/8495a209-dca8-5df1-2ab6-e25f6f6bc6ff.png)

Dockerの上限は、ホストマシンのディスク容量にも依存しますので、まずはホストマシンのストレージ使用状況を確認（dockerデーモンでも制限設定はできるみたい）。

コマンドでも確認できますし、「システム情報」→「ストレージ」でも利用可能容量がわかります。
確認すると、、残り5.8GBしか使えない状態だった...

そもそもストレージが残りわずか、というのも、Dockerで不要なファイルが多く一気に増えていたからかも。

ということで、私は念の為DockerDesktopから目視で削除していきます。
めちゃたまってる...

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2710373/12d313d7-3d86-c4a9-8c80-a4d11da520fb.png)

上記のnoneと出ているものは明らかに不要だったので削除。
もう一度利用状況を確認すると、だいぶ減ったことがわかります。

```
$ docker system df  
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          39        0         15.46GB   15.46GB (100%)
Containers      0         0         0B        0B
Local Volumes   11        0         1.211GB   1.211GB (100%)
Build Cache     267       0         21.15GB   21.15GB
```

Macホストマシンのストレージをみても、利用可能容量が32GBになったことを確認。
この状態で`docker compose up -d`を行うと、無事にイメージ作成ができました。

## ビルドキャッシュも削除！
後に、ビルドキャッシュも削除しました。

```
$ docker builder prune
WARNING! This will remove all dangling build cache. Are you sure you want to continue? [y/N] y
```

ビルドキャッシュとは、Docker イメージのビルド時に作成される一時的なキャッシュのこと。これらがあることで、以前ビルドしたステップが迅速に実行されたり、コンテナイメージの再現性が確保されたり、色々メリットはあるらしい。とはいえ、今回の削除対象は「未参照(`"dangling"`)」のものであって、もう使われていないもの。

20GBもあったので、もういいや！と思って削除したのですが、その後にイメージ再作成などの操作を行うと、以前より遅いような...余計なものまで消してしまったのだろうか（結果7GBは残っているので使っているキャッシュは残っていそうなのですが）。気のせいだと祈ろう。
Javaの開発に使用できるVSCodeの拡張機能や便利機能

# 1.はじめに
業務でVSCodeを使用したJavaの開発を行っていますが、
拡張機能やVSCode自体の機能をあまり知らない、活用できていないと感じたため、
もっと効率良く作業を行えるようにどのような機能があるのか調べ、
個人的に特に便利に思ったものをまとめました。


# 2.Javaの開発で便利な拡張機能
VSCodeでJavaの開発を行う場合、
「[extension pack for java](https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack)」という拡張パックをインストールすることで
Javaの実行環境を構築することができる。
この拡張パックには下記の拡張機能が含まれている。

| 拡張機能 | 概要 |
|:-:|:-:|
| Language Support for Java  | Javaの言語サポートを行えるようにする  |
| Debugger for Java  | Javaのデバッグ機能を追加する |
| Test Runner for Java  | テストコード(JUnit)を実行できるようにする  |
| Maven for Java  | ビルドツールのMaven を使用できるようにする  |
| Project Manager for Java  | Javaプロジェクト管理機能を追加する  |
| IntelliCode  | コーディングの支援、補完機能を追加する  |

　
　
　
その他コーディングに役立つ拡張機能
| 拡張機能 | 概要 |
|:-:|:-:|
| [change-case](https://marketplace.visualstudio.com/items?itemName=wmaurer.change-case)  | 選択したテキストをさまざまな大文字小文字の並びに一括変換|
| [Git Graph](https://marketplace.visualstudio.com/items?itemName=mhutchie.git-graph)  | Gitの機能をVScode上で行えるようにする  |
| [SonarLint](https://marketplace.visualstudio.com/items?itemName=SonarSource.sonarlint-vscode)  | コードの内容から不適切な記載等を指摘してくれる|
|[Code Spell Checker](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker)| 英単語のスペルミスを検出し、波線で表示する|



# 3.便利機能(ショートカット)
下記はVSCodeで開発をする中で使用して特に役に立った、作業効率の上がったと感じた便利な機能です。

| 機能 | ショートカットキー |
|:-:|:-:|
| ファイル内の検索  | Ctrl + F  |
| ファイル内の置換  | Ctrl + H  |
| フォルダ/ワークスペース全体を検索  | Ctrl + Shift + F  |
| フォルダ/ワークスペース全体を置換  | Ctrl + Shift + H  |
| フォルダ／ワークスペース内のファイルを開く  | Ctrl + P  |
| 定義箇所へ移動  | Ctrl + F12  |
| 参照箇所へ移動  | Shift + F12  |
| 矩形選択 | Ctrl + Shift + Alt + ↑/↓/←/→ |
| カーソル位置の単語選択 | Ctrl + D |
| カーソル位置の単語一括選択 | Ctrl + Shift + L |
| 行選択 | Ctrl + L |

# 4.終わりに
Javaの開発に使用できるVSCodeの拡張機能や便利機能をまとめました。
この記事を書いて知った機能もあり、これからの業務に役に立つ良い機会となりました。


# 5.参考
https://staffing.archetyp.jp/magazine/vscode/

https://supersoftware.jp/tech/20221017/17909/#:~:text=1.%E3%82%B7%E3%83%A7%E3%83%BC%E3%83%88%E3%82%AB%E3%83%83%E3%83%88%E9%9B%86&text=Ctr%20%2B%20P%20%2B%20shift%E5%BE%8C%E3%81%ABcase,%E3%82%92%E8%A1%8C%E3%81%86%E3%81%A8%E5%A4%89%E6%8F%9B%E3%81%A7%E3%81%8D%E3%82%8B%E3%80%82
[Nuxt v3] NuxtAuthでHeadersを追加する

## 結論
httpOptionsを使え
NextAuthでもNuxtAuthでも使える

```export default NuxtAuthHandler({
  secret: process.env.NUXTAUTH_SECRET,
  providers: [
    {
    ...
      httpOptions: {
            headers: {
              'X-Api-Version': 11,
            },
          },
        }
    ]
})
```

# きっかけ
VroidHubApiをNuxt3で使いたかった
でもリファレンスはNext製..

# Nuxt3でNextAuth v4を使いたい
普通に使う分には以下のライブラリを使えばOK
https://sidebase.io/nuxt-auth/getting-started

### リファレンスを元に移植
https://github.com/pixiv/VRoidHub-API-Example/
上記のコードを元にNuxtAuthを使ってNuxt3に移植しようと試みる
ただ、Next製でかつNextAuthのv3だった

### まずはNextAuthのバージョンをv3 -> v4へ書き直す

以下一部抜粋
```
params: { grant_type: 'authorization_code' },
accessTokenUrl: 'https://hub.vroid.com/oauth/token',
requestTokenUrl: 'https://hub.vroid.com/oauth/token',
authorizationUrl: 'https://hub.vroid.com/oauth/authorize?response_type=code',
profileUrl: 'https://hub.vroid.com/api/account',
```
これをこう
```
token: 'https://hub.vroid.com/oauth/token',
userinfo: 'https://hub.vroid.com/api/account',
authorization: {
    url: 'https://hub.vroid.com/oauth/authorize',
    params: { scope: 'default', response_type: 'code', grant_type: 'authorization_code' },
},
```

### Headersをどこに..?
NextAuthのv3にはheadersの項目が存在しているがv4にはない
調べてもカスタムのプロバイダーを使ってる記事がほぼない
コードから探すことにした

### 隠されたパラメータ
NextAuth v4のリファレンスにはなかった`httpOptions`を見つけた
使えるものは以下
```
export type HttpOptions = Partial<
  Pick<
    https.RequestOptions,
    | 'agent'
    | 'ca'
    | 'cert'
    | 'crl'
    | 'headers'
    | 'key'
    | 'lookup'
    | 'passphrase'
    | 'pfx'
    | 'timeout'
  >
>;
``` 

これでNuxt3でVroidHubApiを叩くことができた

### Sample
```/server/api/auth/[...].ts
import { NuxtAuthHandler } from '#auth';

export default NuxtAuthHandler({
  secret: process.env.NUXTAUTH_SECRET,
  providers: [
    {
      id: 'vroid',
      name: 'VRoidHub',
      type: 'oauth',
      version: '2.0',
      token: 'https://hub.vroid.com/oauth/token',
      userinfo: 'https://hub.vroid.com/api/account',
      authorization: {
        url: 'https://hub.vroid.com/oauth/authorize',
        params: { scope: 'default', response_type: 'code', grant_type: 'authorization_code' },
      },
      httpOptions: {
        headers: {
          'X-Api-Version': 11,
        },
      },

      profile(profile) {
        return {
          id: profile.data.user_detail.user.id,
          name: profile.data.user_detail.user.name,
          image: profile.data.user_detail.user.icon.sq170.url,
        };
      },

      clientId: process.env.CLIENT_ID,
      clientSecret: process.env.CLIENT_SECRET,
    },
  ],
  callbacks: {
    async jwt({ token, user, account, profile }) {
      if (account?.accessToken) {
        token.accessToken = account.access_token;
      }
      if (profile) {
        token.id = profile.id;
      }
      return token;
    },

    async session({ session, token, user }) {
      session.accessToken = token.accessToken;
      return session;
    },

    async signIn({ user, account, profile }) {
      console.log('signIn', user, account, profile);
      return true;
    },
  },
});
```
Datadog で表示/利用する時間を変更する


## はじめに

Datadog で各種メトリクスを確認している際に 表示される時間を UTC に変更し確認したい時があった。
変更方法が分からず色々なページを開いたり閉じたりしたので備忘録として書き残します。

## 表示/利用する時間を変更する

Personal Settings の Preferences 内 Time zone から変更可能でした。

https://app.datadoghq.com/personal-settings/preferences

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/55950/178af526-af9f-26ea-60ef-a34e6c34ef8a.png)

Change Time Zone をクリックすると Time zone 選択画面が表示されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/55950/f39248f3-cb4e-aa1e-417d-94cdcfecde5c.png)

Timezone を変更すると Metrics や Dashboard 等全ての画面上の時間が変更されます。
最近は UTC のみの表示しかサポートしていないツールは減りましたが、時々 Datadog 外のデータと突き合わすることもあり変更しています。

## Reference

- [Preferences | Datadog](https://app.datadoghq.com/personal-settings/preferences)
- [Account Management](https://docs.datadoghq.com/account_management/#preferences)
【Photoshop】白黒画像をカラー化してみた！

# はじめに

この記事は、株式会社スピードリンクジャパン Advent Calendar 2023 の16日目の記事です。

https://qiita.com/advent-calendar/2023/slj

# Photoshopで白黒画像をカラー化する方法
![スクリーンショット 2023-12-14 20.42.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3524155/c472cea7-e7bf-c55e-0926-3a2518d0c33e.png)
今回はPhotoshopで簡単に白黒画像をカラー化する方法について説明していきます。

## まずはカラー化したい画像を用意します
![スクリーンショット 2023-12-14 20.46.45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3524155/8d85cefc-a348-b4f9-7042-86bb0771fc9e.png)

## 「フィルター」→「ニュートラルフィルター」を押下
![スクリーンショット 2023-12-14 20.50.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3524155/60055bc1-a2c3-6de8-4c20-fb5680b53b06.png)

## 「ニューラルフィルター」パネルから「カラー化」を選択
![スクリーンショット 2023-12-14 20.51.33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3524155/bc20674c-fcdc-5af4-85ae-c873cf9e1781.png)

## これでカラー化ができました！
![スクリーンショット 2023-12-14 20.52.08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3524155/585e1a47-f17c-8548-e518-b154274c41aa.png)

## 最後に
簡単にカラー化できました！
PhotoshopのAI機能には他にも色々あるので是非他の記事も読んでみてください！
【1分でわかる】APIで繰り返し処理を行いたい

性能テストや耐久性テストで「テストデータを500件登録できることを確認したい。でも、curl叩こうにも認証ヘッダたくさんつけるのもめんどくさい」って時に便利なPostmanの機能を紹介します。
めっっっっちゃ簡単です。

# TL;DR
APIをイテレートするにはPostmanのRunner機能を使うとよい

# 手順
- イテレートしたいリクエストが格納されているコレクションの横の三点リーダーからRun collectionを押下

![スクリーンショット 2023-12-15 18.36.03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2779963/adcb6f8d-eae9-35fd-078e-8e5a28dee3ed.png)


- 以下、イテレートの設定を行いRunを押下
    - イテレートしたいリクエスト(今回なら、Post data)にチェック入れる
    - Run manuallyを選択
    - 試行回数(今回は500回)を入力

![スクリーンショット 2023-12-15 18.41.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2779963/270dcf1c-4271-e894-221e-9f4fb6c5ba51.png)

- 実行結果を確認する


View Results： 各イテレーションの詳細を示している。それぞれのリクエストがどのようにレスポンスされたか、具体的なHTTPステータスコードや応答サイズ、応答時間などのデータを確認できる。リクエストごとの成功または失敗のステータスもここで確認可能。

View Summary: テストの全体的な概要を表示する。全イテレーションを通じた成功と失敗の割合、テストの総実行時間、平均応答時間などの概要情報が含まれる。また、成功と失敗の分布を視覚的に表すバーがあり、どのイテレーションで失敗が発生したかを大まかに把握することが可能。


View Summary
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2779963/aebb76f7-da23-4732-a4e3-ba813b90bbf2.png)

View Results
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2779963/398a0690-4cfd-1f95-1da6-04f296a23da3.png)

終わりです！
Goでスクレイピングするのって...

# Goのスクレイピングとの相性
Goはスクレイピングと相性が良い側面と良くない側面があると思います。

## 良い側面
並行処理がとても得意な言語ですので、大量にHTTPリクエストを送る必要がある場合などでとても約に立つでしょう。しかし、単一ドメインに限られた時間内で大量のリクエストを送る行為は、DOS攻撃そのものですので、
意外とこういったユースケースは無いのかもしれません。

## 良くない側面
相性が良くない側面としては、言語として堅すぎるということです。
スクレイピングにおいてはある程度のゆるさも許容すべきだと思います。
自らの都合とは関係なく、取得先の都合で構造が変わるので、都度堅を定義するのは骨が折れます。
必要な値の`nil`チェックをするぐらいで十分な気がしますし、そうなるとPythonではなく、Goを使う理由が思いつかないのです...
VSCodeでショートカットキーを設定する方法

# まえがき
最近vscodeでasciidocやlatexといったものを利用して文章を長く書くことが多く，決まった関数や文字を何度も打つのが面倒になってきたのでショートカットキーを設定して，パっとすぐに関数や決まった文字列を打てるようにしたくなった．

手順としてはかなり簡単であったのが忘れた時ようにメモ感覚で残しておく．

# 手順1
まず初めに，vscodeでkeybindings.jsonを開く．

開き方は，コマンドパレット(［F1］キー全OSで共通．またはWindows／Linuxでは［Ctrl］＋［Shift］＋［P］キー，macOSでは［Command］＋［Shift］＋［P］キー）を開く．![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2110765/693d8626-7cee-c379-c6a8-30d6bd7d3b93.png)
そしたら空欄に「keyboard」と打つと，「基本設定：キーボードショートカットを開く（JSON）」をクリックすることでkeybindings.jsonを開ける．
※ここで注意が必要で似たような「基本設定：既存のキーボードショートカットを開く（JSON）」といったものがあるので間違えないように！！！

keybindings.jsonを開くと以下のようになる．
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2110765/dad42a31-57ab-93d3-5af0-902c7c4e7c71.png)
そしたら，以下のように書き込む．
これは「ctrl」+「j」を押すことで，「あいうえお」という文字が出力される．
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2110765/883f3489-1942-c7f1-2466-9e10aed5b869.png)


コピペ用
```
[
    {
        "key": "ctrl+oem_3",
        "command": "type",
        "args": {"text": "あいうえお"},
        "when": "editorTextFocus"
    },
]
```

※注意が必要で，右下にあるキーバインドの定義を使用すると．
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2110765/25928b4e-a80f-113e-330a-b3f4b2534d8a.png)
下の図のように出てくる．
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2110765/fe861dbc-ec8a-1961-a17a-ed60d7235c64.png)

「args」プロパティを追加することはみんながするだろうが，「command」プロパティを「type」に変更しないとちゃんと実行されない．

# ほんとのほんとの注意
もともとあるコマンドに上書きしてしまう形になるので，
コマンドパレットにも出てきた「ヘルプ：キーボードショートカットの参照」を見て必要のないコマンドにショートカットキーを設定するようにしましょう．個人的におすすめは，「ctrl」+「oem_3(＠キー)」とかかな．

# 実行結果
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2110765/870a076f-aa5f-6415-7c46-27285e8147cd.png)

# まとめ
長い固定文とか，よく使う？書く？のに微妙に長くて打つのが大変だったり，短くても半角全角を切り替えて打たなければならない固定文だったり，関数でも候補として出てこないようなものだったり，，そんなときに楽にしてくれる内容でした．
まあそもそもタイピングが早い人とかは，こんなこと思わないんだろうけど，，，
IBM i 実行管理概要

IBM i の実行管理は様々なレベルで調整が行われています。以下の図は主要なものをまとめています。
![68747470733a2f2f71696974612d696d6167652d73746f72652e73332e61702d6e6f727468656173742d312e616d617a6f6e6177732e636f6d2f302f313031313339342f39326137613430312d666233342d376661312d303039362d6233643536636465373732642.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1011394/ccb9b226-e6c3-6426-ea9c-5e0e67b6e307.png)

## IBM i システム全体の制御：システム値

システム全体を制御する目的で設定するものにシステム値 SYSVAL があります。
システム値には実行管理以外にも、セキュリティ、日付設定、ロギング設定、ストレージ閾値設定、言語設定、電源オフオン設定などがあります。
実行管理に関係するシステム値は　WRKSYSVAL SYSVAL(*ALC) と SYSVAL(*STG) SYSVAL(*SYSCTL)　のコマンドで表示できます。以下でごく代表的なものを記載します。

|システム値  |デフォルト値|説明 |コメント |
|---|---|---|---|
|QMAXJOB |163520 |1つのIBM i OS上で許可されるジョブの最大数。この値に達すると追加のジョブが開始できなくなる。| |
|QACTJOB |200 |システムIPL中にシステム全体で同時に実行可能なスレッド数 | |
|QBASACTLVL |147 |プール#2 ベースプールで同時に活動化できるスレッド数最大値。システム値QPFRADJが1,2,3に設定されている場合、システムが自動調整し常に変動する | |
|QSYSLIBL |QSYS QSYS2 QHLPSYS QUSRSYS |ジョブがデフォルトで参照するライブラリーのシステム関係部分 | |
|QUSRLIBL |QGPL QTEMP |ジョブがデフォルトで参照するライブラリーのユーザー部分 | |

システム値は全て、IBM i OS初期導入時にデフォルトが設定されます。設定値はCHGSYSVALコマンドで変更できます。
※変更不可のシステム値も存在。例：システム製造番号：導入したハードウェアのシリアルNO.が自動セットされます。

### ※（参考）現在は使われていないシステム値
|システム値  |説明 |コメント |
|---|---|---|
|QMAXACTLVL |システム全体で同時に実行可能なスレッド数 |現在のIBM i 7.xでは参照されません。（システム自動調整に変わっておりこの値は無視されます）Java等マルチスレッドプロラムが一般的になって以降、スレッド数での管理があまり現実的で無い事、ハードウェア性能がAS/400時代から劇的に向上したことなどが理由だと思います。 |

## サブシステムでの制御

個々のサブシステム記述 *SBSD に対話型、バッチ型など処理するジョブの特性に合った処理環境を設定します。
デフォルトでIBM提供の複数のサブシステム記述がIBM i OS上に存在している。これらをカスタマイズしてユーザー独自のサブシステム記述を作ることが可能。

|サブシステム記述 SBSDの設定  |デフォルト | 説明　| コメント |
|---|---|---| ---|
|POOLS 記憶域サイズ | SBSで異なる |ジョブが実行されるメインメモリのサイズ |  |
|POOLS 活動レベル |SBSで異なる|プール内で同時に実行できるスレッドの最大数||

サブシステムの設定はCHGSBSDコマンドで変更できる。（実際に利用（開始）するにはSTRSBSコマンドで実行が必要）
サブシステムで設定する主な設定は以下
　- サブシステムで実行するジョブが使用するメインメモリのプール指定
　- サブシステム内で同時実行可能なジョブ数 MAXJOBS
　- ジョブの開始方法（別途説明します）
　- サブシステム内で実行するジョブの処理環境を細かく指定するための経路指定テーブル（後述）
　- 対話型サブシステムではこのサブシステムに接続させる端末ID、端末タイプ

## ジョブ単位の制御

ジョブ記述によって、個々のジョブの実行特性を指定します。
デフォルトでIBM提供の複数のジョブ記述が存在します。これらをCHGJOBDコマンドで修正したり、コピーしてユーザー独自のジョブ記述を作ることも可能。
ジョブ記述の例をいくつか示します。

|ジョブ記述の項目 | JOBD名  |デフォルト | 説明　| コメント |
|---|---|---| ---| ---|
|ジョブ待ち行列JOBQ | QGPL/QDFTJOBD  | QGPL/QBATCH |バッチジョブその他、最も一般的なジョブが投入された際のデフォルトとして使用される |  |
|出力待ち行列OUTQ | QGPL/QDFTJOBD | *USRPRF | *USRPRFはジョブのユーザープロフィールで指定されたOUTQを使用 | ユーザープロフィールを業務単位（営業業務、経理業務等や、地域別のユーザー、本社・子会社・関係会社等とし夫々に別なOUTQ割当することは多い |
|初期ライブラリーリスト | QGPL/QDFTJOBD |  *SYSVAL | システム値QUSRLIBLに指定したライブラリーを参照する | |

上記以外にジョブ記述では以下のような指定も行います。
    - 経路指定データ（後述）
    - ジョブ日付
    - ジョブ待ち行列内でのジョブスケジュール優先順位
    - ジョブにより作成されるスプールファイルのOUTQ内での出力優先順位

※ジョブ記述 JOBD の理解はIBM i の実行管理の仕組みを理解する上で重要です。

## クラス

前の記事
 [活動レベル中でのCPUのディスパッチ](https://qiita.com/gomAnomalocaris/items/d6f485a80772affd98f6) で説明した、クラス CLS も実行管理機能の一つです。
 個々のジョブのCPU タイムスライス値やCPU内の実行優先順位を指定しています。

次の説明では具体的なサブシステムを挙げて、ジョブの実行環境がどのように決まるかを説明したいと思います。
【AWS】  EC2とRDSを自動的に停止・起動させる

# はじめに
EC2インスタンスとRDSデータベースを**EventBridgeScheduler**を使用し、自動停止・自動起動させる方法です

# IAMの作成
## ポリシーの作成

1. IAM＞アクセス管理＞ポリシーから「ポリシーを作成」をクリック

### ステップ１：アクセス許可を指定

1. 「ポリシーエディタ」はビジュアルを選択
2. サービスを選択
    - RDSの場合
        1. 「サービスを選択」からRDSを選択
        2. アクション許可から下記二つを選択
            
            ```markdown
            StartDBInstance
            StopDBInstance
            ```
            
        3. リソースから「特定」を選択し、右にある「このアカウント内のいずれか」にチェック
    - EC2の場合
        1. 「サービスを選択」からEC2を選択
        2. アクション許可から下記二つを選択
            
            ```markdown
            StartInstance
            StopInstance
            ```
            
        3. アクション許可から**StartInstances**、**StopInstances**を選択
        4. リソースから「特定」を選択し、右にある「このアカウント内のいずれか」にチェック(instance,license-configurationどちらも)
3. 「次へ」をクリック

### ステップ２：確認して作成

1. 「ポリシーの詳細」からポリシー名を入力
2. 「ポリシーの作成」をクリック

## ロールの作成

1. IAM＞アクセス管理＞ロールから「ロールを作成」をクリック

### ステップ１：信頼されたエンティティを選択

1. 信頼されたエンティティタイプから「カスタム信頼ポリシー」を選択
2. `scheduler.amazonaws.com`を許可する
    
    ```markdown
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "Service": "scheduler.amazonaws.com"
                },
                "Action": "sts:AssumeRole"
            }
        ]
    }
    ```
    
3. 「次へ」をクリック

### ステップ２：許可を追加

1. 検索欄から先ほど作成したポリシーをチェック

### ステップ３：名前、確認、および作成

1. 「ロールの詳細」からロール名を入力
2. 「ロールを作成」をクリック

# EventBridgeSchedulerの設定

1. Amazon EventBridge＞Scheduler＞スケジュールから「スケジュールを作成」をクリック

### ステップ１：スケジュールの詳細と指定

1. 「スケジュール名と説明」からスケジュール名を入力
2. 「スケジュールのパターン」から以下を設定する
    - 頻度：定期的なスケジュール
    - スケジュールの種類：cronベースのスケジュール
    - cron式：設定したい時間
        
        ```markdown
        例：EC2を止めてからRDSを止める、RDSを開始してからEC2を開始するように設定した場合
        
        EC2ストップ：cron(45,18,?,*,FRI,*) -> 毎週金曜18:45
        RDSストップ：cron(50,18,?,*,FRI,*) -> 毎週金曜18:50
        RDSスタート：cron(50,8,?,*,MON,*) -> 毎週月曜8:50
        EC2スタート：cron(55,8,?,*,MON,*) -> 毎週月曜 8:55
        ```
        
    - フレックスタイムウィンドウ：オフ
3. 「次へ」をクリック

### ステップ２：ターゲットの選択

1. 「ターゲットの詳細」から全てのAPIを選択
2. サービスを選択
    - RDSの場合
        - 開始の設定：全てのAWSのサービス＞AmazonRDS＞StartDBInstanceを選択
        - 停止の設定：全てのAWSのサービス＞AmazonRDS＞StopDBInstanceを選択
    - EC2の場合
        - 開始の設定：全てのAWSのサービス＞AmazonEC2＞StartInstancesを選択
        - 停止の設定：全てのAWSのサービス＞AmazonEC2＞StopInstancesを選択
3. それぞれのサービスに渡すパラメータの設定
    
    ```markdown
    {
      "InstanceIds": [
        "DBインスタンスIDを入力"
      ]
    }
    ```
    
4. 「次へ」をクリック

### ステップ３：設定

1. 「アクセス許可」から既存のロールを選択
2. 先ほど作成したロールを選択
3. 「次へ」をクリック

### ステップ４：スケジュールの確認と作成

1. 「スケジュールを作成」をクリック

---
### 参考資料

[AWS EC2インスタンスの起動・停止をスケジュール実行してみた - Qiita](https://qiita.com/tbtakhk/items/52c81688884f4a1a9325)

[【AWS】RDSを自動停止・自動起動させる方法まとめ - Qiita](https://qiita.com/YuukiYoshida/items/bc4fe61bc8809d34f226)
【AWS】EC2をResourceSchedulerで自動起動させる

## はじめに
ResourceSchedulerを使用すると、`毎日9:00にインスタンスを開始、17:00にインスタンスを停止`というようなスケジュールを組むことができます。
注意事項として`月曜日の17:00にインスタンスを開始、火曜日の9:00にインスタンスを停止`というような、翌日にまたがったスケジュールを組むことは可能ですが、`月曜日の9:00にインスタンスを開始、金曜日の17:00にインスタンスを停止`など、大幅に日をまたぐ設定は出来ないようです。

## 手順
1. **AdministratorAccess**でコンソールに入る
2. **Systems Manager**を開く
3. Quick Setup(高速セットアップ)を選択
4. 自身のホームリージョンを選択して使用開始
    ![スクリーンショット 2023-11-27 13.58.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2534018/9ca4de50-2f87-7593-0d51-926e87cf3737.png)
5. ResourceSchedulerから作成をクリック
    ![スクリーンショット 2023-11-27 10.49.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2534018/8150a28d-1635-d23c-bf31-b938cf4cb660.png)    
    - アカウントにすでに 1 つ以上の設定がある場合は、まず**[設定]** セクションで **[ライブラリ]** タブまたは **[作成]** ボタンを選択し、カードを表示します。
6. **[Instance tag]** (インスタンスタグ) セクションで、スケジュールに関連付けるインスタンスに適用されるタグのキーと値を指定します。
    ![スクリーンショット 2023-11-27 13.46.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2534018/9966422f-e58b-4949-6f5a-fcc3aa5cc2a7.png)
7. **[Schedule options]** (スケジュールオプション) セクションで、インスタンスを起動および停止するタイムゾーン、曜日、時刻を指定します。
    - 時刻は5分以上
    - 日を超える場合は夜通し行われる
8. **[Targets]** (ターゲット) セクションで、スケジュール設定の対象を、組織単位 (OU) の **[Custom]** (カスタム) グループにするか、ログインしている **[Current account]** (現在のアカウント) にするかを次のように選択します。
    - **[Custom]** (カスタム) – **[Target OUs]** (ターゲット OU) セクションで、スケジュールをセットアップする OU を選択します。**[Target Regions]** (ターゲットリージョン) セクションで、スケジュールをセットアップするリージョンを選択します。
    - **現在のアカウント** – [**Current Region** (現在のリージョン)] または [**Choose Regions** (リージョンの選択)] を選択します。**[Choose Regions]** (リージョンを選択) を選択した場合は、スケジュールをセットアップする **[Target Regions]** (ターゲットリージョン) を選択します。
9. **[Summary]** (概要) セクションのスケジュール情報を確認します。
    ![スクリーンショット 2023-11-27 13.51.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2534018/43b8d0bb-c493-98b1-3a92-84e24f459977.png)

10. **[Create]** (作成) を選択します。
    ![スクリーンショット 2023-11-27 14.00.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2534018/ab30d538-1344-fc58-049d-e42de0c61792.png)

    - 少し時間がかかりそう(テストでは2分)なので余裕持って設定しておく方が良さそう
    - 作成した瞬間にインスタンス停止する
        ![スクリーンショット 2023-11-27 14.02.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2534018/18a9a49b-de7a-1692-a16b-fe652b495f22.png)
    - 設定時間になった瞬間実行中になるわけではなく、停止中→保留中→実行中と徐々に開始される

## 削除に関して

![スクリーンショット 2023-11-27 14.12.47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2534018/e65aaaf8-b765-cefe-b24f-26a9a67c134c.png)
![スクリーンショット 2023-11-27 14.14.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2534018/4180edb4-50ce-61a0-5d63-92c57b431c15.png)
- 内容によるが時間かかると思っていた方がいい
- インスタンスは削除する前の状態から変わらない
    - 停止中に削除したら、インスタンスは停止したまま

---
### 参考資料
 [Amazon EC2 インスタンスリソーススケジューリング - AWS Systems Manager](https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/quick-setup-scheduler.html)
LEGO Education SPIKE App3はクソ！

## はじめに
　いきなりタイトルから過激なことを書いてしまいました。しかし、これは私が高校の部活で本当に感じたことです。そのことについて紹介します。

### LEGO Education SPIKEとは？
　全く知らない人のために説明します。こんな感じのロボットを作ったりして、プログラミングや機械設計について学ぶことができます。私が通っている高校の部活では、これで宇宙エレベーターロボット競技会に出場したりしています。
![IMG_2353.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2942430/afa0a0f9-81a1-315e-c785-b0ecca8b0560.jpeg)

## どこが良くないと思うのか
　プログラミングするために使うアプリが新しくなりました。(App2→App3)新しくなったのはいいものの、以前のバージョンから明らかに機能縮小していると思われる部分があるのです。以下に例をいくつか紹介します。

### モーターペアのワードブロックで、パワーを指定できない
　ニッチな話なのですが、「スピード」で指定するよりも「パワー」で指定するほうがより早く、より強く回せるという事情があります。

#### App2(Legacy)の場合
　「移動拡張」を有効にすると「パワー」で指定することができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2942430/d98d6235-62c4-8df0-b552-4c162c3b8d54.png)

#### App3の場合
　「移動拡張」を有効にしてもApp2にあったワードブロックがありません。というか、減りすぎじゃないですか！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2942430/2d73a673-214a-ebda-b908-618cdb3004eb.png)

### MicroPythonでプログラミングすると、パワーを指定する方法がない
　これは、びっくりしました。単一モーターの制御でも、モーターペアの制御でもパワーを指定することができなくなりました。App2(Legacy)でパワーを指定する場合は以下のプログラムになります。
```python:単一モーターの場合
from spike import Motor

motor = Motor("A")
motor.start_at_power(100)
```
```python:モーターペアの場合
from spike import MotorPair

motor_pair = MotorPair("A", "B")
motor_pair.start_at_power(100, 0)
```

### ハブの中に保存されているプログラムを確認したり削除したりできない
　これは地味に不便ですね。なくてものすごく困るというわけではないのですが、今までできていたことがApp3でできなくなるのはどうかと思いました。

## 代替案
1\. MicroPythonでプログラミングするのをやめて、ワードブロックの単一モーターで頑張る。
2\. ファームウェアを無理やりLEGO MINDSTORMS Robot Inventor（以下、マインドストーム）用のものに書き換える。

　私が考えたところ、この二つになると思います。二つ目の案に関しては、マインドストームのハブと中身が同じことと、App2(Legacy)と同等、もしくはそれ以上の機能があることから、有効だと思います。ファームウェアの書き換え方法は以下の記事で紹介しています。

https://qiita.com/cyber-yuito723/items/2346b5d068aa5d7ea6e5

## おわりに
　私の場合は、機能が少ないことにイライラして速攻でマインドストーム用のファームウェアに書き換えました。簡単なのでぜひ皆さんも試してみてください。また、今後の機能追加や機能改善に期待したいところですね。
Mixtral-8x7Bを試してみました。

最近話題となったMixtralを先日試してみました。
MixtralとはMistral-AIが「MOE（Mixture of Experts）」をベースで作ったモデルで、性能としてLlama2-70BとGPT3.5を超えてると言われてます。
MOEについて、私も初めて知りましたが、実はかなり前からあった技術みたいです。
中身は複雑ですが、簡単に言うと、複数のモデルを用意し、問題によって最適なモデルだけ使って回答する仕組みです。（アンサンブルの改善版みたいな感じです。）

例えば今回Mixtralの場合だと、パラメーターが違うMistral7Bモデルを8個準備してルーターネットワーク（メインで処理を行うネットワーク）にします。その後、処理するtokenが入った時に、ルーターネットワークの8つMistralから最適な２つを選んで回答し、それら回答を加算して最終outputする仕組みです。
先日試したのは元サイズ（32bit）と4bit量化バージョンです。元サイズだとメモリーが160GBかかりますので、試せる公開サイト（poe）で試しました。
Mixtralの特徴は処理時間が速い、コーディングスキルが高いです。
難しいコーディング質問は私も知らないので、試してなかったです。基本的な会話、数学問題、コーディングは他の70Bモデルと同じくらいスペックだと感じてました。(下図)

![12-13-13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3556459/28467ec6-8f99-2232-4229-6ff591735c7f.png)

一番びっくりしたのは処理速度の速さです。ほぼ一瞬で回答を生成します。（Mixtralは処理中に2個のモデルだけ使ってますので、実際推理する時は13Bのパラメーターだけ使います。発生するリソースも13B程度なので当然速くなります。）
ちなみに、日本語は対応してないです。（理解はできますが、回答は英語）
量化バージョンはcolabで実行して試しました。（処理中は37GBくらいメモリーかかりました）
ホームページに書いた「量化しても性能あまり落ちてない」のは確かに気づきました。Llama2-70Bを量化して使うと、すぐ理解力が下がっってるのは感じましたが、Mixtralはあまり変わってないような気がします。
Mixtralは同じモデルのミックスでこんなに変わりますので、違うモデル間のMOEならどうなるのか楽しみですね。



Misxtral reportについて：

https://mistral.ai/news/mixtral-of-experts/
Slackに日付教えるよbotをいれてみた


# はじめに
赤ちゃんエンジニア用の技術メモです。
今日の日付を教えてくれるbotが欲しい！と思ったのでやってみる。
（タスクバーをみたら分かるじゃん。とは言わせない）

## 使用したもの
・Microsoft Power Automate
・Slack

## 作成したフロー
### 完成したもの
とってもシンプル。

![PowerAutomateフロー.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3586761/f2771361-bdcb-8228-2299-3bd1893e2c45.png)



手順をメモ
### ①スケジュール設定
スケジュールは出勤日の月曜から金曜に。
画像では0:00にフローが動くようにしていますが、始業時間に変更しました。

![フロー内容_スケジュール.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3586761/37b2c8c0-19b8-c6ae-b386-6a1fe9d288da.png)


### ②Slackにメッセージを投稿
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3586761/c8ab9232-4ef1-c0c5-ee33-dfd6723d79b3.png)


▼formatDataTimeの詳細
日本語で曜日を表示したくformatDateTime()の第三引数で'ja-jp'を指定しました。
```
formatDateTime(convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time'), 'MM/dd dddd','ja-jp')
```
## つまづきポイント
メッセージをSlackに投稿する箇所でエラー。チャンネルが見つけられないとのこと。

```
"error": "channel_not_found",
```

鍵付きチャンネルだからか？
と思ったがプライベートチャンネルの場合はチャンネル名をカスタム値として使用すればOK。

Slackチャンネルにbotでなくユーザーとして投稿する事は出来た。
（手順メモ②の詳細パラメーターを追加）

が、botなのか私自身の発言なのか分かりにくい。
チャンネル自体見つけられないことから権限まわりが怪しい。

## 解決策
botを入れたいチャンネルに「Microsoft Power Platform Connectors」を追加。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3586761/64c290cf-f10b-8df7-c17e-2d2d15e822a6.png)


チャンネル上部からインテグレーション＞アプリの追加から「Microsoft Power Platform Connectors」を選択。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3586761/f298e52a-e448-0ab3-6198-edcc9a3d3800.png)

あっさり。

## 完成！
これで日付を教えてくれるbotを無事入れる事ができました！嬉しい！
がんばろ～

![bot_隠しあり.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3586761/5d67ab4e-bbe7-7332-a444-a3ef70cd8a1b.png)
GitHub Copilotを会社に導入するために

この記事をご覧の方々はGitHub Copilot使っていますでしょうか。
執筆段階でQitaにも`githubcopilot`タグがついた投稿は100を超えており、流行ってきていると言えるのではないでしょうか?

我々も9月からGitHub Copilot導入を進めており、組織内のエンジニアチーム約15人でトライアル運用を実施しました。

おそらくCopilotの使い方, 有効性は他に記事があると思いますので会社としてCopilotを導入するための気にしどころ、上司を説得するための材料を説明できればと思います。
以降は全て2023/12時点の話であり、今後変わる可能性があることを念頭に置いていただければと思います。

## 著作権、セキュリティ
GitHub Copilotの導入に向けて最初に気にするのはセキュリティ面になるかと思います。
自社のコードが学習に使用されるか否か、セキュリティ的に問題ないかは非常に大きいと言えます。
上記含めた気にしどころをいくつか抜粋します。
[抜粋元1](https://github.com/features/copilot/#faq), [抜粋元2](https://docs.github.com/ja/copilot/overview-of-github-copilot/about-github-copilot-individual)

- GitHub Copilotはプライベートコードを学習に用いない
- GitHub Copilotのデータは150字以上の公開コードと似通った提案を抑制するフィルターがある
- GitHub Copilotが出力したコードはGitHub社のものではない
- GitHub Copilotが出力したコードは自身で判断する

特にプライベートコードを学習に用いないというのは最低条件になる企業も多いと思いますのでそこは守っていただいている認識です。また、ソースコードがpublicリポジトリであろうと一致しないようなフィルターがあるというのもソースコードを作成する上では非常に心強いかと思います。

しかし、全てにおいて言えることですがAIの出力するデータはあくまで参考であり最終判断は人間が行います。
古い書き方、バグ、脆弱性などなどをAIは提案してしまう場合があり、それを除外するのは人間の仕事です。
GitHub自身がCopilotはプログラマーの補佐であり、プログラマーでとってかわる存在(auto pilot)ではないと宣言しています。

## 使用感
では実際の使用感はどうでしょうか?
個人開発ならともかく会社開発だと様々な制約がかかる人も多いかと思います。

GitHub CopilotはIDEと統合して、Gitのアカウントを紐づけて使用します。
VSCodeが統合先としてはメジャーですが下記に現状は対応しています。

- Azure Data Studio
- JetBrains IDEs
- Vim/Neovim
- Visual Studio
- Visual Studio Code

VSCodeは拡張機能に入れる関係でリポジトリのGitアカウントとCopilotが使用できるGitアカウントは別々でも問題ありません。
特に取引先の都合でGitアカウントを分けなくてはいけない人たちには役立つハックとなります。
逆に言うと個人アカウントと企業アカウントを分けていてもCopilotを使えてしまうので導入を見送った際は個人での連携を禁止しないと使われてしまう危険もあります。

## 費用面
GitHub Copilotの費用は1ヶ月辺り19ドルとなります。[参考](https://docs.github.com/ja/billing/managing-billing-for-github-copilot/about-billing-for-github-copilot)(2023/12現在)
1ドル140円換算で1人当たり2600円前後です。
課金単位はユーザー単位で割り当てられるので希望者のみやコードをメインで書くメンバーなど柔軟に割り当てられます。トライアルを少人数で始めやすいのもメリットです。
また、オーガナイゼーションで課金が始まった際に個人で契約していた方々は日割りで返金されますので2重契約や個別に解約する必要もないのはうれしいですね。

ちなみにGitHub Copilot Chatは上記に紐づいており、Public Bata版の現在はGitHub Copilotに付属しています。

## 効果計測方法
効果の測定方法はいくつかあり、一つはチーム内でアンケートを取る方法。
もう一つはGitHub側からAccept Rateなどのダッシュボードを出してもらう方法です。

アンケートは文字通り社内で項目をまとめてofficeでもgoogleでもなんでも使用して取っていただければよいのですが、実際にどのくらい役に立ったかというデータを定量的にとりたい場合はGitHub側にお願いするしかありません。

実際にネットでGitHub Copilotを導入した企業の記事を見るとAcceptRate(どれだけAIの提案を受け入れたか)などの謎の統計情報が散見されると思います。

こちらはEnterprise契約であればGitHubの問い合わせで確認することができます。
ちなみに通常のサポートチケットで問い合わせても営業に回されますので最初から[Enterpriseの問い合わせ](https://github.com/enterprise/contact)を行った方が無難です。

## 今後

今後はGitHub Copilot Enterpriseも計画されており1ユーザー39ドルで提供予定となっています。
[参考](https://github.blog/jp/2023-11-09-universe-2023-copilot-transforms-github-into-the-ai-powered-developer-platform/)

こちらではEnterprise用にチューニングされたCopilotが使用できるそうでプライベートリポジトリに基づいた提案ができたり、自動でプルリクを出してくれたりと使いたい機能が目白押しです。

これから先も大分盛り上がっていきそうですので、この記事がGitHub Copilotを使いたい会社や人の一助になれば幸いです。
iOS App 「合同式ますたー」


# アプリの使い方

![IMG_5706.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2661763/b3ca9855-e429-5708-3e71-a81cfda7932e.png)

## 設定

ホーム画面で簡単な設定ができます。

- 効果音の有無
- 経過時間表示の有無
- テストの問題数
- テストの合格点

## 設定した問題数だけ１次合同方程式をひたすら解きます

始めいッボタンを押下すると問題が出題されます。

![IMG_5707.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2661763/e03ce789-7637-4b11-d5c9-b47dce59d631.png)

黒板に表示された問題を解いて，法とする数字によって黒板の下に表示される選択肢から解答する数字のボタンを押下します。
例えば，19を法とする場合は，−9以上9以下の19個の選択肢となります。

![IMG_5708.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2661763/41e7ef04-0784-6819-4ad9-eace6b276905.png)

間違った場合は正解のボタンに⭕️が付きます。
次へボタンを押下して，自身が設定した問題数だけ問題に取り組みます。

![IMG_5713.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2661763/4e2db70a-2da0-1f4a-4d19-6f0d4aa4156b.png)

このようにSlide Overでメモしながら取り組むとよいでしょう。

![IMG_5711.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2661763/f8c13857-a96e-ebce-9ace-0a4dda718dc5.png)

最後の問題を解いた後，採点ボタンを押して採点をします。

![IMG_5712.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2661763/e0e53fdd-d7cf-0605-33df-e2f93ad9269b.png)

たったの５問でも連続して全問正解するのはなかなか難しいと思います笑

よかったら使ってみてください！！！

# プライバシーポリシー

## 利用者情報の取得

本アプリが利用者の個人情報を取得することはありません。

## 利用者情報の利用

本アプリが利用者の個人情報を利用することはありません。

## 利用者情報の第三者提供

本アプリが利用者の個人情報を第三者へ提供することはありません。

## 免責事項

本アプリ利用上の不具合・不都合に対して可能な限りサポートを行っておりますが、利用者が本アプリを利用して生じた損害に関して、開発元は責任を負わないものとします。

## お問い合わせ先

本記事にコメントしてくだされば、対応させていただきます。
(小ネタ) BigQuery にでっかいデータを突っ込む際の注意点

### サマリ
コンソールでクエリを実行した際、でっかいデータを含む行以降の結果が省略されます。

### 状況
以下のようなスキーマのテーブルがあったとして

<kbd>![スクリーンショット 2023-12-15 18.06.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2969458/e9e332ef-0a03-8354-a7f0-7ff350c66352.png)</kbd>

以下のようなデータが入っているとします。
スキーマに記載の通り `content` は長さが `length` の文字列になっています。

| length   | content   |
|-------|-------|
| 1 | a |
| 10 | aaaaaaaaaa |
| 100 | aaaaaaaaaa...... |
| 1,000 | aaaaaaaaaa...... |
| 10,000 | aaaaaaaaaa...... |
| 100,000 | aaaaaaaaaa...... |
| 1,000,000 | aaaaaaaaaa...... |
| 10,000,000 | aaaaaaaaaa...... |
| 100,000,000 | aaaaaaaaaa...... |

ここで以下のようなクエリをコンソールから実行すると
```mysql
select length, content from test_table;
```
以下画像のように `Showing fewer rows per page because the rows are large.` という Warning が表示され、`length` が `10,000,000`　より大きい行の表示が切り捨てられます。

<kbd>![スクリーンショット 2023-12-15 18.20.55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2969458/5f0afdf2-5a43-2799-b3a6-44f03875309f.png)</kbd>


### P.S.
表示は切り捨てられるものの、クエリは実行できているみたいです。
5,500,000 文字くらいまでは切り捨てられずに表示できそうでした。