事始め いやね、何回もreactを勉強しなきゃな！と思いつつも、実際に始めると、結局はhtml + css + vanila jsでやってることの管理を容易にするだけのもの、っていう感が否めなくてね。しかもフレームワークだからブラックボックス化されてい持ち悪いしね。 始めるはいいものの、途中で投げ出してしまうことがもう3回くらいあった。 正直、vanilaでもよくね？と思っている節はある。 htmlでid属性を使って名前を付けて、class名をつけることで、bootstrapを使えば一瞬できれいになる。しかしだ。やはりreactが使われているにはそれなりの理由があるのだろう。 ということで、まじめにやってみることにした。 ホワイトボックス化 ってことでね、結局中で何が実行されているかがわかればええやんってことなんだよね。 最終的にブラウザに届くのはhtml + css + jsであることには変わりない。 これはブラウザ側でhtmlを見ればわかる。 index.htmlが呼ばれているんだよね。 で、index.htmlからは、/static/bundle.jsが読み出されている。この/static/bundle.js が唯一のjavascriptファイルになっている。 reactプロジェクトの方では/src/いかにいろいろなコンポーネントを入れることになると思うんだけど、ビルド時にbundle.jsにまとめ上げられるってことなんだよね。それをまずは理解しよう。 開発　ー＞　ビルド　ー＞　一つのスタティックファイルができるって話。そうだそうだ。 /src以下の話 /srcいかにはいろいろなコンポーネントが入っているって話をしたけど、親玉がいるって話なんよ。それが、index.jsな。こいつがすべてのコンポーネントの生みの親ってこと。 親玉の中身を見てみよう。 import React from 'react'; import ReactDOM from 'react-dom/client'; import './index.css'; import App from './App'; import reportWebVitals from './reportWebVitals'; const root = ReactDOM.createRoot(document.getElementById('root')); root.render( <React.StrictMode> <App /> </React.StrictMode> ); うん。document.getElementByIdでidがrootのやつを召喚している。index.htmlには確かにrootというidを持つタグがいる。 で、ReactDOMってやつにコピーしているのか？わからんが。で、root.renderで何かを作っているな。で呼び出しているぞ。。なるほど。ここに次々にコンポーネントを追加していく感じだな。なるほど。ちなみに、root.render()に渡すのが import React from ‘react’; import ReactDOM from ‘react-dom/client’; import ‘./index.css’; import App from ‘./App’; import reportWebVitals from ‘./reportWebVitals’; ...

卒業した後にやりたいこと いや、こういうのを書くのがかなり研究のモチベにつながると思っている 春休み中にやりたいこと 1. 例のシステムをk8s上に展開。いろいろと仕上げないといけないところもあるけど。そして卒業したい。競馬から。あとは井上に任せて。 しかし、機械学習モデルがまだ完成していないのだよ。 ここができない限りは完成しない。。。。くそ!!どうする！！！わからないぜ。。。どうすればいいんだ。 どうやって機械学習モデルを完成させるか。 2. 30日でできるOS自作を読む 3. CMUのデータベースの授業を全部見て、bustubを完成させる 3.5. Linux kernelを自分でビルドしたい！！Linux kernel newbiesを見て！！ 3.6. くそげーセンターを作りたい！！ (しんいちろうにサーバ借りさせて、そのうえでくそげーを展開させてあげれば、だいぶ喜ぶんじゃないか？ しんいちろうにhtml + css + jsも教えよう。まあ、jsだけでいいかな。canvas) 4. Reactをパーフェクトにする！ 5. 卒業前に研究室にLustreを構築したい！けいちせんせいと！ ーー＞Lustreの構築方法は頭に入れておきたいですね。というのも、僕のデータセンターにLustreファイルシステムを立てたいからですね。 入社後にぼちぼちとやりたいこと 6. GPUの神髄を学びたい。みんながこんなに熱くなるのには必ず理由があるのだ。その理由が知りたい。 7. 競馬の次に考えているプロジェクトが旅行だね。historycal_figure_databaseを作りたいって話だ。これも大がかりなプロジェクトになるな。canvasとデータベースが肝になってくると思っている。あとはwikipediaからのデータのクローリングだな。 8. Myサーバセンターを作るか、DIYで。

