ある異邦人の技術メモ

2016-12-07 ひさしぶり

ここのところ仕事的にも人生的にも忙しく、ここに何もかけずにいました。が、ちょっと仕事でやっていることを個人ブログであるここに書いていい流れができてきたので、またチョボチョボとここにも色々書いていきたく思います。

しかし、はてなダイアリー久しぶりなので、はてな記法とか全然覚えてない。 markdownとかつかえないのかな。

2015-08-18

Personiumの紹介

まず手始めにPersoniumの簡単な紹介から。ペルソニアムと読みます。

http://personium.io

http://github.com/personium/io

このソフトウェアは2008年ごろ、自分が会社の研究所にいたときに「新たなITの形を考えてみよう」という話があったときに、思いついたアイディアから始まりました。今PDS(Personal Data Store)という名前がそこそこ広まって来ましたが、まさにそのアイディアです。そのアイディアを思いついたときは「わっ、すげーこと思いついた」と興奮したのを覚えています。でも、世の中「新たなことを思いついた」と思っても大抵は先人がすでに思いついているもので、これも例にもれずPDSという考え自体は2000年代初頭からあったようですね。

そんなことは露知らず「このアイディアを形にしたい」という想いでプロトタイプをつくり、PDSという言葉もBaaSという言葉もなかったので、このソフトウェアは何であるということを説明するのに苦労しながらも仕事として試作や実証などをさせてもらい、このソフトウェアを成長させることができました。

PDSなのかBaaSなのか

個人的にPDSPDSである前にBaaS(Backend as a Service)でなくてはならないという風に思っています。なぜならば、今、個人というものはスマホタブレット・PC・ゲーム機・センサなど様々な端末で、実に様々なアプリを操作しながら自分のデータというものを生成しつづけているからです。iOSやらAndroidやらWindowsやらと端末のプラットフォームを問わずにデータを入れてもらうためには、RESTという文化がフィットすると思ってます。HTTP(S)がしゃべれないプラットフォームはないですし、RESTという考え方はデータ指向のものだからです。

PDSという世界は、ともすれば既存のICTの在り方を根本から変えませんかという野心的な試みなので、今現在、なかなかそれ単体では「実用」になりづらい研究的な世界のものかと思っています。一方でBaaSというのはモバイル・タブレットアプリをつくるということならばすぐに役に立つ技術です。ですので、会社の仕事としてこれをやってきた関係上、BaaSとしての側面を重点的に磨いてきています。

ODataサポート

具体的にはMicrosoftさんが主導してOASIS標準にしたODataというRESTベースのプロトコルのサポートが一つの強みになっています。ODataはリレーショナルデータの操作を(SQLでなく)RESTでやるためのプロトコルで、すごくよくできた仕様だと思います。

http://www.odata.org/

personiumは、アプリケーションが扱うデータというものは「木構造ディレクトリ構造をもったファイルシステム的なもの」か「リレーショナルデータ的なもの」の2種類でほぼ事足りるかなぁという仮説に立っています。それで、personiumのアプリケーション毎のデータ空間はWebDAVの空間なのですが、そこにODataの空間が切れるようにして2種類のデータを扱えるようにしています。

実は2009年ごろにつくった初代のpersonium実装では、ODataに似た仕組みを自分で考案して実装していたのですが、機能が非常に貧弱で掲示板がやっと作れるかどうかというような代物でした。ちょうどそのころ、良いタイミングでMSさんがODataを発表されました。研究所の同僚がそれを見つけて教えてくれて、これはいいと思って見よう見まねで2010年ごろの実装で取り入れました。ODataは結構高機能で複雑な仕様なので、最初はエッセンスだけ取り入れる感じでしたが、2012ごろの改修時に比較的ちゃんとこの仕様を実装できました。

OASIS標準になったのはOData V4になったときですが、我々がOData実装を取り込んだのがV2の時点だったので現状のpersoniumはOData V2のサポートにとどまっています。OData V4ではV2では仕様化されていなかったSQLでいうところのsum()やらavg()に集約関数などが使えるようになっていたりするので、どこかでOData V4のサポートもできたらいいなと思っています。

2015-08-17

復活

5年ぐらい間が空きましたが、久しぶりにこのBlogを更新してゆこうと思います。理由は、先日仕事でやっている以下のオープンソースPDS/BaaSソフトウェアを公開し、会社の方針として個人Blogを通じて世の中の技術者の皆さんに草の根的に色々伝えてゆくべしということとなったためです。

