サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
kumagi.hatenablog.com
blog.j5ik2o.me 値オブジェクトはドメイン固有型の一種です。なので、不変と等価判定だけではなく、なにかしらのドメイン固有の不変条件(invariant)を維持する責任があると考えます(もちろん型として切り出すわけですからその投資に見合うだけの見返りがないといけません)。 違う。値オブジェクトとはID以外で等価判定をするオブジェクトの事であって、RubyのHash、Pythonのdict、C++のstd::unordered_setすらも値によって等価判定を行うのでこれらは値オブジェクトであるがドメイン固有型ではない。RubyでHashに入れて渡されたユーザ入力値をValidationしてドメイン固有型に詰め直すのはもちろん必要ならやれば良いが、Hashクラスそのものにモンキーパッチなり特異クラスなりを行って不変条件を維持する責任を負った自分専用Hashを作って普通のHashクラ
この記事は pyspa advent calendar 2023の11日目の記事です。 godboltをご存知だろうか。 godbolt.org ブラウザから誰でもアクセスできる無料サービスでコンパイラの挙動について学ぶ事ができる。 例えば簡単に「渡された数Nに対し1+2+....+Nを返す関数sum」を例にすると こんな感じにコンパイル結果のアセンブリを表示してくれる。 アセンブリはマウスカーソルを置くとそれが元のコードのどの場所に対応したものなのかを逐一ハイライト表示してくれる。この機能を実現するために必要な労力は並では無いと思うが詳細はわからない。アセンブリ側も複数色あるのは元のコードの1行が同じ背景色のブロックになった事を表している。 これがすごいのはコンパイラの選択肢の豊富さである。gccはもちろんのことclang, zig c++, msvc, nvc++(なにそれ?), el
凍った木が溶け始める様子をそれっぽく描いてもらった この記事はデータベース・システム系 Advent Calendar 2023の2日目の記事である。前日は僕、明日も僕。 Log Structured Merge Tree(以下LSM-Tree)という物をご存知だろうか。データ構造としては順序付きの辞書であり結構昔に発明されており各操作の計算オーダーは赤黒木等と同じである。システム系学会を追っていると無限に亜種が提案されているので特徴を一言で言い表すのは難しいのだが、その一種であるLevelDBはChromiumの中でも使われている。 https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/leveldatabase/leveldb_chrome.h LSM-Treeの典型的な実装の概要とその利点・欠点を整理すると
AIに描いてもらったストレージで作ったレース会場 はじめに この記事はデータベース・システム系 Advent Calendar 2023の一日目の投稿である。今年読んだ論文(今年書かれた論文とは限らない)の中で驚きや納得があって良かったなぁと思った論文をいくつか紹介していきたいと思う。 論文の本文そのものは機械翻訳なりチャットAIなりに叩き込めば誰でも内容の抽出はできるので、こちらのブログ内では何故これが良いと思ったかについて僕の主観に基づいて書いていく。僕の解釈が厳密に正しいことは一切保障しないし、気になって読んでみたら全然内容違うやんけ!と驚くところまでがセットくらいの気軽なつもりで読んで欲しい。 最初に紹介する論文は「When Database Meets New Storage Devices: Understanding and Exposing Performance Mism
これまでプログラミングモデルのプの字もなかったので申し訳程度にプログラミングモデルの話をする。 分散して特定のアプリを動かしたいだけなら、例えばbitcoinをマイニングするASICクラスタに対して特定のプログラミングモデルは必要とされない。そのように、行いたいタスク抜きにプログラミングモデルを語る事はできない。 HPC(ハイパフォーマンスコンピューティング)系のワークロードは古くからMPIがデファクトとなっている。 MPIでのプログラミング MPIというのは「Message Passing Interface」の略でSmalltalkなどの文脈で語るいわゆるメッセージパッシングとは哲学というかレイヤーが違う。こいつは 配列を引数に取る関数の形で1:1, 1:N, N:Nの通信の典型的なパターン(1:Nなら例えば `MPI_Broadcast` とか)をインタフェースとして定義しており、ユ
blog.j5ik2o.me この記事は彼のブログ投稿への返信です。 彼とのtwitter上でのreplyの応酬スレッドが見返すと引くほど長くなっていたので僕の観点からの要約を纏める。予め断っておくとこれは本当に自転車置き場の議論以外の何物でもなく、技術的な学びはどこにもない不毛なやりとりであって、苦労して理解する価値がなかったなどの苦情は受け付けない。 kumagi: 値オブジェクトはIDによらない等価比較をするオブジェクトの事であって、ドメイン固有の値オブジェクトもそうでない値オブジェクトもある。 かとじゅん: それはおかしい。全ての値オブジェクトは何らかのドメインオブジェクトの一部であって、Integerすらも整数ドメインの問題を解決するために設計されたドメインオブジェクトと言える。Evansも肯定しているはずだ。 kumagi: なるほど、その整理の中で逆にドメインオブジェクトでな
以下ポエム。 TL;DR; 悪者が居ない組織でも無能で勤勉な会議体は未知の力学で動き続けるのだ。 一般に、大企業に就職するのは簡単ではない。 知名度がある分、エントリーしてくる人間の数も多く自然と競争が熾烈になる。 その熾烈な競争を勝ち残った分、そりゃ優秀な人間が多いというのは採用を担当した人事の弁である。 実際に仕事で役立つ力と、採用の現場で重視されるコミュ力では尺度に乖離があったりで必ずしも現実はうまく回らない。 世の中のIT系の巨大プロジェクトは往々にしてデスマーチに見舞われる。 デスマーチに巻き込まれた末端の人間は目の前の個別の問題に対して「おいこりゃやべーよなんとかしないと」とか思いつつも末端故に全体を止めるような力を持ち合わせてない。 であれば、デスマーチの頂点付近にいる重役ぐらいにしかそれを止める強権を発動し得ないのではないかというのは妥当な考えである。だが世の中はうまく行か
この記事は安ワインを煽りながら勢いで書いたので一切の正しさを保証しません。 分散システムで良く出る課題として障害耐性がある。 性能を増やしたい→台数を増やせばいい→一台でも壊れたら全体が死ぬので脆弱になった→一台死んだぐらいで全体が死なないような仕組みにしろ→複数台でデータを複製するしかない という変遷は自然で、ここから一歩踏み出そうとして大量の屍が量産されたのがここ50年ぐらいの歴史。逆に言うとここまでは50年以上前には到達していて、その50年で何も成果が無かったわけじゃない。 中でも大きな成果だと思っているのがLinealizablityの定義。これは分散システムに対して結局のところ人類が何を望んでいるのかを明文化した点で大きな貢献があった。 僕の覚えている定義はこう。 クライアントが要求した順番とシステム内で実行される順番は等しい。 しかもクライアントが要求を発行した全順序と系を跨い
HTMの第一人者にして、obstruction-freeやwait-freeなどの厳密な定義や、CAS命令の数学的な意義を証明し、The Art of Multiprocessor Programmingの著者で、ロックフリーでもSTMでも八面六臂の活躍をしているMaurice Herlihy先生が連名している最近の論文を流し読み。 Aleksandar Dragojevic, Maurice Herlihy, Yossi Lev, Mark Moir: On the power of hardware transactional memory to simplify memory management. PODC 2011: 99-108 「トランザクショナルメモリのパワーでメモリ管理を簡略化する」という感じ。 GCを使わない環境下においてメモリ管理は鬼門になってて、そのせいでC++のロ
TL;DR スタンディングデスクは良い コロナ禍が始まって以来、在宅勤務を続けているが勤務先へのアクセス利便性を優先したが為に住居は1LDK+Sという状況で、2歳になった娘も居る状況で労働環境の確保と充実は急務であった。 スタンディングデスクで探すと昇降デスクと1m程度での高さ固定デスクの2種類が見つかるが、人間の身長は±30cm以上の個人差がある中で特定の固定の高さがジャストフィットする望みは薄く、長時間作業を前提とする場合は微妙な高さのズレが腰痛や肩こりなどの形で跳ね返ってくるのでジャストフィットに調節できる昇降デスクをおすすめしたい。 スタンディングだと疲れるという人は疲れた時には椅子を使ってもいいし、定期的に立ち上がって仕事をするほうが座りっぱなしよりは健康に良いとされる。昇降デスクはもちろん椅子の高さに合わせて下げる事もできるので、高さを替えやすい昇降デスクはその点でも有利だ。
STMの話題では無いのだけれど自分がKVS上でのSTMというものをPythonで作りながら感じた事 pip install python-memcacheで入る、純Python実装のmemcacheクライアントライブラリ memcachedクライアントライブラリは他にも幾つか有ったのだけれどことごとく要件を満たさなかった - cmemcached : libmemcachedをcythonで包んだラッパ。失敗したら論理エラーだろうが物理エラーだろうが全部数字の0を返すというダメっぷりに辟易。ついでにcythonなので今のPyPyでは動かない - pylibmc : libmemcachedを純Cで包んだラッパ。論理的な失敗(add, replace, casのセマンティクス上の失敗)ならきちんとboolで返って来るし、通信ミスなどの物理エラーはきちんと例外飛ばしてくれる。マルチスレッドの時
http://www.amazon.co.jp/dp/1608452352 を読んで自分の気になった所を読みながらメモした物を置いておく。抄訳ほどすら訳していない。 発表のプロットに使うまとめ。論文の参照番号がそのまま埋め込まれてるのは酷いのでそのうち直すかも。気になる人は本を買ってください。 あまりに乱雑に書いてある&&Markdown記法なので読むに耐えないかも…。 ## 並行制御 ロックのタイミング。 衝突頻度が高いほどPessimisiticの方が性能が出るが、衝突頻度が低い場合はOptimisticのほうが速い事が多い。 ### Pessimistic アクセス時にロックする。デッドロックに気をつける必要がある。 ### Optimistic それ以外。デザインの幅が広い。ライブロックの危険がある。 readにOptimistic、writeにPessimiesicを使う亜種もあ
TL; DR; 「神輿は軽くてバカがいい」というのは文字面以上に誠実な上司と社員の信頼関係 大きい企業ではとにかく会議が多い。僕の務めている部署では意図して会議を減らしているのでかなりマシな部類ではあるものの、その減っている会議の中でもときおり大きい組織らしい側面がひょっこり顔を出す。 それは、僕が普段から「ファントム」と呼んでいる現象である。僕の脳内ではFate/Grand Orderに出てくるファントム・オブ・ジ・オペラのイメージでだいたい合っている(画像はゲームから引用)。 会社は組織として動いているので、例えば「部」のレベルでの意思決定が必要な問題に対し、ヒラ社員が勝手に意思決定をすることは当然できない。 そこで部のレベルの承認を得るための道筋を、一個下の課のレベルで検討をするためヒラ社員と課長で会議する。その中での意思決定は「その場に居ない」部長の意思をみんなで想像しながら行う。
このページを最初にブックマークしてみませんか?
『Software Transactional Memo』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く