事始め 研究で開発しているミドルウェアがストレージからの読み出しをするんだよね。しかもparalellに。でもね、なんか知らないけど、paralellの数が3になるとめちゃめちゃ遅延が発生するようになってしまったんだよね。これなんでやと。気になったわけですよね。で、いろいろ調べようと思ったんです。 復習だけど、ファイルシステムとは 物理ストレージにビットを書き込むわけです、保存するためには。ただね、これ、どこにどういう風に書き込むか、というのはすごく面倒くさいんですよね、プログラムから管理するのは。だから、保存操作を抽象化してくれるソフトを作ったわけです。 ファイルシステムというね。ファイルシステムはOSにもともと組み込まれているもので、Linux-kernelを見ると確かにfsっていうディレクトリがある。 で、ファイルシステムはLinux-kernel越しに使うので、I/Oはシステムコールになるって話ですね。はい。 ストレージのパーティションに構築されたファイルシステムの種類を確認 df -Th このコマンドで確認できます。 ストレージへの読み書き速度ベンチマーク ddコマンド The dd command is a simple way to test sequential read performance. You can use it to read a large file in parallel from multiple processes. Here's an example: ってのでもらったexample scriptがこちら # Create a large test file (if it doesn't already exist) dd if=/dev/zero of=testfile bs=1M count=1000 # Use multiple dd processes to read the file in parallel for i in {1..4}; do dd if=testfile of=/dev/null bs=1M iflag=direct status=none & done # Wait for all dd processes to finish wait fioコマンド こっちの方が使いやすいと思う、のでこっちを使うことに使用 ...

事始め フロントエンドを極めたい。 いや、極めたいわけではない。しかし、不自由なく自分のシステムをユーザが使いやすい形に落とし込めるようにはなりたい。それも、そこそこきれいな感じに、バックエンドがどん何すごいことをしていてもユーザが結局使うのはフロントエンドなわけで。。。見せ方がへたくそだから評価が下がるのだけはまっぴらごめんだ。 ってことで買ったのがこの「フロントエンドの知識地図」ってほんなわけですね。はい。まあ、html,css,javascriptの基本的なところはそこそこわかっているんだけれども、一度体系的に学びたいなとね。 とりあえず一回読んだ後の感想 前半はhtmlとcssのグリッドレイアウト以外はためにならない話ばかりだった。 しかし、後半から面白くなっていった。付箋を貼った個所をとりあえず殴り書きさせてくれ。 まずはグリッドレイアウトの話のところだよね。htmlとcssを使って、どの要素をどこに配置するかっていうのが決められるという話だ。これは大事だと思う。 あー、vscodeがwebブラウザ技術を多分に含んでいる、それすなわちwebブラウザが多分にvscodeに技術を含んでいるってことで、githubでvscodeそっくりなテキストエディタが使えるよって話。 はいはい、webのフロントエンドはフレームワークが多すぎてね、何が何かわからないじゃない。で、純粋なjsのことをvanila jsっていうみたいです。 MDNっていうのがhtml + css + jsを用いた開発の辞書みたいなもんやと vanilaで開発しても結局モジュールごとにファイルを分けないと可読性が下がる。だったら、もうReactを使っていいんじゃねーのか、とも思ってきたわけです。 といっても、Jsのフレームワークはあくまでも処理部分をやってくれるフレームワーク。装飾はやってくれない。だから、cssの知識は必要。だけど、タグ内にクラス名を指定するだけで統一感を持たせてくれるのがBootstrapってわけですね。BootStrapは使い方だけは知っておこうよ フロントエンドの知識地図だけど、やっぱりapiのことは説明してたよね。REST,Graphql,RPC全般。まあ、しばらくはRESTでいいよ。簡単だし、なれたし。イケてるIT系のバックエンドではRPCが使われているらしいけどね。 フロントエンドからRESTを使ってバックエンドと通信するときの関数として、fetch APIと、axiosが紹介されています。fetchはブラウザに標準でついている。が、通信機能しか備えていなくて使いづらいのでaxiosの方がいいんじゃね？って言ってます。 CORSについてもちゃんと説明していますね。原則としてwebサイトやwebアプリケーションから、ほかのサーバにあるAPIは読み出せないようになっています。なぜか？これができると、例えば悪意のあるjsスクリプトを入れてamazonの個人情報をゲットしちゃおー！とかができるからですね。でも、corsができないと不便なこともあるよね。その時は、WEBサイトではなく、APIサーバ側 (上の例でいうとamazon側) でcors okをする。 でも思ったんだけど、originがどこかってブラウザが知ってるわけじゃん？つまり、ブラウザをハックすればcorsもできるようになるって話や。 ...