http://personium.io

http://github.com/personium/io

このソフトウェア、色々なところですでに使われているのですが、今のところドキュメント類が少ないのが非常に弱点になってます。ので、それを補う役割も担えたらなと思ってます。

2011-11-03 ThriftとかProtocolBufferとか

自分はREST信者だけど、昨日、「RESTに固執せずThriftとかどうよ」という話をもらった。Thriftとか名前以外あんまり知らなかったので、一応20分ほどWebで調べてみた。結論からいうと、「やっぱりあまり興味を持てない」と思った。

ThriftとかProtocol Bufferのいいところって、

  1. ネットワーク転送量的にオーバーヘッドが少ない
  2. いろんな言語ですぐに使える
  3. HTTPベースのRPC
  4. 色々なサービスの内部で使われることはもちろん、EvernoteAPIとかでも使われている。

ってところだと理解した。が、とりあえずあまり魅力は感じなかった。なぜか。

  1. 1を突きつけられる場面では確かにRESTは多少分が悪い。がXMLの冗長性を攻撃するのアプローチはどうかとおもう。ってのは、XMLが冗長なデータフォーマットであることは登場したときから最初からわかってることだから。パフォーマンスがクリティカルな局面であんな形式の電文を生で流すのはみんな「最初からありえない」前提だったわけでしょ?それを今更なにいってんのと。異文化(業種とか)間相互接続性(名前空間とか)が求められる世界ではXML、異文化相互接続性が不要なら人間にとってのそこそこの可読性を保てるJSON、で、パフォーマンスのため転送量減らしたければ、TransferEncoding: gzip。という形でRESTやっていれば、そこそこ困らない。(パレートの法則的に)
  2. HTTPの接続・切断のオーバーヘッドが気になるなら、KeepAliveすればいい。
  3. そもそもRPC vs Data という話で、あんまりRPCが必要な場面が個人的にはない。
  4. RPCが必要になる場面においても、CORBAやらなにやら、XMLより昔からある"効率的な"RPCと何が違うのかもよくわからない。
  5. ThriftやらProtocol Buffer実際やるとなったら、独自の定義体書くためにはそれを学習しなくてはならないし、細かい話、コンパイルするオペレーションをCIに組み込むにはどうすべきかなど、色々付随する作業が出てくる。その直観的コスト見積もりと、見返りである効果を考えたとき、今のところあまり魅力を感じない。

まあ、全く興味がないというと嘘になって、今、RubyJavaの混在実装を扱ったりしていたりするので、実はふつうにRPCで実装するといいのかもしれない。けど、そもそもまだまだHTTPを使いこなせて(非同期IOとかWebSocketとか)いない今、そっちに時間投資するより、ちゃんとHTTPが使いこなせるようになりたいなと思う。

そんな感じ。まあ、FBやGoogle発だからブランド的にみんなが飛びついて普及するということなら、僕もいずれやるかもな。。っていうか、時間さえあれば、やってみたいとは、思う。

参考:

http://ohnaka.jp/blog/2011/08/493

http://blog.broomie.net/index.cgi?id=38

http://code.google.com/intl/ja/apis/protocolbuffers/

http://code.google.com/intl/ja-JP/apis/protocolbuffers/docs/faq.html

2011-08-11 CouchDB 1.0.3からのバグ

CouchDB 1.0.3 以降で発生するバグを仕事の仲間が発見しました。ひとことでいうと、

「削除されたドキュメントのあるDBをレプリケートしたときに、同じキーでドキュメントを作ろうとすると201が返るが実際は作成されない。」

というもの。1.0.1, 1.0.2 ではこの現象は発生せず、1.0.3, 1.1.0では発生します。

再現手順

    • 任意のDB(db1とする)のなかの任意のドキュメント(doc1)を削除する
    • 新たなDB(db2とそる)をつくり、db1からレプリケーションを行う。
    • レプリケートであるdb2にdoc1と同じキーで新たなドキュメント(doc2)をPUTする。
      • ⇒201 Createdが返ってくる。
    • db2のdoc2をGETする。
      • ⇒(1.0.2以前)ちゃんとさほどいれたドキュメントが返ってくる(あるべき振る舞い)
      • ⇒(1.0.3以降)404が返ってくる。(たぶんバグ)

英語でバグレポートをあげたいねと話をしているところ。