ペーペーのとりあえずメモ

(余裕がある時に分類整理します。)

# 目次（書きかけ）
- [環境構築、設定](#環境構築、設定)

- [実装](#実装)

    - [関数の戻り値以外で、値を返す方法](#関数の戻り値以外で値を返す方法)
    - [オブジェクト指向言語](#オブジェクト指向言語)
        - [kotlin](#kotlin)
            - [非同期処理のjobの管理で、 CoroutineScope.isActiveよりも厳密に状態を管理できる方法](#非同期処理のjobの管理で-coroutinescopeisactiveよりも厳密に状態を管理できる方法)
            - [when句での比較で使う「is」のイメージ](#when句での比較で使うisのイメージ)
            - [関数定義が1つだけの事Interfcce](#関数定義が1つだけの事interfcce)
            - [Jetpack Compose、Android View](#jetpack-composeandroid-view)
            - [Android端末をVPN接続でサーバと繋ぎたい](#android端末をvpn接続でサーバと繋ぎたい)
    - [└実装、レビューで気を付けること](#実装レビューで気を付けること)
- [エラー](#エラー)
- [実装レビューで気を付けること](#実装レビューで気を付けること)
- [markdown](#markdown)
- [フレームワーク](#フレームワーク)
- [作業](#作業)
    - [教訓](#教訓)
- [githubで起きた珍事件](#githubで起きた珍事件)
- [リモートデスクトップが固まるポイント3つ](#リモートデスクトップが固まるポイント3つ)
- [有効数字](#有効数字)
- [UTF-8 BOM](#utf-8-bom)
- [豆知識](#豆知識)

🔍：調べる事

# 環境構築、設定

- 設定とかを弄る時は、必ず元の状態のバックアップを取ってから弄るようにする。
  - 設定ファイル
→弄る前のファイルのコピーを取っておく
  - コマンドで変える
→元の状態のダンプやキャプチャをとっておく
　(戻し方が分からなくなっても、最終的なゴール(この設定にればいい)が分かるようにするため)
- ライブラリとかが非推奨であっても絶対ダメというわけではない
厳密さはそこまで求めないから、とりあえずで簡単にこの機能が使いたい！！という場合であれば、あえて非推奨になっている今まで使ったことがあるライブラリを使うというのも一つの手段
- 仮想環境とかを作った際に、tmp直下に色々と置くのはやめた方がいい（散らかるので）
- 消してはいけないデータやファイルなどは、適切な場所に配置する
→一時フォルダの中に入れてしまうと、あくまで「一時的なファイル置き場」であるため、消されてしまうことが考えられる


# エラー
- よく出るエラーの場合
↓
なんとなく原因の予想が付く
↓
まず、そこを確認しに行く
↓
で、そこがエラーの原因ではなかったら、ログの中身を詳しく見てみる

- 🔍syslog　とは、他のlogとの違い

# vagrant、VM
- vagrant fileは、さくらエディタで開きっぱなしでVMの起動シャットダウンをしてもok!!
(閉じたり開いたりを繰り返さない方がいい)


# バグが起きた時
デバッグできるソースコードが手元にあって、落ちる範囲をなんとなく特定できた場合


try-catchで囲んでエラーバンドリングしてログでも出せば、何が理由で落ちているのかが分かるかも！！！
（↑私個人、この方法でエラー理由を特定した実績あり）

# log
## logger
loggerを見れば以下のことが分かる
- logの吐き出し場所
- logのフォーマット
- logのファイルのローテートの仕方
  - よくあるのが、ファイルのメモリがこれくらいいったら、ファイル名の後ろに日付を付けて保存していき、日付を跨いだらファイルを新しくする

### logの実装方法
https://qiita.com/opengl-8080/items/49719f2d35171f017aa9

# 設計？実装？にて
- URIは、ソースコード上に埋め込む（直書きする）のではなく別ファイル（設定ファイル系？）で、管理する

## 設計
### 画面設計
- 入力欄は、
数値：右寄せ
それ以外：左寄せ
にするのが一般的
↑Excelが参考になるよ
## 結合試験
- 画面にこのシナリオで操作をしたら、どうなりますか？を確認する
(このパターンで入力したら、画面の動きはどうなりますか？的なの)
- 第三者から見た時に、分かる内容になっているか？
- その手順でできるか？
- テストをするための前提条件の状態にするために、必要な条件はないか？
- ↑「これ、試験できなくね？」っていうパターンが無いか？(あった場合は、備考欄にできない理由を書いてドロップアウト)
- 結合試験=
  - シナリオ(動かした時の一連の流れ)が上手くいくかを確認する
  - 全体の流れ。機能として見た時にこの流れあるよねっていうのを確認する
- パーツ毎ではなく、シナリオのパターンごとにどういった意図したことができるのか？

# webアプリ
## Cookieの確認箇所
### ブラウザの開発者ツール
- アプリケーションタブ：ブラウザが覚えているCookieの情報が確認できる
- ネットワークタブ：ブラウザの通信が見れる
　　　　　　　　　そのため、cookieが送信されたり、リクエストヘッダやレスポンスヘッダでset-Cookieされているかが確認できる

# 実装
## 関数の戻り値以外で、値を返す方法
- try-chtchで捕まえて、throwする
- 別ファイルとかに出力して、出力したものを、別なやつで読み込む

# オブジェクト指向言語
## Java,kotlin
### クラスの継承
- 変数の定義を、親クラスの型でしておけば、子クラスの型のデータをそこに入れることが可能
子クラスの型で定義した変数に、親クラスの型のデータを入れることは出来ない（子には定義されているが、親には定義されていない情報があるため）


## kotlin
### バッキングフィールド (backing field)
- 「setter()を介して、最終的にデータが格納される先」のこと
- 必要な時にkotlinにより自動で宣言され、開発者が自分で宣言することはない
- プロパティの一部としてのみ使用され、メモリ内に値を保持する役割がある
- setter()は、フィールドに`set(value)`のvalueの値を代入する
<details><summary>プロパティ</summary>

- Javaでいうところのフィールドとgetter()、setter()メソッドに相当する機能
- Javaではクラス内で宣言された変数（フィールド）に対して、getter()とsetter()を宣言するが、これを一度に全てできるのがバッキングプロパティ（の宣言）
</details>

### set()関数のパラメータの型
- set()関数のパラメータvalueには、変数の型が明示されていない
→set()関数のパラメータの型は、kotlinで予測してくれるため、わざわざプログラマが明示する必要は無い
例）string型のnameのsetter()
　　→パラメータとして渡してくれるvalueというう変数も当然string型
### returnとかの後ろに付いてる@
こうゆうの↓
return @runBlocking
- これはスコープを表している
- アノテーションではない（←最初！アノテーションだと勘違いしてた･･･）

### 非同期処理のjobの管理で、 CoroutineScope.isActiveよりも厳密に状態を管理できる方法
- ```mutex.tryLock()```を使う
#### なぜ```mutex.tryLock```を使った方がいいのか
- jobの以下のような実装の場合「①```coroutineScope.lanch(Dispatchers.IO){処理}```の処理を実行する」のと「②Job型の変数に代入する」というのに分かれている。
そのため、タイミングが悪いと①が終わっているのに、②が終わっていなくて、```job.isActive```の結果がtrueになる可能性がある。
```
val job:Job = scope.launch(Dispatchers.IO){
    // 非同期処理
    println("Hello, world")
}
```
- ```mutex.tryLock()```は必ず1つのmutexだけがlockされることが確約されている
また、mutexのlockを解除するときは、```mutex.unLock()```で実装者が明示的にlockを解除する
必要があるため、lockが解除されるタイミングがコード上で分かりやすい。

以上のことから、mutexを使った方がタイミングのずれによる問題が起きない。
#### 参考

https://developer.android.com/kotlin/coroutines/coroutines-adv?hl=ja#coroutinecontext

https://qiita.com/offwhite/items/94540e7cc3b330507c9c#dispatchers%E3%81%AF%E4%BB%96%E3%81%AB%E4%BD%95%E3%81%8C%E3%81%82%E3%82%8B%E3%81%AE%E3%81%8B

https://developer.android.com/kotlin/coroutines/coroutines-adv?hl=ja#job

https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/is-active.html

https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.sync/-mutex/try-lock.html

https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.sync/-mutex/unlock.html

### when句での比較で使う「is」のイメージ
#### objectの比較では「is」は不要
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2330584/7ece719c-7cf7-487d-8783-e5e768983f77.png)

#### classの比較で「is」を付けた場合のイメージ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2330584/fc2ebc41-6a33-49aa-9ca7-464491c66647.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2330584/b5d1759c-67fa-424a-856e-0474dabe4f43.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2330584/2bb266c2-74b6-4a3b-b12c-aea0259cd061.png)


#### classの比較で「is」を付けなかった場合のイメージ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2330584/fecc03a9-f7ea-42e0-b4dd-1acca0ddbbd8.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2330584/704a2a35-6359-4a45-a509-3409889a67d3.png)

### 関数定義が1つだけの事Interfcce

https://okuzawats.com/blog/functional-interface/



## Jetpack Compose、Android View
- なるべく、親の要素に要素の位置の指定をやらせる
- ```px```が、粒の数
- ```Dp```が、固定の長さ（長さのcmみたいなイメージ）

|Android View|Jetpack Compose|
|---|---|
|ConstraintLayout|Boxみたいなイメージ|
|LinearLayout|Columnみたいなイメージ|

## remember
- rememberもComposable関数
- **rememberの()なし**＝再評価のタイミングを与えない
↑初期描画時の評価のみ行う
- 再評価＝中括弧{}の中の処理
```kotlin:sample1.kt
    var isSuccess by remember {
        Log.d("ample", "debug") // 初期描画時(初回コンポーズ時)にしかログ出力されない
    }
```
- 何かのタイミングで{}の中の処理を実行させたいときは**rememberの()あり**にして、再評価のタイミングを与えてあげる必要がある
     - ()の中を監視して、もし()の中に動きがあったら、{}の中の処理を実行する
```kotlin:sample2.kt
    val eventHoge = remember(event) {
        Log.d("sample2", "debug") // eventが変化するたびにログ出力される
    }
```
- LaunchedEffect↑と同じ感じ
    - ()の中を監視して、もし()の中に動きがあったら、{}の中の処理を実行する感じ
### rememberが値をいつまで保持しているのかのイメージ
![2025-06-04_01h27_29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2330584/4cb7132f-ba01-4bc1-954e-59c6801d40bc.png)
![2025-06-04_01h27_40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2330584/38eb3fc8-0c2c-42cf-b9d1-af5a5158d7c8.png)
![2025-06-04_01h33_40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2330584/72ec1a25-1ed4-47ed-a6da-5f018735f843.png)

### 参考サイト
https://engawapg.net/jetpack-compose/2113/remember-tips/

## Android端末をVPN接続でサーバと繋ぎたい

gnirehtetを使うと、PCの中で起動しているAndroid端末のエミュレータや、PCとUSB接続したAndroid端末とサーバをVPN接続できる

https://github.com/Genymobile/gnirehtet

### イメージ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2330584/15de2fc5-cd37-497c-be56-e28bd8d3f334.png)



## UnitTest
- テスト対象関数のI/Oのみをチェックする
    - 正直中のロジックはどうでもいい
    - 「〇〇の処理を通ることを確認して・・・」「この時は〇〇の処理が呼ばれないことを確認して・・・」とか、中のロジックに依存するテストを書いてしまうと、バージョンが変わってライブラリの仕様が多少変わった場合テストが壊れてしまう
    - 関数のI/Oだけをチェックするテストを作ると、I/Oはそのままで中のロジックが多少変わった場合でもテストが壊れない = 堅牢なテストになる


## JavaScript
### ファイル名
- 小文字のケバブで統一するのが無難
- ファイル名に大文字を混ぜると、OSによって挙動が変わることがある。
- gitでも大文字、小文字の区別をする設定があるが、知らないと結構ハマる

https://www.nyamucoro.com/entry/2020/06/02/204522

https://w.atwiki.jp/aias-jsstyleguide2/pages/15.html

### 定数名
- 具体的な数値や文字列を表す定数
→大文字と「_」(アンダースコア)を組み合わせた名前を付けるのが一般的
こうすることで、コード内で見つけやすくなり、値を変えてはいけないことが一目でわかる
#### 参考文献
Ethan Brown. 初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発（武舎 広幸・武舎 るみ訳）. 株式会社オライリー・ジャパン, 2017, p.26.

## 実装、レビューで気を付けること
- List形式のデータを扱う機能に触れる場合は、並び順に注意する
    - 表示するときに並び順があるデータは、表示結果がどこのデータと合っている必要があるのかを抑えて、表示結果が合っているかを確認する
- データを画面に表示させるようなものは、複数回操作を試してみて操作をする毎に結果が変わるかどうかも確認を行う

# Markdown
- ローカル環境でMarkdownの編集がしたい場合、VScodeで編集すれば、プレビューができる(VScodeの機能で、Markdownのプレビューが可能)
# フレームワーク
- 枠組
- <INS>仕組みそのものを提供する</INS>(←ライブラリは「機能だけ」を提供する)
- 簡単に高速な処理を実現できるように提供されるソフトウェア
- Spring Bootは、SpringMVCを元にできた
![20240820_015424_Original.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2330584/27e0c3e9-7656-c67c-dac1-482497c0d618.jpeg)
 # 作業
 - （あまり良くはないけど）もし時間に余裕が無かった場合は、最悪UnitTestはチケット化してテスターさんにフルリグレッションテストをしてもらっている間にやるってのも1つの手段
     - この時、UnitTestがコンパイルエラーとかで走らなくなる場合もあるので、FIXMEコメントを付けて、@Ignoreアノテーションを付けてテストヲスキップするようにしておく

## 教訓
- GithubActionsで設定しているCIのエラーは、ブラウザで文字列検索とかもできなくて凄い見づらい。
しかし、上から虱潰しに根気強く読んでいけば、エラー原因が書かれている（ことが多い）。
↑詳しく読んでいたつもりになっていたが、自分が見ていた2行下に原因が書かれているのに気づかず、先輩がエラー原因を見つけてくださった・・・（2回くらいこれをやらかした・・・次は根気強く確認しよう・・・）

# リモートデスクトップが固まるポイント（3つ）
- 自分のPC（描画が遅いとか）
- ネットワーク
- 相手のPC

## Githubで起きた珍事件（？）
### 事象
ローカル環境で作業ブランチにdevelopブランチをマージしてコミットした。
すると、developに既に取り込まれていたはずの差分が、Github上のPRで差分として出てしまっていた。
（本当なら、developに既に取り込まていたはずの差分は、GithubのPRで差分として出てこないはず・・・）
### （恐らく）原因
たぶんローカル環境で作業ブランチにdevelopブランチをマージした際に、フェッチをしていない状態でマージをしてそれをコミットしていた。（←記憶があいまいで定かではないが・・・）
そのため、マージされたdevelopブランチの情報が古くなっていたのではないか。


## UTF-8 BOM
javaの単体テストにて、文字列が一致しているのにも関わらず、asssertで失敗する事象が起きた。
原因：CSVファイル側の文字コードがUTF-8 with BOMになっている
対策：文字コードを変更して、BOMが付与されないようにする
### 参考

https://ja.m.wikipedia.org/wiki/%E3%83%90%E3%82%A4%E3%83%88%E9%A0%86%E3%83%9E%E3%83%BC%E3%82%AF

https://wa3.i-3-i.info/word11423.html

※以下のBOMは違うよ！

https://satoshun.github.io/2020/02/gradle-bom-android/

### gnirehtetを使うとAndroidなどの端末をPC経由でVPN接続出来る

https://github.com/Genymobile/gnirehtet


# 有効数字
★0以外の数字の桁が何桁で固まっているかが、有効数字

0.012←有効数字2桁

↓これらも全部有効数字2桁
12
1.2
0.12
0.012
0.0012

## 豆知識
時報の音
- ラ・ラ・ラ　　ラー
  ↑ 440Hz　　　↑880Hz
  
# DDD


https://qiita.com/kotobuki5991/items/22712c7d761c659a784f

https://little-hands.hatenablog.com/entry/2018/12/10/ddd-architecture