Posts

ことはじめ チーム開発演習で、SpringBootのMapperファイルを書いていたんですよね。Mapper.xmlってやつ。 んで、ここがおかしくてバグが生じていたんだけど、JOINについてちゃんと理解していなかったからだった。 JOINには色々あってさ、inner joinとかouter joinとか。 たくさんのテーブルを繋げまっくる時って、どのJOINにするかが大事って話だ。 まずはすごくわかりやすい図があるのでそれで学んでくれ Left JoinとInner Joinをミスっていた。 SELECT I.ITEM_ID, I.ITEM_NAME, I.DESCRIPTION, I.PRICE, I.IMAGE AS ITEM_IMAGE, I.UPDATED_AT AS ITEM_UPDATE_AT, I.CREATED_AT AS ITEM_CREATED_AT, I.DELETE_FLAG AS ITEM_DELETE_FLAG, COUNT(I.ITEM_ID = L.ITEM_ID) AS LIKE_COUNT, U.USER_ID, U.EMAIL, U.PASSWORD, U.PROFILE, U.IMAGE AS USER_IMAGE, U.DELETE_FLAG AS USER_DELETE_FLAG, U.UPDATED_AT AS USER_UPDATED_AT, U.CREATED_AT AS USER_CREATED_AT, U.USER_NAME, C.CATEGORY_ID, C.CATEGORY_NAME, C.UPDATED_AT AS CATEGORY_UPDATED_AT, C.CREATED_AT AS CATEGORY_CREATED_AT FROM ITEMS I LEFT OUTER JOIN USERS U ON I.USER_ID = U.USER_ID LEFT OUTER JOIN CATEGORIES C ON I.CATEGORY_ID = C.CATEGORY_ID LEFT OUTER JOIN LIKES L ON I.ITEM_ID = L.ITEM_ID WHERE I.ITEM_ID = #{itemId} GROUP BY I.ITEM_ID これ長いけど非常にいいSQLだよね。学ぶことがいっぱいある。それは置いておいて、ここのLEFT OUTER JOINのところ、普通のJOINにすると共通部分しか出て来なくなってしまうんだよね。 で、どこに問題が潜んでいるかというと、 ...

