はてなブックマーク

気合いで実装、どうもかわしんです。 この記事は Rust Advent Calendar 2023 の6日目 兼 情報検索・検索技術 Advent Calendar 2023 の 6 日目です。 Rust で SQLite をフルスクラッチで実装しています。 github.com なぜ SQLite を Rust で再実装しようと思ったのかについては以前の記事で紹介しています。一言で言えば、誰も Rust で SQLite を書いている人がいなかったからやってみたのですが、そもそも SQLite が強すぎるということが再実装しているうちにわかってきて絶望しています。 kawasin73.hatenablog.com 4 ヶ月前にこの記事を書いたときは簡単な SELECT 文しか実行できなかったのですが、現時点では SELECT, INSERT, DELETE 文をサポートし、express

後方互換性って辛いね、どうもかわしんです。 最近 Rust で SQLite をフルスクラッチで再実装しています。 github.com 再実装するために SQLite の公式ドキュメントやソースコードを読み込んでいるわけですが、その過程で気付いたおもしろポイントを共有しようかと思います。 今回はその第二弾、ファイルフォーマット編です。第一弾はこちら：SQLite のおもしろ仕様 (1) : データ型 - kawasin73のブログ 前提知識 : ページ まず、この記事を面白いと思ってもらうための前提知識です。 大抵のデータベースはデータを保存するファイルをページという単位で管理します。SQLite ではデフォルトでは 1 ページ 4096 バイトです。これは、ファイルを保存するデバイス（HDD や SSD など）としてブロックデバイスを想定しているからです。ブロックデバイスとはデータの読

型は型、どうもかわしんです。SQLite では型は絶対ではなく、あくまでも尊重です。信用しすぎると裏切られます。 最近 Rust で SQLite をフルスクラッチで再実装しています。 github.com なるべく本家の SQLite と compatible にするために SQLite のドキュメントやコードを読んで挙動を理解しながら作っています。これを作ることになった経緯はこの記事で紹介していますが、その過程でいろいろ知らなかった面白い仕様や実装があったので紹介していきたいと思います。今回はその第一弾です。 kawasin73.hatenablog.com データ型と Type Affinity SQLite のドキュメントの中で、今の所一番面白いのがこれです。 www.sqlite.org まず、SQLite の内部的には 5 つのデータ型しかありません。 NULL INTEGER

困った時はドキュメント、どうもかわしんです。最近、諸事情で SQLite のドキュメントを読んでいます。 前回の記事 で紹介した通り SQLite を Rust で再実装しています。おかげさまで 300 を超える Github Star もいただき嬉しいです。 github.com SQLite は全ての仕様が ドキュメント にまとめられているので、そのドキュメントと本家の実装を読み比べながら実装しています。 SQLite を再実装する上で特に以下のドキュメントは役にたちます。これらだけで最小限の SQLite の実装は作れると思います。 Overview Documents > About SQLite いかに SQLite がすごいかを自慢しているドキュメント。使おうとしている人には安心を、再実装しようとする人には絶望を与えてくれます。 Programming Interfaces >

時代はワークライフバランス。どうもかわしんです。 新しい技術は追わない。これは僕の個人的な方針です。別に最先端を追い続けることを否定するわけではありません。 ここでいう新しい技術は、web 界隈の新しいフレームワークとかライブラリとか SaaS とかです。 新しい技術を追い続けるのって大変 休日も時間を費やして勉強するのって大変ですよね。若いうちは Twitter で流れてくるいろんな技術記事を片っ端から貯めて通勤・通学時間に読んでましたが、もう 26 歳になって体力も時間も限られてきました。今はたまった記事も読まなくなったしそもそも興味を惹かれる記事が流れてこなくなって貯まらなくなりました。 必要ないものにモチベーションが湧かない 今勤めてる会社は社内ツールとか社内フレームワーク、ライブラリが溢れているガラパゴスな環境だから、勉強するモチベーションが湧かないです。使わないので。 あと、僕

セキュリティを盾に一点突破。どうもかわしんです。最近 Rust で SQLite を実装してます。 以前の記事で HTTP Parser を Rust で実装しようとしたものの、すでに実装されていたので断念しましたが、いい題材を見つけました。SQLite です。開発中のリポジトリはこれです。 github.com 今の時点では、Read Only で1つの WHERE 句を持った SELECT 文しか処理できないですが、以下の機能を実装しています。 sqlite3 で生成された database ファイルの読み取り (cursor.rs, btree.rs, record.rs) SQL 文の解析 (token.rs, parser.rs) テーブルとインデックスのメタデータのパース (schema.rs) 動的なファイルの読み込み (pager.rs) SQL クエリとスキーマ情報を元に

