技術日記6/10-6/14
ドメインオブジェクトの設計にテーブル設計もある程度引っ張られるのかと思ってたけどDDDにおけるドメインオブジェクトの設計とテーブル設計は全く別物として考えていいっぽい
これなら割とお試し？的にDDDやっていけるかも
ドメインオブジェクトはガンガン変更加えていくやつっぽいし
デザインができてきたのでここでgraphqlの設計を一部修正加えた
boostnoteでいろんなノートを取るようにしたら作業ログを取りにくくなってきた
作業ログ用専用ツールがほしい
javaの日付系ライブラリ何使えばいいのかずっと整理できてなかったけどやっぱりjava8以降では標準のTime Api使えば良いっぽい
ただ機能過多感が...
しかもまだまだjava8が広まりきってないのか知らんけど、protocol buffersのTimestampではjoda time使ってるし...
graphql×grpc通信のマイクロサービス×RDBという構成で作ってるけど、graphqlのオブジェクト設計とprotocol buffersの設計とtable設計で三箇所ほどでオブジェクトの設計をすることになっている
graphqlとtable設計でデータの持ち方（粒度）が違うのだけど（graphqlオブジェクトを取得するのにtable2,3個見る必要があるとか）
このときprotocol buffersはどんなふうに設計するかと言うのをちょろっと考えたけど、今回はgraphqlとprotocol buffersの設計粒度は基本揃えることにした
理由としてはまずgraphql api（ゲートウェイサーバー）の仕事をシンプルにしたかったから
graphqlとprotocol buffersの粒度が揃っていない場合、別のgrpc呼び出しで取得したものをgraphqlサーバーで加工する必要が出てくると思う
ただなるべくそういったロジックのようなものはgraphqlサーバーではやりたくないなと思った
protocol buffersの設計粒度を細かくすれば、graphql意外の呼び出しとかにも対応できそうだけど、そのシチュエーションはあまり思いつかなかった
graphqlの設計変更につられて修正を入れるということはありそうだけど、そこはまあgraphqlの設計がミスってるせいだから
それにオブジェクトの設計がそれぞれのレイヤーでバラバラになりすぎると管理がめんどくさくなりそうだったから、揃えられそうなところはなるべく揃えたいというのもあった
ただテーブル設計は上のレイヤーの設計には引っ張られずにちゃんと正規化するべき
今更だけど初めてbinary search使った
この前アルゴリズムの勉強したからな
binary searchなんて基礎中の基礎だけど大事だわ
やっといてよかった
もっとアルゴリズムのちから伸ばしたいしAtcoderとかもやっていきたい
作業ログ残すときエラーメッセージと対応したときのコードも残せる場合は記録するようにした
ブログに落とし込むときとかそのまま貼れそうだし
graphql javaはslf4j使ってるのでlogback入れた
ログないとデバッグきつかったのでもっと早くやっといても良かった
テストコード書くのにkotlintestを使っていたけど、DIにKoin使っていて、両方共クラスの継承使ってて、なんか書き方が競合してるような感じで上手く一緒に使えなかったのでkotlintestは使うのやめた
Koinのテストとmockkは一緒に使えた
mockkはかなり使いやすいから安心した
kotlinはデフォルトでassert()関数持ってたけどログが微妙だったのでassertk入れた
殴り書き終了！ Koinとmockkの部分は別記事にまとめたいな
AppSyncとはなんぞや
AppSync
- マネージドgraphql
- AWS AppSync（アプリデータをリアルタイムで保存、同期）| AWS
- データソースにDynamoDB, Elasticsearch Service(ESS), Lambda, HTTP, Aurora Serverlessが使える
- GraphQL Schema（クエリ定義）とResolverを与えるだけっぽい
- 使用した分に対してのみ支払いが発生
- クエリとデータ変更操作
- クエリ及びデータ変更操作100万回につき4.00USD
- リアルタイム更新
- 動機状態を維持したいデータへのリアルタイム更新を受信できる
- リアルタイム更新100万回につき2USD
- AppSyncへの接続100万分につき0.08USD
- 安い
- Data Loaderのようなモノ、BatchInvokeというものがあるらしい
- Lambdaデータソース限定
- 本来複数回必要だったLambdaの実行を一回で済ませることができる
- その他のリソースではData Loaderを使う必要がありそう
技術日記6/3-6/7
先週からちゃんと技術ノートを作るように意識し始めた 自分は記憶力がないから身につけた知識はある程度まとめておいていつでも引っ張り出せるようにしておかないとダメだなと思って ついでにある程度まとまったものはブログにコピペしてpublicに公開していこう
Firebaseのクラウドメッセージングのサーバー実装を軽くやってみた しっかりしたプッシュサーバーを整えるのにはもうちょっとちゃんと設計したほうがいいんだろうけどリソースの関係で一旦カジュアルに使っていきたい所存
DDDに最近興味があって勉強しているけどまだまだ実践に入れていくだけの知識と自信がない 有用性がもう少し感じられたらチームメンバーと勉強会とかして実践していきたい気持ちもあるけどそこまで行けるかどうか
JVM基礎
Jvm
メモリ空間
- JVM上にJavaヒープ、Cヒープ、スレッドスタックの３つのメモリ領域がある。基本的にヒープと呼ばれているのはJavaヒープのこと
- ヒープが一杯になるとOOME(Out Of Memory Error)
ヒープの再利用
- 参照のなくなったオブジェクトはGCが掃除してメモリを開放してくれる
- GCは自動で行われるが、System.gc()メソッドで任意に実行させることもできる（ただやる必要はない）
- GC後もメモリ使用量が増加してしまうことをメモリリークという。これはプログラムの実行に必要ないにもかかわらず参照が残ってしまい、メモリがうまく開放できないときに起こる。メモリリークが起きるとGCが頻繁に起こる。
- メモリリークが発生してるとわかった場合は原因の特定に務める
- ファイナランザfinalize()メソッドをoverrideしてGC回収前に行う処理を実装できる
システムトラブル
- システムトラブルの原因として考えられること
- リソース不足
- コネクションやスレッドのプール数不足
- GCへ与えるスレッド数が足りずCPUを使い切れていない
- GCはヒープの空きメモリ量が少ないと頻繁に実行される。つまり生きてるオブジェクト（参照があるオブジェクト）が大量にあり、空きヒープがないとGCが頻発する
- GCの種類によってはGCが発生中はアプリケーションが停止する。
- 停止問題にはスループット（単位時間(1秒とか）)あたりの処理量）とレスポンスタイムの２つの観点からの対処アプローチ方法がある
- １処理のレスポンスタイムは同タイミングでGCが発生する可能性があることを考えると、最悪GCの実行時間+処理の実行時間になってしまう
- スループットを求める場合は、GCの回数を減らして一回あたりのGCの時間は長くなるが、トータルとして単位時間あたりのGC実行時間は減らせばスループットが上がるというアプローチ
- レスポンスタイムを短縮したい場合はGCの回数は増えるが、一回一回のGCは短い時間で終わるため、アプリケーションのレスポンスタイム（処理の実行時間+GCの実行時間）は短く保てる
3つのGC
- シリアルGC
- パラレルGC
- コンカレントGC
- アプリケーションスレッドを停止せずにGCスレッドを動作させる方法
- アプリケーションスレッドの停止時間が短縮できる。しかし完全に停止時間をなくすことはできない
GCの４つのアルゴリズム
技術日記5/27-5/31
（めっちゃ亀ログ...）
今週はstaging環境作った
skaffold devでローカルのコード反映させるときにimageのtagとか意識しなきゃいけないのが結構つらみ..
Kotlin Ktorでサーバー作ってるけどspring bootのプロファイルみたいに便利に環境毎にpropertiesの値を切り替える方法は流石になさそう
とりあえずKoinでmodule定義するときに環境によって切り替えるようにした
マイクロサービスの開発においてgrpcのデバッグツール（クライアントツール）があったほうが良さそう
とりあえずGUIで使いやすそうでスター数、メンテ状況からbloomrpc使ってみてる
ただprotoファイルのimportがフォルダまたいでできないみたいなのがちょっと微妙かも
IntteliJ使ってたとき急にcommnad+shift+Aでコマンド検索するときターミナルが開くようになった
なんかmacのアプデでショートカットが追加されててそれと競合してたみたいなのでソッコーで無効化
Knativeのpodをkillしてもまた復活してくる
ksvcを削除したら大丈夫
spring-boot-gradle-pluginのアップデートでdistTarタスクがなくなって既存のビルドジョブが動かなかった問題も解決した
application pluginを使うとうまいことやってくれると docs.spring.io
Distributing with the application pluginのところにapplication pluginを使えと書いてあった
graphql java tools使ってgraphqlsファイルでスキーマ定義してるんだけど、schemaのコメントがうまく反映されない。バグ？
作業ログのとり方変えた
今週から作業ログのとり方を変えてみた 今までslackの個人chにログ書いてたけどslackだと他の部屋を行ったり来たりする必要があり
作業ログは取りたいときにサッと書きたかったのでそういった意味でいちいち個人chを都度開くというのがめんどくさかった
なので今はboostnoteを使うようにしてみた
上記の手間がなくなったおかげか今までより細かく作業のログを取るようになった
markdownで書けるしフォルダ管理も嫌いじゃない
ただ検索がファイル名検索とファイル内検索別々なのでそのへんがちょっと微妙かも（一発の検索でファイル名検索かつファイル開いたらファイル内の検索ワードもハイライトしてほしい）
それと作業ログなので書き込んだ時刻が勝手に記入されたほうがいい気もするのでその点ではやっぱslackがいいのかも、とか思った
あんま良いツールも見つからないのでもうこうなったら専用のエディタ自分で作るしかない？
とりあえずログのとり方が変わって今までより情報の整理ができるようになった気がする
Nginx Unit
Nginx Unitとか言うキーワードを初めて見たので軽くググって調べたことをメモ程度に軽く残しておく
この図イメージ掴みやすい