事始め 新卒研修も終わりに近づき、配属が近くなってきた。 研修を受けて学んだことも多くあったので、忘れないように記事を書こう。 全職種共通研修についてはここではハブらせてもらう。 研修のスケジュール Java Spring boot Server + linux 個人での開発 チームでの開発 Java Javaで学んだことは、 そうだなー、すべてがクラスだってことかな。慣れてくるとそんなに悪いものでもない気がする。 ただ、マルチスレッド処理の記述方法がほかの言語とは違うからちょっと気を付けた方がいいかもしれない。 ああ、あとすごく勉強になったのはインターフェースだね。インターフェースを使うことでクラスのインターフェースを定義できる。 どういうことかというと、 インターフェースによって、ポリモフィズムを実現できる、という話だ。 ポリモフィズムとは「メッセージが同じでも、それを受け取るオブジェクトによっ て動作が異なること」だからね。 インターフェースを作っておいて、それを実装するクラスを作る、んで、インターフェース名で変数を作っておいて、そこに紐づけるオブジェクトは、 インターフェースを実装したクラス。これによって、例えば、インターフェースを配列で保持して、各要素ごとに同じメソッドで違う処理をさせることができる、っていう話だね。ハイハイ。 Spring boot ここはいろんなことを学んだね。 DIという概念 単体テストという概念 WEB開発でのレイヤードアーキテクチャの話。 DIをすることでコンポーネント間の依存関係を疎結合にできる、って話だな。インターフェースを定義しておいて、その実装を注入する。 注入されたコンポーネントを使う側のクラスは、何を注入するかだけを考えればいい。中の実装はどうでもいい。だからテストと本番で切り替えることもできる。 あとは単体テストだね。今までは全く意識してこなかったが、確かに、各メソッドについて簡単な単体テストを書いた方がいいに決まっている、という話だな。 WEB開発でのレイヤードアーキテクチャ。これもだいぶいい学びになった。そうね、UIとAPIに分けて開発するっていうのもめっちゃ勉強になったし、その中でも特にAPIでController + Service + repository + Mapperに分けてやるってのだいぶ勉強になった。これからもこのレイヤーは守って進めていきたいなって感じだな。 server + linux ここは特に学んだことはないかなーー。でも、SQLのjoinについてはかなり学んだのでjoinとかそのあたりかな、だから改めてページを作ってまとめていきたいよね。あーー、あとはCI/CDについても学んだな。これはだいぶいい学びだった。Jenkinsを学んだね。しかし、Github Actionsの方がよさそうっていう感想。これも改めてまとめたいね。 個人開発 Spring bootの演習でやったことを個人でもう一回やるって感じだった。ただ、Javaを使ってWebシステムを構築する方法がわかったね。 チーム開発演習 これはマジで勉強になった。特にチームでの開発方法、めっちゃ勉強になった。作業分担の仕方だね、 うちのチームではコンポーネントの依存関係を意識してタスクを振ったけど、これが完全にはまったね。横軸を機能、縦軸をそのサービスを実現するためのコンポーネント（Controller, Service, Repository）で見た時、バックエンドは縦の依存関係が圧倒的に強かった。そもそも縦の依存関係は必ず生じるのだけれどもね。一方で、フロントはほかの機能との横断的な依存関係が多かった（それもそうだよね、APIっていう道具を使ってフロントの人は処理するからね）。こういうときはいっそレイヤーごとに担当を分けてしまった方がすっきり行く。特に最上位層はユーザがみるデザインなわけで、そこを一人の人が開発したのはデザインに統一感が出せてむしろ良かったって話だよね、マジで。 あとは、設計と見えるかの重要性かな。とくにMiroを使って、ワイヤー、そしてそれを実現するための機能、その機能を実現するためのコンポーネント、とか、レイヤードアーキテクチャを設計するときの方法、めっちゃ勉強になった。 あとは、タスク管理ツールだね。GithubのProjectを立ててIssue化することができるって話よ。んで、Git + Githubについてもマジでいろんなことを学んだね。チームメンバーでgitに詳しい人がいてね。それもまとめておきたいね。 うちのチームはかなりスピーディーに開発が進んだけど、これはひとえに設計をちゃんとやって、みんなで共有できたから。この開発方法は一生の宝になると思う。しかし、実現方法がわからないものに出会ってしまったらどうやるのかな。空中分解型アジャイルとかやるのかな。 まとめ Java : インターフェース、ポリモフィズム Spring Boot : DI, 単体テスト、レイヤードアーキテクチャ server + linux : CI/CDツール（Jenkins, Github Actions）, SQLのjoinやgroup by　（個別の記事として出す） 個人開発演習：なし チーム開発演習：タスクの振り分け方、Miroを使って設計を見えるかすること、タスク管理をgithubですること。 (Gitの使い方として新しい記事を出す)

2024/06/14時点でのタスクリスト 開発関係 Jc_Data_checkerがうまく動いてないらしいから、原因を究明してすぐに直してくれ。一体なんでなんだ！！ったく！！–> 修正しました。原因は、HTMLの表示形式が変わって、正規表現で抜き取れなかったことでした。 配信サーバを作ってくれ！！これ、mediasoupeっての使えば行ける –> なんか、ffmpegを使って配信サーバにpublishして、chromeからHLSで動画を見ることができた。ーー＞次は本格的なyoutubeを作ってみよう！って感じやな。 レジュメを作ろう。業務委託を取るために。簡単には作りましたって感じですね。 JC_booking_centerを早く稼働させてくれ –> jc_licence_translationを早く作ってくれ。 La_keibaのTODO LISTをすべて解消してくれ Go言語でdistributed file systemを作ってくれ！このyoutubeを見て 研修で作ったフリマアプリ、まるまる自分のものにしよう。じっさいしてええやろ。 その他 確定拠出年金どうするか早く考えてくれ！6/19までだぞ？！ 企業型確定拠出年金で、マッチング拠出（個人で拠出すること）をする方法を調べてくれ。ちなみに、マッチング拠出とideco(個人型確定拠出年金)の併用は不可能だ。–> 新卒だからまだ無理っぽい？ ニトリでソファーを頼んでくれ –> ネットで頼まないとダメっぽい 研修で学んだことをブログにまとめてくれ！！高解像度で！特に個人的に学びが多かったSQL周り！よろしく！–> とりあえず全体を通しての反省みたいなのは書きました。あとは個別のトピック別に。 実家に健康診断のチケットを取りに行け！ APDCMのJournal書いてくれ！！ 毎日筋トレしてくれ。ジムに行ってくれ。朝がいい。 毎朝早く起きてくれ。23時に寝て0630に起きる生活ができると最高だ。 早く業務委託で何かしらの案件を取ってきて売れ。 なんかいい研究ネタがないか、せんせいにきいてくれ！配属されたら意外と退屈しないかもしれないけど。。。 早くyoutubeチャンネル開設して、経費生活を始めてくれ！ 長期目線 宅建を取ってくれ！！(令和6年7月1日（月）9時30分から7月31日（水）23時59分まで) 簿記2級とってくれ！ 土地をどこに買うかかんがえてくれ！！そして貯金しろ！！マジな話、生活費8万と、共通貯金口座2万以外は全部あっちに回してくれ。

