OmniAICreator/Qiita-1.07M huggingface dataset:
PLATEAUアカデミーで学んだ事を実践してみた

# はじめに
  　国の提唱するデジタルツインの基礎となるPLATEAU 3D都市モデルを作成する事業者向けに
  AIGID様主催の[PLATEAUアカデミー](URL "https://aigid.jp/?page_id=2630")が11/6～8の3日間、東京開催の会場（東京大学駒場キャンパス）にて開催された。
  　元より興味があったので申し込み開始と同時に登録を行い、事前講座で概要を把握。
  希望が多かったようで追加の枠含めも満員となっていた。
  講習の三日間の中で、PLATEAUデータの作成方法についてハンズオンで学ぶ事が出来て大変有意義であった。
  
# PLATEAUアカデミーで学んだ事を実践してみた
　三日間の期間でかなり濃い内容を学習したため、操作関係があやふやな部分や正確に理解出来ていなかったこともあり、ふり返りのため、講義で作成しなかった他のオブジェクトを、復習も兼ねて作成を行いたいと思う。

## 目標（やること）
今回の講義では扱わなかったPLATEAU基本セットの災害リスクモデルを作成することを目標とする

* 災害リスクモデルの一覧
  1. 災害リスク（浸水）モデル
     * 洪水浸水想定区域
     * 津波浸水想定
     * 高潮浸水想定区域
     * 内水浸水想定区域
  2. 災害リスク（土砂災害）モデル
     * **土砂災害警戒区域** 👈今回の対象

    個人的にデータ構造などなじみがあり国土数値情報を入手可能な**土砂災害区域**を作成対象とした。

## CityGML構築の流れ（作業フロー）

 1. データの入手
    1. 国土数値情報をダウンロード
       1.  [国土数値情報ダウンロードサイト](URL "https://nlftp.mlit.go.jp/ksj/gml/datalist/KsjTmplt-A33-2023.html")
       shapefile形式のデータを入手
        
        
    2. 領域加工（対象地区：神奈川県厚木市）
       1. QGIS(プロセシングツールボックス→場所による抽出)
           対象地区の厚木市領域を選択した状態で機能を実行して新しいレイヤとして追加
          ![2024-12-03_16h43_18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/402309/0be47ec7-5487-a9bc-6484-ea3f87dde9ad.png)
          汎用GISではおなじみの機能だが、かなり使い勝手が良いと感じた
          
 2. 幾何検査
    1. QGIS（ベクタ→ジオメトリツール→有効性チェック）
      出力結果
      ![2024-12-03_16h55_03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/402309/cb07daff-60d2-2572-987d-078b9a7a3f95.png)


      ※講座で省略された手順
 3. 属性修正
    1. 属性項目の決定
       標準製品仕様書テンプレートのobjectlistより必須項目＋を選択する
       ![2024-12-03_18h15_02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/402309/fdf9dd88-0a9c-7e3b-c767-cf17a2cbd0c3.png)

    2. メッシュコード付与
       QGIS(属性の空間結合)
       
    3. 属性の再定義
       QGIS(属性のリファクタリング)
       ![2024-12-03_18h43_47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/402309/7b52f60c-afca-62d7-e318-972c913af6c1.png)
       TIPS: json形式で保存しておくことで再利用可能

    4. 符号化
    PLATEAUアカデミーで提供いただいたFME WorkBench Fileを利用して符号化を行う
    ![2024-12-04_16h07_46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/402309/3fb50ab5-8884-5433-308e-17096609ad99.png)

WriterのCityGMLメタ定義について操作方法が分からなかったがPSS様の[公開資料](URL "https://pss-fme-server-public.s3.ap-northeast-1.amazonaws.com/fmewt2022/presentations/08_Create_and_Use_CityGML_City_Models_with_FME.pdf")を参考に見よう見まねで設定を行った。

## 出力結果
データ構造が比較的単純なこともあり、エラーもなく正常にCityGMLに変換できた
    
![2024-12-04_16h14_04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/402309/f60437f7-7512-64c0-67c1-deb26b1e786c.png)

## まとめ

　今回は必須属性が少なくLOD1のみのオブジェクトであったので、問題なく作成が行えた。
講義の中の手順を自分なりに再利用可能な形で改良出来た部分もあり、QGISの関数作成など便利な手順も発見することができ「ふり返り＋学び」があったように思える。

　これまで3D都市モデルのイメージは全貌が見えず雲をつかむような感覚だったが、データ構築という意味で初めて入口に立てたように感じている。
　きっかけは今回のPLATEAUアカデミーなので非常にありがたく思う。アンケートにも書かせていただいたが、もう一歩踏み込んだ内容の講義など開催していただけたら次回も必ず参加します。
アリババクラウドが問題解決能力の高い推理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.4ee35355FNftKD)を参考にしています。
> 翻訳にはアリババクラウドの[ModelStudio](https://www.alibabacloud.com/en/product/modelstudio)([Qwen](https://www.alibabacloud.com/en/solutions/generative-ai/qwen))を使用しております。

AIシステムの中でも、人間の推理過程を模倣して問題解決と意思決定を行うための推理モデルへの関心が高まっています。このトレンドは、AIのニーズがモデルの学習から推論へと徐々にシフトし、運行中のモデルに対して追加の処理時間を割いて信頼性と出力コンテンツの適切性を高める「テスト時計算（推論計算）」に関する議論が拡大したことに合わせています。

![2](https://yqintl.alicdn.com/cfb86f441519449a1922211a52f6d8ed076d7d5f.png)
*注：QwQの発音は/kwju:/、\"quill\"と似ています。

この背景において、アリババクラウドは最近、推理AIモデルのQwQ（Qwen with Questions）を発表しました。公開されたバージョンである[QwQ-32B-Preview](https://qwenlm.github.io/blog/qwq-32b-preview/)は、320億パラメーターを持つオープンソースの研究モデルであり、優れた分析能力を披露しています。

現在プレビュー段階にあるこのAIモデルは、最大3万2千トークンの長さのプロンプトを処理可能です。数学やプログラミングにおける複雑な問題解決に秀でており、MATH-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（All-round Creator and Editor）](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/)でオリジナルに発表したものです。
Aurora DSQLについて

## 概要
AWS re:Invent 2024にて、新サービスとしてAurora DSQLなるものが紹介させていたのでわかる範囲で調べて記載します。

[公式](https://aws.amazon.com/jp/rds/aurora/dsql/)

## DSQLとは
公式サイトを翻訳してみると、
- サーバーレス
- シングルリージョン99.99%、マルチリージョン99.999%の可能性を実現するように設計
- パッチ適用、アップグレード、メンテナンス
- Postgre SQL互換

書いてあることだけみると、DynamodbのSQL版みたいな印象ですね。

## 実際に動かしてみる
東京リージョンでは使えないようなので、バージニア北部で作成します。
コンソールを開いてみたのですが、いつものと同じ画面という感じですね。
(最近コンソールがモダンな感じに変わりましたよね。)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3882356/e0cf67d1-ca99-6d35-ec82-1ac2b5e99c89.png)

今までのAuroraと比べると、設定する内容が少ないですね。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3882356/e0bc8c53-c72d-ac2c-d3a5-51d9b5ea54de.png)

ここでマルチリージョンにできるようですね
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3882356/256ab7a4-fe77-bf10-6297-25bd82a9d2d8.png)

現在2つのリージョンのみ選択可能なので、下記で設定しました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3882356/2b860de9-12f1-8032-5863-3f7524b00750.png)
削除保護機能もちゃんとあるようですね。
今回は検証なので、後で削除しやすいようにチェックを外しておきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3882356/709baa01-aa64-aae9-8ae0-c7f08d6522cf.png)

デプロイしてみます。

Lied Regionsの欄がリージョンですね。
ちゃんと二つ表示されてます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3882356/1c8b5e7e-33c3-897d-5120-9b056227acb1.png)


## まとめ
触ってみた感じですと、簡単にデプロイできるので金額次第では導入してみたいですね。
現状東京リージョンが未対応なので、対応したら別途記事を作成すると思います。
入社半年の僕が就活当時を振り返ってその時の自分に伝えたいことを書いてみた

ジョブカン事業部のアドベントカレンダー13日目です！

https://qiita.com/advent-calendar/2024/jobcan

ジョブカン勤怠管理で開発をしているあいすぱです。

本記事は、半年前まで学生だった私が、エンジニアとして働いてからその時の就職活動を振り返ってみたお話です。
温かい目で見ていただければ幸いです。
# 1.はじめに
本記事では前提として、Web系で開発職としてのキャリアを考えた時の、私なりの **「良い会社の選定基準」** を振り返ってみようと思います。

今振り返ってみると、就活の際にエンジニアのキャリアで検索した記事の多くは、転職エージェントやSES会社が提供していました。

これからお話するのは、私が個人的に考えていることを現場のチーフエンジニアにインタビューしつつまとめた内容です。
みなさんのキャリア（会社選び）のために、少しでも参考になる意見があれば幸いです！

# 2.就活中に誤解していたコト
私は、就活するうえで **「どこでも通用する技術」「高い給与」** の2つを掲げていました。同じようなポイントを意識する方も多いのではないでしょうか。

このポイントを軸に、以下の3つの内容について私が誤解していたことをお話したいと思います！

* **会社のビジネス形態（SES・受託開発・自社開発）**
* **上流工程・下流工程どっちがいいのか**
* **離職率**
 
の3つの誤解について書いていこうと思います。

### 2.1.会社のビジネス形態
1つ目は、**「SES・受託開発・自社開発」** ではどれがいいのかです。
就活当時に見ていた記事や説明会では、よくSES・受託開発・自社開発の企業について書かれていて、どれがいいのかについて語られています。

**結論：自社開発が良かった。**