なぜunixドメインソケットはipソケットよりも高速なのか？ っていう話や。まあ、ちょっと事情があってプロセス間通信をしたいんですわ。 でね、わざわざtcp/ipのレイヤーまでもっていかなくてもいいやない、ローカルホスト内の通信だったらね。だからunixドメインソケットを使おうと思っているんだけど。 じゃあ、なんでunixドメインソケットのほうが高速なのかって話だけど、その理由はもう単純で、tcp/ipまでいかないからやな。もう少し具体的に書こうか。 コンテキストスイッチが発生しない まあ、ネットワーク通信ってシステムコールだからコンテキストスイッチが発生するんだよね。 でもドメインソケットはネットワーク通信ではないから、コンテキストスイッチが発生しないって話や networkStackを通る必要がない コンテキストスイッチが発生する以外にネットワーク通信はいろいろとオーバヘッドが大きいです buffer間でのコピーが発生する UnixドメインソケットはsharedMemoryを使って通信する。 って感じや。 でもソケットって扱いめっちゃ面倒じゃないですか。どうやってやるんですか？ わかるー。マジでわかる。httpはsocketの上で作られているからね。扱いが簡単なんだよね。 あー、でも、ドメインソケットを使ってhttp通信をすればいいってことじゃね？いやそうやん！ そうしましょう。そのやり方を教えましょう。 kwi

c/c++のライブラリーとビルドについて ということで、c++でのヘッダーライブラリ関係を全部まとめます。 ソースコードをビルドするまでの流れ プリプロセス(preprocess) #include は、<> 内に指定したヘッダーファイルの中身をソースコード内に組み込むプリプロセッサ指令です。 つまり、定義が書かれていない入出力関係だけが書かれたヘッダーを読み込むことは、プロトタイプ宣言にだいぶ近いものがあると思います。 コンパイル (compile) 入出力関係を保ったまま、ソースコードを アセンブル (assemble) リンク (link) 制御のジャンプ先をここで決めるわけです。 ヘッダーとライブラリはセット 関数をオブジェクトファイルにして、ほかのソースコードから呼び出せるようにしたものをライブラリといいます。 ソースコードはライブラリの入出力を知るために、ヘッダーファイルを使います。だから絶対にセットなんです。 3rd partyのライブラリをどうやって使うか？ ライブラリの配布のされ方はいろいろあると思うが、大きく分けて二つに分けられると思う。 パッケージマネージャーを通してライブラリを配布 githubでソースが公開されているライブラリを配布 どちらも最終的に使うときには、ヘッダーをインクルードして、ライブラリをリンクするんですが、使えるようになるまでが違います。ってことです。 1. パッケージマネージャーを通してライブラリーを入手する方法 これは、aptとかでライブラリを入手するあれです。 例えば、boost libraryとかは、aptで次のようにインストールできるわけですね。 sudo apt install libboost-all-dev で、ソースコード上でプログラムを使いたいときは、例えば、 #include<boost/asio.hpp> でインクルードして、 さらに、ビルド時にライブラリーをリンクするのを忘れないでください。はい。 ただ、boostはどうやらheader-only-libraryということで、リンクする必要はなさそうですね。はい。大丈夫です。 2. githubでソースが公開されているライブラリ githubからソースコードを持ってきてください。 で、最近は大体cmakeがついていますね。cmakeでMakefileを作って、makeでビルドしてください。 最後に、make installでライブラリとヘッダーのデフォルトのサーチパスにヘッダーとライブラリをおいてくれます。ハイよろしく。

