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

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

目次（書きかけ）

• 設計

  • UML
    • ステートマシン図
      • 参考書

• 環境構築、設定

• 実装

  • オブジェクト指向言語
    • 用語
  • 関数の戻り値以外で、値を返す方法
  • 「オブジェクト指向言語」「クラスの継承」項目は、Java,kotlinの実装で共通で使えるモノ、考え方に移植
    • 「kotlin」項目は、kotlinについての個人的メモに移植
  • └実装、レビューで気を付けること
  • エラー
  • UnitTest
  • UnitTestのモックで、呼び出した回数に応じて返す値を変えたい時
  • UnitTestでハマったこと
    • mockじゃないと、「every」とかの関数の振る舞いを変えるやつは使えない
  • UnitTestでやらかしたこと
    • テストコードのmockがNullPointerExceptionになった(´;ω;｀)
      ＋
      デバッグしたら、本物の方に張ったブレイクポイントで止まった( ˘•ω•˘ )？？ﾊ？ﾅﾆｶﾞﾀﾞﾒﾅﾉ???
    • 既存のJunit4のテストクラスに、テストメソッドを追加したのに、追加したテストメソッドにテストを実行する三角マーク▶が出てこない
  • PRを出す前のセルフチェック項目
  • JavaScript
    • ファイル名
    • 定数名

• 実装レビューで気を付けること

• markdown

• フレームワーク

• 作業

  • 「まで」の罠
  • 教訓
  • 作業の進め方について
  • リモートデスクトップ
  • リモートデスクトップが固まるポイント3つ
  • リモートデスクトップ接続でデュアルディスプレイにする方法
  • Tool
    • ビデオ通話通話アプリ

• GitHubのブランチ名参考

• githubで起きた珍事件

• Gitでstashを使う時の例

• 有効数字

• UTF-8 BOM

• 有効数字

• 豆知識

• DDD

• 例示／実験用として利用できるドメイン名

• 略語（？）

• 商用利用OKのイラスト類

• 自分の特性

  • 参考書の読み方

• ハマったこと

• WAFを使ったSQLインジェクション対策

🔍：調べる事

設計

UML

ステートマシン図

ここのメモを書いた経緯

UMLの公式レファレンスには、ステートマシン図での例外処理の表し方は特に記載が無い。
しかし、例外処理の考慮が必要なため、例外処理をステートマシン図中に表したい時が実際にあった。
そんな中で、私が唯一見つけたステートマシン図で例外処理の記載方法が書かれていたのが、「図解即戦力 UMLのしくみと実装がこれ1冊でしっかりわかる教科書」だった。

• 遷移の関連線の書き方
  
• 遷移の関連線の使い方
  • 例外処理による遷移
    • ギザギザの線で表記する

参考書

• 図解即戦力 UMLのしくみと実装がこれ1冊でしっかりわかる教科書
  • 2022年6月25日紙版発売　出版社：技術評論社　著者：株式会社フルネス　尾崎惇史（おざき　あつし）　ページ：126-127
• UML公式レファレンス
  • 公式サイト：https://www.omg.org/spec/UML/
  • UML/2.5.1/PDF：chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://www.omg.org/spec/UML/2.5.1/PDF
    

環境構築、設定

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

    • 「tmp」は多分「temporary（テンポラリ）」の略です。
      「temporary（テンポラリ）」の意味は「一時の」とか「一時的な」とか「仮の」とかです。

環境構築でハマったこと

バックアップ用にコピーした方の古い設定ファイルを読み込んでしまっていてサーバー起動時にエラーになってしまった
→教訓：バックアップはホームディレクトリに置く
　ホームディレクトリ＝ログインしたらすぐに見れるところ
古いファイルは、サーバー起動時に読み込まれるファイルが置かれている場所に一緒に置いておかない

vagrant、VM

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

設計？実装？にて

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

設計

画面設計

