개발 md

git command

Wed, 15 Apr 2026 00:00:00 +0000

clone branch

branch clone

git clone -branch <branchname>  <remote-repo-url>

getting remote info
updating remote branch info
move to there after clone

git fetch origin
git branch -r   
git switch [remote branch]

branch manipulation

make new branch and move
delete remote and local branch both
rename branch
see default branch

git switch -c [branch]

git push origin --delete [branch이름]

git branch -m [current branch] [future branch name]

git remote show origin

remove local change

git restore [filename]

adding file staging area

add file in staging area for only update and delete

git add -u

add file in staging area for all

git add .

removing all staged file

git restore --staged .

add file to just before commit

no need to increase commit for adding file

git add [file]
git commit --amend -m "message" # or git commit --amend  

removing just before commit, preseving file on worksapce

git reset --mixed

when u want to do experiment about bugs using completely different branch

git stash push -m "my work before fixing a bug"

git switch -c fix/feature

git add .
git commit -m "implement fix"

git fetch origin
git rebase origin/main

git push -u origin fix/feature

# open GitHub PR (fix/feature → main)

git switch main
git branch -d fix/feature

git stash drop stash@{0}   # only if you still have stash left

simplified version that dont use rebase

git switch main
git pull
git switch -c fix/feature

# work + commit
git add .
git commit -m "fix bug"

git push -u origin fix/feature
# open PR

git switch main
git branch -d fix/feature

git command customizing

vim ~/.gitconfig:

it looks like below
- ls is showing commit log pretty
- rs is checking cleared stash list
- dl is checking commit log under some condition
- fl is showing file list that i develope from certain date

[user]
        email = 222
        name = 333
[alias]
        lo = log --oneline
        ls = log --pretty=format:"%C(yellow)%h%Cred%d\\ %Creset%s%Cblue\\ [%cn]" --decorate
        rs = fsck --no-reflog | awk '/dangling commit/ {print $3}' | xargs -L 1 git --no-pager show -s --format="%ci %H" | sort
        dl = git log --name-only --date=local --author=Heo-Jae-Won --since="2024-01-03"
        fl = git log --name-only --author=Heo-Jae-Won --date=local --since="2024-01-03" | egrep -v "^commit|^Date:|^Merge:|^Author:|^\s" | sort | uniq

if we execute this one, we can show this one

git config --list

alias.ls=log --pretty=format:%C(yellow)%h%Cred%d\ %Creset%s%Cblue\ [%cn] --decorate
alias.ll=log --pretty=format:%C(yellow)%h%Cred%d\ %Creset%s%Cblue\ [%cn] --decorate --numstat
.
.

git username email config

git config user.name [username]
git config user.email [email]

seeing previous commit content

git restore --source HEAD~0 [파일이름] ---> current file. useless
git restore --source HEAD~1 [파일이름] ---> 1 commit before file.
git restore --source HEAD~2 [파일이름] ---> 2 commit before file.

git restore [파일이름]---> go back to original HEAD 

HEAD~ and HEAD^ diff for merge commit

HEAD~ is about commit history
- HEAD~1 = C
- HEAD → C → B
- HEAD~2 = B
- HEAD~3 = A
HEAD^ is about commit parent
- HEAD^ = HEAD^1 = C
- HEAD^2 = F

      E -- F
     /      \
A -- B -- C -- D (HEAD)

cherry pick from dev to main

let’s suppose below commit exists

cderf21 --> HEAD

rtqwrr51 --> HEAD~2

below is dangerous, cuz cherry-pick picks out just diff.
so, if target branch doesnt have the file needed for commit cdef21, conflicts happends.
because file is created in commit rtqwrr51. so it’s safer to cherry-pick range.

git cherry-pick cdef21

i want to get commit from HEAD to HEAD~2, then i must execute it reversely
from index is not included. so need to be started from one point before

git cherry-pick rtqwrr51^..cdef21

combining all commit into 1

git cherry-pick --no-commit rtqwrr51^..cdef21
git commit -m "final combined work"
github PR

rebase：replacing cherry pick

above one can be replaced by rebase
but it must be cautious that rebase must be done in local commit, not pushed one

git rebase -i rtqwrr51^

text would be shown like below

pick rtqwrr51
pick abc123 --->squash
pick def456 --->squash
pick cdef21 --->squash
git commit --amend -m "Implement feature X (final version)" # (if message editor doesnt open)
git push # (if already published --force-with-lease)

if it’s already published in remote, teammates should do following one whether it’s used on my own or shared

git fetch
git rebase origin/mybranch

git conflict on branch when using git pull

# fixing content
git add [fixed file]
git merge --continue

structure would be like below

M = merge commit (newly created)
D is NOT rewritten
X → Y is NOT rewritten
Git combines both histories


A --- B --- C --- D              ---> this is merged version
              \       \
               X --- Y --- M

rebase：fix local commit message before publishing to remote

git rebase -i HEAD~n :
pick -> reword 
change commit message -> :wq

rebase：PR

in my feature branch is executed
only for local commit

git fetch origin
git rebase -i origin/dev #(if target is main, origin/main)

if conflicts happens
after rebase, already aligned commit. so it becoms fast forward –> clean history

git add
git rebase --continue
git push origin feature/my-work
open PR → feature → dev 

basic form of rebase is like below
- it means Git will rebase branch onto upstream
but latter one is used often
- it means “Take the current branch (HEAD) and replay its commits on top of origin/dev.”

git rebase <upstream(origin/dev)> <branch(feature/login)>

git rebase origin/dev

so two combination is usally used for rebasing

git switch feature/branch
git rebase origin/dev

reflog：showing history for git conduct

HEAD in reflog doesnt mean branch’s head
- therefore, HEAD@{0} and HEAD@{2} can be actually refer to same thing
reflog show command can limit target of command like below

git reflog show HEAD@{2.days.ago}
git reflog show HEAD@{1.month.ago}
git reflog show HEAD@{1.week.ago}
git reflog show master@{0} master@{yesterday}

reflog：restore file

git reflog show –> finding a commit hash that i need to recover
after restoring, file is recreated in working directory, not inside Git history
so need to again add and commit

git log --all -- '*file*'
    commit 8f3a91c2d7b5a4c1e9a0f2b6c7d8e9f1a2b3c4d5
git ls-tree -r <commit-hash>
    100644 blob aaa111 src/app/main.py
    100644 blob bbb222 src/utils/helper.py
git restore --source <commit> <file-path>

temp save

we can save our work to temp space
but untracked file cannot be target of stash

git stash push -m "my work before fixing a bug"
git stash pop

revert：commit delete from remote repo

let’s suppose below commit flow

A — B — C — D — E — F   (latest = F, commit123 = C)

* f6f6f6f (HEAD -> main) Commit F
* e5e5e5e Commit E
* d4d4d4d Commit D
* c3c3c3c Commit C   <-- commit123
* b2b2b2b Commit B
* a1a1a1a Commit A

then commit from C to F is reverted

git revert --no-commit C^..F

git push origin master

log reading

origin/HEAD is not a branch HEAD
- a pointer to the default branch on the remote
- usually points to origin/main or origin/master
origin/main is remote repo recent commit
main is local repo recent commit
when origin/main and main is together, it means no divergence from local and remote
everything up to date.

de12b0e (origin/main, origin/HEAD, main) commit

local branch is fully up to date with the remote
HEAD -> means that i am not detached state, which means on this branch
if no HEAD ->, it means i am detached state

4c6cfcc (HEAD -> feature/recommend, origin/feature/recommend) commit2

785cd77 HEAD -> feature/authority-profile doesnt be written remote origin.
- it means that remote feature/authority-profile has ahead commit, which means needs git pull
- actually, other developer can commit on my branch if it’s shared branch.
68aa468 (master) Merge pull request #122

785cd77 (HEAD -> feature/authority-profile) Feat: generate role

(feature/dev_wsg) and (origin/feature/dev_wsg) is diverged
it means local has more ahead commit

82174d3 (feature/dev_wsg) fix: exclude deactivated account#2
8339e87 fix: exclude deactivated account
afdfd6d add: search word option(=address)
35d69ef (origin/feature/dev_wsg) adding profile path

8957fea origin/hotfix/add-db-tls doesnt be written (origin/hotfix/add-db-tls, hotfix/add-db-tls)
- in this case, origin/hotfix/add-db-tls is not about ahead or behind when there is no hotfix/add-db-tls in commit log
- it means that i dont publish hotfix/add-db-tls on my local

8957fea (origin/hotfix/add-db-tls) add-db-enable-tls

merge and ff

let’s suppose this kind of commit flow

A ー Bー Cー D.

i diverge branch from main D commit
commit on my branch is E and F is executed.

main: A — B — C — D — G
                 \
feature:          E — F

in this case, when using git status below message is shown
showing ahead and behind simultaneously means diverging of branch

1 commit ahead, 2 commit behind

in this case, ff is impossible
history diverged at D:
- main has G
- my feature has E, F
so Git cannot just “move the pointer”
both branches have unique commits.
Therefore, fast-forward is impossible
merge commit is generated

[merge]
A — B — C — D — G
                 \ 
                  M
                 /
            E — F

if u want flow like below,

A — B — C — D — G — E' — F'

rebase is needed

git switch feature
git rebase main

then when ff is possible?
when no advanced commit on main exists, ff is possible

main:    A — B — C
feature:          D — E

if merging operation is finished, git status shows like this message

up to date

communication-batch

Wed, 15 Apr 2026 00:00:00 +0000

windowsがシャットダウンする際に行われる後処理

ノートパソコンの場合、正常作動すると、ランプがずっと白い。
- シャットダウンにすると、横のランプが点灯した後、完全に電源が切れる。
- なのに、点灯してる何秒際に蓋を閉じると、ススリープ状態に入ってしまうことがある。
  - この場合、パソコンはすでにシャットダウンの命令を受けているため、レースコンディションが発生する。
  - 結果として操作ができなくなり、強制終了以外に手段がなくなる。
強制終了した場合、シャットダウン時に実行される処理は動作しない。
- 特に「リモートデスクトップ For AVD」は、設定ファイルをシャットダウン時に Open → Write → Close するプロセスが動かない。
- Close が行われなかったため、次回 Open も失敗する。
これに関連するログは、設定ファイルだけでなく、レジストリやキャッシュなどにも残る。
- 設定ファイルには改ざん検知用のチェックサムコードも入っているため、他人が直接編集できない。
- そのため、リモートデスクトップ For AVD を使用する場合は、一度アンインストールしてから再インストールする必要がある。
シャットダウンは、次回の起動を早くするために完全な初期化は行われない。
そのため起動は速いが、設定の完全な初期化が必要な場合は再起動が必要。
今回のケースでは、設定ファイルが再起動でも復元できなかったため、再インストールした。
この経験を通して、ウェブサーバーだけじゃなく、OSの段階でも後処理が行われることに気づいた。

windodwsのhostsファイル

チームメンバーから、突然 SI2 環境への接続ができなくなったと助けを求められた。
彼は TerTerm というツールを使っているが、この TerTerm は Windows の HostFile を参照しているため、彼に自身の HostFile を渡すようにお願いした。
確認したところ、問題の環境の IP アドレスが HostFile に書いてなかった。
それを追加すれば、接続できるはずだと伝えた。
念のため、私も同じ環境で実験を行った。

パスはこちら

C:\Windows\System32\drivers\etc\hosts

私が持っているその値を修正すると、多分彼と同じくできなくなるのではないかと予測した。
- それで次のように該当の内容を消してから確認した結果、できなくなった。
- 管理者ではないと操作が不可能なため、管理者としてテキスト編集をさせる必要がある。

文字列解釈に利用するLinuxコマンドの違い：S-jis環境でのless, catの動作の違い

cat ではファイルの内容を文字化けせずに表示できたが、less では正しく表示できなかった。
その違いを理解するために調べてみたところ、cat はバイト列をそのまま出力するだけで、解釈は Tera Term などのターミナルに任せる仕組みであることが分かった。
したがって、cat は余計な処理を行わずシンプルに動作する。
less で文字化けが発生した理由は、文字列をそのまま出力するのではなく、一定の規則に基づいて処理しているためである。

encoding detection

locale checks

multibyte handling

heuristics

そのため、基本的にお勧めされるのはLessのほうだが、いろんなチェックをしてくれるからだ。
しかも、Lessは基本的にエンコーディングがUTF-8のため、S-JISなどに合わせて解釈ができない。
しかし、LessがCatより性能が高いことは否めない。

ページネーションができる
検索ができる
エスケープができる
フレーズされることがない

そのため、Lessを使うことがおすすめされる。
Lessが活用できるようになる方法は以下の通りのコマンドだ。
このコマンドはファイルの内容を更新しないが、StdOut に表示される

iconv -f SHIFT_JIS -t UTF-8 | less

OSにおけるセッション：ユーザーセッションと管理者セッションの動作の違い

substを使ってDドライブを作る必要がある作業があった。　
なぜDドライブを作るのかは社内AIに質問投げてみたら、Dドライブにログなどを残す仕組みだ答えてもらった。
手順には管理者Cmdを開いてくださいと書いてあったため、管理者コマンドを開いて下記のコマンドを叩いた。

subst D: C:\mywork\Ddrive
```　　　　　　　　　　　　　　　

- しかし、Dドライブがsubstのコマンドでも作られなかった。　　　　　　　　　　
- まず成功したのかどうかから確認しようとした。
- そして確認ができる方法は下記のコマンドだった。

```shell
subst

# 成功したら、
# X:\: => C:\D$

つまり、成功ということだ。それでもFileExplorerには表示されなかった。
Cドライブの直下にしなければならないのかとか名前に制限があるのかなどいろいろ試してみてもできなかった。
結局自分のパソコンでもやってみたが、自分のパソコンではちゃんとできていた。
私に与えられたユーザーの権限の問題かと思いつつ、権限を確認してみた。

whoami /groups | findstr /i "admin"

「BUILTIN\Administrators Group used for deny only」が出てきたので、管理者権限は持っている状態だった。

BUILTIN\Administrators        Alias            S-1-5-32-544 Group used for deny only 

管理CmdとしてCMDを開いたら、下記のメッセージが表示される。

BUILTIN\Administrators       Alias            S-1-5-32-544 Mandatory group, Enabled by default, Enabled group, Group owner

管理権限は保持していると考えられるため、本件は権限の問題ではないと結論付けた。
それで調べたところ、AdminTokenとUserTokenの違いについて説明が始まった。
Substは基本的に今開いているSessionだけに影響を与えるコマンドだ
- File ExplorerはいつもUserSessionなので、AdminTokenを利用してるAdminSessionでは開けない。
FileExplorerもAdminSessionで開けば通じるのかと結論に行き着いて、試してみようとしたんだが、意図通りに動かなかった。
AdminSessionで開いてもまだDドライブが見れない。

explorer.exe

実質的にAdminSessionのFileExplorerを開けないそうだ。
とても危ないから、基本的にWindowの操作でそれを塞いでいるらしい。
代わりにUserSessionのFileExplorerを引っ張ってきて利用している。

Admin CMD
 └─ explorer.exe
     └─ connects to existing USER shell process
         └─ runs in USER logon session

結局UserTokenを使っているUserSessionを持ってる、普通のCmdでsubstを実行するすることになる。
そうしないとFileExplorerにはDドライブが分割されてない。
プロセスは下記の通りだ。

subst
  ↓
Creates DOS device (in memory)
  ↓
Windows name resolver can translate D:
  ↓
Explorer asks Windows “what drives exist?”
  ↓
Windows says “D exists”
  ↓
Explorer shows D:

OSにおけるFileSystem：どの流れでソースコードが解釈するのか

ふと、こういうことを考えてしまった。ソースコードでのAPIが直接FileSystemに接近するのであれば、なぜできないのか？
結論から言うと、ソースコード、つまり各言語のAPIはFileSystemに直接接近することができない。
全てのApiはwindows32APIを呼び出すだけ。

new File("D:\\").exists()

ソースコード
 → 言語API (Java / .NET / C runtime)
   → Win32　API
     → NT kernel (Object Manager)
       → File system driver (NTFS)
       　ー＞BIOS

Win32はDNSみたいにDOSサービスを行っている。
DOSサービスはSessionとTokenごとなので、SessionとTokenごとにファイルの呼び方が違くなる場合もある。

\Session\0\DosDevices\   (services)
\Session\1\DosDevices\   (User A)
\Session\2\DosDevices\   (User B)

もし下記のようにUserたちがMappingしたと仮定してみよう。

| User        | `D:` maps to      |
| ----------- | ----------------- |
| User A      | `C:\Users\A\Work` |
| User B      | `C:\Data\Shared`  |
| Admin token | not mapped        |

AのUserは下記のように解釈されてNFTSに到達。

D:\logs\app.log
↓
\DosDevices\D:
↓
\Device\HarddiskVolume3\Users\A\Work
↓
\Device\HarddiskVolume3\Users\A\Work\logs\app.log (NTFS objects live in the kernel object namespace: これは誰でも同じ)

BのUserは下記のように解釈されてNFTSに到達。

D:\logs\app.log
↓
\DosDevices\D:
↓
\Device\HarddiskVolume3\Data\Shared
↓
\Device\HarddiskVolume3\Data\Shared\logs\app.log (NTFS objects live in the kernel object namespace: これは誰でも同じ)

基本的にNTFSやBIOSなどの段階では C、Dなどの名前はわからない。
そういった名前はWindow Kernelで付けてUserが便利に使用させるためだけ。

ファイルの文字コード解釈：数字はなぜ文字コードの区分が付かないのか

数字がある場合は文字のエンコーディングが判別がつかない。
全角じゃなくて半角の場合だけど、数字はどのエンコーディングでも同じ値を持っているからだ。

nkf -g 

#doesn't works

しかし、文字の場合は文字のエンコーディングごとに完全に違う値を持っている。
例えば、’あ’ を解釈すると下のようになる。

| Encoding  | Bytes (hex) |
| --------- | ----------- |
| UTF-8     | `E3 81 82`  |
| Shift-JIS | `82 A0`     |
| EUC-JP    | `A4 A2`     |
| UTF-16LE  | `42 30`     |

どのエンコーディングでもできる場合もある。
そういった場合は、heuristicsで判断する。
- 数字と文字の場合を分けて考えることで気づいた人もいると思うが、文字のエンコーディングの判断は何物か判断することではない。
- むしろできないことを取り除いて、その結果残っているエンコーディングを特定する過程に近い。

ファイルのUTF８保存：UTF８とUTF８(NO BOM)

データをインポートするとき、UTF-8とUTF-8（NON-BOM）があって、なぜこれは違うのかと思って調べてみた。
BOMという仕組みは基本的にUTF-16のために発明されたことであり、UTF-8では必要ではないらしい。
- ファイルの最初の部分にこう書いてあることが Byte Order Mark（BOM）だが、ほとんどこれが書いてあるファイルがない。

EF BB BF

ただ、もし書いてある場合、それをそのまま解釈したら、データが壊れるから、UTF-8（NON-BOM）を推薦してるとのことだ。
実際にDB以外にもほとんどのファイルに NON-BOMが推薦される。
不要なものを事前に防ぐことが重要だから、Non－BOMを選ぶ。

databases
JSON
XML
CSV
source code
config files

DBString：UTF-8　vs UTF-8MB4

上のファイルの文字コードはUTF-8はUTF-8(no BOM)との比較だった。
現代の絵文字とかを表現するためには、UTF-8MB4に文字コードをする必要がある。
下記の表をみると、英語は１Byte、日本語は 3Byte、絵文字は４Byteということがわかる。
Utf8では文字ごとに３バイトが限界で絵文字は入力できない。

| Character | Code point | UTF-8 bytes |
| --------- | ---------- | ----------- |
| A         | U+0041     | 41          |
| あ         | U+3042     | E3 81 82    |
| 😀        | U+1F600    | F0 9F 98 80 |

Oracleも同じ状況。
絵文字などもできるようにするためにはAL32UTF8が必要。

| Oracle charset | Status                         |
| -------------- | ------------------------------ |
| `AL32UTF8`     | ✅ **Real UTF-8 (use this)**    |
| `UTF8`         | ❌ **Legacy / broken (CESU-8)** |

DBString：Collation vs 文字コード

Charset (文字コード)と Collation (コーレーション)は違う。
- Charsetは与えられた文字をいくらのByteを付与するかの問題。
  - 例えば、utf8mb4、latin1、sjisは漢字についてエンコーディングバイトが違う。
- しかし、Collactionは　文字のOrderについて関与する。
oracleはCollationをUserに表示しない。権限もない。
mysqlは表示する。だからCollcationの問題はMysqlで発生する。
MysqlでのCollationの例は下記のことになる。

| Suffix | Meaning               |
| ------ | --------------------- |
| `_ci`  | Case-insensitive      |
| `_cs`  | Case-sensitive        |
| `_bin` | Binary (byte-by-byte) |

Collationは下記の3つに影響を及ぼす。

Pagination
Unique indexes
GROUP BY results

Collationごとに文字比較の結果が異なる分、Bugにつながる可能性もあり。
言語としてはunicode_ciが推薦される。
大文字小文字の区分がつかなければならないときはByteで区分をつける_binが必要。

VARCHAR(20) COLLATE utf8mb4_general_ci
INSERT 'abc'
INSERT 'ABC' → ❌ DUPLICATE KEY
utf8mb4_bin
Now both allowed.

要すると、下記の表がおすすめ。

| Use case             | Recommendation       |
| -------------------- | -------------------- |
| User names, emails   | `utf8mb4_unicode_ci` |
| Login ID / token     | `utf8mb4_bin`        |
| Case-sensitive codes | `*_bin`              |
| Japanese text        | `utf8mb4_unicode_ci` |
| Exact byte match     | `BINARY`             |

ただ、多言語対応が必要の場合は、utf8mb4_0900_ai_ciがおすすめ。
多様な状況に対応ができるからだ。

| Feature            | Supported |
| ------------------ | --------- |
| Unicode standard   | ✅ UCA 9.0 |
| European languages | ✅         |
| Accents ignored    | ✅ (`ai`)  |
| Case ignored       | ✅ (`ci`)  |
| Emoji              | ✅         |
| Correct sorting    | ✅         |

文字コードを場合は、照合順序と違って、Oracleでも見える
ただ、見れる範囲がDBごとに違う

| Feature                          | Oracle           | MySQL          |
| -------------------------------- | ---------------- | -------------- |
| DB-level charset                 | ✔                | ✔              |
| Table-level charset              | ❌                | ✔              |
| Column-level charset             | ❌ (except NCHAR) | ✔              |
| Recommended modern design        | AL32UTF8 DB      | utf8mb4 DB     |

Oracleでは下記のSQLで確認できる。

SELECT parameter, value
FROM nls_database_parameters
WHERE parameter = 'NLS_CHARACTERSET';

Mysqlでは下記のSQLで確認できる。

--サーバー
SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';

-- schema
SELECT
  schema_name,
  default_character_set_name,
  default_collation_name
FROM information_schema.SCHEMATA
WHERE schema_name = 'your_db_name';

-- table
SELECT
  table_name,
  table_collation
FROM information_schema.TABLES
WHERE table_schema = 'your_db_name';

-- column
SELECT
  column_name,
  character_set_name,
  collation_name,
  data_type
FROM information_schema.COLUMNS
WHERE table_schema = 'your_db_name'
  AND table_name = 'your_table_name';

MYSQLはColumnが一番優先順位を持ってる。次はTABLE、DB、Server。
一度に全部見られる方法はこちら。

SELECT
  c.table_name,
  c.column_name,
  c.character_set_name,
  c.collation_name
FROM information_schema.COLUMNS c
WHERE c.table_schema = 'your_db_name'
ORDER BY c.table_name, c.ordinal_position;

DBString：マイグレーションする場合の注意

DBでの文字コードを S-jis からUTFー８に移行するためには、以下のような注意が必要だと思った
- 取るバイトが違くなるから、バイト基盤のバリデーションは全部直す
- UTF8でなく、utf8mb4に変換する

C:データ型とポインター

数字は以下のよう。