ことはじめ Linuxに関するいろいろなことをまとめてあるサイトを見つけたので、自分に有益な部分だけをまとめて行きたいと思う。 参考文献 これです 俺が思うLinux中級者向けのコマンド達 中級者というか、今の時点で俺が知らない、もしくは使いこなせていないコマンドって感じかな。 find ファイルを検索する。 find <検索パス>　-name <ファイル名> ファイル名の一部 的にやるのもだいぶいいと思うけど。 useradd 新規ユーザの作成 id ユーザの確認 stress dmesg lsmod ロード済みのカーネルモジュール一覧を表示する ちなみに、カーネルモジュールとは「カーネルの機能を拡張するためのバイナリファイルです。 例としては、ディスク・ネットワークカード等をLinuxカーネルで使用可能にするためのデバイスドライバなどがあります。 デバイスドライバは各ハードウェアベンダーから提供されることが多いです。 初期のUNIX系OSでは新しいハードウェアを使うにはカーネルの再構築が必要でしたが、 現在のLinuxカーネルは、必要ありません。 起動時に常駐カーネルがメモリにロードされ、必要に応じてロード・アンロードが出来るようになっています。 です。いつか自分でも自作してみたいきはだいぶしていますねー。 modprobe カーネルモジュールのロード、アンロードを行うコマンド 「カーネルモジュールとは、Linuxカーネルの機能の一部を、カーネル本体とは別にロード、アンロードできるように分離したサイズの小さいバイナリファイルです。多くの場合、ハードウェアにアクセスし、操作するためのドライバ部分がカーネルモジュールとなっています。 ドライバ自体をカーネルに組み込む古い方式では、ハードウェア構成を変更した場合に、カーネルの再構築が必要になります。現在では、ほとんどのドライバがモジュールとして提供されているため、ハードウェア構成変更後は、必要なカーネルモジュールをロードしてカーネルに組み込むだけで対応できるようになっています。 modprobeは、モジュールの依存関係を確認し、必要なモジュールがあれば同時に組み込むといった処理も行います。モジュールの組み込みには内部的に「insmod」コマンドを用いており、取り外しでは「rmmod」コマンドを使っています。 」 ってことですね。 FHS (Filesystem Hierarchy Standard)について /bin コマンドファイルが入っている。すべてのユーザが利用するコマンドが保存されているディレクトリ。lsとか、echoとか。 ここに入っているコマンド全部覚えておいて損はないと思いますけどね。 bash fusermount netcat su bunzip2 grep netstat sync busybox gunzip networkctl systemctl bzcat gzexe nisdomainname systemd bzcmp gzip ntfs-3g systemd-ask-password bzdiff hciconfig ntfs-3g.probe systemd-escape bzegrep hostname ntfscat systemd-hwdb bzexe ip ntfscluster systemd-inhibit bzfgrep journalctl ntfscmp systemd-machine-id-setup bzgrep kbd_mode ntfsfallocate systemd-notify bzip2 keyctl ntfsfix systemd-sysusers bzip2recover kill ntfsinfo systemd-tmpfiles bzless kmod ntfsls systemd-tty-ask-password-agent bzmore less ntfsmove tar cat lessecho ntfsrecover tempfile chgrp lessfile ntfssecaudit touch chmod lesskey ntfstruncate true chown lesspipe ntfsusermap udevadm chvt ln ntfswipe ulockmgr_server con2fbmap loadkeys openvt umount cp login pidof uname cpio loginctl ping uncompress dash lowntfs-3g ping4 unicode_start date ls ping6 vdir dd lsblk ps wdctl df lsmod pwd which dir mkdir rbash ypdomainname dmesg mknod readlink zcat dnsdomainname mktemp red zcmp domainname modeline2fb rm zdiff dumpkeys more rmdir zegrep echo mount rnano zfgrep ed mountpoint run-parts zforce egrep mt sed zgrep false mt-gnu setfont zless fbset mv setupcon zmore fgconsole nano sh znew fgrep nc sleep findmnt nc.openbsd ss fuser nc.traditional stty /lib 共有ライブラリを保存するディレクトリです。 共有ライブラリが何なのかわかる？ ...