というのも、**当時は技術力を身につけられるなら「どこでも良い」** と考えていました。

実際、チーフへのインタビューや多くの会社が公開している選考フローでも、SES・受託開発・自社開発ではなく、**どんな課題を解決するためどんな開発経験を積んだのか**というのが本質的にみられていると感じています。

ではどうして自社開発で良かったかというと、若いうちから**高い技術課題に取り組む機会が多い**と感じたからです。

技術課題を抱える顧客にエンジニアの社員がいたら、社員の成長のために優先してアサインします。必然的に、受託開発やSESで関わっている外部のエンジニアは、レベルの高い技術課題に挑戦できる機会が少なくなります。

入社1年目にも関わらず色々なことにチャレンジできているのは、今の会社だからなんだろうと実感しています。

### 2.2.上流工程・下流工程どっちがいいのか
2つ目は「上流工程と下流工程どっちの方がいいの？」についてです。
こちらについても検索してみると、**IT業界は下流の方が労働環境がブラック**だったり、**上流工程の方が給与が高い**という情報を多く耳にします。

そして、上流工程が良いのか、下流工程がダメなのかといった議論もよく見られます。

**結論：上流工程でも下流工程でも関係ない。**

**最も重要**なのは、 **「作りたいモノを作れる知識とスキルが身につくか」** だと感じています。


誰かがシステムで解決してほしい課題を持っていて、それを解決するのがエンジニアの仕事です。多くの開発会社やチームのリーダーは、エンジニアがその課題に対してどのようにアプローチして最適な解決策を見つけるかを重視しているように思います。

これは**エンジニアが自ら考え、議論を進める能力が、プロジェクトの成功にとって非常に重要**だからです。

これらは上流工程・下流工程という概念では表せないものだと考えました。

### 2.3.離職率
3つ目は「離職率」です。就活当時は「離職率が低いのは良い会社」だと信じ込んでいました。

**結論：良い会社かどうかに離職率は関係ない。**

エンジニアとして長期的に活躍していくためには、スキルと経験を積む必要があります。実力がつくと、その会社で上を目指す人もいれば、別の技術に触れたい・別のサービスに触れたい・起業してみたいと考えて他の会社に移る人も出てきます。
これって**エンジニアとしてはスキル・経験が積めるめっちゃ良い会社**だってことですよね？

一緒に働いている仲間が卒業してしまうことは悲しいですが、卒業した人からすると「次のキャリアを目指せるほどのスキル・経験を積めた良い会社」なんだと考えました。

# 3.実際に働いてみてエンジニアが求められるもの
これはもうめちゃくちゃシンプルで、**「作りたいモノを作れるか」** だと思います。

要望を聞くヒアリング力、それをシステムに落とし込む設計力、実際に作る実装力。作るものがズレたら作る意味はないですし、作るものを正しく認識できても設計や実装力がなければ形にできません。

自社プロダクトを開発している会社の選考フローや、上長・リーダーはひとえにここを見ているのだと思います。

今の自分がこの会社で働いているのも、そういう所も含めて見てくれたんだろうなと感じました。

# 4.当時の自分に伝えたいこと

* **入社1-2年目のエンジニアの方にどんな開発に携わっているのか聞いてみる**
* **実際に開発しているエンジニアの方に楽しかった開発や難しい技術課題を解決した話を聞いてみる**


給与や福利厚生などの高ければ高いほどいいモノを除いて、エンジニアとして未来が広がるほど成長できることが重要と考えたときに、この2つはとても大切だと思いました。

# 5.さいごに
いかがだったでしょうか？

いつかまた、同じように振り返って入社半年の自分へ届ける言葉を書いてみたいなと思いました。

配属されるチームや周りの人など、実際働くまで良し悪しはわからないことも多いと思いますが、少しでも参考になれば幸いです。

# 6.お知らせ
DONUTSでは新卒中途問わず積極的に採用活動を行っています。
新卒やインターンの募集もあるので、気になる方はお気軽に応募してみてください。

https://www.donuts.ne.jp/recruit/

https://recruit.jobcan.jp/donuts/show/B001/1396297
【TypeScript】タプルからオブジェクトを生成（type-challenges 初級編 11・Tuple to Object）

## お題
タプルを受け取り、その各値のkey/valueを持つオブジェクトの型に変換する型`TupleToObject`を実装する。

## やりたいこと
```typescript
const tuple = ["A", "B", "C", "D"] as const
type reault = TupleToObject<T>

// expected { "A":"A", "B":"B", "C":"C", "D":"D" }
```

## 解答
```typescript
type TupleToObject<T extends readonly any[]> = {
  [V in T[number]]: V
}
```

## 解説
### 処理の流れ
- `<T extends readonly any[]>`
Tは読み取り専用の配列のみに制約。
→ 単純な配列の型ではなく、配列の具体的な中身を受け取りたいから。
- `[V in T[number]]`
配列の中身を全てユニオン型で取得
- `{ [V in T[number]]:V }`
Mapped Typesでオブジェクトを生成。

### そもそもタプルとは...
- 特定の型と順序を持つ要素の集まり。
配列とは異なり、各要素の型を個別に指定できる。
```typescript
const Person:[string, number] = ["Tom", 20]
// 1番目は文字列、2番目は数値と固定された構造
```

### constアサーション（as const）とは...
- オブジェクト・配列の末尾に`as const`と記述することにより、全ての値を`readonly`（読み取り専用）にする。
- ネストされたオブジェクトに対しても、全ての値が`readonly`になる。
```typescript
const color = ["red", "blue", "green", "yellow", "purple"] as const;
// readonly ["red", "blue", "green", "yellow", "purple"]
```

### typeof演算子とは...
- 変数から型を抽出する型演算子。

```typescript
typeof "Hello World"; // => "string"
typeof 0; // => "number"
typeof true;  // => "boolean"

const Person = {
  name: "Tom",
  age: 20
};
typeof Person; // => { name: string, age: number };

const color = ["red", "blue", "green", "yellow", "purple"];
typeof color // => string[]
```

- nullの判別に注意
値が`null`の場合の演算結果は、`"null"`ではなく`"object"`になる。

### [number]とは...
- タプルの要素の型を**ユニオン型**で抽出する。
```typescript
const color = ["red", "blue", "green", "yellow", "purple"] as const;
type result = (typeof color)[number];

// expected "red" | "blue" | "green" | "yellow" | "purple"
```

### Mapped Typesとは...
https://qiita.com/yuto99999/items/dcc234f3e25a5393a2ab#mapped-types%E3%81%A8%E3%81%AF