int         
short      
long       
long long  
float
double

文字に関しての変数は以下のよう。

char a = 'a';
char *r = "abc";        // const. 修正ができない
char r[] = "abc";       // writable。修正できる
//char r[4] = "abc"; --> Compilerが　char r[] = "abc";を　char r[4] = "abc";のように解釈してくれる

文字列はポインタと一緒に使われることが多いので、ここでポインタについて簡単に押さえておこう。
以下の関数があったとしたら、どう渡すべきか？
もうポインターが設定されてる変数なので、ポインターを表す「＆」は必要ではない。

static int paramCheck (
    char *GetParam
) {

}

char *r = "abc"; 
paramCheck(r);

もし関数がポインターを要求することになると、変数の値ではなくて住所を渡すべきなので、＆をつけて住所値を渡す。

static int paramCheck (
    int *D1Code
) {

}

int a = 1;
paramCheck(&a);

しかし、配列の場合、*がついてなくてもポインターそのもの。
そのため、＆がついてなくてもそのまま渡す。
配列に値を与えるために以下の通りする

int Main () {
    char logName[50];

    memset(logName, 0x00, sizeof( logName )); 
}

char logName[50];
strcpy(logName, "system.log");

もし、Stringを保管したいと思うなら、以下の配列を利用する。

char *logName[50];
logName[0] = "system.log";
logName[1] = "error.log";
printf("%s %s\n", logName[0], logName[1]); // system.log error.log. stringを保存する。

データ型をstructに広げていこう。
例えば、このようなstructがあったとしたら、どう渡すべきか？
前提を簡単にするために、Fieldは全部ポインターなしでいこう。
渡す変数に＊がついているため、prmには＆が必要ではない。

typedof struct {
    char dbFlg;
    char d1[d1_len + 1];
    char FLG[1 + 1];
    int returnCode;
} D1_ARG;

static int paramCheck (
    D1_ARG *prm
    char *GetParam
) {

}

D1＿ARG *prm;
paramCheck(prm, getParam);

ポインターはタイプの後と変数の前についてくるが、変数の前のほうが一般的

D1_ARG* prm; // not common
D1_ARG *prm; // common

C:はコンテクストによって意味が違う*

Syntax	Meaning
`int *readCnt`	type declaration (pointer to int)
`*readCnt`	dereference (get value at address)

int x = 10;
int *p = &x; // これはアドレス

printf("%d", *p); //これは 値


int *p //タイプ宣言＝＞アドレス
*p     //間接参照

C：コンテクストによる意味の違い*

以下の風に数字の値を変換して渡す。
JAVAで例えると、intじゃなくて、intを Wrappingした classを使うような感じ。

main() {
    int readCnt = 0;
    int returnCode = 0;

    returnCode = dealWith333(&readCnt);
    

}

int dealWith333(int *readCnt) {
    int returnCode;
    returnCode = openFile(loopCnt, readCnt)

    return (returnCode);
}

int openFile(int loopcCnt, int *readCnt) {
    for (loopCnt= *readCnt; loopCnt < 10; loopCnt++) {
        .
        .
        .
        (*readCnt)++;
    }
}

*readCntを受け取るため、readCntは住所値を持ってる。
逆に *readCntを渡すと、 *がついてるとdereferencedになってしまう。
だから、その値を渡すことになってしまい、エラーに落ちる。

int dealWith333(int *readCnt) {
    int returnCode;
    returnCode = openFile(loopCnt, *readCnt /* これはミス */)

    return (returnCode);
}

ポインター変数にとって丸かっこを間違えて囲むと、ポインターを移動させることになる。
以下は値を++することではなく、ポインターが++になってしまい、エラーになる。

int openFile(int loopcCnt, int *readCnt) {
    for (loopCnt= *readCnt; loopCnt < 10; loopCnt++) {
        .
        .
        .
        *readCnt++　/* これはミス */;
    }
}

C言語では、++がもっと優先順位がた * より高いから以下の通りになってしまう
それを防ぐために、○を使って優先すべきの間接参照の値の両端にくっつける
```
*readCnt++　ーーーー＞  *(readCnt++)　// エラー
(*readCnt)++;                       // OK
```
以下も不可能。
*readCnt を 0にすることは、値を０にすることではない。
- ポインターを０にする行為、つまり、NULLになってしまう。

main() {
    int *readCnt = 0;
    int returnCode = 0;

    returnCode = dealWith333(readCnt);
    

    returnCode = finishBatchJob(readCnt);
}

*C：文字列における**の活用*

数字じゃなく、Stringも押さえていこう。
基本的にCの関数のParameterはcopyを渡す。
pに他の値を代入してもpは原本ではなく、Copyなので原本は変わらない。

void change(char *p) {
    p = "world";   // only changes local copy
}

char *str = "hello";
change(str); // hello

しかし、その原則を利用して値の変換ができる。
もう一度 * で囲んだら原本のポインターを渡すことになる。
なので、Stringに他の値を代入できる。

void change(char **p) {
    *p = "world";   // change caller's ポインター
}

char *str = "hello";
change(&str);　// world

関数のパラメータにおいて、char ** は文字列のポインターだ
szRecBuffは間接参照された szFileBuffなので、文字列のポインターでなく、文字列だ
その文字列を間接参照すると、文字になる
あの文字の値を比較して、if文に当てはまると、次のポインターを移動する
- szRecBuffは文字列なので、次のポインターは次の文字を指す

static int chopData(
    char *szCol,
    char **szFileBuff
) {
    char *szRecBuff;
    char szColmBuff[13 + 1];

    szRecBuff = *szFileBuff; // string
    if( (*szRecBuff == '"') ) {
        isQuoted = false;
        szRecBuff++; // next char
    }
    .
    .
    .
}

pszCheckRecは文字列なので、そこで＆をつけたら、文字列のポインターになる
つまり、char **pszCheckRecみたいなパラメータに持たせることができる

char *pszCheckRec;
char szFileBuff[512];
pszCheckRec = szFileBuff;
nRet = chopData( szCol, &pszCheckRec);

pszBufがchar**であるため、Stringのポインターだ
それを間接参照した*pszBufはStringになる
それを二重間接参照した**pszBufはCharになる

int inspectCSV(
    char *pszCol,
    char **pszBuf,
    short nMode
) {
    char *pszBufTmp;
    int i;
    pszBufTmp = *pszBuf;
    .
    .

    if(**pszBuf == ',' )  {
        (*psBuf)++;
    } else {
        return (SU_CSV_END);
    }

    return (0);
}

*C：構造体における**の活用*

最後にStructも押さえていこう。
Structでも**を使える。特にSetterのように使える。

typedef struct {
    int age;
    char code;
    char *name;
} Person;

void setAge(Person **p) {
    (*p)->age = 30;
}
void setCode(Person **p) {
    (*p)->code = 'A';
}
void setName(Person **p) {
    (*p)->name = "brick";
}

もちろん、以下のVersionがもっと性能はいい。
不要なポインターの移動がなくなるからだ

void setAge(Person *p) {
    p->age = 30;
}

void setCode(Person *p) {
    p->code = 'A';
}

void setName(Person *p) {
    p->name = "brick";
}

以下は意図した目的の構造体の値の変更ができない
ポインターでない変数は原本じゃんくて、コピーだけを渡されて使うので、以下の関数が終わる時点で変化も失われる

void setCode(Person p) { 
    p->code = 'A'; 
} 

void setName(Person p) { 
    p->name = "brick"; 
}

C：なぜ配列の初期容量の宣言にはなN ＋１が多いのか

CのChar配列は必ず \0 で終わる。
そのため、3個の文字が必要だとはいえ、4個が必要になる。
それを明確にするためには、N＋１の形で記載する。

[ 'A' ][ 'B' ][ 'C' ][ '\0' ]
char szBaceDateId[3 + 1];

次はより明確になる方法

#define BACE_DATE_ID_LEN 3
char szBaceDateId[BACE_DATE_ID_LEN + 1];

配列の場合、最後に \0 を与えるのは手動でしなければならない。
以以下はどれも同じ目的に見える

char szLogName[50] = '\0';
char szLogName[50] = {0};
char szLogName[50] = "";

それともsnprintf Methodを使う。
snprintfはいつも末に \0があるように保障する。
このMethodが文字列を扱う際は、常に %s を通してコピーするようにする。

snprintf(szLogName, sizeof(szLogName), "%s", source);

NullをGuardするLogicは以下のよう。

if (source)
    snprintf(szLogName, sizeof(szLogName), "%s", source);
else
    szLogName[0] = '\0';

//簡潔に
snprintf(szLogName, sizeof(szLogName), "%s", source ? source : "");

C：Charダブル配列の読み方

ダブル配列の場合、最初のカッコに入っている数字が要素数。
後ろはStringの文字数。5だったら、４が文字数。

char array[3][4 + 1] = {
    "0123",
    "1234",
    "2345"
};

C：動的にStringに値を与える

1番では初期化する時のStringの代入仕方を説明した。

char *a = "abc"; //  readable
char a[] = "abc"; // writable

1番目

strncpy(dest, src, sizeof(dest));
dest[sizeof(dest) - 1] = '\0';

2番目

char buf[50];
sprintf(buf, "parameter error");

3番目
一番おすすめ

char buf[50];
snprintf(buf, sizeof(buf), "parameter error");

4番目　
組み込みOSでのやり方

char buf[10];
int i = 0;

while (src[i] != '\0' && i < 9) {
    buf[i] = src[i];
    i++;
}
buf[i] = '\0';

Stringの値をただ接近して修正するのはできない

typedef struct {
    char name[32];
} USER;

USER u;
u.name = src;   // ❌ 配列には直接接近できない

できるが、危険なやり方。
ただ、レガシーのシステムはこのMethodだらけ。

char dest[5];
strcpy(dest, "Hello"); // needs 6 bytes including '\0' → overflow

5番目。これは置換じゃなくて追加

int remaining = sizeof(moji) - strlen(moji) - 1;
strncat(moji, added, remaining);

クリアする時には、3つの中で何でも呼び出す。
String自体をクリアするためには、memsetが必要。

memset(buf, 0, sizeof(buf));
memset(buf, '\0', sizeof(buf));
memset(buf, 0x00, sizeof(buf));

以下は方法はポインターを無効にするためのやつなので、コンテンツとは関係がない。

char *p = NULL;

ただStringを空白にするためには、以下で十分。

char str[100];

str[0] = '\0';
strcpy(str, "");
snprintf(str, sizeof(str), "");

Bufferとかには下記のようにsscanfも使える

int sscanf(const char *str, const char *format, ...);
 nRet = sscanf(szBuff,
            "%s %s %d "
            "%s %c %d %c %s %c %d %c %s %c %d %c %s %c %d %c %s %c %d %c",
            &param.jpName,
            szBuff2,
            &param.nParamNum,
            &param.whereClause[0].date,
            &param.whereClause[0].cFlag,
            &param.whereClause[0].pastDate,
            &param.whereClause[0].host,
            &param.whereClause[0].date,
            &param.whereClause[0].cFlag,
            &param.whereClause[0].pastDate,
            &param.whereClause[0].host,
            &param.whereClause[0].date,
            &param.whereClause[0].cFlag,
            &param.whereClause[0].pastDate,
            &param.whereClause[0].host,
            &param.whereClause[0].date,
            &param.whereClause[0].cFlag,
            &param.whereClause[0].pastDate,
            &param.whereClause[0].host,
            &param.whereClause[0].date,
            &param.whereClause[0].cFlag,
            &param.whereClause[0].pastDate,
            &param.whereClause[0].host,
        );

C：tringを比較する

Stringを比較するときには、＝＝ではできない。
strcmpで比較して０になると、それが同じコンテンツだと示唆する。

if (s1 == s2)  // wrong (compares addresses)
if (strcmp(s1, s2) == 0)

strcmpは case-sensitiveなので、CaseInsensitiveのためには下記のMethodを利用する。
ただ、Ｃ標準ではない。

POSIX: strcasecmp

よく使用される比較はStringが実質的に空白なのか判断すること。

param.gender[0] == '0' || 
param.gender[0] == ' ' ||
param.gender[0] == '\0'

複数のスペースがある時は、下記のように確認する。

char *p = param.gender;

if (*p != '\0') {
   bool blank = true;
    for (; *p; p++) { // for (; *p != '\0'; p++)と同じ。\0になるときは、読み込まる文字がなくなったとき
        if (*p != ' ') {
            blank = false;
            break;
        }
    }
}

C：関数のParameter

関数を定義だけするときは、変数名がなくてもいい

static int ParamCheck021(char *, char *,char *,char *,char *,char *,char *);

ただ、実装するときには絶対になければならない。

static int ParamCheck021 (
    char *GetParam,
    char *type,
    char *memberNo,
    char *withDrawlDate,
    char *memberCode,
    char *staffId,
    char *staffName
) {
   
}

Stringを渡すときには、必ずポインターが必須。
どちらにせよ、同じ意味であり、完全に互換性がある。
関数のParameterは住所値だけ見ているためだ。
配列になり、ポインター変数になり、どちらでも互換性があるので渡したら読み込める。

static int ParamCheck021Astrick ( char *GetParam, char *type, char *memberNo, char *withDrawlDate, char *memberCode, char *staffId, char *staffName )
static int ParamCheck021Bracket ( char GetParam[], char type[], char memberNo[], char withDrawlDate[], char memberCode[], char staffId[], char staffName[] )

char abc[] = "abc";
ParamCheck021Astrick(abc) //できる

char *abc = "abc";
ParamCheck021Bracket(abc) //できる

ただ、不要な誤解を晴らすために、以下の仕組みがおすすめ。
ArrayをParameterTypeとして規定するのはよくない。
Constは修正を欲しくないとき、Constが付いてないのは修正も許容する時。

int ParamCheck021(
    const char *GetParam,
    const char *type,
    ...
);


int ParamCheck021(
    char *GetParam,
    char *type,
    ...
);

Heap sort

Wed, 15 Apr 2026 00:00:00 +0000

実装ーheap sort

最初ダイアグラムとかを見たが、さっぱり理解ができなかった
なので、少しヒントをくれと言ってルールや原則なども貰ったけど、それでも何も理解できなかった

Araryはツリーとして捉えられる

MaxHeapを作る 
MAX値を末尾に移動させる
heapify
繰り返し

実装ー配列をツリーとして捉える

上の文章の意味が当時はいったい何を指してるのかわからなかった全投げするしかなかった
それでソースコードをもらったが、これを見ても全く理解ができなかったので、もう1度CHATGPTに詳しく聞いた
詳しく聞いてからは、配列は特別なツリーの表現として捉えられるという文章の意味が分かった
こういう風に解釈すれば、配列もツリーとして捉えられる

largest := i
left := 2*i + 1
right := 2*i + 2

実装ーＭＡＸＨＥＡＰを作る

それを理解してから、MaxHeapというものを調べた
最初は MaxHeapを作る
MaxHeapを作るためのループの対象となるインデックスは子がある親要素だけだ
そのため、n/2 -1になる
そこからMaxHeapを作る関数を各親に対して呼び出す

for i := n/2 - 1; i >= 0; i-- {
	heapify(arr, n, i)
}

