タグ

2009年6月12日のブックマーク (7件)

  • Key で sort 済みの Key-Value Storage を作り始めた - higepon blog

    タイトルの通り Key で sort 済みの Key-Value Storage を作りはじめました。 良くある DHT だと Key の Hash を取る事で分散させるので順序情報を失ってしまうのですが、それを Skip Graph という仕組みで順序情報を保持したまま分散させることが可能になります。 sort 済みだとうれしいのは KVS に対して Range Query が可能になること。 例えば、empno-999 以上の value リストを 最新10件、KVS に要求するみたいなことが出来るようになります。 従来の KVS では上記のような Range Query は不可能だったので、そこは RDBMS に任せていたと思うんですが。(RDBMS で Range Query 後、Key のリストを KVS に投げるなど) この辺りの RDBMS の負荷と分散しづらさを KVS 側

    Key で sort 済みの Key-Value Storage を作り始めた - higepon blog
  • tokuhirom blog

    Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at

    kazuhooku
    kazuhooku 2009/06/12
    totally agree
  • ぼくがLLのひとに「ガツン」と申し上げたこと - ひがやすを技術ブログ

    ぼくは水曜日にTokyo Cloud Developerの集まりに出た。 そこで、LLのひとから、「Google App Engineは、Python版以外にJava版も出たけど、サンプル見たけど、たくさんコード書かなければいけなくて、正直どこがいいのか教えて欲しい」という質問があった。 blogに名前を出していいかの了解を得ることを忘れたので、ここには、LLの人としか書けない。 ぼくは、そこで一言申し上げた。あるいはそれは、「申し上げた」というような生やさしいものではないかも知れない。端的な言い方をすれば、ガツンと言ってやった。 客観的に見て、ぼくはガツンと言ってやったと思う。LLな方々を前に、「いまどきのフレームワークは進化しているから、言語による差なんて余りない。仮に、Javaのほうが二倍コードを書く必要があったとしても、開発の中でコードを書いている時間より考えている時間のほうが圧倒

    ぼくがLLのひとに「ガツン」と申し上げたこと - ひがやすを技術ブログ
    kazuhooku
    kazuhooku 2009/06/12
    多少冗長でも人によって書き方に差が出にくい Java は、グループ開発にむいたいい言語だと思ってる
  • それでも僕はソースが短い方がいい

    ぼくがLLのひとに「ガツン」と申し上げたこと - ひがやすを blog - 客観的に見て、ぼくはガツンと言ってやったと思う。LLな方々を前に、「いまどきのフレームワークは進化しているから、言語による差なんて余りない。仮に、Javaのほうが二倍コードを書く必要があったとしても、開発の中でコードを書いている時間より考えている時間のほうが圧倒的に長いんだから、その辺は誤差でしょう。」と「がつん」と言ってやった。それが彼らに届いたかどうかは、ぼくには分からない。しかしぼくがガツンと言ってやったことだけは確かだ。 GAEって使えるサーバリソース群って全部自分のコントロール配下になくて、Googleが予め定めた枠の中でしか行動できないから、「何の言語で開発するのか?」って迷う材料が局所的になるよね。好みの問題にしかならない。 Googleが提供するAPI(みたいなもんだよな)叩ければ、それで色々なリソ

    それでも僕はソースが短い方がいい
    kazuhooku
    kazuhooku 2009/06/12
    コーディングレベルでのバグ混入を防ぎたいなら、字数を気にするよりも型チェックの強いコンパイル型言語を使うべきでは?>「書く文字が増えれば増えるほど、バグが混入する可能性は増える」
  • tokuhirom blog

    Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at

    kazuhooku
    kazuhooku 2009/06/12
    tokuhirom++
  • http://diary.eth.jp/?date=20090609

    kazuhooku
    kazuhooku 2009/06/12
    some_map.erase(it++) と書くのが best practice なのかなぁ。てか erase(it->first) は iterator もってるのに再度検索することになるので美しくないと思う
  • 奥さんにささげる - ひがやすを技術ブログ

    奥さんっていってものほうじゃなくて、http://developer.cybozu.co.jp/kazuho/のほうね。 昨日のTokyo Cloud Developerで、kazuhoとBigtableの話をしてたんだけど、ちょうど、松尾さんからいい資料があるといわれてみてみたらとてもすばらしかった。松尾さん、ありがとうー。 http://sites.google.com/site/io/under-the-covers-of-the-google-app-engine-datastore もう既に見ているかもしれないけど、一応ご報告。 Google App Engine(Bigtable)の内部のデータのもちかたが詳しく説明されています。 これをみずに、Bigtableは理解できない。 奥さんじゃない人も、App Engineに興味のある方は見るといいよ。

    奥さんにささげる - ひがやすを技術ブログ
    kazuhooku
    kazuhooku 2009/06/12
    ありがとうございます! higayasuo++ tmatsuo++