Rustでリレーショナルデータベースを自作したときの成果と反省と学び - Yoshisaurのメモ
はじめに この記事では、個人プロジェクトとしてRust言語でリレーショナルデータベースを開発した経験（もう五ヶ月も前...）について、その成果と反省、得た学びを共有します。 DBMSを自作した理由 自分がDBMSの自作に着手したのは、『Designing Data-Intensive Applications』という本の内容を深く理解するためでした。 この本は、データシステムの設計と運用において最も大切な「信頼性」、「拡張性」、「保守性」を保証する方法論を、豊富な文献を引用しつつ、理論と実践の橋渡しを巧みに行いながら、丁寧に説明している名著です。読んだことがない人は速攻購入してくだい。本当にいい本です。 この本は、データベースの内部構造に関する話も豊富に含まれていたので、「データベース自作してみようか...」という気持ちになりました。 Rustを採用した理由 データベースの実装のついでに、
自作RDBMSやろうぜ!
Skip to the content. 自作RDBMSやろうぜ! このサイトの目的 RDBMS（いわゆるリレーショナルデータベース）というものはプログラミング言語の処理系や、OSなどと同様に、世の中で広く使われているソフトウェアであるにも関わらず、いざ自作してみようと思うと日本語で記述されたサイトや書籍で、必要な情報・情報源がまとまったものがないことに気づきました そこで、叩き台として、本サイト管理人および数名のコミッタで開発している自作RDBMSである SamehadaDB が軌道に乗るまでの経験をベースに、自作RDBMSするための道筋をある程度整理して書き記してみました 各々の情報・情報源はあいかわらず多くが英語で記述されていますが、その点はご容赦下さい なお、本サイトは技術的な解説を提供するのではなく、適切と思われる情報・情報源をポイントするようなサイトとなることを想定しています
うるう日にしか発生しないバグ
昨日うるう日にしか発生しないバグに遭遇した。Javascriptを書く人には有名な話だとは思うので大して面白くはないかもしれないが一応メモ。 詳しくは書けないがバグが発生した関数の仕様としてはざっくりと下記のような感じ。 対象の年月日が基準日の1年前から1年後の間に含まれる場合はtrueを返しそうでない場合はfalseを返す 引数として2020-12-24というフォーマットの文字列が渡される(判定対象の日) 引数として2021-01-01というフォーマットの文字列が渡される(+-1年の基準日) Javascriptで書く (例) 対象の日: 2024/10/10 基準日: 2024/01/28 この時、trueになる範囲は2023/01/28 ~ 2025/01/28。なので2024/10/10はtrue。2023/01/28も2025/01/28もtrueになる。閉区間。 とあるコードの
どのレイヤー（層）でトランザクションを実装すべきか
このように、層ごとに関心事の分離を行うことで、保守性の高い（変更容易性や再利用性等）アプリケーションを実現できます。 しかし、「トランザクション」においてはどうでしょうか。 トランザクションはビジネス領域においても、技術領域においても関心事がある内容です。 そういう曖昧なものは「ひとまず usecase 層に入れてしまえ」という方針になりがちです。 ですが、DB 固有の知識を usecase 層の関心事にしてしまっては、関心事の分離をするメリットが得られません。 そのため、関心事の分離を実現しつつトランザクション実装をする方法を模索してみました。 前提 1. クリーンアーキテクチャを採用している（オニオンアーキテクチャやレイヤードアーキテクチャも含む） そもそもビジネス知識と技術知識を分離していないアーキテクチャを採用している場合、メリットは得られません。 そのため、オニオンアーキテクチャ
「目標設定」で大切にしたい3つのこと
3 どんなことを話すの？ 今回のテーマ「⽬標設定‧評価」 LT (5min) なので、考えや共感したいこと全部は伝えきれなさそう ... 😇 • 会社において「目標」の存在が与える影響をどう捉えているか • 人事評価制度と「評価」がどのように結びついているか • 「目標設定」が何で重要なのか • チーム目標と部の目標をどう繋ぎこむか • 評価に対する認識に差が生まれた場合に何をしているか などなど... だったので、以下のようなことに焦点を絞ります！ 🚀 「目標」を決める際、何を重要視しているか 株式会社TOKIUM エンジニアリングマネージャー 5 ⾃⼰紹介 経歴 in TOKIUM 2017年 WebエンジニアとしてTOKIUM (当時 BearTail) に入社（社員14人） 2019年 スクレイピング基盤チームをリーダーとして 0→1 立ち上げ 2020年 改善チーム（SR
長く活躍できるエンジニアになるためには？ 技術者として大切にしたいこと
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
yamlでテストシナリオを書いてそのまま実行までできるAPIテストツールの新星 “runn” を試してみた | DevelopersIO
yamlでテストシナリオを書いたらそのまま実行できる……そんな夢のようなシナリオテストツール"runn"の紹介とやってみた記録です これまでのシナリオテストツールに対する課題感 シナリオテストツールといえば、 Cucumber や Gauge といったツールが有名です。 ですが、これらのツールは「シナリオファイル」とは別に、シナリオを実行するためのコードも書かないといけません。しかも、そのコードではAPIを呼び出す処理を特定のプログラミング言語を使って書かなければなりません。その中には、HTTP Clientを実際に操作するような処理も含まれます。 私は「シナリオテストがしたい」のであって、「シナリオに沿ってAPI呼び出しを行う処理を書きたい」のではありません。こういった課題感を、ここ数年ずっと抱えてきました。 そんなとき、ついに見つけたツールが "runn" でした。 APIのシナリオテ
ソフトウェアアーキテクチャメトリクスの基礎: Software architecture metrics in a nutshell
ソフトウェアアーキテクチャメトリクス - Forkwell Library #44 での発表資料です https://forkwell.connpass.com/event/309739/ 動画: https://www.youtube.com/watch?v=C52rYX_E9bA #Forkwell_Library
ssig33: "最近最小限のReactアプリを作るのに使ってるもの についてとりあえずメモしとく。 ##..."
新人声優 +81-9014502501 mail@ssig33.com 0088-7709-7529 it/it. my opinion may be not my own. but my fate is my own. 最近最小限のReactアプリを作るのに使ってるもの についてとりあえずメモしとく。 前提: デカいフレームワークは使わない next.js, Astro, Remixは使わない。next.jsとAstroは大好きなのだが、社内向けとか個人用とか小さいアプリに使うにはあきらかに恐竜であると思う。Remixは大好きではない。 前提: SSRしない SSRもSSGもISGもしない。CSRでいい。SSRしたいならReactをそもそもぶん投げたほうが(個人レベルなら)いいと思ってる。それがほしいならPHPやRails でええ。今更RailsでView書きたくないとか思うかもしれない
SaaS アーキテクチャ概要
SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。
最近のCloudflare Workers - ゆーすけべー日記
最近のCloudflare Workersについて、知らない方向けにざっくばらんに書いてみます。 連絡事項 自己紹介しておくと、僕はCloudflareのDeveloper RelationsチームにいてDeveloper Advocateをやってます。 一方で、HonoというCloudflareのみならずDenoやBun、Fastly等で動くWebフレームワークを開発してます。 Cloudflare Workersとは？ 本題に入る前に、そもそも「Cloudflare Workersとは？」を簡単に紹介しておきます。 Cloudflare WorkersとはCloudflareのエッジで動くサーバーレス環境です。 基本的にJavaScript/TypeScriptでアプリケーションを書きます。 V8というJavaScriptエンジンの上でアプリを動かすのですが、これはWebブラウザのGo
AWS Lambdaデプロイツール lambroll v1をリリースしました - 酒日記 はてな支店
AWS Lambda用のデプロイツール、lambroll の v1.0 を2024年2月10日にリリースしたのでお知らせです。 github.com リリースして早速ですが v1.0.0 には一部のフラグ名がv0と異なるというバグがあるので、v1.0.1 以降をご利用ください。 v0.x と v1 の変更点 リポジトリ にまとめてありますが、簡単に解説します。 非互換変更 lambroll archive zipのバイナリを、標準出力ではなくファイルに書き出します デフォルトのファイル名 function.zip(--dest オプションで指定可能) に書き出すようになりました。 --dest - を指定することで、v0と同様に標準出力に書き出すことができます。 lambroll diff コマンドは、常に短縮型の unified 形式で出力します --unified オプションは廃止され
IPAマンガでわかるソフトウェア開発データ分析38編.pdf
マンガでわかる ソフトウェア開発 データ分析 データ分析事始め データ分析FAQ (参考)アジャイルメトリクスFAQ 1 独立行政法人情報処理推進機構 超合本版38編 データ分析事始め 目次 データ分析基礎編 01 データ分析ってなんなの？ データ分析 02 信頼幅の線、気になる 信頼幅 03 箱ひげ図のひげ、かわゆくない 箱ひげ図 04 散布図はぜんぜんばらばら 散布図と箱ひげ図 05 どれが本命なの？ 中央値と平均値 分析データ観察編 01 生産性は性癖が出る？ 生産性 02 バグを愛したソース 信頼性（不具合密度） 03 改修・保守が好き過ぎる 開発プロダクトの種別 04 規模はアンバランスでアンビバレント ソフトウェア規模 05 開発期間は短くて長くて短い 開発期間（工期） 06 ウォーターフォールってつおい？ ウォーターフォール型開発 07 ここはツールでしょ 開発ツール 08
毎日本番DBをダンプして、ローカルと開発環境で利用して生産性を上げてる話
シードデータで動作確認して大丈夫だったのに、本番反映してみたら想定してなかった挙動・エラーが出た😱そんな経験はありませんか。 恥ずかしながら私は今までに何回もありました。機能開発だけじゃなくバッチやマイグレーションなんかでも発生しがちなコレ。またはシードデータで動作確認できても、本番データでも通用するか検証ができないままプルリクを作る、なんていうこともあると思います。今回はこちらを無くす試みをしたお話です。 「もう本番DBで開発しちゃえばいいじゃない」の問題点 この課題を解決するには、極論すると本番DBで開発するしかないのですが、そうなると言うまでもなく以下の問題が出てきます。 レビュー通過してないコードが本番に影響を与える トライ＆エラーができない 個人情報をはじめとするセンシティブな情報が開発者の端末に漏れる データ量が多すぎてローカルに持ってこれない しかし言い換えると、これらをク
エンジニアはどう学んでいけばよいのか - つまりは「知ったかぶり」 の積み重ね - Qiita
はじめに この記事では、学んでいくためのマイルストーンとして「知ったかぶりができること」を設定するのもアリなのでは？ という提案をします。 初学者でなくても『どうやって学んでいこうかな～』は全エンジニアの関心事だと思うので誰かの行動のきっかけになれたらうれしいです。 目次 （エンジニア）人生は勉強や！ 「知ったかぶり」を再定義する 「知ったかぶり」を可視化する 無知の知はすぐに自覚できる どうすれば人に説明できるようになるのか いったんここまでのまとめ 脳内イメージの解像度をどう上げていくか アウトプット先を意識したインプットをしよう " 知ったかbrilliant Journey of Engineers " さあ、なにを知ったかぶりしていこう？ おわりに （エンジニア）人生は勉強や！ 技術は高速かつ複雑に成長しているので、新たな分野を学ばなきゃいけない機会はどんどん増えていく。また、そ
自分のパフォーマンスを最大化し続ける方法 - igsr5 のブログ
こんにちは。個人パフォーマンスを安定させることが得意な @igsr5_ です。 最近何人かに何か工夫してることあるの？と聞かれたのでブログとして書き出してみようと思います。 はじめに 業務に慣れてくると、求められるアウトプットのレベルや量は上がっていきます。 しかし業務知識をいくら習得しても、働き方が非効率だとパフォーマンスは安定せず、上昇する期待値についていけません。 仕事の成果を増やしたり、残業を減らしてプライベート時間を充実させるためには自分のパフォーマンスを最大化し続ける必要があります。 4つの意識を持つ 自分のパフォーマンスを最大化し続けるためには、4つの意識を持ちましょう。 決して「余裕」を失わない 「よし、やるぞ！」と脳が勝手に思える習慣を持つ 仕事に「モヤモヤ」を持ちこまない 健康でなければ全ての工夫は無意味 重要なのはプロジェクトが佳境の時など、普段より忙しい時こそ4つの
「世界一流エンジニアの思考法」の内容を実践してみた | DevelopersIO
生産性を爆上げしたい おのやんです。 みなさん、生産性を爆上げしたいと思ったことはありませんか？私は毎日の業務に取り組む上で、どうすれば生産性を上げられるか日々考えています。 そんな中出会ったのが、こちらの「世界一流エンジニアの思考法」です。 本書を読んだ際には、「なるほど、こういう取り組み方をすれば生産性を向上させられるのか」とものすごく腹落ちしました。 その後、本書に書かれている内容を私なりに解釈・適用して実践してみました。その結果、目に見えて生産性やアウトプットに変化が見られました。ということで、今回は実際にやってみた取り組みとその変化について、本記事で紹介したいと思います。 本書について 本書を書かれた牛尾さんは、アメリカのマイクロソフトで現役のソフトウェアエンジニアでいらっしゃいます。マイクロソフトで働く同僚の生産性の高さを観察し、彼らが実践していることなどを紹介する内容となって
「説明能力の高さ」はどこに現れるか
職業柄、昔から人の「説明」を聞くことがとても多かった。 会社の現状、技術的な見解、商品のスペック、あるいは人の経歴についての話もあった。 そして、説明がとても上手な人もいれば、下手な人もいることを知った。 例えば、こんな具合だ。 「では、御社の事業説明をお願いします」 「わかりました、こちらが会社案内です」 「では、始めてください。」 「はい、では1ページ目をご覧ください。弊社の主要な株主は……全国に展開しており……事業所は……」 ……５分経過 「では次は、弊社の主要な事業です。おもに３つあり……」 「（退屈だな……後ろのページでも見ているか）」 ……５分経過 「次に今回お問い合わせの商品についてです……こちらの……」 「（その話はもうサイトで見たからいいよ……話ながいな……内職でもするか）」 ……５分経過 「以上となりますが、なにかご質問はありますか？」 「………いえ。」 例えば上のよう
AWS Lambda Under the Hood
Transcript Danilov: We'll talk about AWS Lambda, how it's built, how it works, and why it's so cool. My name is Mike Danilov. I'm a Senior Principal Engineer at AWS Serverless. A decade ago, I joined EC2 networking team, and it was a fantastic ride. Then, five years back, I heard about Lambda. I really liked the simplicity of the idea. We run your code in the cloud, no servers needed, so I joined
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
キャッシュと向き合う、キャッシュと共に生きる / cache pattern