1番大きいものをわかる必要がない
1番大きいのを親として仮定してみて、そうでなかったら、子と親を入れ替えながら、一番大きいものを上にあげるロジックだ
そのため、親に対しての子たちの要素のインデックスを計算する必要がある
- それが left, right
ただ、最後の親とかの場合、Rightなどの子たちが存在しない場合もあるし、Leftの子たちも存在しない場合もある
そのため、スワップのロジックはまず、スワップの範囲で行われることを確実にする
- それが left < n と rigth < n
子たちが親より大きいかったら、子たちのインデックスを代入して、あとで変える
- それが largest = left、　largest = right、 if largest != i { arr[i], arr[largest] = arr[largest], arr[i]
入れ替わったインデックスによって、変わったインデックスも親の可能性があるので、もう1度確認して heapifyする
- heapify(arr, n, largest)

func heapify(arr []int, n int, i int) {
	largest := i
	left := 2*i + 1
	right := 2*i + 2

	if left < n && arr[left] > arr[largest] {
		largest = left
	}

	if right < n && arr[right] > arr[largest] {
		largest = right
	}

	if largest != i {
		arr[i], arr[largest] = arr[largest], arr[i]
		heapify(arr, n, largest)
	}
}

実装ー最大値を末尾に移動させてから安定化

次は以下の段階に進む
nがサイズなので、ー１してインデックスと合わせる
MAXになった最初の値と iインデックスを入れ替えながら、最大値をデータを末尾に移動させる
その移動によって乱れた順序を修復するため、heapify() を実行する
最後の i = 0はもうソートされてる状態なので、ループを回す必要がない

// 2. Extract elements one by one
for i := n - 1; i > 0; i-- {
	// Move current root to end
	arr[0], arr[i] = arr[i], arr[0]

	// Heapify reduced heap
	heapify(arr, i, 0)
}

もう順序通りになって移動させる必要がなくなった要素を除いてまだソートされてないものだけを対象とする
- left < n, right < n
最初にMaxHeapを作る際に left, right < n の役割とは違くなる
- あの時の役割は、インデックスがない子要素に対するアクセスを防ぐためだった

func heapify(arr []int, n int, i int) {
	largest := i
	left := 2*i + 1
	right := 2*i + 2

	if left < n && arr[left] > arr[largest] {
		largest = left
	}

	if right < n && arr[right] > arr[largest] {
		largest = right
	}

	if largest != i {
		arr[i], arr[largest] = arr[largest], arr[i]
		heapify(arr, n, largest)
	}
}

HeapSortのメリットは以下の通り
- メモリの利用率が低い
  - Nodeとかポインターとかがない
- Cache-friendly
  - メモリ上で連続して配置されている
- インデックスだけ計算すればいい
HeapSortのデメリットは以下の通り
- 安定的でない

実装ー時間計算量

MAXHEAPを作る過程が O(n logn)のように見えるかもしれない
- しかし、要素ごとに同じ必要で計算してるわけではない
- 下の子要素鯛はやすいコストで計算する
  - 葉ノードは高さ0なので、heapify()が呼び出されても演算が行われない
- 上の親要素は高いコストで計算する
  - 一番上位に近いノードは高さが大きくて演算が多く行われる
そのため、全部合わせたら、平均 O(n)になる

        ●        ← height 3 (1 node)
      ●   ●      ← height 2 (2 nodes)
     ● ● ● ●     ← height 1 (4 nodes)
    ● ● ● ● ● ● ● ●  ← height 0 (8 nodes, leaves)

MAX HEAPから最大値を取り出すソートフェーズは以下のソースコード

for (int i = n - 1; i > 0; i--) {
    swap(arr[0], arr[i]);
    heapify(arr, i, 0);
}

スワップはo(1)で、heapify()はさっき言った通りo(logn)
そこでFor文で n回繰り返すので o(n logn)になる

swap O(1)
heapify O(log n)
loop runs n - 1 times ≈ n

O(n) + O(n log n) は漸近的に O(n log n) に等しい

実装ーheap sort降順

arr[left] < arr[largest]と arr[right] < arr[largest]のように矢印の方向だけ変えればいい
それと誤解を払しょくするため、変数名をlargestからsmallestに変える

package main

import "fmt"

// Heapify function (fix subtree rooted at i)
func heapify(arr []int, n int, i int) {
	smallest := i
	left := 2*i + 1
	right := 2*i + 2

	if left < n && arr[left] < arr[smallest] {
		smallest = left
	}

	if right < n && arr[right] < arr[smallest] {
		smallest = right
	}

	if smallest != i {
		arr[i], arr[smallest] = arr[smallest], arr[i]
		heapify(arr, n, smallest)
	}
}

// Heap Sort
func heapSort(arr []int) {
	n := len(arr)

	// 1. Build Max Heap
	for i := n/2 - 1; i >= 0; i-- {
		heapify(arr, n, i)
	}

	// 2. Extract elements one by one
	for i := n - 1; i > 0; i-- {
		// Move current root to end
		arr[0], arr[i] = arr[i], arr[0]

		// Heapify reduced heap
		heapify(arr, i, 0)
	}
}

func main() {
	arr := []int{4, 10, 3, 5, 1}

	fmt.Println("Before:", arr)
	heapSort(arr)
	fmt.Println("After: ", arr)
}

クイックソート

Tue, 14 Apr 2026 00:00:00 +0000

実装ークイックソートOOP版

クイックソートはマージソートと同じ仕組みだと思い、そういう方向で進んでいった
なので、マージソートのように半分に分割して、新しい配列に再起関数を代入する形だとてっきり思った
だが、ピボットになるインデックスをどうやって決めればいいのか、それが全然わからなかった
結局、すべてAIに頼るしかなかった
その結果として得られたのが以下のロジックである
ここではLowとHighというポインターみたいな概念が必要だった

 public class QuickSort {

    public static void quickSort(int[] arr, int low, int high) {
        if (low < high) {
            int pivotIndex = partition(arr, low, high);

            quickSort(arr, low, pivotIndex - 1);   // left side
            quickSort(arr, pivotIndex + 1, high);  // right side
        }
    }

    private static int partition(int[] arr, int low, int high) {
        int pivot = arr[high]; 
        int i = low - 1; 
        for (int j = low; j < high; j++) {
            if (arr[j] < pivot) {
                i++;
                swap(arr, i, j);
            }
        }

        swap(arr, i + 1, high);
        return i + 1;
    }

    private static void swap(int[] arr, int i, int j) {
        int temp = arr[i];
        arr[i] = arr[j];
        arr[j] = temp;
    }
}

ベースケースが見えなくなる短所はあるので、以下のように明確にする
ベースケースの意味はlowとhighが一緒の場合は、分割が意味がなくなるため、必要ではないということ
ピボットインデックスを選択したら、左と右を分けるパーティションを作ってスワップする
最初はメソッドの名前を見ても全然意味が分からなかった

public static void quickSort(int[] arr, int low, int high) {
    if (low >= high) {
        return;
    } 
    int pivotIndex = partition(arr, low, high);

    quickSort(arr, low, pivotIndex - 1);   // left side
    quickSort(arr, pivotIndex + 1, high);  // right side
}

このメソッドの役割は決まったピボットに応じて、ピボットを境界線に大きいものと小さいものを分けることがある
そうやって分けてからそこで次のピボットを決めるという責任もある
OOPでは２つの責任を避けることがおすすめされる
そのため、２つのメソッドに分ける
時間計算量は n log nじゃなくて、2 * n log nになるけど、O（nlogn）には間違えない
ただ、大量のデータになると、そういった余分も大事になるため、古典的なクイックソートを使うことになる

public static void quickSort(int[] arr, int low, int high) {
    if (low >= high) return;

    int pivotIndex = calculatePivotIndex(arr, low, high);

    rearrangeAroundPivot(arr, low, high, pivotIndex);

    quickSort(arr, low, pivotIndex - 1);
    quickSort(arr, pivotIndex + 1, high);
}

実際のメソッドを見てみよう
ピボットのインデックスを計算するロジックは、自分より小さいやつを数えることだ
概念的には、それで得られたインデックスに挿入する形だけど、プログラミング的にはスワップで実装する
For文の範囲としては、Highは除外される
- その理由は、上でPivotとして最後のインデックスを使ったからだ
重複の場合も扱えるよう、＜＝になっている

// Responsibility 1: Calculate where the pivot will end up
private static int calculatePivotIndex(int[] arr, int low, int high) {
    int pivot = arr[high];
    int notBiggerCount = 0;

    for (int i = low; i < high; i++) {
        if (arr[i] <= pivot) {
            notBiggerCount++;
        }
    }

    return low + notBiggerCount;
}

ピボットをピボットのインデックスに移動させる
左からのピボットに移動する i の値と、右からピボットに移動しながら、スワップの対象となる値を探す
ピボットを軸にスワップするインデックスを見つけたら、スワップし、スワップが終わった後、次のインデックスに移動する
ダブルWhile文だといっても、時間計算量はO(n)になる
- 巻き戻しができない仕組みであるため、ダブルFor文みたいに最初から要素を見直すことではないからだ

private static void rearrangeAroundPivot(int[] arr, int low, int high, int pivotIndex) {
    int pivot = arr[high];

    swap(arr, pivotIndex, high);

    int i = low;
    int j = high;

    //  ソートが終わったら、i と　j が
    while (i < pivotIndex && j > pivotIndex) {

        //ピボットより小さい値がない場合は、該当するインデックスをスキップする
        while (arr[i] <= pivot && i < pivotIndex) {
            i++;
        }

        //ピボットより大きい値がない場合は、該当するインデックスをスキップする
        while (arr[j] > pivot && j > pivotIndex) {
            j--;
        }

        //i と j がまだピボットにたどり着けなかったということはスワップに対象になる要素があること
        if (i < pivotIndex && j > pivotIndex) {
            swap(arr, i, j);
            i++;
            j--;
        }
    }
}

例えば、次の配列があったとしたら、一回目で以下のようになる
- ７がピボットになる
- ７より小さい数値の分をピボットのインデクスにしてそこに挿入する（実際にはスワップ）
- ４，２，３は自分自身とスワップすることになるから、不要なスワップをしてしまうが、単純スワップは操作のコストが低いかつロジックの簡潔さを保てる
- １１に当たって、i は増えるけど、Leftというポインターは増えないから、次の変換対象になる小さいRight側の１に当たったら、１１と１のスワップができる

{4,2,3,11,8,9,1,7}
        |
{4,2,3,11,7,9,1,8}
        |
{4,2,3,1,7,9,11,8}

実装ークイックソートLomuto版

上の２つに分かれてるメソッドを１つにまとめると以下になる
partitionを分ける過程でボットを中心に右と左に分けることになる

public class QuickSortLomuto {

    public static void quickSort(int[] arr, int low, int high) {
        if (low < high) {
            int p = partition(arr, low, high);
            quickSort(arr, low, p - 1);
            quickSort(arr, p + 1, high);
        }
    }
}

i はピボットよりも小さい数値が入る領域の空間を確保するインデックスになる
- そのため、最初はアクセスできないインデックスから始まる
- 小さい領域を1つ広げるかつ小さい値を左に入れるための if文
  - いったん全部小さいと大きい領域に分けてから再起しながらソートする

private static int partition(int[] arr, int low, int high) {
    int pivot = arr[high];
    int i = low - 1; // boundary of smaller elements

    for (int j = low; j < high; j++) {
        if (arr[j] < pivot) {
            i++;
            swap(arr, i, j);
        }
    }

    // place pivot
    swap(arr, i + 1, high);
    return i + 1;
}

領域分けが終わったら、以下の状態になる
ピボットを本来あるべき位置に配置するため、i とピボットをスワップする
i = 小さい値の最後の indexなので、pivot の場所はその1つ右

[ 小さい値 ] [ 大きい値 ] pivot
            i

時間計算量は以下になる
パーティションを作る動作は最悪のケースでもO(n)になる

for (int j = low; j < high; j++) {
    if (arr[j] < pivot) {
        i++;
        swap(arr, i, j);
    }
}
swap(arr, i + 1, high);

ただ、再起は違う
普通のケースではT(n) = T(n/2) + T(n/2) + O(n)なので、O(n log n)になる
最悪の場合は、分けることが１つ筒になってしまい、T(n) = T(n-1) + O(n)になってしまい、o(n^2)になる
- 特にとっくにソートされた配列
- 逆にソートされた配列
- ピボットの選択が間違えた場合

深く探究ー3点中央値

ピボットの選択による最悪なケースを減らすため、中央値を探す方法もある
こうやって中央値に近い可能性を高めて最悪のケースになる可能性を減らす
最初の段階に中央値に近い値を探して、末尾に置く

private static int partition(int[] arr, int low, int high) {
    int mid = (low + high) / 2;
    if (arr[low] > arr[mid]) swap(arr, low, mid);
    if (arr[low] > arr[high]) swap(arr, low, high);
    if (arr[mid] > arr[high]) swap(arr, mid, high);
    swap(arr, mid, high);

    int pivot = arr[high];
    int i = low - 1; 

    for (int j = low; j < high; j++) {
        if (arr[j] < pivot) {
            i++;
            swap(arr, i, j);
        }
    }

    swap(arr, i + 1, high);
    return i + 1;
}

以下を実行すると、arr[low] <= arr[mid]になる

int mid = (low + high) / 2;
if (arr[low] > arr[mid]) swap(arr, low, mid);

以下を実行すると、arr[low] <= arr[high]

if (arr[low] > arr[high]) swap(arr, low, high);

lowはmidとhighどちらと比べても小さくなった
以下を実行すると、arr[mid] <= arr[high]

if (arr[mid] > arr[high]) swap(arr, mid, high);

すなわち、以下の連続の if文で arr[low] ≤ arr[mid] ≤ arr[high]になる

if (arr[low] > arr[mid]) swap(arr, low, mid);
if (arr[low] > arr[high]) swap(arr, low, high);
if (arr[mid] > arr[high]) swap(arr, mid, high);

midとhighをスワップすることで、中央値を末尾に配置できる

swap(arr, mid, high);

深く探究ークイックソートHoare版

Lomuto版じゃなくて、Hoare版もある
- ピボットを最後に配置せず、ひとえに境界だけを設定する
- 左と右の比較を同時に進行して、間違えたら修正

[ smaller-or-equal | larger-or-equal ]
          ↑
         boundary (p)

そのため、再帰するインデックスも変わる

//Lomuto
quickSort(arr, low, p - 1);        
quickSort(arr, p + 1, high);

//Hoare
quickSort(arr, low, p);        
quickSort(arr, p + 1, high);

小さい領域だけじゃなくて、大きい領域も新しくできた
- j がそれを代表する
小さい慮域でピボットより小さい値の場合はスキップする
大きいの場合は、真逆のロジックで動作する
両方で間違えた値を見つけたら、スワップする
i が　jと交差する瞬間、パーティション処理が終わったということなので、ソートを抜けるベースケースになる

public class QuickSortHoare {

    public static void quickSort(int[] arr, int low, int high) {
        if (low < high) {
            int p = partition(arr, low, high);
            quickSort(arr, low, p);        // ⚠️ different!
            quickSort(arr, p + 1, high);
        }
    }

    private static int partition(int[] arr, int low, int high) {
        int pivot = arr[low];
        int i = low - 1;
        int j = high + 1;

        while (true) {
            do {
                i++;
            } while (arr[i] < pivot);

            do {
                j--;
            } while (arr[j] > pivot);

            if (i >= j) return j;

            swap(arr, i, j);
        }
    }
}

Lomutoよりはスワップの回数が少ないため、より速い
- 両方で間違えたときだけスワップするので、回数が少ない
それでも、時間計算は同じ

| Case    | Complexity |
| ------- | ---------- |
| Best    | O(n log n) |
| Average | O(n log n) |
| Worst   | O(n²)      |

goのバージョンは以下の通り

package main

import "fmt"

func quickSort(arr []int, low, high int) {
	if low < high {
		p := partition(arr, low, high)
		quickSort(arr, low, p)     // ⚠️ important: p is included
		quickSort(arr, p+1, high)
	}
}

func partition(arr []int, low, high int) int {
	pivot := arr[low]

	i := low - 1
	j := high + 1

	for {
		// move i from left
		for {
			i++
			if arr[i] >= pivot {
				break
			}
		}

		// move j from right
		for {
			j--
			if arr[j] <= pivot {
				break
			}
		}

		// pointers crossed
		if i >= j {
			return j
		}

		swap(arr, i, j)
	}
}

func swap(arr []int, i, j int) {
	arr[i], arr[j] = arr[j], arr[i]
}

func main() {
	arr := []int{10, 7, 8, 9, 1, 5}

	quickSort(arr, 0, len(arr)-1)

	fmt.Println(arr)
}

バランスのいいピボットを選ぶため、以下のようなことがおすすめされる

// ３点中央点
int mid = (low + high) / 2;
if (arr[low] > arr[mid]) swap(arr, low, mid);
if (arr[low] > arr[high]) swap(arr, low, high);
if (arr[mid] > arr[high]) swap(arr, mid, high);

int pivot = arr[mid];

// ランダム
int pivot = arr[low + rand() % (high - low + 1)];

深く探究ークイックソート３Way

Hoare, Lomutoでは重複された値が多いとき、最悪のケースに陥りやすい
3wayはピボットが最後でなく、最初から始める
重複の値をきちんと扱うため、領域を３つに分ける
- lt (less-than boundary)
- i (current index)：
- gt (greater-than boundary)
lomutoとは違って、ピボットが 1 から始まるので、

public static void quickSort3Way(int[] arr, int low, int high) {
    if (low >= high) return;

    int pivot = arr[low];
    int lt = low;      // < ピボット
    int i = low + 1;   // ピボット
    int gt = high;     // > ピボット
}

最初は以下のような状態

[ P | ? ? ? ? ? ]
      ↑ 未知

どんどん動きながら、以下のように未知の領域を減らす

[ < | = = | ? ? | > ]
              ↑ shrinking

そのためのロジックは以下の通り
- 小さい値があったら、値をスワップする
  - スワップしたら、左から未知領域が縮めるので、ltを++する
  - スワップされたら、整頓されたので、現在のインデックス i を次のインデックスに安全に進める
- 大きい値があったら、値をスワップする
  - スワップしたら、右から未知領域が縮めるので、gtを–する
  - スワップしても、i は動かないが、理由はまだ右からピボットに向けてきてるインデックスはチェックされてないからだ
- どちらにも当てはまらなかった場合、重複なので、インデックスをスキップする

while (i <= gt) {
    if (arr[i] < pivot) {
        swap(arr, lt++, i++);
    } else if (arr[i] > pivot) {
        swap(arr, i, gt--);
    } else {
        i++;
    }
}

lt がピボットの領域、つまり重複の領域なので、 lt - 1までにすると、小さい値の領域になる
gt もピボットの領域、つまり重複の領域なので、gt + 1からすると、大きい値の領域になる
クイックソートの作業をもう１度繰り返す

quickSort3Way(arr, low, lt - 1);
quickSort3Way(arr, gt + 1, high);

深く探究ークイックソートハイブリッド

ハイブリットのクイックソートは以下のようになる
- サイズが少ない場合は、挿入ソートが効率高いので、挿入ソートを行う
- 少なくない場合、クイックソートを行う
- ピボットは３点中央値で最悪のケースに陥る可能性を減らす
  - 重複値が多い場合、３way方法で進める
  - でなければ、Hoare方法で進める

public class HybridQuickSort {

    public static void quickSort(int[] arr, int low, int high) {
        if (low >= high) return;

        // Small array optimization (optional but common)
        if (high - low < 16) {
            insertionSort(arr, low, high);
            return;
        }

        // Step 1: median-of-three pivot selection
        int pivot = medianOfThree(arr, low, high);

        // Step 2: detect duplicates (simple heuristic)
        if (isDuplicateHeavy(arr, low, high, pivot)) {
            // Use 3-way partition
            int[] range = partition3Way(arr, low, high, pivot);
            quickSort(arr, low, range[0] - 1);
            quickSort(arr, range[1] + 1, high);
        } else {
            // Use Hoare partition
            int p = partitionHoare(arr, low, high, pivot);
            quickSort(arr, low, p);
            quickSort(arr, p + 1, high);
        }
    }

    // -------- median-of-three --------
    private static int medianOfThree(int[] arr, int low, int high) {
        int mid = (low + high) / 2;

        if (arr[low] > arr[mid]) swap(arr, low, mid);
        if (arr[low] > arr[high]) swap(arr, low, high);
        if (arr[mid] > arr[high]) swap(arr, mid, high);

        return arr[mid]; // median value
    }

    // -------- Hoare partition --------
    private static int partitionHoare(int[] arr, int low, int high, int pivot) {
        int i = low - 1;
        int j = high + 1;

        while (true) {
            do { i++; } while (arr[i] < pivot);
            do { j--; } while (arr[j] > pivot);

            if (i >= j) return j;

            swap(arr, i, j);
        }
    }

    // -------- 3-way partition --------
    private static int[] partition3Way(int[] arr, int low, int high, int pivot) {
        int lt = low;
        int i = low;
        int gt = high;

        while (i <= gt) {
            if (arr[i] < pivot) {
                swap(arr, lt++, i++);
            } else if (arr[i] > pivot) {
                swap(arr, i, gt--);
            } else {
                i++;
            }
        }

        return new int[]{lt, gt};
    }

    // -------- Duplicate detection --------
    private static boolean isDuplicateHeavy(int[] arr, int low, int high, int pivot) {
        int count = 0;
        int sampleSize = Math.min(10, high - low + 1);

        for (int i = low; i < low + sampleSize; i++) {
            if (arr[i] == pivot) count++;
        }

        return count > sampleSize / 2;
    }

    // -------- Insertion sort --------
    private static void insertionSort(int[] arr, int low, int high) {
        for (int i = low + 1; i <= high; i++) {
            int key = arr[i];
            int j = i - 1;

            while (j >= low && arr[j] > key) {
                arr[j + 1] = arr[j];
                j--;
            }

            arr[j + 1] = key;
        }
    }

    // -------- swap --------
    private static void swap(int[] arr, int i, int j) {
        int temp = arr[i];
        arr[i] = arr[j];
        arr[j] = temp;
    }
}

深く探究クイックソートダブルピボット

実際Javaでは、上のようなクイックソートじゃなく、ダブルピボットで基本型のデータをソートするアルゴリズムを実装してる
領域を作るロジック事態は3wayと同じ
しかし、ダブルピボットになるため、領域を決めるWhile文以前の前処理と以後の後処理が違う

public class DualPivotQuickSort {

    public static void quickSort(int[] arr, int low, int high) {
        if (low >= high) return;

        // Ensure pivot1 <= pivot2
        if (arr[low] > arr[high]) {
            swap(arr, low, high);
        }

        int pivot1 = arr[low];
        int pivot2 = arr[high];

        int lt = low + 1;   // boundary for < pivot1
        int gt = high - 1;  // boundary for > pivot2
        int i = lt;

        while (i <= gt) {

            if (arr[i] < pivot1) {
                swap(arr, i, lt);
                lt++;
                i++;
            } else if (arr[i] > pivot2) {
                swap(arr, i, gt);
                gt--;
                // ⚠️ don't increment i here
            } else {
                i++;
            }
        }

        // Place pivots in correct positions
        lt--;
        gt++;

        swap(arr, low, lt);
        swap(arr, high, gt);

        // Recursively sort three parts
        quickSort(arr, low, lt - 1);     // < pivot1
        quickSort(arr, lt + 1, gt - 1);  // between
        quickSort(arr, gt + 1, high);    // > pivot2
    }

    private static void swap(int[] arr, int i, int j) {
        int temp = arr[i];
        arr[i] = arr[j];
        arr[j] = temp;
    }
}

まず、小さいピボットと大きいピボットを決める
そのあと、ピボットを除いて慮域を設定する
慮域の探索のための i はピボットを除いた先頭から始まる

// Ensure pivot1 <= pivot2
if (arr[low] > arr[high]) {
    swap(arr, low, high);
}

int pivot1 = arr[low];
int pivot2 = arr[high];

int lt = low + 1;   // boundary for < pivot1
int gt = high - 1;  // boundary for > pivot2
int i = lt;

領域を決めるロジックは３Wayと変わらない

while (i <= gt) {
    if (arr[i] < pivot1) {
        swap(arr, i, lt);
        lt++;
        i++;
    } else if (arr[i] > pivot2) {
        swap(arr, i, gt);
        gt--;
    } else {
        i++;
    }
}

While文が終わった後では、lt と gtはピボットの中間の領域の境界値
- lt は –して、境界値の直前の値にする
- gt は ++して、境界値の直後の値にする
ピボットが配置されべきのインデックスである lt と gtに調整が終わったので、スワップする

lt--;
gt++;

swap(arr, low, lt);
swap(arr, high, gt);

そうすることで、以下の通りになる

[ < pivot1 | pivot1 | middle | pivot2 | > pivot2 ]

小さい領域、中間領域、大きい領域に分けて１度クイックソートを行う
- low から lt-1
  - 1番目のピボットより小さい要素の集まり
- lt+1 から gt-1
  - 1番目のピボットと2番目のピボットの間の要素の集まり
- gt+1 から high
  - ２番目のピボットより大きい要素の集まり
- lt と gt はピボットであるため、ソート範囲には含まれない。

quickSort(arr, low, lt - 1);     // < pivot1
quickSort(arr, lt + 1, gt - 1);  // between
quickSort(arr, gt + 1, high);    // > pivot2

ダブルピボットが優れている理由
- １度に3つの領域に分割できる
  - より多くのパーティションに分けることで、再帰呼び出しの回数が減る
- データの偏りが抑えられる
  - ピボットを2つ使うことで、データをより均等に分割できる確率が高まる
  - これにより、再帰ツリーがより「浅く」なります。
- キャッシュとメモリ効率が良い
  - 1回のパーティション処理でより多くの要素を処理できるため、CPU観点での局所が向上する

振り返り

OOP版　ー＞ Lomuto版ー＞中央値探索　ー＞ Hoare版ー＞３Way版ー＞ハイブリッド版ー＞ Javaのダブルピボット
OOP版は理解しやすいだけに、効率は悪い
LomotoはOOPより効率は高いけど、ピボットの選択が最悪のケースに陥る可能性がわりとある
中央値はピボットの選択で最悪のケースに陥りにくいが、Lomuto自体がスワップが多く、スワップで遅い
スワップの回数を抑えるため、Hoare版を取り入れる
重複の可能性のあるロジックについてLomutoもHoareも効率が優れてないので、３Wayの方法を作成
全てを踏まえて、堅牢なハイブリット版を導入する
ピボットを１つじゃなくて、２つにするダブルピボット版を実装する

マージソート

Wed, 08 Apr 2026 00:00:00 +0000

実装ーマージソート昇順

最初に工夫して書いたソースコードだけど、正しく動作しない
前半部と後半部が分かれるのはわかるので、折半にすることまでは思いついたが、ベースケースの定義が全然間違っている
なのでmergeSort()を置く位置も間違えてしまった
その上に、CallStackがソースコードで展開するとどのようにメソッドが重なるのか理解をちゃんとしてなかった

public static void mergeSort(int[] arr) {
    System.out.println(arr.length);
    int[] beforeArray = new int[arr.length / 2];
    int[] afterArray = new int[arr.length / 2];

    for (int i = 0; i < arr.length / 2; i++) {
        if(arr.length == 1) {
            return;
        }
        beforeArray[i] = arr[i];

        if(i == arr.length / 2 - 1) {
            System.out.println(Arrays.toString(beforeArray));
            mergeSort(beforeArray);
        }

    }

    for (int i = arr.length /2 ; i < arr.length ; i++) {
        if(arr.length == 1) {
            return;
        }
        afterArray[i] = arr[i];

        
        if(i == arr.length - 1 ) {
            System.out.println(Arrays.toString(afterArray));
            mergeSort(afterArray);
        }

    }
}

前のアルゴリズムを復習しながら、ベースケースの意味をしっかり理解し、修正を加えた
今回は、コールスタックを手書きしながら、どのように展開されるのかを確認しつつソースコードを作成した
このようにして、前半部と後半部に分けるところまではできるようになった

func MergeSort(arr []int) {
	if len(arr) == 1 {
		return
	}

	beforeArray := []int{}
	afterArray := []int{}

	for i := 0; i < len(arr)/2; i++ {
		beforeArray = append(beforeArray, arr[i])
	}

	for i := len(arr); i > len(arr)/2; i-- {
		afterArray = append(afterArray, arr[i-1])
	}
	fmt.Println(beforeArray)
	fmt.Println(afterArray)
	MergeSort(beforeArray)
	MergeSort(afterArray)
}

後ろから要素を取るのは順序が変わってしまうため、以下のように直した

for i := len(arr) / 2; i < len(arr); i++ {
    afterArray = append(afterArray, arr[i])
}

ただし、マージのロジックがどうしても思いつかなかった
マージするには別途の関数が必要だという結論には至ったが、以前の配列などをどのように引き継いで扱うのかが分からなかった
ChatGPTに聞いたところ、変数に再帰関数を代入するという発想が必要だった
再帰関数を変数の代入にも使えるなんて、思ったこともなかったので、勉強になった

mergeSort(arr):
    if length <= 1:
        return arr

    mid = middle
    left = mergeSort(left half)
    right = mergeSort(right half)

    return merge(left, right)


merge(left, right):
    result = []

    while both have elements:
        take smaller one and append

    append remaining elements

    return result1

ChatGPTにもらった疑似コードのおかげで、基本的な枠組みは完成した。

func MergeSort(arr []int) []int {
	if len(arr) == 1 {
		return arr
	}

	beforeArray := []int{}
	afterArray := []int{}

	for i := 0; i < len(arr)/2; i++ {
		beforeArray = append(beforeArray, arr[i])
	}

	for i := len(arr) / 2; i < len(arr); i++ {
		afterArray = append(afterArray, arr[i])
	}
	fmt.Println(beforeArray)
	fmt.Println(afterArray)
	beforeArray = MergeSort(beforeArray)
	afterArray =  MergeSort(afterArray)

	return merge(beforeArray, afterArray)
}

上のソースコードは以下のような syntactic sugarが存在するそして、スライスが空の場合に備えて、ベースケースの条件が変わっていることが分かる

func MergeSort(arr []int) []int {
    if len(arr) <= 1 {
        return arr
    }

    mid := len(arr) / 2

    left := MergeSort(arr[:mid])
    right := MergeSort(arr[mid:])

    return merge(left, right)
}

次の問題は、どうやってマージするかだが、比較してマージするかとマージしてから比較するか、どちらを選ぶべきか悩んでいた
既存の整列アルゴリズムと同じようにするには、比較しながら整列してマージする必要があると考え、その方針で進めた
- ただし、ロジックがなかなか思いつかなかった
- のため、ChatGPTにロジックを教えてもらった
まず、2つのスライスをマージする際は、それぞれの先頭要素を比較し、小さい方を結果の配列に追加する
その際、結果の配列も常に先頭から順に最小値が並ぶようにする
要素を追加したら、その要素はもう不要になるため、対応するインデックスを進める
もう一方の配列の要素の方が小さい場合は、そちらを結果に追加する
この処理を繰り返すと、どちらか一方の配列の要素がすべてなくなるまでループが続く
最後に、残った配列の要素をそのまま結果の配列に追加する
- 残っている要素がどちらの配列にあるか分からないため、それぞれに対してループ処理を用意する
- 条件を満たさないループは実行されないため、パフォーマンスやロジックには影響しない

func merge(left, right []int) []int {
    result := []int{}

    i := 0
    j := 0

    //while
    for i < len(left) && j < len(right) {
        if left[i] < right[j] {
            result = append(result, left[i])
            i++
        } else {
            result = append(result, right[j])
            j++
        }
    }

    // 最後の要素を処理
    for i < len(left) {
        result = append(result, left[i])
        i++
    }

    for j < len(right) {
        result = append(result, right[j])
        j++
    }

    return result
}

時間計算量は n x logn.
- 分割する過程が lognで、半分にすることを1になるまでに続くとlog2nだからだ
- 一方、マージする過程が nで、要素を数分を演算するからだ
わからなかったポイント
- コールスタックの理解が足りていなかった
- 再帰についての応用が足りていなかった
- マージする際、最小限とか最大限などは各配列の先頭に来ること
- 最後の要素を処理すること

実装ーマージソート降順

今回は降順を実装してみた
分割する過程は変わらない

public int[] mergeSort(int[] arr) {
    if (arr.legnth <= 1 ) {
        return arr;
    }

    int[] leftArray;
    for(int i = 0; i < arr.legnth /2; i++) {
        leftArray = leftArray[i];    
    }

    int[] rightArray;
    for(int i = arr.length / 2; i < arr.length; i++) {
        rightArray = rightArray[i - arr.length / 2]
    }

    leftArray = mergeSort(leftArray);
    rigthArray = mergeSort(rightArray);

    return merge(leftArray, rightArray);
}

ただ、Javaで配列を初期化するためには、最初に初期容量を決めなければならない
そのため、以下のように変更する

int mid = arr.length / 2;
int[] leftArray = new int[mid];
int[] rightArray = new int[arr.length - mid];

// Copy elements into left array
for (int i = 0; i < mid; i++) {
    leftArray[i] = arr[i];
}

// Copy elements into right array
for (int i = mid; i < arr.length; i++) {
    rightArray[i - mid] = arr[i];
}

降順のマージソートもあまり違くなるところはない

public int[] merge(int[] leftArray, int[] rightArray) {
    int[] newArray = new int[leftArray.length + rightArray.length];
    int i = 0;
    int j = 0;
    int size = 0;
    while (i < leftArray.length && j < rightArray.length) {
        if (leftArray[i] > rightArray[j]) {
            newArray[size++] = leftArray[i++];
        } else {
            newArray[size++] = rightArray[j++];
        }
    }

    while (i < leftArray.length) {
        newArray[size++] = leftArray[i++];
    }

    while (j < rightArray.length) {
        newArray[size++] = rightArray[j++];
    }

    return newArray;
}

実装ー文字列マージソート

文字列の場合でも、基本的な考え方はあまり変わらない
ただし、比較に使うメソッドが変わるだけである
以下は昇順

if (leftArray[i].compareTo(rightArray[j]) > 0) {
    newArray[size++] = leftArray[i++];
} else {
    newArray[size++] = rightArray[j++];
}

深く探求ーStringとIntの違い

左と右の位置が入れ替わったら、intとStringは安定性の側面で結果が異なる
intの場合は、別に安定性に問題がない
それは int は別のメタデータなどを持ってないからだ

if(rightArray[i] > leftArray[j] ) {
    newArray[size++] = rightArray[i++]
} else {
    newArray[size++] = leftArray[j++]
}

Stringは少し違う
Stringみたいなクラスはメタデータを持っている場合が多い
以下のようにすると、不安定のアルゴリズムになってしまう

if (rightArray[i].compareTo(leftArray[j]) > 0) {
    newArray[size++] = rightArray[i++];
} else {
    newArray[size++] = leftArray[j++];
}

以下のString配列があると仮定してみた

String[] arr = {"apple_1", "banana_2", "apple_3", "cherry_4"};

右側を基準とする場合、While文が進むにつれて状況は次のようになる。
apple_1 が apple_3 より先にあったにもかかわらず、その順序が乱れてしまった。

["apple_1", "banana_2", "apple_3", "cherry_4"]
          /                        \
["apple_1", "banana_2"]       ["apple_3", "cherry_4"]
     /         \                 /           \
["apple_1"] ["banana_2"]   ["apple_3"]   ["cherry_4"]
    \           /                \            /
["banana_2", "apple_1"]     ["cherry_4"] + ["apple_3"] 
            \                       /
["cherry_4", "banana_2", "apple_3", "apple_1"]

そのため、安全性を保証するためには、左を基準にしたほうがいい
特に複数のフィールドを持つクラスの場合、不安定性の問題が顕著に現れる
1が先頭にあるはずなのに、３が先頭になってしまった

Item[] arr = { ("apple", 1), ("banana", 2), ("apple", 3) }

ソート後の結果
("apple", 3), ("apple", 1), ("banana", 2)

深く探求ー部分的なマージソート

部分的にすると、JavaのAPIであるcopyOfRangeを使うと、便利になる

public void executePartialMergeSort(int[] arr, int n, int y) {
    int[] arr = {1,1,2,5,6,8,3,6,11,20,25};

    int[] sub = Arrays.copyOfRange(arr, n, j); 

    sub = mergeSort(sub); 

    for (int i = 0; i < sub.length; i++) {
        arr[n + i] = sub[i];
    }
}

static void ExecutePartialMergeSort(int[] arr, int n, int y)
{
    int[] sub = arr.Skip(n).Take(y - n).ToArray();

    sub = MergeSort(sub);

    for (int i = 0; i < sub.Length; i++)
    {
        arr[n + i] = sub[i];
    }
}

func ExecutePartialMergeSort(arr []int, n int, y int) {
    
	sub := append([]int(nil), arr[n:y]...)

	// Step 2: Sort the subarray using merge sort (descending)
	sub = MergeSort(sub)

	// Step 3: Put it back into original array
	for i := 0; i < len(sub); i++ {
		arr[n+i] = sub[i]
	}
}

振り返り

再帰を多彩の活用に気づけなかった

func MergeSort(arr []int) []int {
    .
    .
    .
    beforeArray = MergeSort(beforeArray)
    afterArray =  MergeSort(afterArray)
}

再帰関数が１つだけで済むと勘違いしていた

func MergeSort(arr []int) []int {
    .
    .
    .
	beforeArray = MergeSort(beforeArray)
	afterArray =  MergeSort(afterArray)

	return merge(beforeArray, afterArray)
}

必ず先頭のインデックスには最小とか最大の数値が並ぶことがわからなかった
振り子のように、左と右のスライスを行ったり来たりすることをどうやって実装するのかピンとこなかった

func merge(left, right []int) []int {
    result := []int{}

    i := 0
    j := 0

    //while
    for i < len(left) && j < len(right) {
        if left[i] < right[j] {
            result = append(result, left[i])
            i++
        } else {
            result = append(result, right[j])
            j++
        }
    }
    .
    .
    .

    return result
}

最後の値は触れられてない状態なので、以下の通り、最後の値を入れる処理が必要だと思えなかった

// 最後の要素を処理
for i < len(left) {
    result = append(result, left[i])
    i++
}

for j < len(right) {
    result = append(result, right[j])
    j++
}

バブルソートと挿入ソート

Mon, 06 Apr 2026 00:00:00 +0000

実装ーバブルソート

最初のロジックは以下だった。
ただ、iを全然使わずにしていた

public static void executeBubbleSort(int[] arr) {
    for(int i = 0; i < arr.length; i++) {
        for (int j = 0; j < arr.length - 1; j++) {
            if (arr[j] > arr[j + 1]) {
                int temp = arr[j];
                arr[j] = arr[j + 1];
                arr[j + 1] = temp;
                break;
            }
        }
    }
}

goに変換して実行しようとしたが、失敗した
declared and not used: i というエラーが出た
私のロジックに何か問題があるのことに気づいた
javaではできたのは、JavaとGoのCompilerの違いから起因したと思った
- 実際にGoのコンパイラは上のオプションを非活性化ができない
以下はコンパイルエラーが出る関数

func ExecuteBubbleSort(arr []int) {
	for i := range arr {
		for j := 0; j < len(arr)-1; j++ {
			if arr[j] > arr[j+1] {
				arr[j], arr[j+1] = arr[j+1], arr[j]
				break
			}
		}
	}
}

そのため、iも利用するしっかりした関数を作った
結局BubbleSortは、最後の値を埋めて見なくてもいいようにするアルゴリズムだ、ということに気づいた
最後に差大値を移動させてそこは見なくてもいいので、jの範囲が　- i されてる
i はそのループカウントを指し示すための変数だった。

public static void executeBubbleSort(int[] arr) {
    for(int i = 0; i < arr.length; i++) {
        for ( int j = 0; j < arr.length - 1 - i; j++) {
            if (arr[j] > arr[j + 1]) {
                int temp = arr[j];
                arr[j] = arr[j + 1];
                arr[j + 1] = temp;
            }
        }
    }
}

go langバージョン
j + 1が動く基準なので、基準が len(arr) - i の範囲内で動くことを明確にした

func ExecuteBubbleSort1(arr []int) {
	for i := range arr {
		for j := 0; j + 1 < len(arr)-i; j++ {
			if arr[j] > arr[j+1] {
				arr[j], arr[j+1] = arr[j+1], arr[j]
			}
		}
	}
}

以下のようにもできる
基準になるインデックスを変えただけ
- j が動く基準なので、基準が len(arr) - i の範囲内で動くこと

func ExecuteBubblesort2(arr []int) {
	for i := range arr {
		for j := 1; j < len(arr)-i; j++ {
			if arr[j] < arr[j-1] {
				arr[j], arr[j-1] = arr[j-1], arr[j]
			}
		}
	}
}

そこで少し改善をすると、スワップがない場合は、もう整列が終わったということになるので、ループさせないようにする

func ExecuteBubblesort2(arr []int) {
	for i := range arr {
		isSwapped := false
		for j := 1; j < len(arr)-i; j++ {
			if arr[j] < arr[j-1] {
				arr[j], arr[j-1] = arr[j-1], arr[j]
				isSwapped = true
			}
		}

		if !isSwapped {
			break
		}
	}
}

上は昇順で、以下は降順
if文の矢印の方向が逆になっただけ

func ExecuteBubblesortDESC(arr []int) {
	for i := range arr {
		isSwapped := false
		for j := 1; j < len(arr)-i; j++ {
			if arr[j] > arr[j-1] {
				arr[j], arr[j-1] = arr[j-1], arr[j]
				isSwapped = true
			}
		}

		if !isSwapped {
			break
		}
	}
}

C#は以下のよう
C#は、JAVA字下げのしかたが違うので、それだけ注意すればほぼJAVAと同じ

static void ExecuteBubblesortDESC(int[] arr)
{
    for (int i = 0; i < arr.Length; i++)
    {
        bool isSwapped = false;

        for (int j = 1; j < arr.Length - i; j++)
        {
            if (arr[j] > arr[j - 1])
            {
                int temp = arr[j];
                arr[j] = arr[j - 1];
                arr[j - 1] = temp;

                isSwapped = true;
            }
        }

        if (!isSwapped)
        {
            break;
        }
    }
}

ここで重要なポイントは以下の通り
- 最後から整列されること
- 基準となるインデックスが１から始まること
- wapされる要素がなくなった時点で、整列が完了したと判断して処理を終了する
時間計算量は以下のよう
- あらかじめ整列されている場合（ベストケース）では、計算量は O(N) になる。
- それ以外の場合は、二重のfor文を使っているため、計算量はどうしても O(N²) になってしまう

実装ー挿入ソート

一週間後で挑戦して解けた
最初のロジックは以下だった

func InsertionSort(arr []int) {
	for i := 1; i < len(arr); i++ {
		std := arr[i]
		n := i
		for arr[n] < arr[n-1] {
			arr[n] = arr[n-1]
			n--
		}

		arr[n] = std
	}
}

ただ、nが負数になる問題があって負数になったらWhile文を抜けるようにした

func InsertionSort(arr []int) {
	for i := 1; i < len(arr); i++ {
		std := arr[i]
		n := i
		for n > 0 　/* 追加 */&& arr[n] < arr[n-1] {
			arr[n] = arr[n-1]
			n--
		}

		arr[n] = std
	}
}

そのあともエラーが出た
実際に回数ごとの展開を書いたところ、比較の対象がバブルソートとは違って、基準数なのに気付いた

func InsertionSort(arr []int) {
	for i := 1; i < len(arr); i++ {
		std := arr[i]
		n := i
		for n > 0 && std /* 変換 */< arr[n-1] {
			arr[n] = arr[n-1]
			n--
		}

		arr[n] = std
	}
}

上と同じ結果だけどインデックスへの捉え方が違う
厳密にいうと、こちらがシフトにもっと近い

func InsertionSort(arr []int) {
	for i := 1; i < len(arr); i++ {
		std := arr[i]
		n := i-1
		for n >= 0 && std < arr[n] {
			arr[n+1] = arr[n]
			n--
		}

		arr[n+1] = std
	}
}

ただ、それは理解しづらかったので、以下のように変数名を切り替えて理解しやすくした

func InsertionSortDESCShiftBased(arr []int) {
	for i := 1; i < len(arr); i++ {
		curValue := arr[i]
		comparedIndex := i - 1
		for comparedIndex >= 0 && curValue > arr[comparedIndex] {
			arr[comparedIndex+1] = arr[comparedIndex]
			comparedIndex--
		}

		arr[comparedIndex+1] = curValue
	}
}

以下はできない
操作中、インデックスが動くので、インデックスじゃなくて、必ず値を格納する必要がある
もう当時のインデックスに対する値が失われてるのでエラーになる

func InsertionSortDESCShiftBased(arr []int) {
	for i := 1; i < len(arr); i++ {
		curIndex := i
		comparedIndex := i - 1
		for comparedIndex >= 0 && arr[curIndex] > arr[comparedIndex] {
			arr[comparedIndex+1] = arr[comparedIndex]
			comparedIndex--
		}

		arr[comparedIndex+1] = arr[curIndex] /* もう当時のインデックスに対する値が失われてる*/
	}
}

For文になると、以下のようになる
While文より理解しづらくなるので、ここではWhile文を使うことをおすすめする

var n int
for n = i - 1; n >= 0 && std < arr[n]; n-- {
    arr[n+1] = arr[n]
}

C#にすると以下となる
Javaとほぼ変わらない
importなどのインペラティブが usingなどに変わっただけ

using System;

class Program
{
    static void InsertionSort(int[] arr)
    {
        for (int i = 1; i < arr.Length; i++)
        {
            int std = arr[i];
            int n = i - 1;

            while (n >= 0 && std < arr[n])
            {
                arr[n + 1] = arr[n];
                n--;
            }

            arr[n + 1] = std;
        }
    }

    static void Main()
    {
        int[] arr = { 5, 2, 4, 6, 1, 3 };

        InsertionSort(arr);

        Console.WriteLine(string.Join(", ", arr));
    }
}

ここで重要なポイントは以下のよう
- Whileを考えること
- 基準となる数という概念を思いつくこ
- 基準となるインデックスが１から始まること
- スワップじゃなくて、シフトということ
- シフトをコンピューター科学てきに実装する方法
時間計算量は以下のよう
- あらかじめ整列されている場合（ベストケース）では、計算量は O(N) になる。
- それ以外の場合は、二重のfor文を使っているため、計算量はどうしても O(N²) になってしまう

実装ー整列以降特定の値を数える

私が最初にこの問題を解いた方法は、以下の通りだ
- カウントは nという変数を導入して処理するが、重複でなくなったら、カウントを元に戻す
- 重なってる最初の要素を見つけたら、その値を入れる
相当多くの変数を使っていたため、それを何とか減らせないか工夫した

public static DupCount[] countDup(int[] arr) {
    int n = 0;
    boolean doubledFlag = false;
    DupCount[] temp = new DupCount[arr.length];
    for (int i = 0; i < arr.length - 1; i++) {
        if (arr[i] == arr[i + 1]) {
            n++;
            doubledFlag = true;
        } else {
            if (doubledFlag) {
                temp[i - n] = new DupCount(arr[i - n], n);
                doubledFlag = false;
            }
            n = 0;
        }

    }

    return temp;
}

private static class DupCount {
    int duplicatedNumber;
    int count;

    public DupCount(int duplicatedNumber, int count) {
        this.duplicatedNumber = duplicatedNumber;
        this.count = count;
    }

    @Override
    public String toString() {
        return "DupCount [duplicatedNumber=" + duplicatedNumber + ", count=" + count + "]";
    }
}

ただ、最後の要素が取れなかったので、最後は以下のようにIf文で手動で処理するようにした

 public static DupCount[] countDup(int[] arr) {
    int n = 0;
    boolean doubledFlag = false;
    DupCount[] temp = new DupCount[arr.length];

    int i = 0;
    for (i = 0; i < arr.length - 1; i++) {
        if (arr[i] == arr[i + 1]) {
            n++;
            doubledFlag = true;
        } else {
            if (doubledFlag) {
                temp[i - n] = new DupCount(arr[i - n], n);
                doubledFlag = false;
            }
            n = 0;
        }
    }

    if (doubledFlag) {
        temp[i] = new DupCount(arr[i - n], n);
        doubledFlag = false;
    }

    return temp;
}

しかし、配列に合うサイズではなく、全てのサイズを取っているため、冗長なNull値などが見えた
なので、必要ない要素を取り除くために diff という変数を付け加えた
カウントは初期化されるので、初期化に自由な変数として diffを導入したわけだ
カウントも１から始まるので、＋１にした

public static DupCount[] countDup(int[] arr) {
    int n = 0;
    boolean doubledFlag = false;
    DupCount[] temp = new DupCount[arr.length];

    int i = 0;
    int diff = 0;
    int length = 1;
    for (i = 0; i < arr.length - 1; i++) {
        if (arr[i] == arr[i + 1]) {
            n++;
            diff++;
            doubledFlag = true;
        } else {
            if (doubledFlag) {
                temp[i - diff] = new DupCount(arr[i - n], n + 1);
                doubledFlag = false;
                length++;
            }
            n = 0;
        }
    }

    if (doubledFlag) {
        temp[i - diff] = new DupCount(arr[i - n], n + 1);
        doubledFlag = false;
    }

    return Arrays.copyOf(temp, length);
}

ChatGPTが最適化してくれたソースコードだ
Countはあるとしたら、最初から１から始まるべきなのに、そこまで考えが及ばなかった
重複された値の最後のやつだけ引っ張ってきて入れればいい
- そのため、入れる値を探すためのインデックスは i - n が要らない
- ただ i - 1でもいい
- n 自体の必要性が要らなくなったので、消す
doubledFlagもカウントが１超過になったら、重複なのでその変数もいらないから消す

public static DupCount[] countDup(int[] arr) {

    DupCount[] temp = new DupCount[arr.length];
    int size = 0;
    int count = 1;

    for (int i = 1; i < arr.length; i++) {

        if (arr[i] == arr[i - 1]) {
            count++;
        } else {
            if (count > 1) {
                temp[size++] = new DupCount(arr[i - 1], count);
            }
            count = 1;
        }
    }

    // last group
    if (count > 1) {
        temp[size++] = new DupCount(arr[arr.length - 1], count);
    }

    return Arrays.copyOf(temp, size);
}

GOに変換した

type DupCount struct {
    dupNum int
    count  int
}

func NewDupCount(dupNum int, count int) *DupCount {
    return &DupCount{
        dupNum: dupNum,
        count:  count,
    }
}

func (d DupCount) String() string {
    return fmt.Sprintf("DupCount [dupNum=%d, count=%d]", d.dupNum, d.count)
}

func CountDup(arr []int) []DupCount {
    temp := []newDupCount
    size := 0
    count := 1

    for i = 1; i < len(arr); i++ {
        if arr[i] == arr[i - 1] {
            count++
        } else {
            if (count > 1) {
                temp[size++] = NewDupCount(arr[i-1], count)
            }

            count = 1;
        }
    }

    if(count > 1) {
        temp[size++] = NewDupCount(arr[i-1], count)
    }
}

goについての変数宣言などが間違えていた
Sliceを利用するので、サイズという変数も要らなくなる
sliceに要素を追加するときは、Appendを利用する
宣言された構造体を共有して使うためには、ポインタとして渡す必要がある

func CountDup(arr []int) []DupCount {
    var temp []DupCount
    if len(arr) == 0 {
        return temp
    }

    count := 1

    for i := 1; i < len(arr); i++ {
        if arr[i] == arr[i-1] {
            count++
        } else {
            if count > 1 {
                temp = append(temp, *NewDupCount(arr[i-1], count))
            }
            count = 1
        }
    }

    // Handle last group
    if count > 1 {
        temp = append(temp, *NewDupCount(arr[len(arr)-1], count))
    }

    return temp
}

C#に変換すると、Javaとほぼ同じ
ただ、Array.copyOfじゃなくて、Copyに名前が変わる

Array.Copy(temp, result, size);

ここで重要なポイントは以下の通り
- 最後の要素を手動で操る必要がある場合もある
- カウンタを数えて重複有無が判別がつくので、ブリアン変数はいらない
- 重複状態を初期化するロジックをどこに置けばいいか

実装ー整列された配列で１番近いいペアを探索

最初に組んだプログラムだ
数字動詞に引き算をした結果を格納して、格納した値の中で1番小さい数字を選んだら、それが正解だと思った
しかし、一番最後の数字に更新されるエラーが出た
- １番近いペアが複数になると思えなかった私の不注意だった

public static int[] executeFindingNearestOne(int[] arr) {
    int[] temp = new int[arr.length - 1];
    for(int i = 0; i < arr.length - 1; i++) {
        temp[i] = arr[i + 1] - arr[i];
    }

    int minIndex = 0;;
    for (int i = 0; i < temp.length; i++) {
        if(temp[0] >= temp[i]) {
            minIndex = i;
        }
    }

    int[] retArr = {arr[minIndex], arr[minIndex + 1]};

    return retArr;
}

全ての一番近い数字を記録する必要があったので、クラスを別途に作成した
そのため、最小値が複数になるケースを想定して、最小値に当たる値を見つけたら、そのインデックスを格納する
最後に、インデックスを利用して元の配列の値を探す

public static NearestNumbers[] executeFindingNearestOneNoOverLapping(int[] arr) {
    int[] temp = new int[arr.length - 1];
    for(int i = 0; i < arr.length - 1; i++) {
        temp[i] = arr[i + 1] - arr[i];
    }

    int min = 0;
    for (int i = 0; i < temp.length; i++) {
        if(temp[0] >= temp[i]) {
            min = temp[i];
        }
    }

    int size = 0;
    int[] prevArr = new int[temp.length];
    for (int i = 0; i < temp.length; i++) {
        if(temp[i] == min) {
            prevArr[size++] = i;
        }
    }

    NearestNumbers[] retArr = new NearestNumbers[size];
    for(int i = 0 ; i < size; i++) {
        retArr[i] = new NearestNumbers(arr[prevArr[i]], arr[prevArr[i] + 1]);
    }

    return retArr;
}

private static class NearestNumbers {
    int num1;
    int num2;
    public NearestNumbers(int num1, int num2) {
        this.num1 = num1;
        this.num2 = num2;
    }
    @Override
    public String toString() {
        return "NearestNumbers [num1=" + num1 + ", num2=" + num2 + "]";
    }
}

ここで重要なポイントは以下の通り
- 各数値間の最も小さい差を計算する
- 最も小さい差を示す数値のインデックスを求める

実装ー整列後重複除外

Javaの配列が固定サイズだということを忘れていた
だから以下のような馬鹿みたいにソースコードを書いてしまった

public static int[] executeRemoveDuplication(int[] arr) {
    int[] indexs = {};
    int[] newArray = {};
    
    for (int i = 0; i < arr.length - indexs.length; i++) {
        if(arr[i] == arr[i + 1]) {
            indexs[i] = i + 1;
        }
    }

    int doubledCount = 0;
    for (int j = 0; j < arr.length; j++) {
        boolean doubled = false;
        for(int k = 0; k <indexs.length; k++) {
            if(j == indexs[k]) {
                doubled = true;
                doubledCount++;
            }
        }

        if(!doubled) {
            newArray[j - doubledCount] = arr[j];
        }
    }

    return newArray;
}

配列を全部検査して重複のものを消す方法で、私がやってた方法。

public static int[] executeRemoveDuplication(int[] arr) {
    int n = 0;
    Integer[] temp = new Integer[arr.length];
    int i = 0;
    for (i = 0; i < arr.length - 1; i++) {
        if(arr[i] == arr[i + 1] ) {
            n++;
            continue;
        }


        temp[i - n] = arr[i];
    }
    temp[i - n] = arr[i];

    int j = 0;
    for(int k = 0; k < temp.length; k++) {
        if(temp[k] != null) {
            j++;
        }
    }

    int[] newArr = new int[j];
    for(int k = 0; k < newArr.length; k++) {
        newArr[k] = temp[k];
    }

    return newArr;
}

実際のサイズだけを集中していくもっと簡単な方法。
全部検査ではなくて、必要な論理てきに有効なサイズだけを見ていく

public static int[] executeRemoveDulication(int[] arr) {
    int[] temp = new int[arr.length];
    int size = 0;

    temp[size++] = arr[0];

    for (int i = 1; i < arr.length; i++) {
        if (arr[i] != arr[i - 1]) {
            temp[size++] = arr[i];
        }
    }

    return Arrays.copyOf(temp, size);
}

golangeでsliceを使うと、より簡単にできる

func ExecuteRemoveDuplication1(arr []int) []int {
	result := []int{arr[0]}

	for i := 1; i < len(arr); i++ {
		if arr[i] != arr[i-1] {
			result = append(result, arr[i])
		}
	}

	return result
}

実装ー整列後重複の要素だけを集める

最初は以下のようにソースコードを作成した
問題は以下は変数が曖昧なところと、最後の重複が処理できないところが問題になった

public static int[] extractDuplicatedNumber(int[] arr) {
    int[] temp = new int[arr.length];
    int size = 0;
    int count = 0;

    for (int i = 0; i + 1 < arr.length; i++) {
        if (arr[i+1] == arr[i]) {
            count++;
        } else {
            if(count > 0) {
                temp[size++] = new DupCount(arr[i])
            }
            count = 0;
        }
    }

    return Array.copyOf(temp, size);
}

変数名は重複が起こった数字がいくつなのかを明確にした
以前のソースコードは、「1, 2, 2」のような配列では、末尾で重複が発生するが、else文に入らないため、正しく動作しなかった
そのため、末尾の要素も処理対象に含めた

public static int[] extractDuplicatedNumber(int[] arr) {
    int[] temp = new int[arr.length];
    int size = 0;
    int duplicatedNumberCount = 1;

    for (int i = 1; i < arr.length; i++) {
        if (arr[i] == arr[i - 1]) {
            duplicatedNumberCount++;
        } else {
            if (duplicatedNumberCount > 1) {
                temp[size++] = arr[i - 1];
            }
            duplicatedNumberCount = 1;
        }
    }

    if (duplicatedNumberCount > 1) {
        temp[size++] = arr[arr.length - 1];
    }

    return Arrays.copyOf(temp, size);
}

以下のようにすると、冗長なif文は削除できる
ただし、このような書き方に慣れていない人にとっては読みやすさが損なわれる

public static int[] extractDuplicatedNumber(int[] arr) {
    int[] temp = new int[arr.length];
    int size = 0;
    int count = 1;

    for (int i = 1; i <= arr.length; i++) {

        if (i < arr.length && arr[i] == arr[i - 1]) {
            count++;
        } else {
            if (count > 1) {
                temp[size++] = arr[i - 1];
            }
            count = 1;
        }
    }

    return Arrays.copyOf(temp, size);
}

ここで重要なポイントは以下の通り
- 最後の要素を処理する必要がある

深く探求ーロジックの改善

ChatGPTに聞いた結果、findNearest()の改善が見られた
- 最終的に隣接した２つの数値の差が１番小さいものしか使わないので、最初からそれを探す
- なので、不要な臨時配列は要らなくなる
- それに応じて最後も隣接した２つの数値の差が最小値になった場合だけ格納することにする

public static NearestNumbers[] findNearest(int[] arr) {

    int min = Integer.MAX_VALUE;

    for (int i = 0; i < arr.length - 1; i++) {
        int diff = arr[i + 1] - arr[i];
        if (diff < min) {
            min = diff;
        }
    }

    int count = 0;
    for (int i = 0; i < arr.length - 1; i++) {
        if (arr[i + 1] - arr[i] == min) {
            count++;
        }
    }

    NearestNumbers[] result = new NearestNumbers[count];

    int index = 0;
    for (int i = 0; i < arr.length - 1; i++) {
        if (arr[i + 1] - arr[i] == min) {
            result[index++] = new NearestNumbers(arr[i], arr[i + 1]);
        }
    }

    return result;
}

golangに変換したら、以下になる
初期容量を気にしなくてもいいので、ロジックがより簡潔になる

type NearestNumbers struct {
    formerNum int
    latterNum int
}

func NewNearestNumbers(formerNum int, latterNum int) *NearestNumbers {
    return &NearestNumbers{
        formerNum : formerNum,
        latterNum : latterNum
    }
}

func SeekNearesetNumbers(arr []int) ([]*NearestNumbers, bool) {
    if len(arr) < 2 {
        return nil, false
    }

    var nearestNumbers []*NearestNumbers
    minDiff := math.MaxInt64;
    for i := 1; i < len(arr); i++ {
        if arr[i] - arr[i-1] < minDiff {
            minDiff = arr[i] - arr[i - 1]
        }
    }

    for i := 1; i < len(arr); i++ {
        if arr[i] - arr[i-1] == minDiff {
            nearestNumbers = append(nearestNumbers, NewNearestNumber(arr[i-1], arr[i]))
        }
    }

    return nearestNumbers, true
}

arr := []int{1, 3, 4, 8, 9, 10}
pairs, ok := SeekNearestNumbers(arr)

if ok {
    for _, p := range pairs {
        fmt.Printf("(%d, %d)\n", p.formerNum, p.latterNum)
    }
}

Golangのsliceと同じく、Javaも最初から配列じゃなくてArrayListを使う方法もある
ただ、ArrayListを使うと、clear() などの操作のコストが比較的高い。

List<NearestNumbers> result = new ArrayList<>();
int min = Integer.MAX_VALUE;

for (int i = 0; i < arr.length - 1; i++) {
    int diff = arr[i + 1] - arr[i];

    if (diff < min) {
        result.clear();
        result.add(new NearestNumbers(arr[i], arr[i + 1]));
        min = diff;
    } 
    else if (diff == min) {
        result.add(new NearestNumbers(arr[i], arr[i + 1]));
    }
}

countDup()も改善ができる

public static DupCount[] countDup(int[] arr) {
    DupCount[] temp = new DupCount[arr.length];
    int size = 0;

    int count = 1;

    for (int i = 1; i <= arr.length; i++) {
        if (i < arr.length && arr[i] == arr[i - 1]) {
            count++;
        } else {
            if (count > 1) {
                temp[size++] = new DupCount(arr[i - 1], count);
            }
            count = 1;
        }
    }

    return Arrays.copyOf(temp, size);
}

最初から配列じゃなくてArrayListを使う方法もある

public static DupCount[] countDup(int[] arr) {
    List<DupCount> list = new ArrayList<>();

    int count = 1;

    for (int i = 1; i <= arr.length; i++) {
        if (i < arr.length && arr[i] == arr[i - 1]) {
            count++;
        } else {
            if (count > 1) {
                list.add(new DupCount(arr[i - 1], count));
            }
            count = 1;
        }
    }

    return list.toArray(new DupCount[0]);
}

深く探求ーなぜバブルソートより挿入ソートが効率に優れてるのか

時間計算量は同じであるにもかかわらず、選択ソートがより適している理由は、スワップよりシフトがCPUの効率に優れているためである
- スワップは3回の代入が必要だが、シフトは1回で済む
- 演算回数は同じように見えても、CPUの観点ではシフトが圧倒的に有利
- CPUのcacheの動作にも起因する
以下はspatial localityとTemporal localityが保てる
- CPUは１つの要素だけを読み込んまない
- CPUは配列で１つの要素だけをアクセスするソースコードがあっても、６４BYTEの単位でデータを読み込む
- そのため、データの塊（CHUNK）を一度読み込むと、それがキャッシュに保存される
- そのキャッシュを複数回再利用できる
挿入ソートがキャッシュに非常に優しい理由は、Bubble sortと違って、０に戻らないからだ
i が変わってもほぼ隣接したインデックスなので、キャッシュの活用に有利

for n >= 0 && std < arr[n] {
    arr[n+1] = arr[n]
    n--
}

平均を考えたら、以下のようにロードしたCPUキャッシュを生かせることができる
Worstケースだったら、Cache Loadが[95-80], [79-64], [63-48], [47-32],[31-16],[15-0]を全部ロードする必要がある
そういった場合になると、iが大きくなってしまうと、L1キャッシュの限界容量を超えてしまい、全部キャッシュが失われてしまう
ただし、実際は部分的に整列されたデータが多いため、CPUキャッシュで効率が優れる

Step i = 100:

Cache load:
[96 ~ 111]　

Use:
100 → 99 → 98 → 97 → (reuse same cache line)

→ minimal cache misses

実際のソースコード

func InsertionSort(arr []int) {
	for i := 1; i < len(arr); i++ {
		std := arr[i]
		n := i
		for n > 0 　/* 追加 */&& arr[n] < arr[n-1] {
			arr[n] = arr[n-1]
			n--
		}

		arr[n] = std
	}
}

その反面、BubbleSortは次の照会になったら、いつも jの値が０に戻るため、キャッシュが初期化される場合が多い
L1とL2Cacheはかなり小さいからだ

| Level | Size    |
| ----- | ------- |
| L1    | ~32 KB  |
| L2    | ~256 KB |

そのため、要素が多ければ多いほど、CPUの局所性が損なわれる
こういった仕組みはキャッシュに優しくないし、頻繫なロードが必要とされるため、遅くなる

Pass 1:
[0 ~ 15] → [16 ~ 31] → ... → [n]

Pass 2:
[0 ~ 15]  ← must reload (evicted)
[16 ~ 31] ← must reload
...

実際のソースコード

func ExecuteBubbleSort1(arr []int) {
	for i := range arr {
		for j := 0; j + 1 < len(arr)-i; j++ {
			if arr[j] > arr[j+1] {
				arr[j], arr[j+1] = arr[j+1], arr[j]
			}
		}
	}
}

振り返り

以下のコードはただスターポイントが異なるだけではない。
なぜこんなスターポイントをセットすることがいいのかに気づいた

for (int j = 0; j < arr.length - 1; j++) {
    if (arr[j] > arr[j + 1])
}

for (int j = 1; j < arr.length; j++) {
    if (arr[j - 1] > arr[j])
}

アルゴリズムのやり方によって For文での活用し方が異なる
- 選択ソートは最初の値から整列するからスタートポイントを移動させる
- Bubbleソートは最後の値から整列するからエンドポイントを移動させる

for (int j = 1 + i; j < abc.length; j++)        // SelectionSort
for (int j = 0; j < arr.length - 1 - i; j++)    // BubbleSort

隣接してる数値を比較するとき、詩以後のやつが残るときは、手動で対応するしかない

int i = 0;
for (i = 0; i < arr.length - 1; i++) {
    if (arr[i] == arr[i + 1]) {
        n++;
        doubledFlag = true;
    } else {
        if (doubledFlag) {
            temp[i - n] = new DupCount(arr[i - n], n);
            doubledFlag = false;
        }
        n = 0;
    }
}

/* 手動で*/
if (doubledFlag) {
    temp[i] = new DupCount(arr[i - n], n);
    doubledFlag = false;
}

ArrayListとかのデータ型にすると、ロジックが大いに簡潔になるところを見て、やはりAPIを知ることの大事さを改めて思い知らされた

再帰

Tue, 24 Mar 2026 00:00:00 +0000

再帰

再帰
- ベースケース
  - 再帰が止まる条件
- 再帰呼び出し
  - ベースケースに当てはまるまでずっと繰り返して自信を呼び出す

再帰を用いたデータ仕組み

スタックフレーム - CallStackにはいくつかのスタックフレームがある - そのスタックフレームも再帰を用いた仕組み

実装ーfactorial

最初に実装したFactorial
グローバル変数が必要

public static int factorial(int n) {
    a = a * n;
    if (n > 1) {
        factorial(n - 1);
    }

    return a;
} 

AIに上のコードを投げて得られたものだけど、かなり違いがあってどこでこのようなロジックの違いが起こったのか考えてみた
- グローバル変数が必要ではない関数に書き換える
- 数学的には F(n) = n * F(n-1)なので、戻り値も左のような形になる
  - そこでベースケースまで考えが及ばなかった
  - そもそもベースケースの定義を間違っていて、停止じゃなくて、持続の条件として使っていた
- factorial(0)が０ではないことを認識していなかった
  - 例えば、factorial(6)は 6 x 5 x 4 x 3 x 2 x 1 x factorial(0)になる
  - factorial(0)で停止するので、 0 x fatorial(-1)じゃなくて、１をリターンする

public static int factorial(int n) {
    if (n  < 1) {
        return 1;
    }
    return n * factorial(n - 1);
}

ただ、 n < 1 よりは n - 1 < 0がより理解しやすくてその部分だけ変更した

public static int factorial(int n) {
    if (n - 1  < 0) {
        return 1;
    }
    return n * factorial(n - 1);
}

go lang version
nが1未満よりは０になった時がもっと理解しやすいと思い、書き換えた

func Factorial(n int) int {
	if n-1 < 0 {
		return 1
	}

	return n * Factorial(n-1)
}

実装ーfibonacchi数列再帰

ベースケースの重要性を感じてからは、ちゃんとベースケースを定義することになった
最初にひねり出して書いたFibonacci数列関数

public static int fibonacci(int a, int b) {
    if (a + b >= 5) {
        return a + b;
    }
    return fibonacci(b, a + b);
}

わかりしやすくするため、変数名を書き換える
問題は、ベースケースがFibonacciのN番目の値をわかることが前提なので、相当活用しにくい

public static int fibonacci(int small, int big, int limit) {
    if (small + big >= limit) {
        return small + big;
    }
    return fibonacci(big, small + big);
}

で、ChatGptに質問投げて受け取ったコードは全然違ってて分析した
ChatGptはFibonacci数列を何番進めるかを着目してソースコードを書いてくれた
ベースケースが分かりやすいと思った
考えてみれば、どんな戻り値の形が必要なのかをまず決めてからベースケースを決めたらいいかもと思った

public static int fib(int n) {
    // base case
    if (n <= 1) {
        return n;
    }

    // recursive case
    return fib(n - 1) + fib(n - 2);
}

ただ、私としてはベースケースが理解しにくかった
結局全てのfibonacciメソッドはfibonacci(0)とfibonacci(1)に分解されるので、こうやって変換したら、ロジックが理解できた
- Fibonacci(1)の分を足したら、それがFionbacci数列になる
- リターンの再帰関数が(n-1)と(n-2)というパラメータになってるので、0とか1をケースしたら、無限繰り返しになるのではないかと最間違えた
- しかし、結局EarlyReturnになるので、全然そんな心配は無用だった

public int fibonacci(int n) {
	switch(n) {
        case 0:
            return 0
        case 1:
            return 1
	}

	return fibonacci(n-1) + fibonacci(n-2)
}

go lang

func Fibonacci(n int) int {
	switch n {
	case 0:
		return 0
	case 1:
		return 1
	}

	return Fibonacci(n-1) + Fibonacci(n-2)
}

上はFibonnaciの演算のカウント分をパラメータとして受け取ってる
パラメータの数字に当たる位置を探すための関数はどうすればいいか思った結果、あっけなく答えが出た
その位置の結果値は演算を１回少なくしただけなので、以下のようになる

func FibonacciLocation(n int) int {
    Fibonacci(n - 1);
}

実装ー文字列反転させる

これを再帰にする

public static String recursiveReverseString(String abc, StringBuilder reverse, int n) {
    reverse.append(abc.charAt(abc.length() - 1 - n));
    if (n == abc.length() - 1) {
        return reverse.toString();
    }
    return recursiveReverseString(abc, reverse, n + 1);
}

golangにはポインターがあるので、Structはポインターを使って渡す
そうしないと、共有されない全部各自のSbが生成されるので、ロジックが壊れる

var sb strings.Builder
sb.Grow(len("abcd"))
fmt.Println(recall.ReverseStringNoCreate("abcd", &sb, len("abcd")))

func ReverseStringNoCreate(s string, sb *strings.Builder, n int) string {
	if n-1 < 0 {
		return sb.String()
	}

	sb.WriteByte(s[n-1])

	return ReverseStringNoCreate(s, sb, n-1)
}

実装ー列配列の合計

再帰でもFor文と同じく総合の計算ができる

public static int sumArray(int[] arr, int n) {
    if ( n < 0) {
        return 0;
    }
    
    return arr[n] + sumArray(arr, n - 1);
}

golangではベースケースの条件に変化を与えた
実装方法によってカウントとかは違くなる

func SumArray(arr []int, n int) int {
	if n > len(arr)-1 {
		return 0
	}

	return arr[n] + SumArray(arr, n+1)
}

実装ーJsonParserクラス作成

最大の深さを理解するための一番いい例として、JSON structures parsingがある
以下のJsonデータをparsingするとき、再帰が必要になる。

{
  "a": {
    "b": {
      "c": [1,2,3,4],
      "d":"2",
      "e":false
    }
  }
}

どうしてもJSONのパースは自分の頭ではうまく理解できなかった
- 私は全てのJSON形式が必ずキーを持っていると思い込んでいた
- で、キーとバリューのどう分けるのか、どうしてもピンとこなかった
- 空白や特殊記号をどう処理すればいいのか、どうしてもピンとこなかった
- 多様なデータ型をどうすればいいのか、どうしてもピンとこなかった
なので、ChatGPTに聞いて以下のように進めた
- 1番目は分析
- 2番目はChatGPTのコードをそのまま手でなぞる
- 3番目は見ずに自分で打ち込む
メインポイントは以下だった
- データ型に分ける
- 空白や特殊記号はスキップする
まずは以下のようにNodeタイプ仕組みを作成する
JsonはObject,Value,Array３つがあるので、その３つのタイプを統一させるための抽象クラスが必要

public abstract class Node {

}

class ObjectNode extends Node {
    Map<String, Node> map = new HashMap<>();
}

class ArrayNode extends Node {
    List<Node> list = new ArrayList<>();
}

class ValueNode extends Node {
    Object value;
    ValueNode(Object value) { this.value = value; }
}

次は実際のパースを実装する
以下で直接再帰が起こるわけではなくて、parseValue()で起こる
空白を取り除くためparseValue()じゃなくて、parse()にして一緒に呼んでる形だ
実は parse()のところのskipWhitespace()は不要だけど、防御的プログラミングのために残す
- 誰かparseValue()のロジックがskipWhitespace()が削られたとき正常な動作を確保できる
- パースの前はいつも空白をトリムすることを明示する仕組み

class MiniJsonParser {

    private final String json;
    private int index = 0;

    public MiniJsonParser(String json) {
        this.json = json;
    }

    public Node parse() {
        skipWhitespace();
        return parseValue();
    }
}

parseValue()は読み込んだ文字列に応じて切り分けて処理される
peek()は現在のインデックスの文字を持ってくるメソッドだ
parseKey()が別にない理由はキーはオブジェクトにしかないためだ

private Node parseValue() {
    skipWhitespace();
    char c = peek();

    if (c == '{')
        return parseObject();
    if (c == '[')
        return parseArray();
    if (c == '"')
        return new ValueNode(parseString());
    if (c == '-' || Character.isDigit(c))
        return new ValueNode(parseNumber());
    if (match("true"))
        return new ValueNode(true);
    if (match("false"))
        return new ValueNode(false);
    if (match("null"))
        return new ValueNode(null);

    throw new RuntimeException("Unexpected char: " + c);
}

consume()は該当の文字はスキップするメソッドだ
- javaオブジェクトとしては｛、：、, などの特殊記号は必要でないので素通りする
  - Jsonオブジェクトの場合、mapは put()が結果値を追加する行動
  - Json配列の場合、listは add()が結果値を追加する行動
  - Json文字列は append()結果値を追加する行動
  - Json数値は負数と小数に切り分ける

private Node parseObject() {
    ObjectNode obj = new ObjectNode();
    consume('{');
    skipWhitespace();

    //ベースケース
    if (peek() == '}') {
        consume('}');
        return obj;
    }

    while (true) {
        // キーをパース
        String key = parseString();
        skipWhitespace();
        consume(':');

        // 再帰
        Node value = parseValue();

        obj.map.put(key, value);

        skipWhitespace();
        if (peek() == '}') {
            consume('}');
            break;
        }
        consume(',');
    }

    return obj;
}

private Node parseArray() {
    ArrayNode arr = new ArrayNode();
    consume('[');
    skipWhitespace();

    //ベースケース
    if (peek() == ']') {
        consume(']');
        return arr;
    }

    while (true) {
        // 再帰
        Node value = parseValue();
        arr.list.add(value);

        skipWhitespace();
        if (peek() == ']') {
            consume(']');
            break;
        }
        consume(',');
    }

    return arr;
}

private String parseString() {
    consume('"');
    StringBuilder sb = new StringBuilder();

    while (peek() != '"') {
        sb.append(next());
    }

    consume('"');
    return sb.toString();
}

private Double parseNumber() {
    int start = index;

    if (peek() == '-')
        next();

    while (Character.isDigit(peek()))
        next();

    if (peek() == '.') {
        next();
        while (Character.isDigit(peek()))
            next();
    }

    return Double.parseDouble(json.substring(start, index));
}

便宜機能メソッド
主に文字列を読み込んでどう処理するかについてのメソッド
- インデックスを軸に処理してる姿が見える

private char peek() {
    return json.charAt(index);
}

private char next() {
    return json.charAt(index++);
}

private void consume(char expected) {
    if (peek() != expected) {
        throw new RuntimeException("Expected " + expected);
    }
    index++;
}

private void skipWhitespace() {
    while (index < json.length() && Character.isWhitespace(peek())) {
        index++;
    }
}

private boolean match(String keyword) {
    if (json.startsWith(keyword, index)) {
        index += keyword.length();
        return true;
    }
    return false;
}

これをJavaオブジェクトとして変換するためにも再帰が必要

public class ToJavaObject {

    public static Object toJavaObject(Node node) {
        if (node instanceof ValueNode) {
            return ((ValueNode) node).value;
        }

        if (node instanceof ObjectNode) {
            Map<String, Object> map = new HashMap<>();
            ObjectNode obj = (ObjectNode) node;

            for (Map.Entry<String, Node> entry : obj.map.entrySet()) {
                // 再帰
                map.put(entry.getKey(), toJavaObject(entry.getValue()));
            }

            return map;
        }

        if (node instanceof ArrayNode) {
            List<Object> list = new ArrayList<>();
            ArrayNode arr = (ArrayNode) node;

            for (Node n : arr.list) {
                // 再帰
                list.add(toJavaObject(n));
            }

            return list;
        }

        throw new RuntimeException("Unknown node type");
    }

}

深く探求ーStringとStringBuilder

Stringの＋演算は新しいStringBufferを作ることになる
内部的には以下のようにソースコードが変換される

reverse += str.charAt(i);

//
reverse = new StringBuilder(reverse)
              .append(str.charAt(i))
              .toString();

そのため、新しいStringBufferは以前のStringBufferをコピーすること＋追加する演算が必要
1回づつ演算回数が増えるので、最終的に１＋２＋…＋ｎになる

"abcd"


Iteration 1
    copy: 0 chars  X
    append: 1 char --->a
    → total work ≈ 1
Iteration 2
    copy: 1 char   --->a
    append: 1 char --->+b
    → total work ≈ 2
Iteration 3
    copy: 2 chars  --->ab
    append: 1 char --->+c
    → total work ≈ 3
Iteration 4
    copy: n-1 chars --->abc
    append: 1 char  --->+d
    → total work ≈ 4
    .
    .
    .
Iteration n
    copy: n-1 chars --->n-1 count char
    append: 1 char  ---> + nth char
    → total work ≈ n

できれば、Stringには＋の演算はしないほうがいい

public static String recursiveReverseString(String abc, StringBuilder reverse) {
    reverse.append(abc.charAt(abc.length() - 1 - n));
    if (n == abc.length()) {
        return reverse.toString();
    }
    return recursiveReverseString(abc, reverse);
}

ただ、上にもまだ問題は残っている
StringBuilderはサイズを超えるとオブジェクトのコピペのプロセスが走る
Resizingが走ってもまだ時間計算量は O(n)ではあるが、不要な動作が入ってくしまうので、効率が悪くなる
そのため、サイズをわかったら指定したほうがいい

StringBuilder str = new StringBuilder("abcdefg".length());

それはGolangも同じなので、初期容量を指定する

var sb strings.Builder
sb.Grow(len("abcd"))

深く探求ー絵文字を含めた文字列

文字列反転させるで紹介したメソッドは絵文字などがあるとロジックが壊れる
javaも絵文字を鑑みてappendCodePointメソッドを使うことにする

String s = "😊a";

int[] codePoints = s.codePoints().toArray();

StringBuilder sb = new StringBuilder();
for (int i = codePoints.length - 1; i >= 0; i--) {
    sb.appendCodePoint(codePoints[i]);
}

System.out.println(sb.toString());

ここは、Unicode code pointという概念をしっかり押さえていく必要がある

Character	Code point
`A`	U+0041
`a`	U+0061
`あ`	U+3042
`😊`	U+1F60A

Javaでも Unicode code pointを使ったように、Goでも使う
runeがそのデータ型で、内部は int32である

func ReverseString(s string) string {
	runes := []rune(s)
	for i, j := 0, len(runes)-1; i < j; i, j = i+1, j-1 {
		runes[i], runes[j] = runes[j], runes[i]
	}
	return string(runes)
}

深く探求ーSQLの再帰

典型的な例　ー＞ SQL 深さによる探索
最初のアドレスと最新のアドレスを探すことにしたら、再帰が必要

name            |pcode          |new_pcode(次のアドレス)
A               |20184          |20143
A               |20143          |20155
A               |20155          |

以下はMYSQLで使えるSQL

WITH RECURSIVE Explosion(name, pcode, new_pcode, depth)
AS
(
    SELECT name,pcode,new_pcode,1　                                /* depthは再帰カウンタ*/
    FROM AddressHistory
    Where name = 'A'
    AND new_code IS NULL　　　　　　                                /* 最初の検索スタート条件*/

    UNION ALL                                                   　 /* 結果を積み重ねる*/

    SELECT Child.name, Child.pcode, Child.new_pcode, depth + 1     /* 次の関数を呼び出す再帰処理 */
    FROM Explosion AS Parent, AddressHistory AS Child
    WHERE Parent.pcode = Child.new_pcode
    AND Parent.name = Child.name
)

SELECT name, pcode, new_pcode
FROM Explosion
WHERE depth = (SELECT MAX(depth) FROM Explosion);

結果値は以下

name        |pcode       |new_pcode
A           |20184       |20143

oracle version.

WITH Explosion(name, pcode, new_pcode, depth)
AS
(
    SELECT name,pcode,new_pcode,1 /* depthは再帰カウンタ*/
    FROM AddressHistory
    Where name = 'A'
    AND new_code IS NULL /* 最初の検索スタート条件*/

    UNION ALL   /* 結果を積み重ねる*/

    SELECT Child.name, Child.pcode, Child.new_pcode, depth + 1   /* 次の関数を呼び出す再帰処理 */
    FROM Explosion AS Parent
    Inner JOIN AddressHistory AS Child
    on Parent.pcode = Child.new_pcode
    AND Parent.name = Child.name 
)

SELECT name, pcode, new_pcode
FROM Explosion
WHERE depth = (SELECT MAX(depth) FROM Explosion);

振り返り

ベースケース以外のところであるリターン文はベースケースでは気にしなくていい
ベースケースに達すると、処理が打ち切られて値が返るからだ

func Factorial(n int) int {
	if n-1 < 0 {
		return 1
	}

	return n * Factorial(n-1)
}

再帰による結果値を追加する形が必ず必要

func SumArray(arr []int, n int) int {
	if n > len(arr)-1 {
		return 0
	}

	return arr[n] + SumArray(arr, n+1)
}

しかし、それがかならずしもリターン文の以内である必要はない

public static String recursiveReverseString(String abc, StringBuilder reverse) {
    reverse.append(abc.charAt(abc.length() - 1 - n));
    if (n == abc.length()) {
        return reverse.toString();
    }
    return recursiveReverseString(abc, reverse);
}

ベースケースがよく思いつかないとしたら、数字を左に移動させてからもう一度考える

public static int factorial(int n) {
    if (n - 1  < 0) { // n < 0 より理解しやすい
        return 1;
    }
    return n * factorial(n - 1);
}

選択ソート

Wed, 18 Mar 2026 00:00:00 +0000

時間計算量

時間計算量
- コンピュータが問題を解く際、入力データ量の増加に対して、必要な処理のステップ数（計算や操作回数）がどう変化するかを指し示す。
- O(1), O(n), O(nlogn), O(ｎ２)などがあり、Ｏ(1)が一番効率高い。例は以下のよう。
  - 配列のアクセス
  - for文
  - Quickソート
  - 選択ソート、ダブルFor文

選択ソート

選択ソート
- 未整列のデータ列から最小値（または最大値）を毎回選択し、整列済みの列の末尾に移動させる単純な並べ替えアルゴリズム

実装ー最大の値を探索

最大の値を探索
- 最大値を想定すること。
- スターポイントのための１個目のFor文
- 比較のための２個目のFor文
ダブルFor文なので、O（ｎ２）になる

int[] abc = { 0, 1, 7, 2, 13, 15, 6 };
int max = abc[0];
for (int i = 0; i < abc.length; i++) {
    for (int j = 1 + i; j < abc.length; j++) {
        if (max <= abc[j]) {
            max = abc[j];
        }
    }
}

go langではJavaと宣言とか、データ型を決める方法が違う
- 関数も大文字にする必要がある。
- パラメータも Arrayじゃなくて、Sliceタイプを使うようになる

func FindMaxValue(arr []int) int {
	max := arr[0]
	for i := range arr {
		for j := i + 1; j < len(arr); j++ {
			if max < arr[j] {
				max = arr[j]
			}
		}
	}
	return max
}

実装ー最小値を探索

最小限の値を探索
上と同じ。ただ以上の方向が変わっただけ

int[] abc = { 3, 1, 7, 2, 13, 15, 6 };
int min = abc[0];
for (int i = 0; i < abc.length; i++) {
    for (int j = 1 + i; j < abc.length; j++) {
        if (min >= abc[j]) {
            min = abc[j];
        }
    }
}

go lang

func FindMinValue(arr []int) int {
	min := arr[0]
	for i := range arr {
		for j := 1 + i; j < len(arr); j++ {
			if min > arr[j] {
				min = arr[j]
			}
		}
	}

	return min
}

実装ー配列を反転させる

配列を反転させることではSwappingの技術が必要
- SwappingはJavaではTemp変数が必要
- 要素にアクセスするためには、要素 - 1が必要。
- そこで i を引く理由は後半から逆に行きながらSwappingするからだ
時間計算量は n/2なので O(n)になる
- n / 2になる理由は前半だけを見て後半と比較すると後半の要素はループが不要

int[] abc = {0,1,7,2,4,13,6};
for(int i = 0; i < abc.length / 2; i++) {
    int temp = abc[i];
    abc[i] = abc[abc.length - 1 -i];
    abc[abc.length - 1 -i] = temp;
}

func ReverseArray(arr []int) {
	for i := 0; i < len(arr)/2; i++ {
		arr[i], arr[len(arr)-1-i] = arr[len(arr)-1-i], arr[i]
	}
}

ただ、不変性が重要なので、不変性を担保するために、新しいオブジェクトを返すことにする
今回はプリミティブ型なので、Cloneでも問題はないが、参照型としたら、シャローコピーになってしまう。
ディープコピーにするためにはFor文でループしながら１つづつコピーするしかない

public int[] returnReversedArray(int[] arr) {
    int newArr = arr.clone();
    for(int i = 0; i < newArr.length / 2; i++) {
        int temp = newArr[i];
        newArr[i] = newArr[newArr.length - 1 -i];
        newArr[newArr.length - 1 -i] = temp;
    }
}   

Integer[] newArr = new Integer[arr.length];
for (int i = 0; i < arr.length; i++) {
    newArr[i] = arr[i].clone(); //オブジェクトの時
}

プリミティブ型はただのシャロ―コピーもディープコピーと同じ効果が現れる
makeはJavaに例えれば、newと同じ
Copyは以下のFor文と同じ効果

func ReturnNewReverseArray(arr []int) []int {
	newArray := arr //ーーー＞シャロ―コピー

    newArray := make([]int, len(arr)) //ーーー＞ディープコピー
    copy(newArray, arr)
    /*for i := range arr {
        newArray[i] = arr[i]
    }*/

	for i := 0; i < len(newArray)/2; i++ {
		newArray[i], newArray[len(arr)-1-i] = newArray[len(newArray)-1-i], newArray[i]
	}

	return newArray
}

実装ー選択ソート昇順

選択ソート昇順
If文で比較の対象が abc[i] じゃなくて、abc[minValueIdx]になる理由は、実際に最小値を見つけたとき、minValueIdxが変わるからだ

public static void main(String[] args) throws Exception {
    int[] abc = { 3, 1, 7, 2, 13, 15, 6 };
    int minValueIdx = abc[0];
    for (int i = 0; i < abc.length; i++) {
        for (int j = 1 + i; j < abc.length; j++) {
            if (abc[minValueIdx] > abc[j]) {
                minValueIdx = j;
            }
        }

        int temp = abc[i];
        abc[i] = abc[minValueIdx];
        abc[minValueIdx] = temp;
    }
}

実装ー選択ソート降順

選択ソート降順
if文の方向だけ変えればいい

public static void main(String[] args) throws Exception {
    int[] abc = { 3, 1, 7, 2, 13, 15, 6 };
    int maxValueIdx = abc[0];
    for (int i = 0; i < abc.length; i++) {
        for (int j = 1 + i; j < abc.length; j++) {
            if (abc[maxValueIdx] <= abc[j]) {
                maxValueIdx = j;
            }
        }

        int temp = abc[i];
        abc[i] = abc[maxValueIdx];
        abc[maxValueIdx] = temp;
    }
}

不変性を担保するため、新しい配列を返す

public static void main(String[] args) throws Exception {
    int[] abc = { 3, 1, 7, 2, 13, 15, 6 };
    int[] sortedArray = abc.clone();

    int maxValueIdx = sortedArray[0];
    for (int i = 0; i < sortedArray.length; i++) {
        for (int j = 1 + i; j < sortedArray.length; j++) {
            if (sortedArray[maxValueIdx] <= sortedArray[j]) {
                maxValueIdx = j;
            }
        }

        int temp = sortedArray[i];
        sortedArray[i] = sortedArray[maxValueIdx];
        sortedArray[maxValueIdx] = temp;
    }
    
    System.out.println(Arrays.toString(sortedArray));
}

go lang

func SelectionSort(arr []int) []int {
	maxIndex := 0
	newArr := make([]int, len(arr))
	copy(newArr, arr)

	for i := range newArr {
		for j := i + 1; j < len(newArr); j++ {
			if newArr[maxIndex] < newArr[j] {
				maxIndex = j
			}
		}

		newArr[i], newArr[maxIndex] = newArr[maxIndex], newArr[i]
	}

	return newArr
}

深く探求ー文字列を反転させる

１週目は数字を反転させた
今回は文字列だが、回帰と違いを理解するために、For文で書く
文字列　ー＞配列列の場合

public static StringBuilder reverseStr(String str) {
    StringBuilder reverse = new StringBuilder();
    for (int i = str.length() - 1; i >= 0; i--) {
        reverse.append(str.charAt(i));
    } 
    return reverse;
}

数字を反転させる方法と同じく、半分だけ見ればいいので、StringBuilderを利用したほうよりはパフォーマンスが高い
- method callがない
- リサイジングがない
- インデックスが有効なのかチェックが走らない
時間計算量は以下になる
- toCharArray()にコピー　-> O(n)
- swap ループ -> O(n/2)
- new String(arr) -> 再びコピー O(n)

public static String reverse(String s) {
    char[] arr = s.toCharArray();
    for (int i = 0; i < arr.length / 2; i++) {
        char temp = arr[i];
        arr[i] = arr[arr.length - 1 - i];
        arr[arr.length - 1 - i] = temp;
    }
    return new String(arr);
}

JAVA apiは以下のようだ
実は以下が一番パフォーマンスが高いと認められる
時間計算量は以下になる
- StringBuilder()にコピー -> O(n)
- swap ループ -> O(n/2)
- new String(arr) -> 再びコピー O(n)
配列を手動でいじる時と時間計算量は変わらない
- しかし、JVMのレベルでの最適化を踏まえると、JAVAのAPIを使ったほうがいい

public static void main(String[] args) {
    char[] newArray = { 'a', 'b', 'c', 'd', 'e', 'f' };

    String reversed = new StringBuilder()
            .append(newArray)
            .reverse()
            .toString();
}

以下がJAVAのAPIであるStringBuilderのreverseメソッドの実装部だ
文字列に関して、文字列は必ず負数であるため、(n-1) » 1 は (n-1) / 2 と同じだ
ただ、CPU単位で踏まえると、効率が違う
- 　» 1 はCPUの観点ですごく簡潔な１つの命令
  - ただの移動だけで済む
- / 2 はすごく難しい１つの命令
  - 商を計算する
  - 余りを計算する
  - 負の数を正しく処理する
  - オーバーフローを回避する
現代JVMはそういった部分で最適化をしてくれる可能性が高いが、昔はそうでなかったので、まだああいう書き方が残っている

public AbstractStringBuilder reverse() {
        byte[] val = this.value;
        int count = this.count;
        int n = count - 1;
        if (isLatin1()) {
            for (int j = (n-1) >> 1; j >= 0; j--) {
                int k = n - j;
                byte cj = val[j];
                val[j] = val[k];
                val[k] = cj;
            }
        } else {
            StringUTF16.reverse(val, count);
        }
        return this;
    }

go lang
JavaはUTFー16に文字列を保存しているので、charAt()を使ったら、自動的にByte単位で計算してそのインデックスの文字列を引っ張てくる
go langにはそんなのがないので、Byte単位で全部変換する
0 ~ 255からが１Byteの範囲であるので、その中で文字ことに決まった数字があるので、１Byteの中で97が入ってきたら、それは ‘a’に変換される
同じく２Byteは１６Bitなので、２の16乗ー１まで数字を格納する

func ReverseString1(s string) string {
	strbuilder := strings.Builder{}
	for i := len(s) - 1; i >= 0; i-- {
		strbuilder.WriteByte(s[i])
	}
	return strbuilder.String()
}

振り返り

ダブルFor文でｊの値をどう設定していけばいいのかわかなかった

//最初
for (int i = 0; i < abc.length; i++) {
    for (int j = 1/*ここどうすればいい？ */; j < abc.length; j++) {

    }
}

//AI参考
for (int i = 0; i < abc.length; i++) {
    for (int j = 1 + i; j < abc.length; j++) {

    }
}

位置を入れ替えるためには、Indexが必要だったのにそれに気づかなかった

//最初
int maxValue = sortedArray[0];
for (int i = 0; i < sortedArray.length; i++) {
    for (int j = 1 + i; j < sortedArray.length; j++) {
        if (sortedArray[maxValueIdx] <= sortedArray[j]) {
            maxValue = sortedArray[j];
        }
    }
}

//AI参考
int maxValueIdx = sortedArray[0];
for (int i = 0; i < sortedArray.length; i++) {
    for (int j = 1 + i; j < sortedArray.length; j++) {
        if (sortedArray[maxValueIdx] <= sortedArray[j]) {
            maxValueIdx = j;
        }
    }

recipe-community-project

Mon, 21 Apr 2025 00:00:00 +0000

GITガイダンス作成

GITを使うことが初めてだった人が多かったため、GITの使用説明書を作成しました。
ステージングエリア、ローカルリポジトリ、リモートリポジトリ、ブランチなどの基本的な概念からGITコマンドまで必要なことを教わりました。
それを見ながら練習できるようにさせるため、シナリオも作りました。

リモートリポジトリローカルにコピーする：git clone

ファイル作成: untracked
Gitリポジトリの状態を確認する: git status
ステージングに追加する: git add 
ローカルリポジトリに変更を確定する: git commit
コミット履歴を確認: git log
確定した変更をリモートリポジトリに送信: git push

ブランチを作る: git switch -C [branch name]
ファイル修正: changed
ステージングに追加する: git add 
ローカルリポジトリに変更を確定する: git commit（コミット）
確定した変更をリモートリポジトリに送信: git push（プッシュ）

ブランチお互いに融合する: pull request(プルリクエスト)

リモートリポジトリの変更をローカルに同期する: git pull
ファイル修正: changed
ファイルの変更を元に戻す: git restore
ファイル修正: changed
途中の作業を一時的に保存する: git stash

GIT戦略

GITの初心者がいるため、管理戦略に関しては簡単な戦略、トランクベース開発戦略にしました。 -DEVブランチを設けず、FEATUREブランチから直接MAINブランチにマージする戦略を採用していました。
- 複雑性を下げて実務を体験することができると思いました。
チーム全体で、こまめにプルリクエストを出すよう心がけました。
- ブランチの統合が遅れると、Gitのコンフリクトが増え、解決が困難になるためです。
- それと朝着いた直後、昼ご飯食べてIT授業が始まったばかりで、授業が全部終わる30分前最、つまり小限3回はプルリクエストするようにしました。
- その結果、大きなコンフリクトが発生しなかったと思います。

JavaScriptクロージャの使用例①

以前の派遣プロジェクトでクロージャを作りましたが、難しいと拒否されたことがあります。
今回はグローバル変数を使わないでクロージャを使おうと思いました。
グローバル変数を使用すると、開発者ツールで値を改ざんされ、バリデーションロジックを迂回してサーバーに送信される恐れがありました。
一方、ローカル変数であればそのような心配がないため、より安全性の高い実装が可能になります。
多重クリックができないようにするため、サーバーからレスポンスを受け取ってからクリックできるようにしました。
- そのためFINALLY文でisClicked変数を初期化します。
- 多重クリックが発生すると、同じデータが重複して登録され、データの整合性が損なわれる恐れがあります。

function createToggleBookmark() {
    let isClicked = false; 

    return async function toggleBookmark() {

        if (isClicked) {
           .
           .
           .
        }


        isClicked = true; 

        const data = {
            title,
            recipeCondition: { usage, menu, taste, level },
            outputContent,
            nonce
        };

        try {
            const response = await fetch('/recipe/history/save', {
                headers: { 'Content-Type': 'application/json' },
                body: JSON.stringify(data),
                method: 'POST'
            });
        .
        .
        .

        } catch (error) {
            console.error("Error:", error);
        } finally {
            isClicked = false;
        }
    };
}

サーバーでデータの登録が完了したら、同じデータを重複して登録してはいけません。
登録が成功した場合、そのデータの主キー（ID）を返します。
オートインクリメントを使用しているため、最初に登録されたデータの主キーは 1 から始まり、0 ではありません。
そのため、キャプチャ変数には初期値として 0 を設定します。登録が完了するとその値は 0 ではなくなるため、0 でない場合はすでに登録されていると判断できます。

JavaScriptクロージャの使用例②

function createToggleBookmark() {
    let isClicked = false; 
    let recipeSeq = 0; 

    return async function toggleBookmark() {

        if (isClicked) {
            alert("もうクリックしました")
            return;
        }

        if (recipeSeq !== 0) {
            alert("もう保存されたデータです")
            return;
        }


        isClicked = true; 

        const data = {
            title,
            recipeCondition: { usage, menu, taste, level },
            outputContent,
            nonce
        };

        try {
            const response = await fetch('/recipe/history/save', {
                headers: { 'Content-Type': 'application/json' },
                body: JSON.stringify(data),
                method: 'POST'
            });
        .
        .
        .

        recipeSeq = await response.json();

        } catch (error) {
            console.error("Error:", error);
        } finally {
            isClicked = false;
        }
    };
}

//実行コンテキストを形成する
const toggleBookmark = createToggleBookmark();
document.querySelector('.bookmark-btn').addEventListener('click', toggleBookmark);

JavaScriptクロージャの使用例③

他の関数でキャプチャされた変数も、getterのような関数を通じて別の関数から参照できます。

const createPasswordChecker = () => {
    let isPasswordCorrect = false;

    async function checkPw() {
        try {
            const response = await fetch("/mypage/checkPassword", {
                method: "POST",
                headers: { "Content-Type": "application/json" },
                body: JSON.stringify({ currentPassword: password.value })
            });
            const data = await response.json();
            isPasswordCorrect = data;

            validateForm();

            return isPasswordCorrect;
        } catch (error) {
            console.error("Error:", error);
            return false;
        }
    }

    const debouncedCheckPw = debounce(checkPw, 300);

    function isPasswordValid() {
        return isPasswordCorrect;
    }

    return { checkPw: debouncedCheckPw, isPasswordValid };
};

password.addEventListener("keyup", async () => {
    await passwordChecker.checkPw();
});

実行コンテキストを作ってからgetterのような関数を通じて参照した例です。

function validateForm() {
    const isNickNameValid = nickName.value.trim().length >= 2 && nickName.value.trim().length <= 11;
    const isNewPwValid = newPW.value.length >= 8 && newPW.value === newPWCheck.value;

    const nickNameLengthMessage = document.getElementById("nickNameLengthMessage");
    nickNameLengthMessage.style.display = isNickNameValid ? "none" : "block";

    if (newPasswordSection.style.display === "none") {
        changeInfoBtn.disabled = !(passwordChecker.isPasswordValid() && isNickNameValid);
    } else {
        changeInfoBtn.disabled = !(isNickNameValid && isNewPwValid);
    }

    changePwBtn.disabled = !(passwordChecker.isPasswordValid() && isNickNameValid);
}

const passwordChecker = createPasswordChecker();

最適化：凝集性

サービスクラスにif文を作るよりentityやDTOで直接メソッドを管理した方が良いです。
サービスクラスでif文で処理すると、そのif文が複数のクラスで使われた場合、変更する時、他のところにもそのようなif文があるか全部探していちいち修正する必要があります。

if (!boardDTO.getThumbnailUrl() != null && !boardDTO.getThumbnailUrl().isEmpty()) {
    return;
}

String thumbnailUrl = boardDTO.getThumbnailUrl();
String savedFileName = "";
if (thumbnailUrl.startsWith("/uploads/")) {
    savedFileName = thumbnailUrl.substring(9);
}

凝集性があるように、つまり、一つのクラスだけを修正すれば他のクラスでも全部適用されるようにクラスのメソッドにします。

public class BoardDTO {
    .
    .
    .
    
    public boolean isThumbnailUrlEmpty() {
        return StringUtils.hasText(this.thumbnailUrl);
    }

    public boolean isUploadedInCurrentBoard() {
        return this.thumbnailUrl.startsWith("/uploads/");
    }
}

クラスに入れたメソッドなら一括で適用されるので運用保守が便利になります。
BoardInsertServiceクラスやBoardUpdateServiceクラスを修正しなくて一つのBoardDTOだけ修正することで十分です。

public class BoardInsertService {

    public void insertBoard(BoardDTO boardDTO) {
        .
        .
        if (boardDTO.isThumbnailUrlEmpty()) {
            return;
        }

        .
        .
        String thumbnailUrl = boardDTO.getThumbnailUrl();
        String savedFileName = "";
        if (boardDTO.isUploadedInCurrentBoard()) {
            savedFileName = thumbnailUrl.substring(9);
        }
        
        .
        .

    }
    
}

public class BoardUpdateService {

    public void updateBoard(BoardDTO boardDTO) {
        .
        .
        if (boardDTO.isThumbnailUrlEmpty()) {
            return;
        }

        .
        .
        String thumbnailUrl = boardDTO.getThumbnailUrl();
        String savedFileName = "";
        if (boardDTO.isUploadedInCurrentBoard()) {
            savedFileName = thumbnailUrl.substring(9);
        }

        .
        .
    }
}

最適化：可読性向上

最初はコードの作成に集中したので読み取りにくい状態でした。

function insertImageToQuill(file, base64Data, fileUrl) {
	let range = quill.getSelection();
	let insertIndex = range ? range.index : quill.getLength();
	quill.insertEmbed(insertIndex, 'image', base64Data);
	quill.setSelection(insertIndex + 1);

	let fileKey = file.name + file.size;
	uploadedFiles.set(fileKey, { file: file, base64: base64Data, url: fileUrl });

	file.previewElement.classList.add('dz-complete');

	let thumbnailLabel = document.createElement('div');
	thumbnailLabel.classList.add('thumbnail-label');
	thumbnailLabel.textContent = 'サムネイルとして指定する';
	thumbnailLabel.style.display = 'none';
	file.previewElement.insertBefore(thumbnailLabel, file.previewElement.firstChild);

	file.previewElement.addEventListener('click', function (e) {
		if (e.target.classList.contains('dz-remove')) return;
		document.querySelectorAll('.dz-preview').forEach(function (preview) {
			preview.classList.remove('thumbnail-selected');
			let label = preview.querySelector('.thumbnail-label');
			if (label) { label.style.display = 'none'; }
		});
		file.previewElement.classList.add('thumbnail-selected');
		thumbnailLabel.style.display = 'block';
		document.getElementById('thumbnail').value = base64Data;
		document.getElementById('thumbnailUrl').value = fileUrl;
		console.log('サムネイルとして指定する:', fileUrl);
	});
}

可読性を向上するため、段階を区切って段階ごとに注を付けて分かりやすくしました。

function insertImageToQuill(file, base64Data, fileUrl) {
	let range = quill.getSelection();
	let insertIndex = range ? range.index : quill.getLength();
	quill.insertEmbed(insertIndex, 'image', base64Data);
	quill.setSelection(insertIndex + 1);

	let fileKey = file.name + file.size;
	uploadedFiles.set(fileKey, { file: file, base64: base64Data, url: fileUrl });

	file.previewElement.classList.add('dz-complete');

    //サムネイル表示生成
	let thumbnailLabel = document.createElement('div');
	thumbnailLabel.classList.add('thumbnail-label');
	thumbnailLabel.textContent = 'サムネイルとして指定する';
	thumbnailLabel.style.display = 'none';
	file.previewElement.insertBefore(thumbnailLabel, file.previewElement.firstChild);

    //画像クリック時にサムネイルを更新するリスナー
	file.previewElement.addEventListener('click', function (e) {
		if (e.target.classList.contains('dz-remove')) return;

        //サムネイル変更
		document.querySelectorAll('.dz-preview').forEach(function (preview) {
			preview.classList.remove('thumbnail-selected');
			let label = preview.querySelector('.thumbnail-label');
			if (label) { label.style.display = 'none'; }
		});
		file.previewElement.classList.add('thumbnail-selected');
		thumbnailLabel.style.display = 'block';
		document.getElementById('thumbnail').value = base64Data;
		document.getElementById('thumbnailUrl').value = fileUrl;
		console.log('サムネイルとして指定する:', fileUrl);
	});
}

各段階を関数化し、関数名で処理の内容が分かるようにします。
コメントは更新されない場合があるからも関数化の理由の一つです。

function insertImageToQuill(file, base64) {
    let range = quill.getSelection();
    let insertIndex = range ? range.index : quill.getLength();
    quill.insertEmbed(insertIndex, 'image', base64);
    quill.setSelection(insertIndex + 1);

    let fileKey = file.name;
    uploadedFiles.set(fileKey, { file, base64 });

    file.previewElement.classList.add('dz-complete');

    const thumbnailLabel = generateThumbnailLabel(file);

    file.previewElement.addEventListener('click', function (e) {
        if (e.target.classList.contains('dz-remove')) {
            return;
        }
        updateThumbnailSelection(file, thumbnailLabel, base64);
    });
}

JavaScriptのファイルクラスではなく、Dropzoneクラスのファイルインスタンスが必要なです。
それを明確に表示するため、JSDOCを使用します。

/**
 * 
 * @param {File} file  Dropzoneのインスタンス。JavaScriptのFileとは別物
 * @param {HTMLElement} thumbnailLabel 
 * @param {base64String} base64 
 */
function updateThumbnailSelection(file, thumbnailLabel, base64) {

    //　サムネイル画像を切り替えるために、以前のサムネイル表示用のCSSをリセットします。
    document.querySelectorAll('.dz-preview').forEach(function (preview) {
        preview.classList.remove('thumbnail-selected');
        let label = preview.querySelector('.thumbnail-label');
        if (label) {
            label.style.display = 'none';
        }
    });

     //　新しく選択されたサムネイル画像を表示するために、対応するCSSを追加します。
     file.previewElement.classList.add('thumbnail-selected');
     thumbnailLabel.style.display = 'block';

     //　新しく指定されたサムネイル画像に対応するように、サーバーに送信するデータを更新します。　
    document.getElementById('thumbnail').value = base64;
    document.getElementById('thumbnailUrl').value = base64;
}

最適化：並行性制御

조회 수가 동시에 증가되지 않게끔 하는 로직이 필요했다.

public interface BoardRepository extends JpaRepository<BoardEntity, Long> {

    // 조회수(hitCount)만 증가시키는 update 쿼리 (update_date에는 영향을 주지 않음)
    @Modifying
    @Query("update BoardEntity b set b.hitCount = b.hitCount + 1 where b.boardSeq = :boardSeq")
    void incrementHitCount(@Param("boardSeq") Long boardSeq);
}

最適化：安全性

リプレイ攻撃やリロードによる無限保存を防ぐために、nonce値を導入しました。
まず、UUIDで生成した nonce をセッションに保存します。

@PostMapping("/recipe/chatGPT")
@ResponseBody
public void viewRecipeOutput(@RequestBody RecipeUserRequestDTO recipeUserRequestDTO, HttpSession session) {

    RecipeUserResponseDTO response = recipeService.getRecipeResponse(recipeUserRequestDTO);
    
    session.setAttribute("recipe", response);
    String newUUID = UUID.randomUUID().toString(); 
    session.setAttribute("nonce", newUUID);
}

モデルに格納して送ったnonceは、HTMLでhiddenフィールドとして保存されます。

<input type="hidden" th:value="${nonce}" name="nonce" id="nonce">
<input type="hidden" th:value="${recipe.recipeConditionDTO.usage}" name="usage" id="usage">
<input type="hidden" th:value="${recipe.recipeConditionDTO.menu}" name="menu" id="menu">
<input type="hidden" th:value="${recipe.recipeConditionDTO.taste}" name="taste" id="taste">
<input type="hidden" th:value="${recipe.recipeConditionDTO.level}" name="level" id="level">

保有しているnonce値をJavaScriptオブジェクトに設定し、サーバーに送信します。

 const title = document.querySelector(".recipe-title").textContent;
const outputContent = document.querySelector(".recipe-info").innerHTML;
const usage = document.querySelector("input[name='usage']").value;
const menu = document.querySelector("input[name='menu']").value;
const taste = document.querySelector("input[name='taste']").value;
const level = document.querySelector("input[name='level']").value;
const nonce = document.querySelector("input[name='nonce']").value;

const data = {
    title,
    recipeCondition: { usage, menu, taste, level },
    outputContent,
    nonce
};

nonce値を確認して保存し、保存が成功した場合はnonce値をセッションから削除して、リプレイやリロードによる無限保存を防ぎます。

@PostMapping("/recipe/history/save")
@ResponseBody
public ResponseEntity<Long> saveRecipeHistory(@RequestBody RecipeHistroyRequsetDTO recipeHistroyRequsetDTO, HttpSession session) throws InterruptedException {
    String userNonce = (String) session.getAttribute("nonce");

    if (!StringUtils.hasText(userNonce) || !recipeHistroyRequsetDTO.getNonce().equals(userNonce)) {
        throw new RuntimeException("nonce値が存在しません。");
    }

    Long savedRecipeSeq = recipeHistoryService.saveRecipeAndReturnSavedPK(recipeHistroyRequsetDTO);
    if(savedRecipeSeq != 0) {
        session.removeAttribute("nonce");   
    }
    
    return ResponseEntity.ok(savedRecipeSeq);
}

最適化：可読性のための JPQL

最初は下記のようにクエリメソッドを活用しようと試みましたが、メソッド名が長くなり、可読性が下がると感じました。

public interface RecipeMyPageRepository extends JpaRepository<RecipeEntity, Long> {

    List<RecipeEntity> findByUserEntity_UserSeqAndRecipeInputKeywordEntityListIsNotNullAndRecipeOutputEntityIsNotNull(Long userSeq);
    
} 

従って、下記のように JPQL を使用する形に変更しました。

public interface RecipeMyPageRepository extends JpaRepository<RecipeEntity, Long>{
    
    @Query("""
        SELECT DISTINCT r FROM RecipeEntity r
        JOIN r.recipeInputKeywordEntityList k
        WHERE r.userEntity.userSeq = :userSeq
        AND r.recipeOutputEntity IS NOT NULL
    """)
    Page<RecipeEntity> findRecipesWithPagination(
        @Param("userSeq") Long userSeq,
        Pageable pageable
    );
    
} 

OneToOneやOneToManyなどのエンティティ間の関連を表すアノテーションによって、複数のエンティティがまとめて取得されるようになります。
実際には冗長なクエリが多いため、一括で取得してJava側でパースする必要があるように思われました。

Hibernate: 
    select
        distinct re1_0.recipe_seq,
        re1_0.created_at,
        re1_0.user_seq 
    from
        recipe re1_0 
    join
        recipe_input_keyword rikel1_0 
            on re1_0.recipe_seq=rikel1_0.recipe_seq 
    left join
        recipe_output_content roe1_0 
            on re1_0.recipe_seq=roe1_0.recipe_seq 
    where
        re1_0.user_seq=? 
        and roe1_0.recipe_output_content_seq is not null 
    order by
        re1_0.created_at 
    limit
        ?

Hibernate: 
    select
        roe1_0.recipe_output_content_seq,
        roe1_0.output_content,
        roe1_0.recipe_seq,
        roe1_0.recipe_title 
    from
        recipe_output_content roe1_0 
    where
        roe1_0.recipe_seq=?

Hibernate: 
    select
        ue1_0.user_seq,
        ue1_0.created_at,
        ue1_0.is_deleted,
        ue1_0.roles,
        ue1_0.updated_at,
        ue1_0.user_email,
        ue1_0.user_id,
        ue1_0.user_name,
        ue1_0.user_password 
    from
        user ue1_0 
    where
        ue1_0.user_seq=?

Hibernate: 
    select
        roe1_0.recipe_output_content_seq,
        roe1_0.output_content,
        roe1_0.recipe_seq,
        roe1_0.recipe_title 
    from
        recipe_output_content roe1_0 
    where
        roe1_0.recipe_seq=?

Hibernate: 
    select
        roe1_0.recipe_output_content_seq,
        roe1_0.output_content,
        roe1_0.recipe_seq,
        roe1_0.recipe_title 
    from
        recipe_output_content roe1_0 
    where
        roe1_0.recipe_seq=?

Hibernate: 
    select
        count(distinct re1_0.recipe_seq) 
    from
        recipe re1_0 
    join
        recipe_input_keyword rikel1_0 
            on re1_0.recipe_seq=rikel1_0.recipe_seq 
    left join
        recipe_output_content roe1_0 
            on re1_0.recipe_seq=roe1_0.recipe_seq 
    where
        re1_0.user_seq=? 
        and roe1_0.recipe_output_content_seq is not null

Hibernate: 
    select
        rikel1_0.recipe_seq,
        rikel1_0.keyword 
    from
        recipe_input_keyword rikel1_0 
    where
        rikel1_0.recipe_seq=?

Hibernate: 
    select
        rikel1_0.recipe_seq,
        rikel1_0.keyword 
    from
        recipe_input_keyword rikel1_0 
    where
        rikel1_0.recipe_seq=?

Hibernate: 
    select
        rikel1_0.recipe_seq,
        rikel1_0.keyword 
    from
        recipe_input_keyword rikel1_0 
    where
        rikel1_0.recipe_seq=?

最適化：性能のための＠EntityGraph

冗長なクエリがないようにEntityGraphアノテーションを使います。

@EntityGraph(attributePaths = {"recipeOutputEntity", "recipeInputKeywordEntityList", "userEntity"})
@Query("""
    SELECT DISTINCT r FROM RecipeEntity r
    JOIN r.recipeInputKeywordEntityList k
    WHERE r.userEntity.userSeq = :userSeq
    AND r.recipeOutputEntity IS NOT NULL
""")
Page<RecipeEntity> findRecipesWithPagination(
    @Param("userSeq") Long userSeq,
    Pageable pageable
);

冗長なクエリはなくなりましたが、JOINがLEFTのままになっています。
常にデータが存在するテーブルなので、LEFTではなくINNERにすればパフォーマンスが向上します。

select
    distinct re1_0.recipe_seq,
    re1_0.created_at,
    rikel1_0.recipe_seq,
    rikel1_0.keyword,
    roe1_0.recipe_output_content_seq,
    roe1_0.output_content,
    roe1_0.recipe_seq,
    roe1_0.recipe_title,
    ue1_0.user_seq,
    ue1_0.created_at,
    ue1_0.is_deleted,
    ue1_0.roles,
    ue1_0.updated_at,
    ue1_0.user_email,
    ue1_0.user_id,
    ue1_0.user_name,
    ue1_0.user_password 
from
    recipe re1_0 
join
    recipe_input_keyword rikel1_0 
        on re1_0.recipe_seq=rikel1_0.recipe_seq 
left join
    recipe_output_content roe1_0 
        on re1_0.recipe_seq=roe1_0.recipe_seq 
left join
    user ue1_0 
        on ue1_0.user_seq=re1_0.user_seq 
where
    re1_0.user_seq=? 
    and roe1_0.recipe_output_content_seq is not null 
order by
    re1_0.created_at

Hibernate: 
select
    count(distinct re1_0.recipe_seq) 
from
    recipe re1_0 
join
    recipe_input_keyword rikel1_0 
        on re1_0.recipe_seq=rikel1_0.recipe_seq 
left join
    recipe_output_content roe1_0 
        on re1_0.recipe_seq=roe1_0.recipe_seq 
where
    re1_0.user_seq=? 
    and roe1_0.recipe_output_content_seq is not null

最適化：＠EntityGraph と INNERJOIN

isNotNull も不要な条件です。レシピを作成する際には、必ず recipe_output_content がレシピと一緒に生成されるためです。isNotNullは消します。
削除する一方で、recipeOutputEntity はJOIN条件として保持する必要があるため、JOIN句に追加します。
JOIN句が紛らわしくなる恐れがあるため、INNER JOIN と明示しておきます。

@EntityGraph(attributePaths = {"recipeOutputEntity", "recipeInputKeywordEntityList", "userEntity"})
@Query("""
    SELECT DISTINCT r FROM RecipeEntity r
    INNER JOIN r.recipeInputKeywordEntityList k
    INNER JOIN r.recipeOutputEntity j
    WHERE r.userEntity.userSeq = :userSeq
""")
Page<RecipeEntity> findRecipesWithPagination(
    @Param("userSeq") Long userSeq,
    Pageable pageable
);

recipeOutputContent テーブルは LEFTJOIN から INNERJOIN に変えました。

select
    distinct re1_0.recipe_seq,
    re1_0.created_at,
    rikel1_0.recipe_seq,
    rikel1_0.keyword,
    roe1_0.recipe_output_content_seq,
    roe1_0.output_content,
    roe1_0.recipe_seq,
    roe1_0.recipe_title,
    ue1_0.user_seq,
    ue1_0.created_at,
    ue1_0.is_deleted,
    ue1_0.roles,
    ue1_0.updated_at,
    ue1_0.user_email,
    ue1_0.user_id,
    ue1_0.user_name,
    ue1_0.user_password 
from
    recipe re1_0 
join
    recipe_input_keyword rikel1_0 
        on re1_0.recipe_seq=rikel1_0.recipe_seq 
join
    recipe_output_content roe1_0 
        on re1_0.recipe_seq=roe1_0.recipe_seq 
left join
    user ue1_0 
        on ue1_0.user_seq=re1_0.user_seq 
where
    re1_0.user_seq=? 
order by
    re1_0.created_at
Hibernate: 
select
    count(distinct re1_0.recipe_seq) 
from
    recipe re1_0 
join
    recipe_input_keyword rikel1_0 
        on re1_0.recipe_seq=rikel1_0.recipe_seq 
left join
    recipe_output_content roe1_0 
        on re1_0.recipe_seq=roe1_0.recipe_seq 
where
    re1_0.user_seq=? 

他のテーブルは INNER JOIN になりましたが、user テーブルだけは LEFT JOIN になっています。
ユーザーが退会しただけでなく、データベースから完全に削除された場合でもレシピを表示する必要があるのであれば、ユーザーが NULL であってもデータを取得できる必要があります。したがって、LEFT JOIN が適切です。
ただし、マイページで表示する情報は、ユーザーがログインしていなければアクセスできないページなので、LEFT JOIN を使うと無駄が多く、パフォーマンスが低下する可能性があります。
ログイン済みのユーザーが前提となっているため、ここではEntityGraphからUserエンティティを削除し、INNER JOINに変更します。

@EntityGraph(attributePaths = {"recipeOutputEntity", "recipeInputKeywordEntityList"})
@Query("""
    SELECT DISTINCT r FROM RecipeEntity r
    INNER JOIN r.recipeInputKeywordEntityList k
    INNER JOIN r.recipeOutputEntity j
    WHERE r.userEntity.userSeq = :userSeq
""")
Page<RecipeEntity> findRecipesWithPagination(
    @Param("userSeq") Long userSeq,
    Pageable pageable
);

それではUserテーブルの LEFT JOIN も INNER JOINに変更されます。
INNER JOIN の方が LEFT JOIN よりも処理対象のデータが少なくなるため、クエリの実行効率が高くなる傾向があります。

select
    distinct re1_0.recipe_seq,
    re1_0.created_at,
    rikel1_0.recipe_seq,
    rikel1_0.keyword,
    roe1_0.recipe_output_content_seq,
    roe1_0.output_content,
    roe1_0.recipe_seq,
    roe1_0.recipe_title,
    re1_0.user_seq 
from
    recipe re1_0 
join
    recipe_input_keyword rikel1_0 
        on re1_0.recipe_seq=rikel1_0.recipe_seq 
join
    recipe_output_content roe1_0 
        on re1_0.recipe_seq=roe1_0.recipe_seq 
join
    user ue1_0 
        on ue1_0.user_seq=re1_0.user_seq 
where
    ue1_0.user_seq=? 
order by
    re1_0.created_at

select
    count(distinct re1_0.recipe_seq) 
from
    recipe re1_0 
join
    recipe_input_keyword rikel1_0 
        on re1_0.recipe_seq=rikel1_0.recipe_seq 
join
    recipe_output_content roe1_0 
        on re1_0.recipe_seq=roe1_0.recipe_seq 
join
    user ue1_0 
        on ue1_0.user_seq=re1_0.user_seq 
where
    ue1_0.user_seq=?

最適化： DISTINCT 削除

しかし、JPQL ではなく NATIVE SQL としては DISTINCT が不必要です。
OneToOneやOneToManyなどのエンティティ間の関連を表すアノテーションによって JPA で発生した重複を除外するために JPQL で DISTINCT が必要だけです。

public Page<RecipeMyPageResponse> findAllRecipeByUser(Long userSeq, int currentPage) {
    Pageable pageable = PageRequest.of(currentPage, 10, Sort.by(Sort.Direction.ASC, "createdAt"));
    
    return recipeMyPageRepository.findRecipesWithPagination(userSeq, pageable)
                                    .map(RecipeMyPageResponse::toDTO);
};

DISTINCT を削除して JAVA 側で処理するようにします。
NATIVE SQLで DISTINCT は削除されます。不必要の作動がなくなるので性能が高くなります。
重複を削除するためページネーションなので順序が重要なのでLINKED

@EntityGraph(attributePaths = {"recipeOutputEntity", "recipeInputKeywordEntityList"})
@Query("""
    SELECT r FROM RecipeEntity r
    INNER JOIN r.recipeInputKeywordEntityList k
    INNER JOIN r.recipeOutputEntity j
    WHERE r.userEntity.userSeq = :userSeq
""")
Page<RecipeEntity> findRecipesWithPagination(
    @Param("userSeq") Long userSeq,
    Pageable pageable
);

Javaで重複を削除する方法について、2つの工夫を行いました。
最初は、セットクラスを使ってロジックを実装しました。
- LinkedHashSetの重複判定は、ハッシュコードを基準に行われます。
- そのため、Recipeエンティティに@EqualsAndHashCodeを使用しました。
- ただし、重複の基準はrecipeSeq変数のみであるため、@EqualsAndHashCodeにその点を明示的に指定しました。

@Getter
@Setter
@AllArgsConstructor
@NoArgsConstructor
@Builder
@Entity
@Table(name = "recipe")
@EqualsAndHascode(of = "recipeSeq")
public class RecipeEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "recipe_seq")
    private Long recipeSeq;
    .
    .
}