オブジェクトストレージとは？ tiledbの使い方の基本 まず、知っておきたいのは、TileDBはmariadbやmysqlののようにサーバクライアント方式のデータベースではないということ。どちらかというと、sqliteやhdf5のように、ライブラリとして提供されているものだと思ってほしい。しかし、なんとデータの実態はリモートに置いておいて、httpでそのデータを取ってくるってこともできる。この時に、オブジェクトストレージってのが使われます。 で、c++とpythonの二つがあるけど、使いやすいし、今回はpythonでやろうと思う。環境構築はいたって簡単。condaとかで新しい環境を作って、 pip install tiledb をするだけです。 非常に簡単！で、ここからは使い方ですね。 import import tiledb 空間とスキーマを定義し、 # Don't forget to 'import numpy as np' dom = tiledb.Domain(tiledb.Dim(name="rows", domain=(1, 4), tile=4, dtype=np.int32), tiledb.Dim(name="cols", domain=(1, 4), tile=4, dtype=np.int32)) schema = tiledb.ArraySchema(domain=dom, sparse=False, attrs=[tiledb.Attr(name="a", dtype=np.int32)]) データベースの名前を定義 array_name = "quickstart_dense" tiledb.DenseArray.create(array_name, schema) 重要事項 上のarray_nameっていうので、データのディレクトリが指定されます。ただ、ここには、次のような形式でパスを指定することもできるし、 リモートにあるオブジェクトストレージにアクセスすることだって可能です。こんな感じです。 array_name = 'file:///home/usrname/my_array array_name = 's3://bucket-name/array-name' みたいな感じですね。ここで出てきたs3っていうのが、僕にとっては初耳の知識でした。結構web業界では使われてるみたいですね。 amason simple storege service (amazon s3)とは、オブジェクトストレージサービスです。 ブロックストレージというのがいつも使っているハードディスクとかssdとか、あの辺のやつね。 じゃあオブジェクトストレージとは何か？って話なんだけど、 まあ簡単に言うと、ファイルシステムが入っていななくて、データ単体をオブジェクトとして保存している、というかんじ。 Object storage systems typically do not have a traditional file system hierarchy within them. Instead, they store data as objects, each with its own unique identifier (often called a key) and associated metadata. These objects are typically organized in a flat namespace rather than a hierarchical directory structure. In a traditional file system, you have directories (folders) that contain files, and you navigate through the hierarchy to access your data. In contrast, object storage relies on a flat namespace where each object is stored independently and accessed by its unique key. This approach simplifies data management and makes it well-suited for storing large volumes of unstructured data, such as images, videos, documents, and backups. オブジェクトストレージはファイルシステムを持っていなくて、フラットなデータストレージ上にキーとそのデータを保管しているんだね。key-valueストアだね。その構造についてだけど、実際にハードディスクへの書き込みをするコンポーネントが合って、メタデータを管理するコンポーネントがあって、httpでのアクセスに対して処理をするコンポーネントがある。 ...