キャリアの危機。どうもかわしんです。 この記事の内容は全て僕個人の意見であり、所属する組織を代表するものではありません。 最近周りで ChatGPT が話題です。特に GPT-4 が出てきたあたりからの Twitter で観測する人々の騒ぎ方をみるにこれまでとは何か潮目が変わったなと感じたので、これからの自分のキャリアを見つめ直すことにしました。 AI は詳しくないので間違ってることがあるかもしれないですが、それはそれで。 ChatGPT にみる AI の特性 GPT は大量の文章データを学習し、入力文章から文章を出力するものです。大規模言語モデルの驚異と脅威 - Speaker Deck のスライドを読んだ感じは、学習したデータを元に出力単語列にもっともらしい次の単語を繋げて文章として出力しているみたいです。 これを発展させると、GPT は「公開されているそれぞれの領域の最先端の知識やス

速さは正義。どうも、かわしんです。 Rust で一番速い HTTP パーサーは C で書かれた picohttpparser の Rust バインディング、picohttpparser-sys です。ガハハ。 $ RUSTFLAGS="-C target-feature=+sse4.2" cargo +nightly bench Finished bench [optimized] target(s) in 0.28s warning: the following packages contain code that will be rejected by a future version of Rust: traitobject v0.1.0 note: to see what the problems were, use the option `--future-incompat-re

順番は守りましょう。どうも、かわしんです。トランザクションを実装中です。 さて、先日トランザクションの並行制御アルゴリズムである「S2PL (Strict Two Phase Lock)」を実装した 1 のですが、Read オペレーションでは Read Lock を取った後にすぐに解放していました。2 しかし、よくよく考えると 2PL はロックを解放した後にロックを取得することを禁じているため（だからこそ 2 phase なのですが）、実装が間違っていました。 つまり、Read Lock して Read した値はロックを保持し続け、Write するときにロックを Write Lock に昇格させる必要がありました。 この振る舞いを実現するためには、昇格に対応した Read Write Lock の仕組みが必要になります。 Go には sync.RWMutex という goroutine に

LISENCE と LICENSE 、正しいスペルがどっちかわからない。どうも、かわしんです。正解は LICENSE です。 僕は、よく MIT ライセンスを使います。気が向いたら WTFPL（ Do What The F*ck You Want To Public License ）を使います。趣がありますよね。 さて、僕の実家は山口にあるのですが、年末の帰省のタイミングで C コンパイラを作りました。正確には去年の 12月 30 日の東京発博多行き新幹線のぞみ号に乗った時から、今年の 1 月 4 日の夜までです。新幹線は片道5時間くらい乗ってるので開発にうってつけです。本当は東京に戻ってきたらやめると決めてたんですが、キリが悪かったので１日延長して昨日までやってました。 去年の夏あたりに Rui Ueyama さんが作った 9cc が話題になり、僕もいつか作ってみたいなと思っていました

誰一人見捨てない!!! どうも、かわしんです。Celery は見捨てるんです。 この記事は Pythonその2 Advent Calendar 2019 の 15 日目の記事です。 やや強めのタイトルですが、AWS SQS を使った非同期ワーカーでまともな実装は ndkale しかないという内容です。Celery は論外です。 github.com 前半はディスってばっかりなので、ndkale のことだけを知りたい場合は途中の「大本命 ndkale」から読んでください 前提としての欲しい機能 まず、諸々をディスる前に非同期ワーカーとして欲しい機能をあげておきます。 正しく SQS を使って信頼性のあるタスク実行をする 即時再実行をする 複数のキューを使い分ける。また同じタスクでも動的に利用するキューを切り替えたい Dead Letter Queue も使えると嬉しい まず Celery を

一歩ずつ一歩ずつ前へ進んでいく、確実に。どうも、かわしんです。 到底 1 記事に収まるような内容ではなく長いので、トランザクションの作り方に興味のない方は途中の「なぜ Go なのか」まで読んでいただければ嬉しいです。 この記事は、Go2 Advent Calendar 2019 の 7 日目と セキュリティキャンプ 修了生進捗 #seccamp OB/OG Advent Calendar 2019 の 7 日目を兼用しています。 さて、僕の興味は必要になったライブラリやミドルウェアなどを自作して、作りたいプロダクトを完成させることです。必要なコンポーネントがないからといってプロダクトを作るのを諦めたり妥協したりはしたくありません。 多くのアプリケーションではデータベースは重要なコンポーネントです。大抵のアプリケーションは MySQL や Postgres、Redis など既存のデータベース

いつも心に省メモリ。どうも、かわしんです。今日はメモリアロケーションについてのポエムを綴ります。さらっと流してください。 ちなみに、ここでいう省メモリとはメモリサイズだけの話ではありません。 メモリをアロケート（確保）するとき、あなたはどんな感情を抱くだろうか？おそらく何も感じない人がほとんどだろう。というかメモリをアロケートしたことにすら気づいていないのかもしれない。 僕はメモリをアロケートするたびに心が痛む。本当はアロケートしなくてもいいのではないか、別のところでまとめてアロケートした方がいいのではないか？色々悩んだ結果、苦渋の選択としてメモリをアロケートするのだ。 メモリアロケーションのコストとは何か 僕がなんとなくメモリアロケーションに罪悪感を覚え始めた時、僕はメモリアロケーションのことを何も知らなかった。大きなメモリを確保するほどコスト（確保に必要な計算時間）が大きくなると思って

プログラマーあるある、なにかと独自のミニ言語を作りがち。どうも、かわしんです。どうしても簡潔にやりたいことを表現するためにミニ言語つくりがちですよね。JSON で構文作ると長いし。 さて、ACES Inc. という東大の松尾研究室発の AI ベンチャーがあるのですが、そこの創業者メンバーと学科の同期だったので最近お手伝いしながらアーキテクチャ設計をしたり Python をゴリゴリ書いたりしています。ちなみに僕はディープラーニングも機械学習もしてないです。 その中で推論結果が dict と list を組み合わせたデータ構造で返ってくるのですが、それを JSON と CSV の両方で保存したいという仕様がありました。JSON への変換は json.dumps() を使えば一発なので自明ですが、CSV への変換は list が含まれた時にそれをどのように展開するかが自明ではありません。 推論ア

イテレーションの速さがあなたの生産性を左右する。どうも、かわしんです。生産性の高いプログラマって１つ１つの試行が素早い（自動化しているかツールを使っている）ためにものすごいスピードで開発できていると思うんですよね。 さて、最近 Python で開発をしているのですが、世の中の Docker と Pipenv の開発環境を調べてもろくなものがなかったので、自分でテンプレートを作りました。いわゆる「俺の考える最強の Pipenv + Docker 開発環境」というやつです。 リポジトリはこちらになります。 github.com 特徴としては、以下の2つが大きいです。 pipenv install をコンテナ起動時に行うため、docker イメージを作り直す必要がない pipenv shell 相当の仮想環境のアクティベートを自動で行う なぜ Docker + Pipenv なのか Docker

掴んで離さぬコネクション。どうも、かわしんです。しがみつかずに適切なタイミングで離しましょう。 この１週間で RFC を読みながら TCP/IP プロトコルスタックを自作した 1 のですが、その時にコネクションの終了処理でハマったので後学のために書き残しておきます。 一言でまとめると FIN -> FIN/ACK -> ACK は間違っていて、正しくは FIN/ACK -> FIN/ACK -> ACK であったという話です。 ちなみに、僕が自作した TCP/IP プロトコルスタックはこれです。 github.com 現象 それは TCP のリスナーと close 処理が出来上がってコネクション管理のテストをしていた時のことでした。 自作 TCP スタックでポートを Listen して Accept したらすぐにサーバ側からコネクションを切断するというテストコードを書いて実行し、Linux

この記事は、PSI（東京大学工学部システム創成学科知能社会システムコース） Advent Calendar 2018 の 22 日目です。 はじめに 東大の応用プロジェクトという授業で、LabVIEW というソフトウェアを使ってセンサーアプリケーションを作ることになりました。 しかし、大学から支給される Windows PCが遅い。信じられないくらい遅い。 LabVIEW を立ち上げるのに10分とかかかります。平気で。 それが許せなくて自分のパソコンで LabVIEW をやりたくなりました。ところが、macOS しか持っていない僕はインストールできない。（LabVIEW 自体は macOS にもインストールできるみたいですが、ライセンス関係がめんどくさそう） さらに、他の授業でも Window でしか動かないソフトウェアを使うことがあり（ここで支給される PC も遅い）、自分も Windo

RFC は裏切らない。どうも、かわしんです。僕は RFC に裏切られました。 さて、今週の頭から4日間開催された KLab Expert Camp に参加して、TCP/IP プロトコルスタックを実装してきました。今回はその体験記を書いていこうと思います。 成果物ですが、こちらになります。 github.com ネットワークデバイスの抽象化、Ethernet、ARP、IP、TCP を実装しました。使用言語は C 言語です。詳しくは後半で説明します。 KLab Expert Camp とは 今回参加したのは KLab 株式会社の実践的なインターンプログラムである KLab Expert Camp です。記念すべき第 1 回目として「TCP/IPプロトコルスタック自作開発」が開催されました。 応募ページはこれです。 https://klab-hr.snar.jp/jobboard/detail.

JWT とかいてジョットと詠む。どうも、かわしんです。タイトルは釣りです。 この記事は、JWT はログアウトが大変 という内容です。以下で挙げるデメリットを許容できるなら JWT をユーザに渡してもいいと思います。 ログアウトとは、管理者による強制ログアウトや、ユーザのパスワードの変更による全トークンの無効化をさします。ログアウトによって全てまたは一部のトークンが無効化されるユースケースです。 JWT におけるログアウト JWT はログアウトが大変です。なんかいい方法がないものかと調べていましたが、以下の記事に落ち着きました。 javascript - Invalidating JSON Web Tokens - Stack Overflow この記事の結論としては、いい方法などない というものです。残念でした。 JWT をログアウトに対応させる方法は ブラックリストを用意する か トーク

整骨院は保険がきく。どうも、かわしんです。 突発的な不調の場合は整骨院は保険が適用され 3 割負担になります。慢性的なもの（肩こり）には適用されません。 さて、5 月 20 日に以下のように宣言して作り始めた OS が、昨日ようやくひと段落したのでまとめの記事を書くことにしました。 さて、それでは今日から30日かけてOSを作っていきたいと思います— かわしん@ソフトウェアエンジニア (@kawasin73) May 19, 2019 かの有名な「30日でできる! OS自作入門」（通称 : 30日OS本）をただ写経しただけなのですが、すごく勉強になりました。 30日でできる! OS自作入門 作者: 川合秀実出版社/メーカー: マイナビ出版発売日: 2006/03/01メディア: Kindle版この商品を含むブログを見る この本は 30 日とうたっていますが、僕は 55 日かかりました。ただ忙

この記事は、ソフトウェアテスト #2 Advent Calendar 2018 - Qiita の１日目です。 github.com/kawasin73/bitset という Go 言語のビットベクトルのライブラリを作りました。このライブラリはバイトオーダーがビッグエンディアンのマシンでもリトルエンディアンのマシンでも同じ振る舞いをするように実装されています。 ビッグエンディアンとリトルエンディアンのそれぞれのマシンで正しく動くことを確認するテストを Travis CI で実行する手法を試行錯誤したので紹介します。 ビッグエンディアン、リトルエンディアンとは エンディアン（ Endianness ）とはバイトの並び順のことで、ビッグエンディアン（ Big Endian ）とリトルエンディアン（ Little Endian ）の2種類があります。（ミドルエンディアンなど他のエンディアンもある

言語の壁をぶっ壊す。どうも、かわしんです。 プロセス間の待ち合わせの手法としてファイルロックがあります。このファイルロックをタイムアウトでキャンセルすることを可能にするために以下のライブラリを作ったのでその解説をしたいと思います。 github.com 対象 今回の対象は以下の環境とします UNIX 系環境、特に macOS と Linux Go Version : 1.11.4 ファイルロックを実現するシステムコール Linux では、fcntl と flock というシステムコールでファイルロックができます。 この 2 つで獲得されるロックはカーネル内では別のものとして扱われますが、 FLOCK の 注意 にもある通り、一部のシステムでは flock と fcntl が影響を与える可能性があるため、単一のプログラムの中ではどちらかのロックのみを使うようにした方が良さそうです。（プログラ

この記事は、PSI（東京大学工学部システム創成学科知能社会システムコース） Advent Calendar 2018 の 25 日目です。 はじめに この記事は、僕がどんなエンジニアになりたいと思っているのかをつらつらと書くポエムです。 この考えを誰かに押し付けるつもりもありませんし、この考えが完全に正しいと主張している訳でもありません。「こういう考え方もあるんだな」程度に思っていただければ嬉しいです。 ここでのエンジニアは主に Web 系とかのソフトウェアエンジニアとかを想定しています。 作る人と使う人 エンジニアはプロダクトを作ります。そしてユーザーがそのプロダクトを使います。プロダクトには、作る人（エンジニア）と使う人（ユーザー）がいます。 同じようにエンジニアの世界にも作る人と使う人がいます。様々なフレームワークやライブラリを作る人と使う人です。 ライブラリを 作るエンジニア には