public Page<RecipeMyPageResponse> findAllRecipeByUser(Long userSeq, int currentPage) {
    Pageable pageable = PageRequest.of(currentPage, 10, Sort.by(Sort.Direction.ASC, "createdAt"));
    Page<RecipeEntity> rawPage = recipeMyPageRepository.findRecipesWithPagination(userSeq, pageable);

    List<RecipeEntity> deduplicated = new ArrayList<>(new LinkedHashSet<>(rawPage.getContent()));

    List<RecipeMyPageResponse> dtoList = deduplicated.stream()
                                                        .map(RecipeMyPageResponse::toDTO)
                                                        .toList();

    return new PageImpl<>(dtoList, pageable, rawPage.getTotalElements());
};

DISTINCT がない場合は COUNTクエリを明確にして暗黙的なクエリを呼び出さないように処理します。

@EntityGraph(attributePaths = {"recipeOutputEntity", "recipeInputKeywordEntityList"})
@Query(value = """
    SELECT r FROM RecipeEntity r
    INNER JOIN r.recipeInputKeywordEntityList k
    INNER JOIN r.recipeOutputEntity j
    WHERE r.userEntity.userSeq = :userSeq
""",  countQuery = """
        select count(r) FROM RecipeEntity r
        where r.userEntity.userSeq = :userSeq
""")
Page<RecipeEntity> findRecipesWithPagination(
    @Param("userSeq") Long userSeq,
    Pageable pageable
);