ブログの引っ越し ブログ引っ越した。 家の引っ越しをして自宅サーバからブログを公開できなくなった。 そこで、VPSをレンタルしてそこから配信するように変更。そこからの一発目の投稿。 昔の記事はgithubに保存したので、そこから引っ張ってきて普通に見られるようにした。 hugoのアップデート hugoのアップデートに伴い、昔のraspiで動かしていたhugoのバージョン (v0.54.0) から、v0.127.0にアップグレード？？いやなんか、ダウングレードされてね？どゆことや。。。まあそれはさておき、何が言いたいかというと、 バージョンが変わったから使用方法も少し変わってしまったということや。新しいポストの作り方だけ覚えておけば問題ないかな？ ポストの新規作成方法 ~/hugo_site、つまり、contentとかがあるディレクトリ上で hugo new post/new_post_name.md って感じね。まえはpostディレクトリがある場所でこれをやる必要があったけど、変わってしまった、という話だ。 その他注意点 brタグは使ってはいけません。バグる。改行したい時は普通にエンター二つで開けてください。よろしく。 テストで改行。うまくいってるみたいね。しかも、ライブ変更してくれる？フロント側も少し担当してくれているって感じなのかな？websockでつながってる？ちょっと検証。あーやっぱりそうだね。ライブリロードって機能でws使ってるみたいや。ええやん。プッシュ通知できて。 その他知っておいた方がいいTIPS hugoの設定関係 archtypes/default.mdを変更するとデフォルトで生成されるmdファイルを変更することが可能。yamlに変更。 Categoriesを各記事ごとに作ることができる。しかし、ホットリロードはされない模様（カテゴリ一覧から検索することは不可能である）。だから、カテゴリーを反映させたかったら、サーバを再起動する必要がある。 sslの設定方法

です 恥ずかしながら、この年になりまして、初めてgitのコミットを取り消したので、やり方を記録しておきたいと思います。 1. コミットを何個さかのぼりたいかを決める git rebase -i HEAD~n nに何コミット分さかのぼりたいかを書きます。例えば、3コミットさかのぼりたかったら git rebase -i HEAD~3 って書きます。次です。 2. 実際にどのコミットを取り消すかを決める 以下のようにテキストエディタが出てきます。 pick 1234567 Commit message for commit to keep drop 9004867 Commit message for commit to remove ただ、pick -> dropに変更するとそのコミットが取り消されます。

