ぐりとぐらの縮尺適当すぎ娘たちが寝る前にぐりとぐらを毎日読んでやってるんだけど、あの絵本の物とか動物の縮尺ってどうなってるんだ。 どんぐりがぐりぐらの手のひらくらいの大きさなのは順当として、ライオンと木がぐりぐらと同じ大きさなのは納得いかん。ライオンと同サイズのネズミって怖いじゃん。 あと泡立て器とお玉はぐりぐらより小さいのに何で鍋とボールはあんなに大きいものを家に用意してるんだ。 そもそもあのデカイ卵が何の動物の卵だったのか最後まで明らかにされないのも不完全燃焼で嫌ですね～私は。
サーバレス時代におけるヘテロジニアス時系列データベースアーキテクチャ - ゆううきブログ
この記事は、第2回ウェブシステムアーキテクチャ研究会の予稿です。 ウェブシステムをモニタリングするために、高可用性、高書き込みスケーラビリティ、メトリックの長期保存が可能な時系列データベースが求められている。 これらを実現するために、性能特性の異なる汎用Key-Value Store(以下KVS)を組み合わせ、透過的に問い合わせ可能な、ヘテロジニアス時系列データベースであるDiamondを開発した。 この記事では、Diamondを分散システムの観点で捉え、アーキテクチャ、データ構造、実装を紹介し、考察によりFuture Workを議論する。 1. はじめに 2. アーキテクチャ アーキテクチャ概要 動作フロー データ構造 KVSの機能要件 3. 実装 実装概要 KVS間のデータ移動 データ位置の解決 費用特性 4. 考察と今後の課題 Diamondの欠点 将来機能 5. まとめ スライド
「懲戒請求→返り討ち」が発生した事情
今週のはじめ頃だと思うのだが、ツイッター上で2人の弁護士への組織的な懲戒請求が話題になった。 タイムラインに流れてきたいくつかの書き込みを眺めて、私は 「まあ、よくある話だわな」 と判断して、以後、たいして注目していなかった。 というよりも、すっかり忘れていた。 ところが、しばらく私が注視を怠っているうちに、この件はちょっとした事件に発展しつつある。 なるほど。 よくある話だと見て軽視したのは、私の考え違いだったようだ。 よくある話だからこそ、重要視していなければならなかった。 よくある不快ないやがらせだからこそ、めんどうがらずに、的確に対応せねばならない。 肝に銘じておこう。 話題の焦点は、インターネット上で挑発的な言論運動を展開しているブログの呼びかけに応じる形で、特定の弁護士に対して集団的な懲戒請求を送った人々が、その懲戒請求の対象である2人の弁護士によって逆に損害賠償の訴訟を示唆さ
クライアントサイドのモデルとは何か 後編 ~ 単方向データフローと参照透過性 - mizchi's blog
この記事は クライアントサイドのモデルとは何か 前編 ~ クライアントサイド MVC の死 - mizchi's blog の後編。 前提として、今回の出す例で、「Web フロントエンドで、そこまで複雑な状態を考慮するなんてそもそも間違ってる」という意見があると思う。これに関して、そもそも「SPA というものが、いかに実現可能になったか」という視点の話であり、また、自分の経験上「フロントエンドなんて雑でシンプルでいいでしょ」というものが、複雑な構成を取っていくのを、何度も目にしてきた、という2つの前提がある。 適切な粒度に応じた適切な構成をとるべし、というのは別の話で、今回、対象が複雑なアプリケーションなのは前提とする。 Flux 以前 先の記事で ActiveRecord を前提にしたサーバーサイド ORM をクライアントで輸入しようとすると、クライアントでは Storage 層が存在し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