しかし、単にページネーションのためだけにエンティティクラスに @EqualsAndHashCode を付け加えるのは好ましくないと感じました。
セットクラスとマップクラスは、内部実装を確認したところ、CPU性能にそれほど大きな違いはないように思われたため、マップクラスによる実装も検討しました。
マップは、hashCode や equals に依存せずに処理できる点が利点です。
ページネーションでは順序が重要となるため、LinkedHashMap を使用しました。

public Page<RecipeMyPageResponse> findAllRecipeByUser(Long userSeq, int currentPage) {
    Pageable pageable = PageRequest.of(currentPage, 10, Sort.by(Sort.Direction.ASC, "createdAt"));

    Page<RecipeEntity> rawPage = recipeMyPageRepository.findRecipesWithPagination(userSeq, pageable);

    List<RecipeEntity> deduplicatedList = rawPage.getContent().stream()
                                                .collect(Collectors.toMap(
                                                    RecipeEntity::getRecipeSeq,
                                                    Function.identity(),
                                                    (a, b) -> a,
                                                    LinkedHashMap::new
                                                ))
                                                .values()
                                                .stream()
                                                .toList();

    List<RecipeMyPageResponse> response = deduplicatedList.stream()
                                                        .map(RecipeMyPageResponse::toDTO)
                                                        .toList();

    return new PageImpl<>(response, pageable, rawPage.getTotalElements());
}