共通言語を学ぶ なんでか知らんけど、javaが共通言語になっているみたいなんだよね。 理解不能なんだけども。 ということで、軽くやりますかね。 環境構築から Javaの精神は、「ビルドワンス、らん絵にウェア」だった気がする。 つまり、OSごとに新たにコンパイルしなおしたりしなくていいってことなんだけど、 まあ、そういうのを実現するためには、新しいレイヤーを一枚かませないとだめなんだよね。 それが、JVMだね。 JVM (Java Virtual Machine) は、1 つの命令セットを持ち、メモリーを使用する抽象的な演算マシン。 で、JvMは、JVM専用のファイルじゃないと走らないって思っているんだけど、そうだよね？ javacで、コンパイルして、JVMが読める形式に変換して、javaコマンドで実際に動かすって感じかな？ で、JVMが読める形式っていうのが、classファイルだったと思うんだけど、どうなんかな。 そうですね。 で、.classはどのjvmでも動くようになっているんですね。つまり、一度コンパイルされたソースコードは、 jvmがあるおかげでどこでも動くって話だ。 で、よく見るjarファイルってのが、.classがいっぱい入っているzipファイルなんだよね。 あれ、java -jarとかですぐ実行できるやん？そういうことや。 JDK = java development kit これには何が入っているんだ。はい、わかりやすいね。 このきーた が。 JDKはJREを内包している。そして、JREはJVMを内包している。 JDKはコンパイラとデバッガを内包している。 つまり、JDKはjavacとを含んでいる。 んで、JREはjava runtime environmentだから、jvmとc/c++でいう標準ライブラリを含んでいる。 javaコマンドは、JVM上で.classファイルを動かすためにあるんだと思う。そんな気がする。そうです。 つまり、結局はJDKをインストールすればコンパイルと実行はできるようになるってことです。 sudo apt install openjdk-17-jdk-headless これで、jreを入る。 環境構築完了。 補足知識 「具体的には、jarファイルはコンパイル済みのclassファイルや画像などのファイルを、zip形式に圧縮してまとめたファイルです。」 コンパイルから実行までのながれ まず、ソースコードを書きます。拡張子は、.java class Hello { public static void main(String[] args) { System.out.println("初めてのJava program"); System.out.println("画面に表示"); } } で、ファイル名は、クラス名と一致させるのがいいみたいですね。つまり、ファイル名は、Hello.javaになります。 で、javacで中間コードにコンパイルします。 javac Hello.java 出てくるのは、Hello.classってファイルです。 んで、実行するときは、 java Hello だけでいいっす。 でも、じつは、 ...

事始め 例のシステムで、tcコマンドでネットワークレイテンシーを増加させたんですけどね。 そしたら、たったの100msの遅延だったんですけど、64MiBのデータを送信するときに、 アプリから見た時の遅延の時間がなんと1sくらいまで伸びてしまったんですよね。これ、めちゃめちゃ面白い話で、深堀りする価値があるんです。 もしかしたら、ロングファットパイプ問題についても、わかるかもしれないね。 まず、TCPの基礎、どうやって動いているのかを理解する必要がある。 が、せっかくなので、もう一回上からやろうか。 アプリケーションレイヤーから、どうやってデータが通信相手まで伝わるのか、ってのをもう一回確認して、 本題のTCPレイヤーのMTU,MSS,windowサイズについて話した後、tcpダンプの使い方を調べ、最後に実際にTCPダンプをして、 例のシステムにおいて、サーバ・クライアント間で100msの遅延が生じているときのデータのやり取りについてみてみましょう。 OSIモデル、プロトコルスタックについて確認 まず、プロトコルスタックとは「コンピュータネットワーク用のプロトコルの階層」のことです。 OSIモデル(7層) で見ていくのが大事そうですね。上から、アプリケーション層、プレゼンテーション層、セッション層、トランスポート層、ネットワーク層、データリンク層、物理層。 アプリケーション層では、具体的なサービスを提供。HTTPとか、websocketとか、FTPとか、SSHとか、その他いろいろ。 プレゼンテーション層は、データのフォーマットを定義する？そうですね。エンコードの方法とか。これはおそらくまだOSレイヤーの話ではない。 ここからがOSの世界の話。 セッション層は、connect(sockdrp,IP)で、コネクションを確立したときに、コネクションの相手を覚えておく層、だと思っていい。 つまり、ソケットのことです。ソケットが通信相手の情報を覚えておきます。 ソケットは、OSによってプログラムのされ方が違うらしいです。それでも異なるOS同士ど通信ができるのは、トランスポート層で規定されているプロトコルにすべてのOSが準拠しているからです。 トランスポート層 (L4) が、TCP / UDP です。TCPでは、アプリケーションからもらったデータを小分けにして、通し番号を付けて、 小分けにしたデータをちょっとづつ送ります。小分けにされたデータが、いわゆる「パケット」です。 再送とかもする。信頼性が高いのです。その代わりスループットは悪くなります。 一方、UDPはデータを投げっぱなしにします。信頼性は低いですが、スループットは高くなります。VoIPなどに使われますね。 L4ではまだ、IPは指定しません。 その下、ネットワーク層が、IPです。ルーティングを決めてくれます。 その下、データリンク層が、イーサネットですね。L2TPとかをするVPN、ありますよね。あれはね、このレイヤーで動いているんですよね。 その下、もう物理層です。L1です。 L4、トランスポート層のTCPについてもう少し詳しく見ていく まずは、TCPヘッダーのフォーマットを見てみましょう。 送信元ポート番号：16bit 送信先ポート番号：16bit シーケンス番号：32bit ACK番号：32bit データオフセット：4bit 未使用：6bit コントロールビット：6bit ウインドウ：16bit チェックサム：16bit 緊急ポインタ：16bit オプション：可変長 いろいろありますが、ここでまず注目したいのは、通信相手のIPアドレスがないってことですね。 なぜなら、それはL3が担当するからです。 その他、自分的にまだ理解が完ぺきではないけど大事そうなのは、シーケンス番号、ACK番号、コントロールビット、 ウィンドウの、４つですね。それぞれについて説明していきます。 シーケンス番号 「このパケットの先頭のデータが送信データの何バイト目にあたるのか送信側から受信側に伝えるためのもの」 TCPではデータを小分けにして送りますね。パケットです。で、何バイト目か？って話ですね。32bitしかないってことは、 2^32/1024/1024/1024 = 4GiBしか一回で送れないってこと？まじ？？まあいいや。そんなことはないと思うけどね。 ACK番号 「データが何バイト目まで受信側に届いたのか、受信側から送信側に伝えるためのもの。」だそうです。 コントロールビット URG:緊急ポインタ ACK:データが正しく受信側に届いたことを意味する PSH:FLUSH動作によって送信されたデータである RST:接続を強制的に終了：異常終了 SYN:送信側と受信側で連番を確認しあう。これで接続どうさを表す FIN:切断 ウィンドウ 「受信側から、送信側にウィンドウサイズ (受信確認を待たずにまとめて送信可能なデータ量) を通知するために使う。」 これが16bitであるのが、もんだいなんですよ！！ 以上を念頭に次に進みます。 TCPが接続を開始して、データを送信し、切断するまで はい。一言でいうと、 「TCPはスループットを犠牲に、信頼性を高めた通信プロトコル」です。 信頼性を高めるために、されている工夫が２つあるんですね。それが、 3ウェイハンドシェイクと、パケット送信時の受け取り確認です。 （UDPはスリーウェイハンドシェイクも、受け取り確認もしない） ...

