Posts

2024/07/5時点でのタスクリスト 開発関係 研修で作ったフリマアプリ、まるまる自分のものにしよう。じっさいしてええやろ。 JC_booking_centerを早く稼働させてくれ、同時にjc_licence_translationを早く作ってくれ。 La_keibaのTODO LISTをすべて解消してくれ。TODOの解消はもういいから、ラズパイでk8sクラスタを完成させてくれ。んで、そのうえでこのサービスを展開して。さらに、blog.ingenboy.comの8080をsite to siteのトンネルを通してうちのk8sクラスタにつなげる感じにしたらめっちゃおもろないか？？えぐいよね。 Go言語でdistributed file systemを作ってくれ！このyoutubeを見て Grafanaを使っていろいろと可視化してみたい。DBは自分で用意する必要があるのかな？？ 分散システムの勉強を続けてくれ。頼む。 buy raspberry pi 5 and run k8s on it using ansible. Monitory the above k8s system using grafana and prometheus and make it possible to access the server from outside. その他 APDCMのJournal書いてくれ！！たしか、July 30が締め切り。やらないとなーーー。せっかくだからjournal一本出したいよね。 毎日筋トレしてくれ。ジムに行ってくれ。朝がいい。 毎朝早く起きてくれ。23時に寝て0630に起きる生活ができると最高だ。 早く業務委託で何かしらの案件を取ってきて売れ。 なんかいい研究ネタがないか、せんせいにきいてくれ！配属されたら意外と退屈しないかもしれないけど。。。やっぱり分散ストレージとか、分散システムとか、なんか知らんけどその辺にすごいひかれる。そもそも分散しているのに強調して動くシステムはすごく惹かれる。k8sとかね。しかしk8sはあまりにもインフラすぎる。できればもう一つ上のレイヤーで動く何かが作りたいって話だ。 早くyoutubeチャンネル開設して、経費生活を始めてくれ！ 今の部署との付き合い方 ほとんどコードを書くことはない。 なので、コードを書かないとコーディング力はみるみる落ちていくと思われる。 しかし、そのようなことが起こってはいけない。マジでだめ。 つまり、自分でどうにかしてコーディングをしないといけない。一日、7.5hは仕事をする必要がある。 このうち、仕事自体は6hで、んで、自分のタスクに2h-2.5hかけられるといいね。 自分のタスクを何にするか？それがすごく大事。まあやらないといけないタスクは実際たくさんある。上のやつね。 それを一つ一つやっていくしかないかな。インプットもちゃんとやっていこうな。 これだけど、分散システムを勉強する時間にする。よろしく頼む。もう一回、本気で分散システムを勉強しようって思った。 ...