最適化：大容量データに備えて SQL 切り替え

上のSQLは一回で全部データを受け取ることができますが、JOIN の数が多いです。
それを JOIN が少なくする必要があります。
SQL を二回に分けて大容量のデータを受け取るようにします。
二回に分けて性能が悪くなるのではないかと思うかもしれません。

@Query("""
    SELECT r.recipeSeq FROM RecipeEntity r
    WHERE r.userEntity.userSeq = :userSeq
""")
List<Long> findRecipeIdsByUser(@Param("userSeq") Long userSeq);

@EntityGraph(attributePaths = {"recipeOutputEntity", "recipeInputKeywordEntityList"})
@Query(value = """
    SELECT r FROM RecipeEntity r
    INNER JOIN r.recipeInputKeywordEntityList k
    INNER JOIN r.recipeOutputEntity j
    WHERE r.recipeSeq IN :recipeIds
    and r.isDeleted = false
""", countQuery = """
        select count(r) FROM RecipeEntity r
        WHERE r.recipeSeq IN :recipeIds
        and r.isDeleted = false
""")
Page<RecipeEntity> findRecipesByIds(@Param("recipeIds") List<Long> recipeIds, Pageable pageable);

ORDER BY を行う場合は主キーを採番する段階で順序を決めておくと、後の処理での性能が向上します。
JOIN を行った後は、レコード数が増えるため、ORDER BY に必要なリソースも増加します。
特に大容量データを扱う場合は、ORDER BY にかかるリソースを抑えることで、システムの応答性を改善できます。