## 参考記事
### タプル
- [タプル | TypeScript入門『サバイバルTypeScript』](https://typescriptbook.jp/reference/values-types-variables/tuple)
### constアサーション
- [constアサーション「as const」 | TypeScript入門『サバイバルTypeScript』](https://typescriptbook.jp/reference/values-types-variables/const-assertion)
- [keyof と typeof をすこ〜し細かく解説！後輩の質問から得たTypeScriptの知識| Qiita](https://qiita.com/yusei53/items/8e2af948b8a86d1dc0fe#const%E3%82%A2%E3%82%B5%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3as-const)
### typeof演算子
- [typeof演算子 | TypeScript入門『サバイバルTypeScript』](https://typescriptbook.jp/reference/values-types-variables/typeof-operator)
### [number]
- [配列からオブジェクトを生成する型を作ろうの解説 | mosya-TC](https://mosya.dev/blog/tc-tuple-to-object#%E8%A7%A3%E8%AA%AC)

## 今回の問題
https://github.com/type-challenges/type-challenges/blob/main/questions/00011-easy-tuple-to-object/README.ja.md
自社プロダクトでのNew Relic活用事例

アプリケーションの運用において、パフォーマンスやエラーを監視し、迅速に対応することは安定稼働に欠かせません。本記事では、ラフールが実際に**New Relic**を利用してプロダクトをどのように監視しているかについて解説します。

以下のポイントを中心に、New Relicを活用した監視体制を紹介します：  

1. [**負荷監視 (Dashboard)**](#1-dashboardでの負荷監視)  
2. [**アラート通知**](#2-アラート通知)  
3. [**APMによるパフォーマンス改善及びエラー分析**](#3-apmによるパフォーマンス改善及びエラー分析)  
4. [**ログカスタマイズ**](#4-ログのカスタマイズ)  

---

## **1. Dashboardでの負荷監視**

New Relicのダッシュボードを利用することで、リアルタイムのシステム負荷を視覚化できます。

### **1.1 監視対象**
- **リソース使用率**  
  アプリケーションサーバーのCPU、メモリ、ディスクなどの使用状況を監視します
- **リクエスト数**  
  リクエスト数の監視は、負荷監視の一環としてリソースコストの管理に役立ちます
- **実行プロセス**  
  サーバー上で実行中のプロセス詳細を把握し、リソース枯渇時の原因を特定し、対策を立てることができます

### **1.2 活用例**
- **リソース不足の検知**: 使用率が閾値を超えるタイミングで開発チームに通知し、迅速な対応につなげます
- **リソース調整**: 負荷に応じたリソース利用状況は、調整時の根拠となります

---

## **2. アラート通知**

New Relicは、異常検知時にアラートを発生させる機能を提供しています。Slack通知やサービス死活監視の設定を追加することで、迅速な対応が可能です。

### **2.1 サーバーリソース枯竭**
1. **アラート条件を設定**  
   - CPU使用率、メモリ使用量、ディスク容量に対して、それぞれ閾値を設定します。  
2. **通知設定**  
   - Slackやメールでアラートを送信するようWebhookを設定します
   - New Relic Alert設定ガイド: [公式ドキュメント](https://docs.newrelic.com/jp/docs/alerts/overview/)  

### **2.2 Step MonitorやPingによる死活監視**
- **Step Monitor**を利用して定期的にアプリにログインし、サービスの正常稼働を確認します。  
  - 例: サインインページにログインし、HTTP 200を返すかチェック。  
- 利用ツール: [New Relic Synthetic Monitoring](https://newrelic.com/jp/blog/how-to-relic/synthetics/new-relic-synthetics_step-monitor)

### **2.3 サーバーエラーリアルタイム通知**
アプリケーションでエラーが発生した際に、**New Relic**のError Notifications機能を活用して、リアルタイムでSlackに通知する仕組みを構築します。  
これにより、エラーの検知から対応までのスピードを向上させ、チームの効率的な運用を実現できます。

### **2.4 ポリシーによる通知管理**
Alert Policiesごとに連携するSlackチャンネルを分けることで、問題元の感知やアラートレベルを管理しやすくなります。


---

## **3. APMによるパフォーマンス改善及びエラー分析**

New RelicのAPM (Application Performance Monitoring) を活用することで、アプリケーションのボトルネックを特定し改善が可能です。

### **3.1 トランザクション監視**
- **Transactions**タブで、エンドポイントごとのレスポンスタイムやトラフィック量を確認します
- **遅いエンドポイントの特定**: 処理が遅いAPIやコントローラーを改善します

### **3.2 データベース全体調査**
- **Slow Queries**: 遅いSQLクエリを一覧で確認可能 
- **N+1問題の発見**: クエリ数の異常増加を検知し、ActiveRecordで対策していきます。(それ以外、Bullet Gemなどを利用して検出を行い、改善しています)

### **3.3 Errors inbox**
- **Error Analytics**: エラークラス、エラーメッセージ、発生箇所のコントローラーやメソッド名など、詳細な分析が可能です
- **Group errors**: エラーメッセージ、エラークラス、UI名など、最大5つの属性を任意に選んでグループ化できる機能です。さらに、ログのカスタマイズによって追加された独自の属性も活用できるため、エラーの根本原因や影響範囲を迅速に特定し、効果的な対応が可能となります

[Error Analytics の詳細はこちら](https://docs.newrelic.com/jp/docs/errors-inbox/errors-inbox/)

---

## **4. ログのカスタマイズ**

ログの出力内容をカスタマイズすることで、問題発生時の原因特定が迅速化します。

### **4.1 必要な情報をログに追加**
- **`company_id`**: 企業単位で問題を追跡します。
- **`user_id`**: ユーザーごとのエラートラブルを解析します。  
- **`uuid`**: リクエストを追跡します。

### **4.2 実装例**
```ruby
    ::NewRelic::Agent.add_custom_attributes({
      user_id: user_id,
      company_id: @company&.id,
      uuid: request.uuid,
    })
```

[カスタム属性の収集](https://docs.newrelic.com/jp/docs/data-apis/custom-data/custom-events/collect-custom-attributes/)


### **4.3 活用例**
1. **影響範囲の特定**  
   「このエラーがどの程度の企業やユーザーに影響しているか」を評価します。

2. **ユーザー動作の追跡**  
   特定ユーザーのアクセス解析ができ、問い合わせ対応に役立ちます。

---

## **まとめ**

New Relicを活用することで、以下のような包括的なアプリケーション監視が可能になります。

- ダッシュボードでの負荷監視とアラート通知
- パフォーマンスボトルネックの特定と改善
- ログ管理のカスタマイズによる迅速な問題解決

これらを統合することで、システムの安定性を大幅に向上させることができます。ぜひプロジェクトで取り入れてみてください！
python 組み込みモジュール③ re

## モジュール概要
N/A


## reモジュールでよく使われるメソッド
&nbsp;

### match() と fullmatch()
Python の正規表現モジュール re では、match と fullmatch はどちらも正規表現パターンと文字列の一致を確認するために使用されますが、それぞれの動作には明確な違いがあります。

 ① match()
* 機能：match メソッドは、文字列の先頭から正規表現パターンが一致するかどうかを確認します。
* 一致ルール：部分一致でOKです。文字列全体を一致させる必要はありません。
* 使用方法：re.match(pattern, string, flags=0)
```python
import re

# 成功: "123" は文字列の先頭に一致
result = re.match(r'\d+', '123abc')
print(result.group())  # 出力：123

# 失敗: "abc" が先頭にあるため一致しない
result = re.match(r'\d+', 'abc123')
print(result)  # 出力：None
```

 ② fullmatch()
* 機能：fullmatch メソッドは、正規表現パターンが文字列全体と一致するかどうかを確認します。
* 一致ルール：文字列全体が一致する必要があり、一部のみ一致する場合は失敗します。
* 使用方法：re.fullmatch(pattern, string, flags=0)
```python
import re

# 成功: "123" は文字列全体に完全一致
result = re.fullmatch(r'\d+', '123')
print(result.group())  # 出力：123

# 失敗: "123abc" には余分な "abc" があるため一致しない
result = re.fullmatch(r'\d+', '123abc')
print(result)  # 出力：None
```

### 違いのまとめ
| 特徴  | re.match | re.fullmatch |
|:-------|:---------|:-------------|
一致範囲|文字列の先頭から一致|文字列全体が一致
部分一致   |可能|不可能
使用シーン|文字列が特定のパターンで始まるか確認|文字列全体がパターンに一致するか確認


### 選択のポイント
* **文字列全体が完全一致**するかどうかを確認したい場合は、fullmatch を使用します。
* **文字列の先頭部分**がパターンに一致するかどうかを確認したい場合は、match を使用します。


## flagsについて
Pythonの正規表現モジュールreにおいて、flagsは正規表現の動作を変更するためのオプションを指定する引数です。正規表現の処理に対して特定の条件や設定を付加する際に使用されます。

* re.IGNORECASE（re.I）
大文字・小文字を区別せずに一致させます。
```python
import re
result = re.match(r'abc', 'ABC', flags=re.IGNORECASE)
print(result.group())  # 出力：ABC
```

* re.MULTILINE（re.M）
^や$を、文字列全体ではなく各行の開始や終了に対応させます。
```python
text = "first line\nsecond line"
result = re.findall(r'^.+', text, flags=re.MULTILINE)
print(result)  # 出力：['first line', 'second line']
```

* re.DOTALL（またはre.S）
.（ドット）が改行文字（\n）を含むすべての文字と一致するようにします。
```python
text = "first line\nsecond line"
result = re.match(r'.+', text, flags=re.DOTALL)
print(result.group())  # 出力：first line\nsecond line
```

* re.VERBOSE（またはre.X）
正規表現を見やすく記述するために、空白やコメントを許可します。
```python
pattern = r'''
\d+   # 数字
\s+   # 空白
\w+   # 単語
'''
result = re.match(pattern, '123 abc', flags=re.VERBOSE)
print(result.group())  # 出力：123 abc
```

* re.ASCII（またはre.A）
パターン内の\wや\dなどのメタ文字をASCII文字に限定します。
```python
result = re.match(r'\w+', 'こんにちは', flags=re.ASCII)
print(result)  # 出力：None（ASCII外の文字は一致しない）
```

* re.LOCALE（またはre.L）
ロケール（地域設定）に基づいて\wや\dなどの動作を変更します。（あまり使われません）

* re.UNICODE（またはre.U）
Unicodeに基づいて\wや\dなどの動作を適用します。（デフォルトで有効）

### flagsの複数指定
複数のflagsを同時に使用することができます。
|（ビット単位のOR演算子）を使って組み合わせます。

```python
import re
pattern = r'abc'
text = "ABC\nabc"
result = re.findall(pattern, text, flags=re.IGNORECASE | re.MULTILINE)
print(result)  # 出力：['ABC', 'abc']
```
PM向けにfigmaの「オートレイアウト」と仲良くなるための勉強会をした話

こんにちは、UIデザイナーのおしまです。
[クロスマート・テック Advent Calendar 2024](URL "https://qiita.com/advent-calendar/2024/xmart") の6日目を担当します🖊️

今回は、PM向けに開催したFigma勉強会を振り返りつつ、「オートレイアウト」と仲良くなれる記事を書いてみたいと思います。




## Figmaとは？

FigmaはUI/UXデザインやプロトタイプ作成に特化したクラウドベースのデザインツールです。リアルタイムでチームと共同編集が可能で、ブラウザ上で動作するため、弊社でも多くのメンバーが活用しています。

オートレイアウトはFigmaの代表的な機能のひとつです。たとえば、ボタンを作る際、テキストの長さに応じてボタン幅が自動調整されたり、要素間の間隔を設定すれば新しいアイテムも一定の間隔で整列します。

![01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3951449/97597a81-f1b0-f119-fcb8-91f36e5edba1.png)

「部品を整える手間を減らしてくれる便利ツール」と覚えると分かりやすいです！
ただし、使いこなすにはある程度の経験が必要です。初心者にとっては少し難解な機能であるのも事実です😅

## PM向けFigma勉強会の開催

弊社のPM陣は、ワイヤーフレームを作成したり要件を整理する際にFigmaを使う機会が多いです。その延長で、オートレイアウトを活用したデータにも触れることが増えてきました。

そこで、「オートレイアウトの基本を理解すれば、もっと活用の幅が広がるのでは？」という期待を込めて、非デザイナー向けの勉強会を開催しました！


### 課題：可変メモを作ってみよう

オートレイアウトは実際に操作してみないとなかなか理解が進みません。
そこで、基礎的な説明の後PMがフロー図を作成するときに使えそうな「文字数に応じて可変するメモ」を作成する課題を用意し、取り組んでもらいました。

![02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3951449/65e70e0a-76de-8d71-76c6-48443f38181d.png)


#### 🔨 作り方

![03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3951449/91c76264-f072-daa3-cbd8-92f97504e660.png)

課題の作り方をまとめた図を用意しましたので、ぜひチャレンジしてみてください！
勉強会は15分×5回の実施でしたが、PM陣にもオートレイアウトの便利さが伝わったようで安心しました👍

## オートレイアウトのありがちな失敗
勉強会でPMからよく出た質問を2つピックアップしました。設定が正しくないと混乱することもありますが、ひとつずつ設定を見直せばすぐに解決できるので確認してみてください♪


![Frame 625575.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3951449/fe22695e-cbb0-faea-83ca-8b78d7272454.png)

⇧ この経験、あるあるでは？そういうときは幅指定が悪さをしていないかチェックです

![Frame 625576.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3951449/72e648aa-2a55-c777-4ba3-f3e3d5d0ec3c.png)

⇧ デザイナーが作るFigmaデータはオートレイアウトだらけですが、パーツごとに設定を読み解けばシンプルな構造であることが見えてきます

## 最後に
オートレイアウトは初めは難しく感じるかもしれませんが、基本を押さえれば確実に業務効率がアップします！この記事が、Figmaを活用するPMや非デザイナーの皆さんのお役に立てば嬉しいです😊

明日の[クロスマート・テック Advent Calendar 2024](URL "https://qiita.com/advent-calendar/2024/xmart") もお楽しみに！
基本設計の詳細ガイド：プロジェクト成功のための必須スキル

## **はじめに**
基本設計は、システム開発プロジェクトにおいて重要な役割を果たします。要件定義を具体化し、開発フェーズにスムーズに移行するための「設計図」を作成するプロセスです。本記事では、基本設計の詳細な内容や具体例を紹介し、実践的なスキルを身につけるためのヒントを提供します。

---

## **基本設計とは何か？**
基本設計は、**要件定義書**を基に以下を具体化します。

1. **機能要件の具体化**
   - どのような機能が必要か。
   - 各機能の詳細な動作仕様。

2. **非機能要件の落とし込み**
   - パフォーマンス要件（応答時間、同時接続数など）。
   - セキュリティ要件（暗号化、認証方式など）。
   - 運用要件（障害対応、ログ管理など）。

3. **設計の各種観点**
   - **画面設計**: UI/UXの詳細設計。
   - **データ設計**: データベース構造やデータフロー。
   - **業務フロー設計**: 業務プロセスを考慮した機能連携。
   - **インターフェース設計**: 他システムとのデータ連携やAPI仕様。

これらを文書化することで、開発チームと関係者間の認識を合わせ、品質向上とリスク軽減を図ります。

---

## **基本設計の主なドキュメントと内容**
以下は、基本設計で作成される主なドキュメントの詳細です。

### **1. 機能一覧表**
機能一覧表では、システムで実現すべき機能を一覧化し、優先順位や関連情報を整理します。

| 機能ID | 機能名           | 概要                        | 優先度 | 備考           |
|--------|------------------|-----------------------------|--------|----------------|
| F001   | ユーザー登録     | 新規ユーザーの登録機能      | 高     | 必須           |
| F002   | ログイン機能     | ユーザー認証機能            | 高     | セキュリティ重視|
| F003   | タスク追加       | ToDoのタスクを追加する機能  | 中     | データベース必要|

---

### **2. 画面設計書**
画面設計書では、各画面のレイアウトや画面遷移を定義します。

#### **ログイン画面例**
- **目的**: ユーザー認証を行う画面。
- **レイアウト**:
  - 入力フィールド:
    - メールアドレス（テキストフィールド）
    - パスワード（パスワードフィールド）
  - ボタン: ログイン、パスワードを忘れた方はこちら。
- **エラー表示**:
  - 未入力時: 「メールアドレスを入力してください」
  - 認証失敗時: 「メールアドレスまたはパスワードが正しくありません」

---

### **3. データ設計書**
データ設計書は、データベースの構造やデータ間の関係性を定義します。

#### **ユーザーテーブル例**
| カラム名       | 型         | 制約              | 備考                      |
|----------------|------------|-------------------|---------------------------|
| user_id        | INT        | PRIMARY KEY       | ユーザーID                |
| email          | VARCHAR(255) | UNIQUE          | メールアドレス            |
| password_hash  | VARCHAR(255) | NOT NULL        | ハッシュ化されたパスワード|
| created_at     | DATETIME   | DEFAULT CURRENT_TIMESTAMP | 作成日時         |

#### **ER図**
ユーザーとタスクの関係を以下のように設計します。
- ユーザーは複数のタスクを持つ（一対多）。

---

### **4. 業務フロー図**
業務プロセスを図解して、システムの流れを整理します。

#### **タスク管理フロー**
1. ユーザーがログイン。
2. タスクを追加、編集、削除。
3. 完了したタスクは「完了済み」として表示。
4. 必要に応じてタスクをアーカイブ。

---

### **5. インターフェース設計書**
外部システムとの連携に必要なAPIやプロトコルを定義します。

#### **例: タスク取得API**
- **エンドポイント**: `/api/tasks`
- **メソッド**: `GET`
- **リクエスト例**:
  ```json
  {
    "user_id": 12345
  }
  ```
- **レスポンス例**:
  ```json
  {
    "tasks": [
      {
        "id": 1,
        "title": "買い物",
        "status": "未完了"
      },
      {
        "id": 2,
        "title": "会議資料作成",
        "status": "完了"
      }
    ]
  }
  ```

---

## **基本設計での注意点**

1. **関係者との認識合わせ**
   - 仕様の曖昧さを防ぐため、定期的にレビューを行う。

2. **セキュリティ要件を忘れない**
   - 特にログインやデータ連携時のセキュリティ対策を徹底。

3. **将来の拡張性を考慮**
   - 機能追加や仕様変更に柔軟に対応できる設計を目指す。

4. **ドキュメントの一貫性**
   - 同じ用語やフォーマットを使用し、読みやすさを確保。

---

## **おわりに**
基本設計はシステム開発の「基礎工事」に例えられる重要な作業です。この記事を参考に、自分のプロジェクトに合わせた基本設計を作成し、プロジェクトを成功に導きましょう。

**この記事が役立ったと思ったら、「いいね」や「ストック」をお願いします！**
カスタムサイズのエミュレータでFireStoreを使用する方法

## はじめに
Flutter開発のアルバイトでFirebase導入後のプロジェクトで、ミニマムデバイスの画面サイズでオーバーフローが起こらないか調査しようとした際に、サイズを指定したエミュレータを作成しました。アプリ起動時、Flutterのロゴで止まってしまう事象に遭遇したため、調査をしたところ下記の原因が最も有力になり、対策を行ったところ無事に解決しました。
>Android StudioのエミュレータでFireStoreを使用しようとした際、Google Play Storeに対応していないエミュレータでは問題が発生することがあります。

この記事では、その問題の解決策と、Google Play Storeを有効にする方法について説明します。

## 問題の背景
FireStoreを含む一部のFirebase SDKは、Google Play servicesに依存しています。そのため、Google Play servicesがインストールされていないデバイスやエミュレータでは、これらのサービスが正常に動作しない可能性があるそうです。

## 解決策
##### 1. Android Studioの Virtual Device Manager を開きます
##### 2.対象のエミュレータの詳細メニュー（3点リーダー）をクリックし、「Show on Disk」を選択します
##### 3.config.iniファイルをテキストエディタで開きます
以下の2箇所を変更します：
```text
PlayStore.enabled=true

image.sysdir.1 = system-images/android-XX/google_apis_playstore/ARCH/
```
**注意: XXはAndroidのAPIレベル、ARCHはアーキテクチャを示します。**

##### 4.変更を保存し、エミュレータを再起動します。


## おわりに
Google Play Storeに対応していないエミュレータでFireStoreを使用する際の問題は、エミュレータの設定を変更してGoogle Play Storeを有効にすることで解決できました。（変更する箇所が少なすぎてこの問題で躓いていたのがすごく悔しかったです．．．）
同じ問題で悩んでいる方の参考になれば幸いです！
Macのデフォルト機能で画像を編集する方法

# Macにペイントツール入ってない問題
テストのエビデンスや、画面仕様書を作成する際、画像編集したい瞬間ってありますよね。
Windowsを使用していた頃は、ペイントツールがあって、簡単にキャンバスの大きさの変更などができたものですが、、、Macにはない！

ということで、Macのデフォルト機能である「プレビュー」での基本的な画像編集の一部を紹介します。

## まずはマークアップツールバーを表示しよう
ツールバーはデフォルトだと初期表示されません。
Window上部の以下のマークを押すと
<img width="717" alt="スクリーンショット 2024-08-26 11.58.33.png (40.1 kB)" src="https://img.esa.io/uploads/production/attachments/21227/2024/08/26/160775/5f9ed5bc-125f-464e-ac2a-26346fc1b8d8.png">

ツールバーが表示されます。
<img width="708" alt="スクリーンショット 2024-08-26 11.58.58.png (53.4 kB)" src="https://img.esa.io/uploads/production/attachments/21227/2024/08/26/160775/2bbb5574-61bb-4be5-ac44-9be7f923de8c.png">



---


## ２つの画像を一つにしたい
例えば、スマホのスクリーンショットなど。
縦に長いページを結合して、１枚のスクリーンショットにしたいとき。

1. 画像①をプレビューで開き、command+A で全体を選択　→ command+X で全て切り取る
1. そのままツールバーの「サイズを調整」を押す
<img width="708" alt="スクリーンショット 2024-08-26 11.58.58.png (48.4 kB)" src="https://img.esa.io/uploads/production/attachments/21227/2024/08/26/160775/517d8803-7fd3-43cb-9758-f421bbd6de9e.png">

3.ダイアログで「縦横比を固定」のチェックを外し、高さや幅を変更し、OKを押す。
（縦に長い画像を作成したいときは高さを変更する。）
<img width="474" alt="スクリーンショット 2024-08-26 13.08.53.png (168.2 kB)" src="https://img.esa.io/uploads/production/attachments/21227/2024/08/26/160775/303059ba-78d3-435f-a1f3-99f54a9e60cb.png">

4.無の状態のキャンパスに、先ほど切り取った画像①を貼り付ける。

5.結合したい画像②をプレビューで開き、command+A で全体を選択　→ command+X で全て切り取る

6.先ほど編集した画像①のプレビュー画面を開き、cpmmand+p で画像②を貼り付ける。
　サイズを調整。

**結合した画像完成！！**



## 画像の拡張子を変更したい
 iPhoneで撮影した写真をAirDropでPCに送ると、.HEIC という拡張子になっています。
テストで画像を使用したいけど、.jpeg　や　.png じゃないからエラーになってしまうというときは以下の方法で拡張子を変更できます。

1. 拡張子を変更したい画像をプレビューで開く
1. 画面上部「ファイル」→　「書き出す」
1. ダイアログの「フォーマット」で変更したい拡張子を選択
1. 「保存」を押す

**拡張子変更完了！！**

## 画像の解像度を下げたい
500MBの画像にしたい、など、、、、あるとおもいます。
プレビューでのやり方は２通りあります。

①　保存時、品質の数値を下げる
1. 解像度を調整したい画像を開く
1. 画面上部「ファイル」→　「書き出す」
1. ダイアログの「品質」の数値を最低の方へ下げる
![スクリーンショット 2024-12-04 16.26.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2629197/22cbe890-572d-99fd-bde0-3da442767334.png)


4. 「保存」を押す

**画像サイズ変更完了！！**

②サイズ調整で解像度をいじる
1. 解像度を調整したい画像を開く
1. ツールバーの「サイズを調整」を押す
1. 「解像度」部分の数字を変更
1. OKを押すし、画像を保存する

**画像サイズ変更完了！！**



---


### 画像じゃなくて「動画ファイルのサイズを下げる簡単な方法」も紹介
1. Finderでサイズ変更したい動画を選択し、右クリック
1. 「選択したビデオファイルをエンコード」を押す
<img width="291" alt="スクリーンショット 2024-08-26 13.32.49.png (176.1 kB)" src="https://img.esa.io/uploads/production/attachments/21227/2024/08/26/160775/819256b5-3710-49d0-bb44-ee697193935d.png">

3. 次のダイアログでそのまま「続ける」を押す
4. **サイズダウンした動画が同じフォルダに作成される**
手順3の時、「設定」を変更すると、音声のみの動画にできたりもします。

**Before：258.5MB**
<img width="418" alt="スクリーンショット 2024-08-26 13.37.24.png (87.3 kB)" src="https://img.esa.io/uploads/production/attachments/21227/2024/08/26/160775/a4e300d1-84a9-4e64-a415-78cde5dbbda8.png">

**After:12.9MB**
<img width="415" alt="スクリーンショット 2024-08-26 13.37.15.png (73.2 kB)" src="https://img.esa.io/uploads/production/attachments/21227/2024/08/26/160775/acdc6910-f9b0-44ae-9290-0310fea1f963.png">
構造化ログを渡す際に注意したい message フィールドの挙動

:::note info
この記事はZOZO Advent Calendar 2024 シリーズ 1 の 9 日目の記事です。
:::

## はじめに
<!--
何についての記事なのか、誰に向けた記事なのかを簡単に説明しましょう。
-->
Goggle Cloud には Cloud Logging というログ管理サービスがあり、JSON 形式で書き込まれたログを構造化ログとして記録することができます。

Cloud Logging で提供される特別な JSON フィールドを活用することでログの記録や検索・分析の効率が向上します。

この記事では、特別な JSON フィールドの１つである message フィールドについて構造化ログを渡した時に特殊な挙動をとるので記事にまとめました。

## 構造化ログとは
機械的に読み取り可能なフォーマットでキーと値が書き込まれている形式のログのことです。

例えば以下のような形式のログが構造化ログと言います。
```json
{
    "pri": "6",
    "host": "192.168.0.1",
    "ident": "fluentd",
    "pid": "11111",
    "message": "[error] Syslog test"
}
```

## CloudLogging の仕様について
<!--
読んだら何がわかるようになるのか、何ができるようになるのかを書きましょう。
-->
Cloud Logging では JSON 形式で出力されたログを構造化ログとして認識します。

特別な JSON フィールドと認識された場合、Cloud Logging 側で自動的に処理され意図しないログフォーマットになることがあります。

https://cloud.google.com/logging/docs/structured-logging?hl=ja#special-payload-fields

### 特別な JSON フィールド
Google Cloud の構造化ロギングで使用される特定のキーのことで、ログエントリに特定の意味や挙動を持つことがあります。

例えば以下のようなものがあります
- severity フィールド：ログ エントリに記述されたイベントの重大度（INFO, ERROR, WARNINGなど）を示す
- timestamp フィールド：ログのタイムスタンプを指定する際に使用される
- message フィールド：Cloud Logging に保存され、設定した文字列が表示される

今回は message フィールドについて検証したことを書いていきます。

## messageフィールドについて
Cloud Logging において message フィールドは構造化ログの渡し方によって動作が異なり、以下のような動作をします。

### パターン１： message のみ入力した場合
以下のように構造化ログを設定してCloud Logging に保存してみました。

```json
{
    "severity": "ERROR", 
    "time": "2024-12-06T07:12:45:769Z",
    "message": "Sample log message"
}
```
severity フィールドと time フィールドはそれぞれ対応した LogEntry フィールドに保存されます。

他に特別な JSON フィールドを除く構造化データがない場合、message フィールドの値は textPayload に保存されます。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3924190/f3a35776-4148-6e87-1f6a-8de0d53fec91.png" width="500">


また、message フィールド以外に特別な JSON フィールドがなく複数の message フィールドが渡されると、それらの値は自動的に結合されて textPayload に保存されます。

```json
{
    "severity": "ERROR", 
    "time": "2024-12-06T07:03:37:169Z",
    "message": "message1"
    "message": "message2"
}
```

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3924190/312a742e-bd23-feeb-0c2d-e112e5393901.png" width="500">


### パターン２： message 以外のキーを渡している場合
message フィールドに加えて新しいキーと値を追加して以下のように構造化ログを設定してCloud Logging に保存してみました。

```json
{
    "severity": "ERROR", 
    "time": "2024-12-06T07:20:56:174Z",
    "message": "Line Notification is not allow"
    "msg": "Line Notification is not allow"
}
```

この場合、message フィールドと msg フィールドの値は jsonPayload に保存されます。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3924190/5a81c9dc-38a3-4072-5515-be1b3088d648.png" width="500">

このように message 以外に新しくフィールドを追加した構造化ログを渡すことで jsonPayload フィールドに保存することができます

## まとめ
Cloud Logging の仕様を踏まえて、特別な JSON フィールドである message フィールドの扱いについて検証した結果をまとめました。

ログを設計するときの参考になれば嬉しいです。

最後まで読んでいただきありがとうございました！
JUnitの@MethodSourceを活用して複雑な条件付きロジックをテストする

# はじめに

こんにちは、Gakken LEAP のエンジニアの Minami です。
WEBアプリケーションをJavaで開発するにあたり、テストツールとしてJUnitを使用しました。
単純な機能だけでなく、特定の条件に基づいて動作するロジックのテストは、実装や管理が面倒ではありますが、とても重要なことです。この記事では、@&#xFFF0;MethodSource を活用して、複数のテストパターンを簡単にまとめる方法を解説します。

---

# サンプル用テスト対象機能の概要

今回のテスト対象は、数値リストから偶数のみを抽出し、その合計を計算するメソッドです。このメソッドの特徴は以下の通りです：

1. 入力：整数のリスト
2. 処理：偶数をフィルタリング
3. 出力：偶数の合計

## サンプルコードの解説

まず、テスト対象となる sumEvenNumbers メソッドは以下のように実装されています。

```java
private int sumEvenNumbers(List<Integer> numbers) {
    return numbers.stream()
            .filter(n -> n % 2 == 0) // 偶数をフィルタリング
            .mapToInt(Integer::intValue) // intに変換
            .sum(); // 合計を計算
}
```

このメソッドでは、Stream API を活用して、リスト内の偶数をフィルタリングし、その合計を計算します。

# テストコード

次に、@MethodSource を使ったテストメソッドを見てみましょう。

```java
@ParameterizedTest
@MethodSource("provideTestDataForSumEvenNumbers")
void testSumEvenNumbers(List<Integer> input, int expectedSum) {
    int result = sumEvenNumbers(input);
    assertEquals(expectedSum, result, () ->
        String.format("Expected sum of even numbers in %s to be %d, but got %d", input, expectedSum, result)
    );
}
```

このテストメソッドでは、@&#xFFF0;MethodSource を使って、外部メソッド provideTestDataForSumEvenNumbers からテストデータを供給しています。テストデータは以下のように構築されています。

```java
private static Stream<Arguments> provideTestDataForSumEvenNumbers() {
    return Stream.of(
        Arguments.of(List.of(1, 2, 3, 4, 5), 6),  // 2 + 4 = 6
        Arguments.of(List.of(2, 4, 6, 8, 10), 30), // 2 + 4 + 6 + 8 + 10 = 30
        Arguments.of(List.of(1, 3, 5, 7, 9), 0),  // 偶数がない
        Arguments.of(List.of(), 0),               // 空リスト
        Arguments.of(List.of(0, 2, 4, -6), 0)     // 0を含む負の偶数をテスト
    );
}
```

このデータセットでは、以下のようなケースをカバーしています。

1. 偶数と奇数が混在するリスト
2. 偶数のみのリスト
3. 偶数が含まれないリスト
4. 空リスト
5. 負の数やゼロを含むリスト

テストパターンさえ整理できていれば、あとはこのデータセットにまとめて書いておくだけなので、管理も楽になります。

# テスト結果

テストを実行すると、各ケースについて期待通りの結果が得られることを確認できます。

```terminal
Test run started
✔ testSumEvenNumbers([1, 2, 3, 4, 5], 6)
✔ testSumEvenNumbers([2, 4, 6, 8, 10], 30)
✔ testSumEvenNumbers([1, 3, 5, 7, 9], 0)
✔ testSumEvenNumbers([], 0)
✔ testSumEvenNumbers([0, 2, 4, -6], 0)
Test run completed
```

---

# まとめ

この記事では、@&#xFFF0;MethodSource を使ったテストデータ管理の利便性を解説しました。特に、条件付きロジックのテストにおいて、この手法を活用することで、テストコードの柔軟性と可読性を向上させることができます。

---

# エンジニア募集中

Gakken LEAP では教育をアップデートしていきたいエンジニアを絶賛大募集しています！！

https://gakken-leap.co.jp/recruit/
への識別RTA!![クソアプリ Advent Calendar 2024]

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3851721/712f73d8-97c1-cabc-cdd8-69eb5563f362.png" width=30%>

## [クソアプリ Advent Calendar 2024]の季節

2024年も残り少しですね。

今回は、面白そうなイベントがQittaであると知って参加してみました!!

## への識別RTA!!

https://nekozyarasisan.vercel.app/

内容は至ってシンプルです。**へとヘを見分けるRTA**です!!

![スクリーンショット 2024-12-04 15.56.05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3851721/b6a66e61-1865-8df2-454b-0c20f0fdfc2a.png)

カタカナのヘとひらがなのへは実は微妙に違うという事実を元に作ったというアプリです。

世の中には**アンパンマングミRTA**などがありますよね！

それに着想を得て作りました。

ランキング機能も完備しているのでRTAで競うことができます!!

## への識別RTA(100問RTA部門)　公式ルール

- 100問ランダムに出題される「へ」と「ヘ」を見分ける
- 不正解で脱落
- 全問正解かつタイムの短い人が優勝

100位以内でついったーのバンドルを乗せるとランキングに表示されます!!

ランキングからあなたのアカウントに飛ぶことができ、**世界記録保持者として讃えられます**

## 使ったもの(技術的)

Next.js
cloudflare
v0

v0にバックエンドのコードを書いたらすぐできました!!

## おわりに
これを機に **へとヘを見分けるRTA!!** を布教できたらと思います!!

ぜひ挑戦してみてください!!

ちなみに、私のスコアは**50.220秒**です

https://nekozyarasisan.vercel.app/

作ったアプリはここに載せていただけたら嬉しいです!!
⇩個人開発アプリを紹介できるサイト(開発してます)⇩

https://indieapps.tech
Zabbix Upgradeについて．6.4→7に上げる際に詰まった話．

## 背景
- 監視環境として，Zabbix6.4を公式提供の[Docker compose](https://github.com/zabbix/zabbix-docker)を使って構築していました．
- Zabbix7にupgradeする際に詰まったので解決方法を記載します．

## 環境
- Zabbixのversion：6.4
- DB：MYSQL

## 流れ
1. 6.4verのMySQLに入り以下のコマンドを実行．
    1. `` docker exec -it MYSQLのコンテナ名 /bin/bash ``
    1. `` mysql -u root -p `` PWはデフォルトの場合``root_pwd``
    1. ``SET PERSIST log_bin_trust_function_creators = 1;``
        1. ここが肝：Docker以外の手法では普通にSETするだけで永続化するが，Dockerは永続化しないのでこのコマンド．
1. ``Docker compose down``で稼働中のコンテナを停止．
1. 使用中の``compose.yaml``の該当箇所を全て6.4から7.0に書き換える．
1. ``Docker compose up -d``で再度立ち上げる．
    1. ``docker compose logs``を用いて適宜logを見てください．
    1. しばらく待ったらupdateに伴う処理が終わり，立ち上がるはずです．
1. 終わり．
    1. 任意のブラウザでzabbixにアクセスしてください．version7にあがっているはずです．

## エラー
### 表示されたエラー
Webブラウザに表示されたエラー
> The Zabbix database version does not match current requirements. Your database version: 6050035. Required version: 7000000. Please contact your system administrator.


docker compose logsのエラー
> query failed: [1419] You do not have the SUPER privilege and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable) [create trigger hosts_name_upper_insert　before insert on hosts for each row

### 原因と解決方法
原因：log_bin_trust_function_creatorsをオンにしていないこと
解決方法：先述の流れのStep1を実行する．
【chatGPT対話備忘録】ボリュームライセンス契約（基本情報技術者令和5年免除　問60）

# 私：
解説お願いします
# ChatGPT:

この問題は「ボリュームライセンス契約」を説明している選択肢を選ぶものです。

### 各選択肢の解説
#### ア:
企業などソフトウェアの大量購入者向けに、インストールできる台数をあらかじめ取り決め、ソフトウェアの使用を認める契約

解説:
ボリュームライセンス契約とは、企業や教育機関など大量にソフトウェアを使用する組織に対し、複数台のコンピュータにインストール可能なライセンスを一括で購入する契約を指します。
この選択肢はボリュームライセンス契約の特徴を正確に説明しているため、正しい選択肢です。
#### イ:
使用場所を限定した契約であり、特定の施設の中であれば台数や人数に制限なく使用が許される契約

解説:
この説明は「サイトライセンス契約」に該当します。サイトライセンスは特定の物理的な場所や施設で利用できる契約であり、ボリュームライセンス契約とは異なります。
よって、誤りです。
#### ウ:
ソフトウェアをインターネットからダウンロードしたとき画面に表示される契約内容に同意することを選択することによって、使用が許される契約

解説:
この説明は「クリックラップ契約」（Clickwrap Agreement）に該当します。ソフトウェアをインストールする際に表示される利用規約に同意して使用を開始する仕組みであり、ボリュームライセンス契約とは異なります。
よって、誤りです。
#### エ:
標準の使用許諾条件を定め、その範囲で一定量のパッケージの包装を解いたときに、権利者と購入者との間に使用許諾契約が自動的に成立したとみなす契約

解説:
この説明は「シュリンクラップ契約」（Shrinkwrap Agreement）に該当します。シュリンクラップ契約とは、パッケージソフトの包装を開封した時点で契約が成立する形式を指しますが、ボリュームライセンス契約とは異なります。
よって、誤りです。
正解
ア:
企業向けにソフトウェアの大量購入を行い、インストールできる台数をあらかじめ決める契約

もし追加の説明が必要であれば、さらに詳しく解説します！






# あなた:
ボリュームライセンス契約とは
# ChatGPT:

### ボリュームライセンス契約とは？
**ボリュームライセンス契約（Volume Licensing Agreement）**は、企業や教育機関、自治体などの大規模組織がソフトウェアを大量に利用する際に、複数台のコンピュータにインストールできるライセンスを一括して購入する契約形態です。

#### 主な特徴
大量購入の割引が適用される:

一般的な個別ライセンスよりも費用を抑えることができる。
例えば、100台分のライセンスを一括購入する場合、1台ごとの価格が安くなる。
台数やユーザー数をまとめて管理:

契約内容によって、利用できる台数やユーザー数が決まっており、それを管理する仕組みが提供される。
管理者が一元的にライセンスを付与したり回収したりできる。
ソフトウェアのインストールや管理が効率的:

ソフトウェアのインストールに共通のライセンスキーを使用するため、1台ごとに個別のプロセスを行う必要がない。
更新やアップグレードもまとめて行える。
カスタマイズ可能な契約:

企業のニーズに応じて、ライセンスの範囲や対象を調整することが可能。
一部の契約では、リモートアクセスやクラウド利用のオプションが含まれる場合もある。
対象となるソフトウェア:

主にMicrosoft OfficeやAdobe製品、アンチウイルスソフトなどの商用ソフトウェアが対象。
特に企業や教育機関が使用する頻度の高いソフトウェアが多い。
##### メリット
###### コスト削減:
大量購入の割引により、総コストを抑えられる。
効率的なライセンス管理:
管理者が一元管理できるため、管理負担が軽減される。
###### 拡張性:
必要に応じて台数を追加購入できる。
#### 利用例
###### 企業:
社員が使用するPCにMicrosoft Officeを一括インストールする場合。
###### 教育機関:
学生用PCや教員の端末にAdobe Creative Cloudを導入する場合。
###### 自治体:
公共施設内のコンピュータにアンチウイルスソフトを導入する場合。
#### 契約例（Microsoftのボリュームライセンス）
###### Microsoftでは以下のような契約形態があります：

Open License:
小規模企業向け。
Enterprise Agreement:
大規模企業向け。すべての社員が同じソフトウェアを利用可能。
Academic Agreement:
教育機関向けに提供される割引契約。
もし具体的な利用方法や他社の事例についてさらに知りたい場合はお知らせください！
renderで画面表示するとURLが変わってしまう問題

## 0. 問題の概要

リクエスト送信時の画面表示方法として、処理に成功した際には`redirect_to`を使い、処理に失敗した際は`render`を使用することが一般的です。

`redirect_to`と`render`の違いについて、こちらの方の記事を参考にしました。
https://qiita.com/koki_73/items/78b8cb2bde7930d55194


しかし、renderで画面表示した際に、URLが変わってしまうという問題があります。
この記事では、この問題に直面した際の解決策について説明しています。

### 0-1. 実装例

例として、posts_controllerのcreateアクションを実装するとします。
投稿に成功した場合は`redirect_to`で画面遷移をし、投稿に失敗した場合はフラッシュメッセージを表示させ、`render`でnew画面を再描画します。

``` ruby: posts_controller.rb

def create
  @post = current_user.posts.build(post_params)
  if @post.save
    # 途中の処理を省略
    flash[:sucess] = "投稿しました！"
    redirect_to sample_path(@post)
  else
    flash.now[:alert] = "投稿に失敗しました"
    render :new
  end
end
```
また、ビューファイル(new.html.erb)は以下のように記述する。
``` ruby: new.html.erb

  # 途中の処理を省略

  <%= form_with url: post_sample_path, method: :post do %>

  # 以下の処理を省略

  <%= end %>
```

また、ルーティングは以下のとおりです。
``` route.rb
new_post_sample_path GET  /post/sample/new(.:format) post/sample#new
post_sample_path     POST /post/sample(.:format)     post/sample#create
```

以上のように実装することで、投稿が失敗すると、フラッシュメッセージを表示させるとともに、new画面が表示されます。
しかし、**フラッシュメッセージが表示された後のnew画面でリロードを行うと、ルーティングエラーまたは別画面が表示されてしまいます**。

## 1. 解決策

結論から言うと、`new.html.erb`のフォーム部分でpostリクエストを指定しているため、createアクションの`render :new`で画面を再描画した際に、POSTリクエストのURLが表示されてしまうことが原因でした。

### 1-1. redirect_toを使う

``` ruby: posts_controller.rb

def create
  @post = current_user.posts.build(post_params)
  if @post.save
    # 途中の処理を省略
    flash[:sucess] = "投稿しました！"
    redirect_to sample_path(@post)
  else
    flash[:alert] = "投稿に失敗しました"
    redirect_to new_post_sample_path(@post) 
  end
end
```
`render`から`redirect_to`に変更することで、URLが変わってしまう問題が解決する。

しかし、`redirect_to`でURLを指定することで、入力した情報が保持されず、初期化されてしまうという新たな問題も発生してしまった。

その場合の解決策についてはこちらの方の記事にありました。
https://qiita.com/yuyasat/items/49e3296f3c64fccc7811

## 2. まとめ

リクエスト送信時の画面表示方法を`render`から`redirect_to`に変更することで以下の問題を修正することができました。

> フラッシュメッセージが表示された後のnew画面でリロードを行うと、ルーティングエラーまたは別画面が表示されてしまう

しかし、入力していた情報が消えてしまうという新たな問題も発生してしまいました。
この新たな問題については、今後考えていきます。


## 3. 参考
 * https://qiita.com/koki_73/items/78b8cb2bde7930d55194
 * https://qiita.com/yuyasat/items/49e3296f3c64fccc7811
Angular × Nxで 80/20アプローチ を成し遂げるまで


これは[Hubble Advent Calendar 2024](https://qiita.com/advent-calendar/2024/hubble)の4日目[^1]の記事です。


## はじめに

株式会社Hubbleのフロントエンドを担当している @KOHETs です。

去年の[Advent Calendar](https://qiita.com/KOHETs/items/bfcbd2b8a5a69dab37fe)でNxを導入した話を書いたのですが、あれから約1年が経ちました。今年は、導入当初からの目標だった **80/20アプローチ**をついに成し遂げたので、それについて話したいと思います。

正直「いつ終わるんだ？」と思うこともありましたが、やり遂げた今は達成感しかありません。

![Screenshot 2024-12-04 at 14.36.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/138755/0a3d74e1-0bf2-c3a7-34bb-a39d14f5b410.png)

## 80/20 アプローチとは

まず、80/20アプローチについて簡単に説明します。

Nxは、アプリケーション（apps）とライブラリ（libs）という2つの要素で構成されています。アプリケーションは複数のライブラリを組み合わせて構築される仕組みです。この構造を利用して、**80%のロジックをlibsに集約し、20%のロジックをappsに配置する**のが80/20アプローチです。

Nx v18時点の[公式ドキュメント](https://github.com/nrwl/nx/blob/18.3.x/docs/shared/workspace/applications-and-libraries.md#mental-model)に記載されていましたが、現在のドキュメントでは削除されています。そのため、この記事では当時の記述を参考に進めます。

このアプローチの魅力は、コードの再利用性を高め、CIの効率を大幅に向上させる点です。特に、Nxの「影響範囲キャッシュ」と組み合わせることで、必要な部分だけビルドやテストを行うことができるのです。

## Nx導入前の状態

2020年当時、Hubbleでは以下のように、独立したリポジトリで開発が行われていました。

- `app1`、`app2`、`app3`の3つのアプリケーションがそれぞれ別リポジトリで存在。  
- 共通コンポーネントを管理するUIライブラリも独立したリポジトリで運用。

一見、リポジトリを分けることで整理されているように見えますが、開発が進むにつれて以下の課題が明らかになりました。

- **リポジトリ間でのコードの重複**：複数のアプリケーションに共通するロジックが重複し、修正や拡張が煩雑に。  
- **CI/CDの効率の悪さ**：UIライブラリを変更するたびに、各アプリケーションが個別にビルドやテストを実行。  
- **UIライブラリ提供の手間**：npm packageを利用しているため、UIライブラリの変更がアプリケーションに反映されるまでの手間が大きい。

これらの課題を解決するため、「モノレポを導入し、すべてのコードを1つのリポジトリに統合しよう」という決断をしました。

## モノレポ統合後の状態

Nxを導入してモノレポに統合した直後のディレクトリ構成は以下のような形でした。

```
.
├── apps
│   ├── app1
│   │   └── src/app
│   │       ├── feature1
│   │       ├── feature2
│   │       └── shared
│   ├── app2 (app1と同じ)
│   └── app3 (app1と同じ)
└── libs
    └── shared
        └── ui
```

これにより、リポジトリ間の分散は解消されましたが、まだ以下の問題が残っていました。

- **CI/CDの非効率性**：各アプリケーションのテストやビルドがすべて実行される状態は変わらず。  
- **モジュール化の不足**：ライブラリはUIコンポーネントだけに限定され、再利用性の向上には至らず。

## 80/20アプローチに向けて

モノレポ統合の次に取り組んだのが、**アーキテクチャの再設計**です。

アプリケーションごとにディレクトリを分け、それぞれの機能を独立したライブラリとして切り出しました。具体的には以下のような構成に変更しました。

```
.
├── apps
│   ├── app1
│   ├── app2
│   └── app3
└── libs
    ├── app1
    │   ├── feature1
    │   ├── feature2
    │   └── shared
    ├── app2 (app1と同じ)
    ├── app3 (app1と同じ)
    └── shared
        └── ui
            ├── button
            └── dialog
```

Angularでは、機能ごとにモジュールを分割する設計が基本となっており、Lazy Loadingによってモジュールが独立した単位で運用されています。この特性を活かし、Feature ModuleをNxのライブラリ構造に移行する際にも大きな変更は必要ありませんでした。

移行作業は、`import`パスを変更し、依存関係を明確に整理するだけでスムーズに完了しました。

---

## 移行のプロセス

移行作業は一度にすべて行うのではなく、新しいモジュールを作成する際には新構成を適用し、既存のコードは少しずつリファクタリングしました。この柔軟なアプローチにより、日々の業務に支障をきたすことなく進行しました。

Angularや他のライブラリのバージョンアップとも並行していたため、最終的に移行が完了するまでに約4年を要しました。そして2024年11月、すべてのモジュールがライブラリ化され、80/20アプローチを完全に実現しました。



## 現在の状況

Hubbleの開発規模はこの4年間で大きく拡大し、現在ではアプリケーションが9つ、ライブラリが198個に達しました。このような規模でも、Nxの影響範囲キャッシュ機能を活用することで、効率的な開発体制を維持しています。

現在のCIの実行時間もワーストケースでは30分以上かかってしまいますが、平均11分で完了するようになりました。さらに、コードのモジュール化が進んだことで、可読性やメンテナンス性も向上しました。

## まとめ

この記事では、HubbleがNxを活用して80/20アプローチを達成するまでの道のりを紹介しました。モノレポ導入からアーキテクチャの再設計、移行作業、そして現在の成果まで、チーム全体の努力の結晶です。

似たような課題に直面している方にとって、この経験が少しでも参考になれば嬉しいです。もし興味が湧いたら、ぜひチャレンジしてみてください！

明日は @beltway7 さんです！

[^1]: 平日のみの投稿なので5日ですが、4日目の記事としています。
配列を入力するときの注意

```java:Ex1_08_3
/*-< 演習：Ex1_08_3 >---------------------------------
コマンドライン引数として３つの数値を受け取り、その合計値を
表示するプログラムを作成してください。
<例>
コマンドライン入力値：13 7 20
表示される値：40
----------------------------------------------------*/
class Ex1_08_3 {
	public static void main (String[] args) {
		
		int input1 = Integer.parseInt(args[0]);                      
		int input2 = Integer.parseInt(args[1]);                      
		int input3 = Integer.parseInt(args[2]);                                                                    
		System.out.println( input1 + input2 + input3 );   
		
	}
}

```

String（文字）→int（整数）に直す場合は、Integer.parseInt（ｘ）を用いた。
初めは、args[]を１からスタートすると勘違いしていたが、０からスタートなのでコマンドライン引数を入力するときにエラーが出たので気を付ける。
Ribbonが上手くつけられずに困った話

# 概要
Juliaを使って簡単な線形予測の結果とノイズ項込みの信頼区間を表示しようと, `plot`関数のパラメータの1つである`ribbon`を用いることにした.
[公式ドキュメント](https://docs.juliaplots.org/dev/gallery/gr/generated/gr-ref037/)によると, ribbonの引数は
> Ribbons can be added to lines via the ribbon keyword; you can pass a tuple of arrays (upper and lower bounds), a single Array (for symmetric ribbons), a Function, or a number.
(上限と下限の配列・数値を入れればOKやで)

と書かれていたのに, 実際は基準となる値からの差分を入力する必要があることが判明した.

# plot関数におけるribbonとは
`plot`関数のパラメータの1つである`ribbon`を用いると, 指定された範囲を塗りつぶして視覚的に表現することができる. 主な用途としては, 信頼区間や予測区間を示す際に, データの変動範囲を強調するために使用される.
```test_ribbon.jl
using StatsPlots

p = plot(0:10, ribbon = 0:0.5:5)
```
![test.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2702347/04173766-62bd-877f-6e75-51a47b8111f2.png)

# ribbonの使い方
```ribbon.jl
plot(x, data, ribbon=(lower, upper), fillrange=:bottom, alpha=0.3)
```
[公式ドキュメント](https://docs.juliaplots.org/dev/gallery/gr/generated/gr-ref037/)によると, `ribbon`は`plot`関数の中のパラメータの1つであり, 下限と上限を指定することで使用することができるようである. (1番目が下限, 2番目が上限, 単に1つだけだと, 上限と下限が等しいと認識する)
引数として設定できるデータは数値そのものか, データとサイズが等しいサイズのものであればOK. 
また, 併せてよく用いられるパラメータの1つが, `ribbon`の後ろに続く`fillrange`である. `fillrange`は, どの方向に塗りつぶしを行うかを指定することが可能である. 例えば, `fillrange=:bottom`はリボンを下側方向に塗りつぶし, `fillrange=:top`は上側方向に塗りつぶされる. デフォルトでは, `fillrange=:none`に設定されているが, 特に指定しなくても問題ない.
もう1つ, よく用いられるパラメータは`alpha`だが, これは塗りつぶされた箇所の透明度を表している.(0になるほど透明になる)

# 注意してほしい箇所
> `ribbon`は`plot`関数の中のパラメータの1つであり, 下限と上限を指定することで使用することができるようである

先程, このように伝えたが, これは少し語弊がある.(と筆者は感じている.)

以下のように,  ”言われた通り”上限と下限を入力すると, 想定よりも大きく信頼区間が出てしまう.
```figure.jl
using GLM, CSV, DataFrames, StatsPlots

d = CSV.read("./input/data.csv", DataFrame)
# 線形回帰モデルを構築 (y ~ x)
res_lm = lm(@formula(Y ~ X), d)
# プロット用の仮データ
X_new = DataFrame(X = 23:60)

pred_95 = predict(res_lm, X_new, interval=:prediction, level=0.95)

# グラフをプロット
p = scatter(d.X, d.Y, xlabel="X-axis", ylabel="Y-axis", label="")
p = plot!(X_new.X, pred_95.prediction, ribbon=(pred_95.lower, pred_95.upper), fillrange=:bottom, alpha=0.3) 
```
![p2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2702347/3facc918-ba6b-6368-2f35-89a2e729d6d2.png)

これは, パラメータに引数として入力するべき値が「下限」や「上限」ではないことに由来する.
正しくは **「下限までの差分」** 及び **「上限までの差分」** を入力する必要があるのである.

よって, 先程のコードは以下のように書き換えることで, 正しく表示させることができるのである.
```figure.jl
using GLM, CSV, DataFrames, StatsPlots

d = CSV.read("./input/data.csv", DataFrame)
# 線形回帰モデルを構築 (y ~ x)
res_lm = lm(@formula(Y ~ X), d)
# プロット用の仮データ
X_new = DataFrame(X = 23:60)

pred_95 = predict(res_lm, X_new, interval=:prediction, level=0.95)

# グラフをプロット
p = scatter(d.X, d.Y, xlabel="X-axis", ylabel="Y-axis", label="")
# 下限/上限との差分を取る
p = plot!(X_new.X, pred_95.prediction, ribbon=(pred_95.prediction - pred_95.lower, pred_95.upper - pred_95.prediction), fillrange=:bottom, alpha=0.3) 
```
![p3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2702347/a3251ee5-9403-5811-c89f-cb5a4e3a79e7.png)
【chatGPT対話備忘録】１バイトの歴史

# 私：
１バイトの歴史について教えて
# ChatGPT:

「1バイト」の歴史について説明します。この概念はコンピュータやデジタルデバイスの進化に密接に関連しています。

### 1バイトの定義
1バイト (1 byte) は8ビット (8 bits) で構成される情報単位です。
コンピュータの基本的なデータ格納・処理の単位として使われます。
### 歴史的背景
##### 初期のデジタルコンピュータ（1940年代〜1950年代）

コンピュータはビット単位（0と1の2進数）で動作していました。
データの格納や処理における「単位」はまだ統一されていませんでした。
各コンピュータが異なるビット幅（例えば6ビットや9ビット）を採用していました。
##### 8ビットの標準化（1960年代）

IBMの「System/360」（1964年発表）が、1バイトを8ビットと定義しました。
これにより、「8ビット = 1バイト」が事実上の標準となりました。
1バイトで256通り（0〜255）の値を表現できるため、ASCII文字コード（7ビット）を効率的に格納可能。
##### マイクロプロセッサと1バイト（1970年代）

初期のマイクロプロセッサ（例えばIntel 4004）は4ビット幅を使用しましたが、その後8ビットプロセッサ（Intel 8008、8080）が普及。
この頃から「8ビットコンピュータ」が一般的に使われ始めました。
##### 1バイトの用途の拡大（1980年代〜1990年代）

メモリ単位やキャラクタ単位として1バイトが広く利用されるようになりました。
カラーディスプレイでは、1バイトが8色や256色を表現する最小単位として使用されました。
##### マルチバイト文字と国際化（1990年代〜）

ASCIIコードは英語圏向けの文字セットでしたが、日本語や中国語などの多言語対応が必要になり、Shift_JISやEUC-JPなどの「マルチバイト文字コード」が登場しました。
UTF-8のようなエンコーディング方式では、文字の表現に1バイト以上を使用しますが、1バイト単位で基本のデータを格納する設計は変わりません。
### 現代の1バイトの位置づけ

1バイトは依然として基本的なデータ単位であり、テキスト、イメージ、サウンドなどさまざまなデータ形式で使用されています。
メモリ容量やストレージはバイト単位で表記されます（例：ギガバイト、テラバイト）。
まとめ
1バイトは、コンピュータのデータ単位としての歴史の中で進化してきました。IBMの8ビット標準化から始まり、国際化や複雑な文字エンコーディングを含む現代の情報社会まで、1バイトはデータ処理の基本単位として重要な役割を果たし続けています。
【時短Tips】エンジニアのためのコードレビュー効率化術

## はじめに
コードレビューはプロジェクトの品質向上に不可欠ですが、多くの時間を要することも事実です。この記事では、コードレビューを効率化する方法について、具体的なツールや手法を紹介します。忙しいエンジニアの方にとって、少しでも時間を節約できるヒントになれば幸いです。

---

## 1. **コードレビューの基本原則**
レビューを効率化するためには、明確な基準を設けることが重要です。

### 1.1. 明確なルールを設定
- **コーディング規約を共有**
  - チーム全員で統一されたコーディング規約を遵守することで、指摘内容を減らせます。
  - 例: AirbnbのJavaScriptスタイルガイドを採用。
- **レビューの目的を明確化**
  - レビューのフォーカスを「機能」「パフォーマンス」「セキュリティ」などに分けると効率的。

### 1.2. 小さなプルリクエスト
- **プルリクの粒度を小さく保つ**
  - 大量の変更を1つのプルリクで送ると、レビュー時間が長引きます。
  - 理想的なプルリクの変更範囲は「300行以下」が目安。

---

## 2. **ツールの活用**
ツールを使ってレビュー作業を自動化・効率化しましょう。

### 2.1. 静的解析ツール
- **ESLint**や**Rubocop**などの静的解析ツールを活用することで、コーディング規約違反を自動検出。
- サンプル: ESLintの設定例
  ```json
  {
    "extends": "eslint:recommended",
    "rules": {
      "indent": ["error", 2],
      "quotes": ["error", "double"],
      "semi": ["error", "always"]
    }
  }
  ```

### 2.2. CI/CDツールとの連携
- **GitHub Actions**や**CircleCI**でテストを自動化し、レビュー前に品質を確認。
- サンプル: GitHub Actionsの設定例
  ```yaml
  name: CI
  on: [push, pull_request]
  jobs:
    test:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v2
        - uses: actions/setup-node@v3
        - run: npm install
        - run: npm test
  ```

---

## 3. **効率的なレビュー方法**
### 3.1. 時間を区切る
- コードレビューの時間を1回あたり30分以内に制限。
- 長時間レビューすると集中力が低下し、指摘の質が落ちる。

### 3.2. コメントのテンプレート化
- よく使う指摘はテンプレート化しておくと時短に。
  - 例:
    - "この関数はリファクタリング可能です。1つの責務に絞りましょう。"
    - "マジックナンバーを定数化してください。"

---

## 4. **コミュニケーションの工夫**
### 4.1. 非同期コミュニケーション
- チャットやコメントで非同期に指摘を行うことで、レビュー待ち時間を削減。
- **Slack**の通知とGitHubを連携すると便利。

### 4.2. 指摘の優先順位付け
- 重大な問題（バグやセキュリティ問題）を最優先で指摘。
- 細かいスタイルの問題はツールや後続の改善で対応。

---

## 5. **実践例**
以下は、コードレビュー効率化の具体例です。

1. **コードレビューガイドを作成**  
   チームのレビュー基準を文書化し、新メンバーにも共有。

2. **レビューのタイムボックス設定**  
   毎日10:00～10:30にレビュー時間を確保。

3. **自動化ツールを導入**  
   ESLintとGitHub Actionsでコーディングスタイルチェックを自動化。

---

## 6. **まとめ**
コードレビューの効率化は、個人の工夫だけでなくチーム全体の取り組みが重要です。この記事で紹介した方法をぜひ試して、時短と品質向上を両立させてください！