めも 研究を通してやったソフトウェア開発で学んだこと まあ、やっぱりアジャイルっぽくはなるので、試作を作って、それを改良していく感じにはなります。 ただ、これだけは忘れないでほしい。試作を作る段階で今後の可能性を狭めない方がいい。 いや、具体例を一言でいうと、ハードコーディングするな。マジで。そのときはいいかもしれないけど、あとで見つけるの、マジでだるい。頼む。 具体例 いやね、tolを変えて評価したいんですわ。でもね、L3prefetcherのところ、tolがハードコーディングされてるのよね。0.1で。これを変えるのがめんどくさすぎるーーーー。

gdbを使えるようになりたい デバッガは使えた方がいいですよ。ステップ実行とかね。まあ、ちゃんとしたソフトウェア開発っやったことないんで、いまいちピンとこないんですよね。でも、大事なことには変わりないです。頑張りましょう。 python3から、c++の共有ライブラリを呼び出すときにおこったバグの見つけ方 chatgptさんに聞きました。 The error message "munmap_chunk(): invalid pointer" typically indicates a memory corruption issue or a double-free error. It means that at some point during the program's execution, it is trying to deallocate memory that has already been freed or that was never allocated in the first place. To identify the exact point where the issue occurs, you can follow these steps 1:Enable address sanitizer (ASAN) in your C++ code to help detect memory issues. You need to recompile your C++ library with ASAN flags (-fsanitize=address) and then rerun your Python script under GDB. ASAN will provide more detailed information about memory errors. Modify your CMakeLists.txt to include ASAN flags: set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -g -fsanitize=address") Then rebuild your C++ library. 2: Run your Python script again under GDB with ASAN enabled: gdb -ex r --args python3 crash.py

makeの高速化 cmake ..でmakeファイルを生成して、最後にmakeすると思うんだけど、これ、高速化する技があるんですね。 make -j <number of cores> で、めっちゃ高速化されます。