public interface RecipeMyPageRepository extends JpaRepository<RecipeEntity, Long>{
    
    @Query(value = """
        SELECT r.recipeSeq FROM RecipeEntity r
        WHERE r.userEntity.userSeq = :userSeq
    """, countQuery = """
        select count(r) FROM RecipeEntity r
        WHERE r.userEntity.userSeq = :userSeq
    """)
    Page<Long> findRecipeIdsByUser(@Param("userSeq") Long userSeq, Pageable pageable);

    @EntityGraph(attributePaths = {"recipeOutputEntity", "recipeInputKeywordEntityList"})
    @Query(value = """
        SELECT r FROM RecipeEntity r
        INNER JOIN r.recipeInputKeywordEntityList k
        INNER JOIN r.recipeOutputEntity j
        WHERE r.recipeSeq IN :recipeIds
        and r.isDeleted = false
    """)
    List<RecipeEntity> findRecipesByIds(@Param("recipeIds") List<Long> recipeIds);
} 

public Page<RecipeMyPageResponse> findAllRecipeByUser(Long userSeq, int currentPage) {
    Pageable pageable = PageRequest.of(currentPage,  10, Sort.by(Sort.Direction.DESC, "createdAt"));
    Page<Long> recipeIds = recipeMyPageRepository.findRecipeIdsByUser(userSeq, pageable);

    List<RecipeMyPageResponse> recipes = recipeMyPageRepository.findRecipesByIds(recipeIds.getContent()).stream().map(RecipeMyPageResponse::toDTO).toList();

    return new PageImpl<>(recipes, pageable, recipeIds.getTotalElements());
};