何の記事 vpnサーバに接続してきたvpnクライアントがいるネットワークに、vpnサーバからアクセスできるようにする方法の手順を解説 ちなみに、これはCloudflaairとかいう会社が提供しているzero trustっていうサービスと同等のことを可能にしてくれる。 初めに VPNサーバを立てて、VPNクライアントのパケット通信をVPNサーバを通すようにすることはできていた。 これによって、クライアントはサーバと同じネットワーク上にいるかのようにふるまうことができていたわけだね。 しかしこの逆ができなかったのですよ。 つまり、 サーバがクライアントのネットワークにいるかの如くふるまうように設定することがずっとできなかったんですよね。 その必要性も当時はあまりなかったからね。 だが、この度新しいおうちに引っ越して、「単一のグローバルipが与えられておりポート開放できるルータがある」環境を失ってしまった。 外からアクセスできないんですよね、今のうちのネットワーク環境だと。 家の外に借りたVPSは結構あって、そこにVPNサーバを立てることはできる。 そこで今まで試したけど挫折してきた、「隔絶されたネットワークに、そのネットワークにいるvpnクライアントを介してアクセスする方法」。 今回はそれを可能にする方法を教えます。 ちなみに、二つの異なるネットワークセグメントをvpnサーバとvpnクライアントを使って完全につなげることを、 「site to site routing」といいます。マジでかっこいいですね。あこがれちゃいます。そんな憧れを、今回、達成してしまうんです。 これによって、「remote.it」のように、ポート開放をしていない、隔絶されているネットワーク環境に、外からアクセスできるようになるんです。えぐいですねーーー。えぐい。とにかくえぐい。 参考記事 記事1 記事2 openVPN公式 site2siteに関しては二つ目がかなりいい感じにまとめてくれています。 まずはいつも通り普通にopenvpnサーバを立てる OpenVPNとeasy-rsaのインストール sudo yum install openvpn easy-rsa -y easy-rsaを使って証明書関係を作る ./easyrsa init-pki ca証明書を作成 ./easyrsa build-ca *ca証明書＝認証局(ca)証明書。 認証局(CA)とは、ウェブサイトやその他の独立した存在などに、デジタル証明書を発行する信頼できる組織。 できたら移動しておく cp pki/ca.crt /etc/openvpn diffie-helman parameterを生成 ./easyrsa gen-dh 移動しておく sudo cp pki/dh.pem /etc/openvpn Certificate Revocation List (CRL) を生成 ./easyrsa gen-crl OpenVPN Serverように証明書と秘密鍵を生成　（サーバ証明書の生成） ./easyrsa build-server-full server nopass 移動しておく sudo cp pki/issued/server.crt /etc/openvpn sudo cp pki/private/server.key /etc/openvpn クライアント証明書と秘密鍵を生成 ./easyrsa build-client-full username 各コマンドの詳しい説明 ./easyrsa build-ca ./easyrsa build-ca コマンドは、 Easy-RSAツールを使用して 新しい認証局（CA）のルート証明書と秘密鍵を生成するためのものです。 認証局は、VPN証明書を発行および署名するために使用されます。 このプロセスは通常、VPNサーバーをセットアップする最初のステップの一つです。 具体的には、このコマンドは以下の操作を行います： CAの秘密鍵の生成：認証局（CA）の秘密鍵を生成します。 この鍵は、CAによって発行される証明書に署名するために使用されます。 CAの自己署名証明書の生成：CAの自己署名証明書を生成します。 この証明書は、CA自身が正当な認証局であることを証明します。 このコマンドを実行すると、以下のファイルが生成されます： ca.crt: CAの自己署名証明書 ca.key: CAの秘密鍵 これらのファイルは、VPNサーバーの証明書発行および署名プロセスで使用されます。 具体的には、CAの秘密鍵 (ca.key) は秘密に保管されるべきであり、 CAの証明書 (ca.crt) はクライアントと共有され、 クライアントはこれを使用してサーバー証明書の有効性を検証します。 証明書には公開鍵も含まれていると考えていいです。 ./easyrsa build-server-full server nopass ./easyrsa build-server-full server nopass コマンドは、Easy-RSAツールを使用してOpenVPNサーバーの証明書と秘密鍵を生成するためのものです。このコマンドは、サーバー証明書を生成し、その秘密鍵にパスフレーズを設定せずに保存します。 具体的には、このコマンドは以下の操作を行います： サーバー証明書の生成：指定された名前（この場合は server）でサーバー証明書を生成します。この証明書はサーバーがVPNクライアントに自身を証明するために使用されます。 サーバーの秘密鍵の生成：サーバー証明書と一緒に使用される秘密鍵を生成します。この秘密鍵は、VPN接続を暗号化するために使用されます。 証明書署名要求（CSR）の作成および署名：証明書署名要求（CSR）を作成し、それを認証局（CA）で署名することで有効な証明書を生成します。 パスフレーズの省略：nopassオプションにより、生成される秘密鍵にはパスフレーズが設定されません。これにより、サーバーが起動するたびにパスフレーズを入力する必要がなくなります。 このコマンドを実行すると、通常、以下のファイルが生成されます： server.crt: サーバー証明書 server.key: サーバーの秘密鍵 server.req: 証明書署名要求（CSR） これらのファイルは、OpenVPNサーバー設定に必要なものであり、適切に保管されるべきです。特に、server.key は秘密に保つ必要があります。 ./easy gen-dh ./easyrsa gen-dh コマンドは、Easy-RSAツールを使用してDiffie-Hellman（DH）パラメータを生成するためのものです。DHパラメータは、VPNサーバーとクライアント間で安全にキー交換を行うために使用されます。これにより、セッションごとに異なる鍵が生成され、通信のセキュリティが強化されます。 具体的には、このコマンドは以下の操作を行います： Diffie-Hellmanパラメータの生成：DH鍵交換プロトコルに使用されるパラメータを生成します。これらのパラメータは、安全な通信チャネルを確立するために必要です。 生成されたファイルの保存：生成されたDHパラメータは、VPNサーバーの設定で使用されます。 このコマンドを実行すると、以下のファイルが生成されます： dh.pem: Diffie-Hellmanパラメータ ./easyrsa gen-crl ./easyrsa gen-crl コマンドは、Certificate Revocation List (CRL) を生成するためのものです。CRLは、無効または失効された証明書のリストを保持し、認証局（CA）が管理します。 具体的には、このコマンドは以下の操作を行います： CRLの生成：現在の認証局の設定に基づいて、新しいCRLファイルを生成します。このファイルには、CAによって失効された証明書のリストが含まれています。 既存の失効証明書の確認：CRLを生成する際に、すでに失効されている証明書が正しくリストに含まれていることを確認します。 CRLは、VPNサーバーやその他のサービスがクライアント証明書の有効性を確認するために使用されます。具体的には、クライアントがVPNに接続しようとする際、サーバーはそのクライアントの証明書がCRLに含まれていないことを確認することで、失効された証明書による不正アクセスを防ぎます。 生成されたCRLファイルは通常、crl.pem という名前で保存されます。このファイルは、VPNサーバーの設定に組み込まれる必要があります。例えば、OpenVPNサーバーでは、crl-verify オプションを使用してこのCRLファイルを指定します。 ./easyrsa build-client-full username このコマンドは、Easy-RSAツールを使用してOpenVPNクライアント証明書と鍵を生成するためのものです。具体的には、build-client-fullコマンドは以下の操作を行います： クライアント証明書の生成：指定されたユーザー名（この場合はusername）に対して、クライアント証明書を生成します。証明書はクライアントがVPNに接続するために必要なものであり、認証局（CA）によって署名されます。 クライアントの秘密鍵の生成：クライアント証明書と一緒に使用される秘密鍵を生成します。この鍵は、クライアント証明書とともにVPN接続を確立するために必要です。 証明書署名要求（CSR）の作成および署名：証明書署名要求（CSR）を作成し、それを認証局（CA）で署名することで有効な証明書を生成します。 このコマンドを実行すると、通常、以下のファイルが生成されます： username.crt: クライアント証明書 username.key: クライアントの秘密鍵 username.req: 証明書署名要求（CSR） これらのファイルは、VPNクライアント設定に必要なものであり、適切に保管されるべきです。クライアントはこれらの証明書と鍵を使用してOpenVPNサーバーに接続し、暗号化された通信を確立します。 以上の鍵が生成される順番と、これらのカギを使って実際にクライアントがサーバとコネクションを張り暗号化された通信をするまでの流れ 1. 接続の確立 クライアントがVPNサーバーに接続を試みます クライアントはVPNサーバーに接続リクエストを送信します。 2. サーバーの証明書を検証 クライアントはサーバーから送られてきた証明書 (server.crt) を検証します。 クライアントは自身のCA証明書 (ca.crt) を使用して、 サーバー証明書がCAによって署名されていることを確認します。 この検証により、 クライアントは接続しようとしているサーバーが信頼できるものであることを確信します。 3. クライアントの証明書を検証 サーバーもクライアントから送られてきた証明書 (username.crt) を検証します。 サーバーは自身のCA証明書 (ca.crt) を使用して、 クライアント証明書がCAによって署名されていることを確認します。 サーバーはさらに、クライアント証明書が失効していないことをCRL (crl.pem) を用いて確認します。 4. 秘密鍵の使用 クライアントとサーバーのそれぞれの秘密鍵（username.key と server.key）は、相手の証明書と合わせて使用され、相互認証を実施します。 サーバーの秘密鍵（server.key）は、サーバーが送信するデータのデジタル署名と暗号化に使用されます。 クライアントの秘密鍵（username.key）は、クライアントが送信するデータのデジタル署名と暗号化に使用されます。 5. 鍵交換とセッションの確立 Diffie-Hellman鍵交換プロトコルの使用 クライアントとサーバーは、Diffie-Hellman鍵交換プロトコルを使用して、セッション鍵を安全に交換します。 このプロセスでは、サーバーの dh.pem ファイルが使用されます。 セッション鍵の生成 Diffie-Hellman鍵交換によって生成されたセッション鍵を使用して、クライアントとサーバー間で安全な通信チャネルを確立します。 これにより、以降の通信が暗号化されます。 暗号化された通信の開始 暗号化された通信の開始 セッション鍵が確立された後、クライアントとサーバー間の通信は暗号化されます。 以降のデータは、このセッション鍵を使用して暗号化・復号化されます。 各通信データは、相手側の公開鍵で暗号化され、自身の秘密鍵で復号化されます。 VPNサーバの起動 sudo systemctl stop openvpn サーバがうまく起動できないとき こっちで試してみるのもありかもしれない。 ...

ことはじめ チーム開発演習で、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で。これを変えるのがめんどくさすぎるーーーー。