oauthの大枠について、いい感じに理解したので、覚えているうちにアウトプットしておく まあ、経験的にもわかると思うけど、新しくemailを登録してそこに確認メールを送って、認証する、っていうやつ、あれやっぱり面倒くさくて、CVR下げるのよね。ってことで、やっぱりgoogleとかLINEとかを使った認証のほうが圧倒的に楽なわけですわ。ポチってしまうわけですわ。これ、自分のアプリに組み込むことで圧倒的にユーザを確保できると思うんですよね。ってことで、 仕組み 大事なのは、どのフェーズにおいても、URLそのものに重要な情報を乗っけてやり取りしてるってこと。 まず、ユーザがログインページでgoogleによる認証をクリックしたとするよね。これはゲットリクエストなわけですわ。このgetリクエストに対して、サーバはユーザをgoogleの認証サーバにリダイレクトするわけです。 で、リダイレクトのurlの中にこのサイトの情報が乗ってるんですよね、サイトのIDってやつです。 このIDは事前にgoogleのdeveloperサイトでもらえます。google側はこのIDでどのサイトかを判別しているんですね。更にこのサイトでコールバックのURL (ユーザがgoogle側にこのアプリに情報を送ることを承認するボタンを押したあとにリダイレクトされるURL) も登録しておきます。 で、ユーザが承認すると、コールバックのURLにユーザの情報にアクセスするためのトークンを乗っけてこっちにリダイレクトされるわけですわ。 で、そのトークンを使って、ユーザの情報にアクセスできるようになるわけです。 ただ、自分でメール認証の仕組みを作るのも重要だとは思っている。 これの作り方、そんなにむずくないよね。 まず、ユーザにメールアドレスを入力してください。ってお願いするわけです。 で、入力されたメールアドレスに、このサイトのurlと/auth/mail/{random} みたいなのを入れておくわけですわ。randomっていうのが、そのメールアドレスと一時的に紐付けられているランダムな値です。で、ユーザが/auth/mail/{random}にアクセスしてきたら、まあ、実際にそのメールアドレスがあったんやなってわかるわけですわ。まあなんでもいいよ、mail2uuid := map[string]stringとかで管理しているやつと for k,v := range m { if v == uuid { // そのイーメールアドレスを認証する、って感じです。 // このときにcookieを入れておくといいですね。ええ。 // cookieとemailを紐付けるのを忘れないように。 // useridとパスワードを入力するページにリダイレクトします。 // って感じです。はい。 } } これ、有効期間決めておいたほうがいいですね。数分とかそんな感じで。 ちなみに、golangからemailを送信する一番いい方法なんだけど、 やっぱり、リレーするのがいいみたいです。ええ。 chatGPTに出してもらったコードがこちらですね。 package main import ( "net/smtp" "log" ) func main() { // Sender and recipient email addresses. from := "your_email@gmail.com" to := "recipient@example.com" // SMTP server configuration. smtpServer := "smtp.gmail.com" smtpPort := "587" smtpUsername := "your_email@gmail.com" smtpPassword := "your_email_password" // Compose the email message. subject := "Hello, Golang Email!" body := "This is a test email sent from a Golang application." // Define the SMTP server's authentication information. auth := smtp.PlainAuth("", smtpUsername, smtpPassword, smtpServer) // Create the email message. msg := "Subject: " + subject + "\r\n" + "To: " + to + "\r\n" + "From: " + from + "\r\n\r\n" + body // Send the email. err := smtp.SendMail(smtpServer+":"+smtpPort, auth, from, []string{to}, []byte(msg)) if err != nil { log.Fatal(err) } log.Println("Email sent successfully!") } 決済の方法についてもいくつかあると思うので、まとめておきたい。 まずは、どの決済を組み込むかなんだけど、まあ普通に paypayとpaypalとまああとはクレジットカードでいいかね。 そうね、ユーザにポイントを付与する感じにするか。 1シミュレーション100ポイントとかにしてとかにして、って感じかね。 実際に購入画面に進むためには500ポイントとかにして。1000ポイント買うと、200ポイントおまけでついてくる、とかにしてね。 ...

サムアルトマンのブログでかなり好きだったポスト The Strength of Being Misunderstood A founder recently asked me how to stop caring what other people think. I didn’t have an answer, and after reflecting on it more, I think it's the wrong question. Almost everyone cares what someone thinks (though caring what everyone thinks is definitely a mistake), and it's probably important. Caring too much makes you a sheep. But you need to be at least a little in tune with others to do something useful for them. It seems like there are two degrees of freedom: you can choose the people whose opinions you care about (and on what subjects), and you can choose the timescale you care about them on. Most people figure out the former [1] but the latter doesn’t seem to get much attention. The most impressive people I know care a lot about what people think, even people whose opinions they really shouldn’t value (a surprising numbers of them do something like keeping a folder of screenshots of tweets from haters). But what makes them unusual is that they generally care about other people’s opinions on a very long time horizon—as long as the history books get it right, they take some pride in letting the newspapers get it wrong. You should trade being short-term low-status for being long-term high-status, which most people seem unwilling to do. A common way this happens is by eventually being right about an important but deeply non-consensus bet. But there are lots of other ways–the key observation is that as long as you are right, being misunderstood by most people is a strength not a weakness. You and a small group of rebels get the space to solve an important problem that might otherwise not get solved.