meeting-room-reservation

Wed, 16 Apr 2025 00:00:00 +0000

考慮する場合の数：開始時間が終了時間以降にならないようにする

会議室の予約に基本的に必要な条件を自分で考えて実装することになりました。
最初に考えたのは、開始時間が終了時間以降にならないようにすることです。
最初に活用したのは、java.timeパッケージのZonedDateTimeクラスクラスに属するメソッドのisBefore(), isAfter()でした。
しかし、これだけでは不十分で、isBefore()とisAfter()というメソッドでは、会議が終わる時間に合わせて登録する場合、重複とみなされました。
- 15:00に終わったら15:00開始で登録することがほとんどの場合だったので、isBeforeやisAfterメソッドは使うことができませんでした。

//inputStartDateTime: ユーザーが選択した会議開始時間
//inputEndDateTime: ユーザーが選択した会議終了時間
boolean previousThaninputEndDateTime = inputStartDateTime.atZone(ZoneId.of("Asia/Seoul"))
															.isBefore(inputEndDateTime.atZone(ZoneId.of("Asia/Seoul")));

compareToに変更し、15:00に終わったら15:00に始まってもエラーに見なさないようにしました。

//inputStartDateTime: ユーザーが選択した会議開始時間
//inputEndDateTime: ユーザーが選択した会議終了時間
public void insertEvent(MeetingReqDto meetingReqDto) throws Exception {
	boolean previousThaninputEndDateTime = inputStartDateTime.atZone(ZoneId.of("Asia/Seoul"))
																.compareTo(inputEndDateTime.atZone(ZoneId.of("Asia/Seoul"))) < 0;
	if (!previousThaninputEndDateTime) {
		throw new BizException(ErrorEnum.CALENDAR_END_BEFORE_START);
	}

}

考慮する場合の数：スケジュールが重ならないようにする

次の課題は、スケジュールが重複しないようにすることでした。
考えても考えても明確なアルゴリズムが浮かばなかったです。
まずは全てのスケジュールが必要なのではなく、開始時間付近の2つのスケジュールがわかればよいという結論に至りました。
したがって、ユーザが要求した開始時刻の前後に1つずつスケジュールを照会する。

//inputStartDateTime: ユーザーが選択した会議開始時間
Events events = service.events().list("ddddd@gmail.com")
								.setTimeMin(inputStartDateTime)
								.setMaxResults(2)
								.setSingleEvents(true)
								.setOrderBy("starttime")
								.execute();
List<Event> items = events.getItems();

もし前後のスケジュールがなければ、重複を考慮する必要がないので、スケジュールを作ってそこでアーリーリターンを行います。

// 選択した時間帯に後日予定がない場合は、重複検査を行わず、すぐに登録する。
if (items == null) {
	service.events().insert("ddddd@gmail.com", event).execute();
	return;
}

itemは前後のスケジュールで数が2つなので、for文で巡回します。
前のスケジュールと重複しても、後のスケジュールと重複してもいけないので、どちらか一つでも引っかかると例外をスローします。

//inputEndDateTime: ユーザーが選択した会議終了時間
//listStartDateTime: 既存会議開始時間
ZonedDateTime listStartDateTime = null;
boolean previousThanListStartDateTime = false;
for (Event item : items) {
	listStartDateTime = ZonedDateTime.from(
											Instant.from(DateTimeFormatter.ISO_DATE_TIME.parse(item.getStart().getDateTime().toStringRfc3339()))
													.atZone(ZoneId.of("Asia/Seoul"))
											);

	// スケジュールの重複を確認します。終了時間と重なってすぐに開始する場合は、重複と見なさないです。
	previousThanListStartDateTime = inputEndDateTime.atZone(ZoneId.of("Asia/Seoul"))
													.compareTo(listStartDateTime) <= 0;
	if (!previousThanListStartDateTime) {
		throw new BusinessException(ErrorEnum.CALENDAR_ALREAY);
	}
}

考慮する場合の数：修正の際には自分自身を修正する場合は許可する

入力の場合と全く同じアルゴリズムを使おうとしました。
しかし、修正の場合、同じ時間帯に置いて修正すると、重複と判断する結果を引き起こしました。
実際、間違えて同じ時間帯で修正をしたのに、修正をしたら重複と表示されたら困惑することでしょう。
この場合、重複でも問題ないため、そのまま修正されるようにアルゴリズムを修正しました。

List<Event> filteredItems = items.stream().filter(element -> {
	return !element.getId().equals(meetingReqDto.getEventId());
}).collect(Collectors.toList());

for (Event item : filteredItems) { //not All item, but filteredItem
	//duplication check logic
}

考慮する場合の数：週末にはinsertしないようにする

とりあえず、プロントエンド側で週末の場合、別の色で塗って入力時に警告を出すようにしましたが、それだけでは不十分だと思いました。
なので、週末にスケジュールを登録できないように週末かどうか確認するようにしました。
入力された値が週末であれば、わざわざGoogle cloud dbを活用する必要もないので、最初にチェックするように追加しました。

private boolean isWeekend(String isoDateTimeString) {
	LocalDateTime dateTime = LocalDateTime.parse(isoDateTimeString);
	DayOfWeek dayOfWeek = dateTime.getDayOfWeek();
	return ((dayOfWeek == DayOfWeek.SATURDAY) || (dayOfWeek == DayOfWeek.SUNDAY));
}

public void insertEvent(MeetingReqDto meetingReqDto) throws Exception {
	if(isWeekend(meetingReqDto.getStartDateTime())) {
		throw new BusinessException(ErrorEnum.CALENDAR_WEEKEND);
	}
}

考慮する場合の数：休日には登録しないようにする

週末を含めたので、祝日も除外することにしました。
ただ、週末以外の休日を取得する方法はJAVA APIにはないので、別途に探さなければなりませんでした。
方法は国が提供するAPI、あるいは現在使っているGoogle Calendar APIでした。
類似性が高いGoogle Calendar APIを使うことにしました。
下記のように二つを取得させた結果、反応性が悪くなりました。最初に私たちが作ったスケジュールselectが完了した後、休日のスケジュールをselectする形だったからです。

public void insertEvent(MeetingReqDto meetingReqDto) throws Exception {
	Events events = service.events().list("ddddd@gmail.com")
									.setTimeMin(startDateTime).setMaxResults(2)
									.setSingleEvents(true)
									.setOrderBy("starttime")
									.execute();
	List<Event> items = events.getItems();

	Events holidays = service.events()
							.list("ko.south_korea#holiday@group.v.calendar.google.com")
							.setTimeMax(lastDay)
							.setTimeMin(firstDay)
							.execute();
	List<Event> holidays = events.getItems();

	items.add(holidays);
}

この部分を修正するには、同時にエーピーアイをコールすることが必要でした。
その中でCompletableFutureを活用しました。
parallelStream, ExceutorService + Future, Spring Reactiveなどの選択肢がありました。
- parallelStreamやFuture classはエラー処理が難しかった。
- Spring Reactiveは私たちのプロジェクトにない技術であり、学ぶのに時間がかかるという評価が多かったです。
- なので、エラー処理が簡単で、fucntional chainingも可能なCompletableFutureを使うことにしました。
最初はOauth サービスを使うCalendarオブジェクトを各リクエストが共有して使う形にしました。

public List<CalendarEventRes> getEventList(String firstDayOfMonth, String lastDayOfMonth)
		throws FileNotFoundException, IOException, GeneralSecurityException {
	Calendar service = getServiceAuth();

	CompletableFuture<Events> companyEventsCf = CompletableFuture.supplyAsync(() -> { 
		return service.events().list("ddddd@gmail.com")
								.setTimeMax(lastDay)
								.setTimeMin(firstDay)
								.execute(); 
	});
	CompletableFuture<Events> holidayEventsCf = CompletableFuture.supplyAsync(() -> { 
		return service.events().list("ko.south_korea#holiday@group.v.calendar.google.com")
								.setTimeMax(lastDay)
								.setTimeMin(firstDay)
								.execute(); 
	});

	List<Event> items =  companyEventsCf.thenCombine(holidayEventsCf, (prev, cur) -> {
		cur.putAll(prev);
		return cur;
	}).join().getItems();	

	return items;							
}

しかし、Googleで作ったCalendarクラスがスレッドセーフなのか確信がありませんでした。
スレッドセーフなクラスでないとマルチスレッド環境で問題を起こす可能性がありました。
スレッドセーフでない共有オブジェクトなのでレースコンディションに陥る可能性があると判断しました。
したがって、共有オブジェクトではなく、それぞれのスレッドで別々にオブジェクトを作る形に変更しました。

public List<CalendarEventRes> getEventList(String firstDayOfMonth, String lastDayOfMonth)
		throws FileNotFoundException, IOException, GeneralSecurityException {
	Calendar service = getServiceAuth();

	CompletableFuture<Events> companyEventsCf = CompletableFuture.supplyAsync(() -> { 
		Calendar service = getServiceAuth();
		return service.events().list("ddddd@gmail.com")
								.setTimeMax(lastDay)
								.setTimeMin(firstDay)
								.execute(); 
	});
	CompletableFuture<Events> holidayEventsCf = CompletableFuture.supplyAsync(() -> { 
		Calendar service = getServiceAuth();
		return service.events().list("ko.south_korea#holiday@group.v.calendar.google.com")
								.setTimeMax(lastDay)
								.setTimeMin(firstDay)
								.execute(); 
	});

	List<Event> items =  companyEventsCf.thenCombine(holidayEventsCf, (prev, cur) -> {
		cur.putAll(prev);
		return cur;
	}).join().getItems();	

	return items;							
}

リカバリーが必要の場合はexceptionally()を使います。
ラムダ式なのでチェック例外は対応できませんのでラムダ式内にtry~catch文が必要です。
チェック例外を CompletableFutureクラスで求められるCompletionExceptionにラップします.

public List<CalendarEventRes> getEventList(String firstDayOfMonth, String lastDayOfMonth)
		throws FileNotFoundException, IOException, GeneralSecurityException {
	Calendar service = getServiceAuth();

	CompletableFuture<Events> companyEventsCf = CompletableFuture.supplyAsync(() -> { 
		try {
			Calendar service = getServiceAuth();
			return service.events().list("ddddd@gmail.com")
									.setTimeMax(lastDay)
									.setTimeMin(firstDay)
									.execute(); 
		} catch (Exception ex) {
				throw new CompletionException(ex);
		}
	}).exceptionally(ex -> {
		return new Events();
	});

	CompletableFuture<Events> holidayEventsCf = CompletableFuture.supplyAsync(() -> { 
		try {
			Calendar service = getServiceAuth();
			return service.events().list("ko.south_korea#holiday@group.v.calendar.google.com")
									.setTimeMax(lastDay)
									.setTimeMin(firstDay)
									.execute(); 
		} catch (Exception ex) {
				throw new CompletionException(ex);
		}
	}).exceptionally(ex -> {
		return new Events();
	});

	List<Event> items =  companyEventsCf.thenCombine(holidayEventsCf, (prev, cur) -> {
		cur.putAll(prev);
		return cur;
	}).join().getItems();	

	return items;						
}

無限待機になってはいけないのでタイムアウトを設定します。
orTimeoutメソッドはJDK1.9以上のバージョンでしか使用できません。

public List<CalendarEventRes> getEventList(String firstDayOfMonth, String lastDayOfMonth)
		throws FileNotFoundException, IOException, GeneralSecurityException {
	Calendar service = getServiceAuth();

	CompletableFuture<Events> companyEventsCf = CompletableFuture.supplyAsync(() -> { 
		try {
			Calendar service = getServiceAuth();
			return service.events().list("ddddd@gmail.com")
									.setTimeMax(lastDay)
									.setTimeMin(firstDay)
									.execute(); 
		} catch (Exception ex) {
				throw new CompletionException(ex);
		}
	}).orTimeout(5, TimeUnit.SECONDS) 
	.exceptionally(ex -> {
		return new Events();
	});
	CompletableFuture<Events> holidayEventsCf = CompletableFuture.supplyAsync(() -> { 
		try {
			Calendar service = getServiceAuth();
			return service.events().list("ko.south_korea#holiday@group.v.calendar.google.com")
									.setTimeMax(lastDay)
									.setTimeMin(firstDay)
									.execute(); 
		} catch (Exception ex) {
				throw new CompletionException(ex);
		}
	}).orTimeout(5, TimeUnit.SECONDS) 
	.exceptionally(ex -> {
		return new Events();
	});

	List<Event> items =  companyEventsCf.thenCombine(holidayEventsCf, (prev, cur) -> {
		cur.putAll(prev);
		return cur;
	}).join().getItems();	

	return items;						
}

例外をスローする必要がある場合はexceptionally()ではなく、handle()を使います。
一つでもラムダ式で例外をスローしたら、thenCombine()も例外をスローします。
- その例外はCompletionExceptionなので、プロントエンド側が処理できるようにBusinessExceptionにラップします。

public List<CalendarEventRes> getEventList(String firstDayOfMonth, String lastDayOfMonth)
        throws FileNotFoundException, IOException, GeneralSecurityException {
    Calendar service = getServiceAuth();

    CompletableFuture<Events> companyEventsCf = CompletableFuture.supplyAsync(() -> {
        try {
            Calendar service = getServiceAuth();
            return service.events().list("ddddd@gmail.com")
                    .setTimeMax(lastDay)
                    .setTimeMin(firstDay)
                    .execute();
        } catch (Exception ex) {
            throw new CompletionException(ex); 
        }
    }).orTimeout(5, TimeUnit.SECONDS)  
      .handle((result, ex) -> {
          if (ex != null) {
              throw new CompletionException(ex);
          }
          return result;  
      });

    CompletableFuture<Events> holidayEventsCf = CompletableFuture.supplyAsync(() -> {
        try {
            Calendar service = getServiceAuth();
            return service.events().list("ko.south_korea#holiday@group.v.calendar.google.com")
                    .setTimeMax(lastDay)
                    .setTimeMin(firstDay)
                    .execute();
        } catch (Exception ex) {
            throw new CompletionException(ex);  
        }
    }).orTimeout(5, TimeUnit.SECONDS)  
      .handle((result, ex) -> {
          if (ex != null) {
              throw new CompletionException(ex);
          }
          return result;  
      });

    try {
		List<Event> items = companyEventsCf.thenCombine(holidayEventsCf, (prev, cur) -> {
			cur.putAll(prev);
			return cur;
		}).join();

		return items;	
	} catch (CompletionException ex) {
		throw new BusinessException(ErrorEnum.CALENDAR_GOOGLE_FAILED); 
	}
}

ラムダ式の中でtry-catch文が繰り返されると、可読性が下がります。
チェック例外を扱えるようにするためのラッパークラスを作成します。

public class LambdaExceptionWrapper {
    @FunctionalInterface
    public interface SupplierWithException<T, E extends Exception> {
        T get() throws E;
    }

    public static <T, E extends Exception> Supplier<T> checkedExceptionWrapper(SupplierWithException<T, E> supplier) {
        return () -> {
            try {
                return supplier.get(); //変わった部分
            } catch (Exception e) {
                throw new RuntimeException(e);　//チェック例外をラップしてruntimeExceptionに変えます。
            }
        };
    }
}

ラムダ式の中にチェック例外を扱えるラッパークラスを通じてtry~catch文を削除して可読性を上げました。

import static foo.bar.LambdaExceptionWrapper.checkedExceptionWrapper;

public List<CalendarEventRes> getEventList(String firstDayOfMonth, String lastDayOfMonth)
        throws FileNotFoundException, IOException, GeneralSecurityException {

    Calendar service = getServiceAuth();

    // Wrapping the supplier with the exception handler
    CompletableFuture<Events> companyEventsCf = CompletableFuture.supplyAsync(checkedExceptionWrapper(() -> {
        Calendar service = getServiceAuth();
        return service.events().list("ddddd@gmail.com")
                .setTimeMax(lastDay)
                .setTimeMin(firstDay)
                .execute();
    })).orTimeout(5, TimeUnit.SECONDS)
      .handle((result, ex) -> {
          if (ex != null) {
              throw new CompletionException(ex);
          }
          return result;
      });

    CompletableFuture<Events> holidayEventsCf = CompletableFuture.supplyAsync(checkedExceptionWrapper(() -> {
        Calendar service = getServiceAuth();
        return service.events().list("ko.south_korea#holiday@group.v.calendar.google.com")
                .setTimeMax(lastDay)
                .setTimeMin(firstDay)
                .execute();
    })).orTimeout(5, TimeUnit.SECONDS)
      .handle((result, ex) -> {
          if (ex != null) {
              throw new CompletionException(ex);
          }
          return result;
      });

    try {
        List<Event> items = companyEventsCf.thenCombine(holidayEventsCf, (prev, cur) -> {
            cur.putAll(prev);
            return cur;
        }).join();

        return items;
    } catch (CompletionException ex) {
        throw new BusinessException(ErrorEnum.CALENDAR_GOOGLE_FAILED);
    }
}

必要な情報だけジェイソンデータで送る

最終的にAPIを完成して私がメンタリングをする時貰ったサーバーにデプロイをした後、プロント側と協業を始めました。
フロント側で必要ないデータは受け取っても目障りなだけで、ネットワークトラフィックが増えるので、必要な値だけ送ってほしいと言われました。
ハッシュマップを使ってその要件を実装しました。

public HashMap<String, Object> getEvent(String eventId)
		throws FileNotFoundException, IOException, GeneralSecurityException {
	Calendar service = serviceAuth();

	Event event = service.events().get("ddddd@gmail.com", eventId).execute();
	HashMap<String, Object> map = new HashMap<String, Object>();
	map.put("summary", event.getSummary());
	map.put("description", event.getDescription());
	map.put("start", event.getStart());
	map.put("end", event.getEnd());
	map.put("id", event.getId());
	
	return map;
}

マップの代わりにDTOを使う

そして、マップクラスでプロント側にreturnするのはメンテナンスにとても良くないので、それをDtoやVOに変えるようにアドバイスをもらいました。
特に、プロント側とのコミュニケーションにSwaggerを使う場合、マップクラスはサポートされないので、DTOに変えてほしいと言われました。
どのように入れるか悩みましたが、最初はリクエストDTOとレスポンスDTOを区別せずにそのまま入れました。
- 何がリクエストで何がレスポンスなのか、変数名による区別が難しかったです。

public class MeetingDto {
	
	@NotBlank
	private String startDateTime; 
	@NotBlank
	private String endDateTime;
	@NotBlank
	private EventDateTime startEventDateTime; 
	@NotBlank
	private EventDateTime endEventDateTime;
}

さらに、リクエストDTOとレスポンスDTOに受け取るデータのタイプが違う必要がありました。
レスポンスで根のデータとプロント側で受け取ったリクエストデータでGoogleに送る時、違うデータタイプが要求されたからです。
従って、レスポンスとリクエストDTOを分離して作りました。

public class MeetingReqDto {
	
	@NotBlank
	private String startDateTime; 
	@NotBlank
	private String endDateTime;
}

public class MeetingResDto {

	@NotBlank
	private EventDateTime startDateTime; 
	@NotBlank
	private EventDateTime endDateTime;

}

개발 md

git command

clone branch

branch manipulation

remove local change

adding file staging area

add file to just before commit

when u want to do experiment about bugs using completely different branch

git command customizing

git username email config

seeing previous commit content

HEAD~ and HEAD^ diff for merge commit

cherry pick from dev to main

rebase：replacing cherry pick

git conflict on branch when using git pull

rebase：fix local commit message before publishing to remote

rebase：PR

reflog：showing history for git conduct

reflog：restore file

temp save

revert：commit delete from remote repo

log reading

merge and ff

communication-batch

windowsがシャットダウンする際に行われる後処理

windodwsのhostsファイル

文字列解釈に利用するLinuxコマンドの違い：S-jis環境でのless, catの動作の違い

OSにおけるセッション：ユーザーセッションと管理者セッションの動作の違い

OSにおけるFileSystem：どの流れでソースコードが解釈するのか

ファイルの文字コード解釈：数字はなぜ文字コードの区分が付かないのか

ファイルのUTF８保存：UTF８とUTF８(NO BOM)

DBString：UTF-8 vs UTF-8MB4

DBString：Collation vs 文字コード

DBString：マイグレーションする場合の注意

C:データ型とポインター

C:*はコンテクストによって意味が違う

C： コンテクストによる * 意味の違い

C： 文字列における**の活用

C： 構造体における**の活用

C：なぜ配列の初期容量の宣言にはなN ＋ １が多いのか

C：Charダブル配列の読み方

C：動的にStringに値を与える

C：tringを比較する

C：関数のParameter

Heap sort

実装ーheap sort

実装ー配列をツリーとして捉える

実装ーＭＡＸＨＥＡＰを作る

実装ー最大値を末尾に移動させてから安定化

実装ー時間計算量

実装ーheap sort降順

クイックソート

実装ークイックソートOOP版

実装ークイックソートLomuto版

深く探究ー3点中央値

深く探究ークイックソートHoare版

深く探究ークイックソート３Way

深く探究ークイックソートハイブリッド

深く探究クイックソートダブルピボット

振り返り

マージソート

実装ーマージソート昇順

実装ーマージソート降順

実装ー文字列マージソート

深く探求ーStringとIntの違い

深く探求ー部分的なマージソート

振り返り

バブルソートと挿入ソート

実装ーバブルソート

実装ー挿入ソート

実装ー整列以降特定の値を数える

実装ー整列された配列で１番近いいペアを探索

実装ー整列後重複除外

実装ー整列後重複の要素だけを集める

深く探求ーロジックの改善

深く探求ーなぜバブルソートより挿入ソートが効率に優れてるのか

振り返り

再帰

再帰

再帰を用いたデータ仕組み

DBString：UTF-8　vs UTF-8MB4

C:はコンテクストによって意味が違う*

C：コンテクストによる意味の違い*

*C：文字列における**の活用*

*C：構造体における**の活用*

C：なぜ配列の初期容量の宣言にはなN ＋１が多いのか

最適化：性能のための＠EntityGraph

最適化：大容量データに備えて SQL 切り替え