• 入力欄は、
  数値：右寄せ
  それ以外：左寄せ
  にするのが一般的
  ↑Excelが参考になるよ

結合試験

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

webアプリ

Cookieの確認箇所

ブラウザの開発者ツール

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

webアプリはchrome以外のブラウザを使って開発するとよい

webアプリを chromeで使う場合は、webアプリ側で細かい設定をしてしていなくても、よしなに表示したり動かしてくれる
しかし、他のブラウザは、きちんと設定していないと変な動きになることがよくあるため

実装

オブジェクト指向言語

用語

• オーバーロード
  • 仮引数の個数か型が異なれば、同じ名前のメソッドを複数定義できること
    ただし、引数が同じで、戻り値の型だけが異なるものは定義できない
• シグネチャ（signature）
  • 以下のようなメソッド宣言の「save(int hoge, int huga)」の部分
  • メソッド宣言に記述するメソッド名や引数の個数や型とその並び順の情報のことをメソッドのシグネチャと呼ぶ
  • 戻り値の型は含まれない
  • オーバーロードは、シグネチャが重複しない場合のみ許される

Image.java

public static int save(int hoge, int huga) { // 以下略

シグネチャ（signature）の日本語訳

著名、サイン、著名すること、（調子、拍子）、記号

• シングルトン
  • 「一つだけしかインスタンスが作成されないクラス」
  • objectを使って定義する

エラー

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

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

バグが起きた時

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

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

log

logger

loggerを見れば以下のことが分かる

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

logの実装方法

関数の戻り値以外で、値を返す方法

• try-chtchで捕まえて、throwする
• 別ファイルとかに出力して、出力したものを、別なやつで読み込む

UnitTest

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

UnitTestのモックで、呼び出した回数に応じて返す値を変えたい時

※前提：Junit4とMockKを使用

andThenを使う

// モックのgetNumber("hoge")メソッド の1回目の呼び出しで返すのは1、2回目は2、3回目は3が返されるようになる
every { mockClass.getNumber(5) } returns 1 andThen 2 andThen 3

参考
MockK公式サイト

📝「使ってるライブラリ名（Junit4とか、MockKとか）＋やりたいこと」で検索をかけるといいかも
　（使ってるライブラリ名を検索ワードに入れずにググり、情報が出てこず一敗・・・（先輩が↑のやり方で見つけてくれた））

　UnitTestでハマったこと

mockじゃないと、「every」とかの関数の振る舞いを変えるやつは使えない

every { testTarget.getId() } returns "ID"
    //     ↑{}の中がmockではなく本物だと、振る舞いを変えることができない

ただし、コンパイルエラーとかにはならないので注意が必要！！⚠️
※前提：Kotlin、Junit4、MockKを使用

UnitTestでやらかしたこと

テストコードのmockがNullPointerExceptionになった(´;ω;｀)
＋
デバッグしたら、本物の方に張ったブレイクポイントで止まった( ˘•ω•˘ )？？ﾊ？ﾅﾆｶﾞﾀﾞﾒﾅﾉ???

• mockが意図せずNullPointerExceptionになることは無い
• mockを作ってるのに、本物のメソッドに張ったブレイクポイントで止まるのはおかしい

↓↓↓
mockがNullPointerExceptionになった場合や、mockにしたものが本物のメソッドに張ったブレイクポイントで止まる場合は、
「mockではなく、本物の方を使ってしまっているカモ！！」　←⚠️要確認⚠️

既存のJunit4のテストクラスに、テストメソッドを追加したのに、追加したテストメソッドにテストを実行する三角マーク▶が出てこない

• 試したこと
  • @Testのインポートを間違えて、違うのを使っていないかを確認
  • Android Studioのキャッシュを削除
    それでもダメ(´;ω;｀)ﾅﾝﾃﾞ?!

結論

テストメソッドを書いた場所のスコープが、他のテストメソッドの中だった
ｷﾞｬｱｧｧｧｧ━(ﾟДﾟ|||)━━!!!!!!（先輩が見つけてくれた）

こんな感じのイメージ↓

教訓（先輩の教え）

Android Studioとかだと、上の所にスコープが出ている。そこからスコープが間違えていることに気付けるようになるといいね・・・

PRを出す前のセルフチェック項目

• フォーマッタがかかっているか
  • インデントがずれていないか
  • 不要なimport文が残っていないか
• 不要なものが残っていないか
  • 空行
  • コメントアウトして消し忘れた行
  • デバッグ用のlog
    • （Cucumberの@debugタグとかも）
• 表記揺れを起こしていないか
• メソッド名やクラス名が実態と合っているか
• JavadockやKdock
  • 説明書きが実態と合っているか
  • @paramや@returnの記載が漏れていないか、書いてる内容が合っているか
• 記載ルールが合っているか
  （「記載ルール」にそもそも何があるのかの把握と、明記（？）が必要）
  • CucumberのGivenやWhenなどの文言の記述がガイドと合っているか
  • メソッド名や、変数名が決められたルールと合っているか

JavaScript

ファイル名

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

定数名

• 具体的な数値や文字列を表す定数
  →大文字と「_」(アンダースコア)を組み合わせた名前を付けるのが一般的
  こうすることで、コード内で見つけやすくなり、値を変えてはいけないことが一目でわかる

参考文献

Ethan Brown. 初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発（武舎 広幸・武舎 るみ訳）. 株式会社オライリー・ジャパン, 2017, p.26.

実装、レビューで気を付けること

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

Markdown

• ローカル環境でMarkdownの編集がしたい場合、VScodeで編集すれば、プレビューができる(VScodeの機能で、Markdownのプレビューが可能)

フレームワーク

• 枠組
• 仕組みそのものを提供する(←ライブラリは「機能だけ」を提供する)
• 簡単に高速な処理を実現できるように提供されるソフトウェア
• Spring Bootは、SpringMVCを元にできた
  

作業

• （あまり良くはないけど）もし時間に余裕が無かった場合は、最悪UnitTestはチケット化してテスターさんにフルリグレッションテストをしてもらっている間にやるってのも1つの手段
  • この時、UnitTestがコンパイルエラーとかで走らなくなる場合もあるので、FIXMEコメントを付けて、@Ignoreアノテーションを付けてテストヲスキップするようにしておく

「まで」の罠

-「4月1日まで」と言われた時、4月1日がセーフなのかダメなのか分からない・・・

教訓

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

作業の進め方について

• アジャイル開発で設計と実装を一つのタスクとして見積もっていた。
  しかし、実際に作業をやってみたところ、設計において考慮すべきことが見積をした時に想定していた以上にあり、見積もったストーリーポイントよりも時間がかかった。
  また、設計をした結果、ファイルの変量がかなり多くなった。
  • 教訓：設計と実装はタスク（チケット）を分ける（実装の前段階の整理をするようなチケットとかでも、チケットを分ける）

リモートデスクトップ

リモートデスクトップが固まるポイント（3つ）

• 自分のPC（描画が遅いとか）
• ネットワーク
• 相手のPC

リモートデスクトップ接続で、デュアルディスプレイにする方法

リモート接続先がデュアルディスプレイであれば、リモートデスクトップ接続アプリ > 画面 > リモートセッションで全てのモニターを使用する にチェックを入れればOK！

Tool

ビデオ通話、通話アプリ

• Microsoft Teamsとかで起きた事件
  • マイクの音声が入らない（音は聞こえる）
  • 原因：マイクを使用する権限がOFFになっていた。
  • 対応：PCの設定から、アプリへのマイクの権限を許可する

GitHubのブランチ名参考

• refactor/xxxxx_〇〇-migrate-△△
  • リファクタリングで、〇〇を△△へ移行する（作業）
  • migrate：移行する
  • 例：refactor/xxxxx_android-view-migrate-compose
    • リファクタリングで、AndroidViewをComposeに移行する（置き換える）
    • チケット番号がない場合は、チケット番号の箇所を「xxxxx」にしてしまうのもあり
• sandbox/xxx_〇〇-demo

Githubで起きた珍事件（？）

事象

ローカル環境で作業ブランチにdevelopブランチをマージしてコミットした。
すると、developに既に取り込まれていたはずの差分が、Github上のPRで差分として出てしまっていた。
（本当なら、developに既に取り込まていたはずの差分は、GithubのPRで差分として出てこないはず・・・）

（恐らく）原因

たぶんローカル環境で作業ブランチにdevelopブランチをマージした際に、フェッチをしていない状態でマージをしてそれをコミットしていた。（←記憶があいまいで定かではないが・・・）
そのため、マージされたdevelopブランチの情報が古くなっていたのではないか。

Gitブランチ名、コミットメッセージ参考サイト

UTF-8 BOM

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

参考

※以下のBOMは違うよ！

Gitでstashを使う時の例

①ブランチでコードを更新した
②①の途中で、developブランチを今のブランチにマージしようとしたが、①の変更のせいでマージできないって言われた
③stashで、①のコードを退避
④改めてdevelopブランチを今のブランチにマージ
⑤③でstashで退避したコードを元に戻す

有効数字

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

0.012←有効数字2桁

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

豆知識

時報の音

• ラ・ラ・ラ　　ラー
  ↑ 440Hz　　　↑880Hz
• JavaScriptは昔、ビルド無しで使えたらしい

なんかのメモ

• SFTPコマンド
  • ↑テルネットと同じ

DDD

例示／実験用として利用できるドメイン名

略語（？）

DD：詳細設計
CD：実装
UT：単体試験
IT：結合試験

商用利用OKのイラスト類

• SILHOUETTE ILLUST（シルエットイラスト）
  • https://www.silhouette-illust.com/policy
  • 2025/08/17調べ
  • 加工OK、アカウント登録不要、個数制限無し
  • 使用可能な例：広告媒体、お便り、プレゼン資料、お知らせや告知の張り紙、HPなどのWebサービス内のアイコンとして、Youtubeなどの動画配信サービス内のコンテンツ、無料のアプリ、テレビ番組での放送、等

自分の特性

参考書の読み方

・本に書かれている全て黒文字コードを読み解くのに苦戦していたが、自分に合った読みやすい方法を知ることができた

(コードをIDEで表示してハイライト付きで読むのが一番効果が大きかったことから、「脳がどこに注目すべきが判断する負荷」が一番大きかったと考える)

・技術書によってはソースコードがダウンロードできるようになっている意図が分かった

・DDDの本を読み進めるのが遅くなっているのを、以下の方法で対処できないか試してみる

・サンプルコードが黒文字で読みにくい (→脳の処理速度に負担がかかっている)

→コードをIDEで表示してハイライト付きで読む

・サンプルコードの改変が追えない (改変前のコードを覚えられないため、差分を探すのが負担になっている)

→各段階ごとにコードを「ファイルに保存」して、Gitとかの差分表示を使う

・オブジェクト指向言語の用語 (staticとか)が分からない

→自分専用の「用語チートシート」を作る (A4 1枚くらいのやつ)

ハマったこと

テストコードの、実行の順番

WAFを使ったSQLインジェクション対策

R7秋の応用情報の午後問題で出てきた😭

ざっくり📝
・リクエストパラメータをチェックして、サーバに到達する前に防ぐ
・「SQLのエスケープ文字は一律ダメよ！」というルールを設けておけば、それが含まれているリクエストはサーバに到達しないので、SQLインジェクション対策になるよ
・SQLインジェクション対策だけでこれをやるにはちょっと微妙かも。ほかの攻撃に対するフィルタと合わせて設定するとイイかも