間接参照を巨大仮想メモリで飲み込む - Software Transactional Memo
この記事はデータベース・システム系 Advent Calendar 2023の3日目の記事である。昨日の記事も僕でした。 間接参照を巨大仮想メモリで飲み込む メインメモリはハードディスクやSSDより容量が小さく、この問題は当面は解決の目処が立たない。 そもそも今のDRAMより速くて安くて大きいストレージが仮に発明されてもそれがDRAMに取って代わるメインメモリの立ち位置になるだけであってその下のレイヤーには依然としてそのメインメモリより安くて大きなストレージが置かれる事になる。大局的な観点ではストレージの階層構造とは経済活動の鏡像でもある。 バッファプール さて、耳にタコができるほど繰り返しているが現代のデータベースはディスクなどの永続ストレージにデータの本尊が保存され、メインメモリはそれに対する読み書きを高速化するためのデータ一時置き場としての役割を担当している。 代表的なRDBMSは3
「禅とオートバイ修理技術」をプログラマが読んだ - Software Transactional Memo
「禅とオートバイ修理技術」これら2つの間にどのように関係があるのかまるで見当が付かず、タイトルだけ聞くとキワモノのようだがWikipediaによるとアメリカでは一番良く売れた哲学書とされている。 海外のエンジニアのブログを読み漁っていた時にオススメされていたのでKindleで買って読んだのだが想像以上に良かったのでメモを残したい。と言ってもwikipediaで説明されている内容を改めて説明しても面白くないのでソフトウェアエンジニアとして響いた部分を引用して僕の感じた事を書き連ねていく。 大都市の重工業地帯に一歩でも足を踏み入れてみれば、そこにはその全てが存在している。テクノロジーである。正面には有刺鉄線を施した高い塀が立ちはだかり、門は常に閉ざされ、「立入禁止」の札が掛かっている。そしてその向こうの薄汚れた大気の中には、金属や煉瓦で造られた醜い建物が立っている。その目的は不明であり、またそ
キャリアハックの奇行 - Software Transactional Memo
エンジニアの奇行 嚢中の錐という言葉がある。有能な人物は自ずと傑出していくという意味だが、有能さとは例えば学歴の高さとは一致しない。 たとえMIT卒であろうとも大成するとは限らないし、ましてや入試の点数などで見れる人間の側面は限定的である。 企業などで採用する側からしてみたら当然ながら採用後の活躍を期待して雇用するのであり、入社をゴールとしてそれ以降働かなくなる人は望ましくないし、学歴や入試の点数によってそういう人かどうか判定する事はできない。 活躍という観点で言うと長いキャリアにおいてより重要となるのはキャリア開始時での能力の高さよりも、険しく長い道のりを自己メンテナンスしながら歩み続けられる根気の強さが重要とされている。その根気の源泉は執着だったり崇拝だったり妄信だったりトラウマだったり原体験だったり人によって様々だが、ここではひっくるめて「やる気」と簡略化して呼ぶことにする。 さて「
Re: ブロックチェーンでそんなことはできない - Software Transactional Memo
はじめに chike0905.hatenablog.com この記事は大変楽しく拝読したが、ブロックチェーン素人ながら気になる点がいくつかあったので指摘する。要旨は以下である。 タイトルで「できない」と言ってる割には「できるけど筋が悪い」だけに見える 研究中で結論が出ていないトピックを「できない」と呼ぶのは違うのではないか 文体が学術めいている割には用語の使い方がやや雑に見える ブロックチェーンに「不可能」な事にフォーカスすべき 浮足立つ界隈に対して問題提起するならば的を絞って指摘すべきで、容易に解決可能そうに見えてしまう批判はかえって混乱を招く恐れすらある ノードの独立性 各自で検証し、他のノードに依存するプロセスは本定義のブロックチェーンの動作の中には含まれない。 従って、他のノードに何かを問い合わせる必要もなく、信頼する第三者などは存在しない。 この部分はあまり正しく理解している人が
Value Objectについて整理しよう - Software Transactional Memo
Value Objectとは何であるか? マーチン・ファウラーのPatterns of Enterprise Application Architecture(PofEAA)やエヴァンス・エリックのDomain Driven Design: Tackling Complexity in the Heart of Software(DDD)が原典であるが、PofEAAではこう切り出している。 When programming, I often find it's useful to represent things as a compound. プログラミング時は物をcompound(合成物)として表現すると便利なことがしばしばある。 例えば2次元空間上での座標のように複数のメンバ(属性)を持つ物は便利である、と。しかしそれらを比較する方法は一意ではない、そこで Objects that a
ブロックチェーンの作り出す価値に付いて - Software Transactional Memo
TL;DR 疑いの目を向けてみると怪しい奴ばかり 通貨発行は楽しい、これは真理である。 www.sinseihikikomori.com 1人プレイ用のゲームの中で敵を倒してゲーム内の通貨を得る行為は広義の通貨発行と見做せる。ドラクエの世界でスライムを倒して3ゴールドを得る行為すら通貨の発行であるという観点で考えた時、このブログの読者は誰しも通貨発行の体験があるはずである。 現実で使われる通貨を鋳造したら普通の犯罪であるが、この日本で法に触れずにこれに近い行為を達成できるのが借金である。人から10万円を借りて、その引き換えに「x万円を○月○日までにお返しします」と借用書を書けばその「○月○日にx万円を受け取る権利」自体が債権としてそれなりの値段y円で市場で取引される一方で自分はx万円を得ることができ、世界に存在する価値の総量がy円だけ増えたことになる。これは経済の基本である。 この借用書、
Re: Web3というテロリズム - Software Transactional Memo
えふしんさんに何の恨みも無いのだけれど わからないことを偉そうに書いて怒られて進化したいという芸風なので書いてみました。 Web3というテロリズム｜えふしん #note https://t.co/84SoYtIzDC — えふしん (@fshin2000) 2022年2月17日 というのだから技術的に正確なツッコミを入れて欲しいという事だと信じて書く。まさか後釣り宣言など来ないだろう。 Web3という言葉は、既存の権力構造に対する宣戦布告と考えれば、割と素直に受け入れられる。 ここは本当にその通りで「下剋上」の雰囲気感だけで業界が振り回されているのは見るに耐えない。権力構造を敵対視するあまり、本当に味方に付けるべきエンドユーザーの事がなおざりになっているとすら感じている。市場経済で世の中が動く中、エンドユーザーは確かな利益が無ければ動かないし、利益無しで人やお金を動かさせたら詐欺である。こ
書評：並行プログラミング入門 - Software Transactional Memo
TL;DR 並行処理を実装する人のこれからのスタンダードになる一冊。買い。 並行プログラミング入門 ―Rust、C、アセンブリによる実装からのアプローチ 作者:高野 祐輝 オライリージャパン Amazon 買ったら思いの外早く届いたのでパラパラと読み始めたら一気に読み終えてしまった。 総評 敢えて雑な喩え方をするなら The Art of Multiprocessor Programming (通称TAoMP本) の内容を薄めてRustやアセンブラや計算モデルを足したような本だった。 日本語の書籍としてはかなり珍しくWait-Free, Lock-Free, Obstruction-Freeの違いなどを適切に論じており、TTAS Lock, MCS Lock, TL2といった日本語では希少な情報が書かれているレアな本である。これらに付いて論じている日本語の本は知る限り (TAoMP本と昔僕
こうしてGoogleに入社した(kumagi編) - Software Transactional Memo
Googleオフィスの窓からの眺めをGoogle Photoが自動加工したもの TL;DR AtCoderやろうぜ Googleの(僕から見て)偉い人が立て続けにブログを書いており ctrl-x-s.blog hoge.blog ここ数件の僕のブログへの反響を読んでも「Googlerだから特別」みたいな意見が散見され、入社へのハードルが変に高く見られてしまっている気がするので、僕がGoogleに入社する準備として取り組んでいた事とそのレベルを紹介する。程度の低さに安心して欲しい。 英語 英語の論文は興味の赴くままに読んでいたため読むことに関してはあまり苦手意識は無いものの、絶対的な英語力に関して言うとTOEIC500点というスコアが端的に表している。これがどれぐらいかというと、得意分野から外れると長文を読む速度と精度がガタ落ちし、リスニングも結構な単語を聞き落とし、文脈からの推測と辛うじて
分散ロックという名の過ち - Software Transactional Memo
 TL;DR; 「分散ロック」が分散システムの設計図に登場した時 だいたいその設計は間違っていて本当に必要なものはトランザクションだ 並行システムを実装する際にロックを用いるのはとても自然なことだ。 僕も普段はロックフリー系のアルゴリズムに詳しいと言われがちだが知識量でいったら実はロック系の方が多く蓄えているかも知れない。 分散システムは並行システムであることが多いので、その中にロックが登場するのはとても自然な発想である。 よく「分散」「並行」「並列」の言葉の定義がごっちゃになっているケースがあり、この記事の主題にしたいわけではないので深くは言及しないが、分散システムは環境などの要因で突如として参加者が音信不通になったり復活したりする点で並行システムと大きく異なる。 並行システムと同じノリで分散システムを設計しようとした際に陥る頻出の過ちが「分散ロック」である。そのアイデアはとても簡単で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
