APIデザインケーススタディ —— Rubyライブラリを移植する前に読む本 - 世界線航跡蔵
『 APIデザインケーススタディ 』という本を頂戴したので読んでみた。 ライブラリ作者に向けて この本はRuby標準ライブラリを題材にして、分かりやすく、多様な機能をサポートして、互換性を保つAPIの設計をするにはどのように考えるべきかを教えてくれる。 ここでAPIと言っているのは、一般的なRubyのクラスとオブジェクトとメソッドから成るライブラリをどうデザインするか、という話である。 別にChef RecipeやRSpec DSLのようなちょっと変わったDSLを設計するとかそういう話ではない。確かにその種の言語内DSLのデザインには固有のセンスが必要とされるし、 Ruby DSL Handbook なんて本が書かれているように実装にあたってもある種のテクニックが必要なのも確かだ。でも、それ以外の「ふつう」のライブラリのデザインは果たして簡単だろうか。 適切な粒度のクラスを定義する。必要な
gRPC-JSON proxy - 世界線航跡蔵
grpc-gateway という gRPC からJSON APIへの変換プロキシ生成機を書いた。 これを使えばシステム内部ののmicroservicesはgRPCで通信しつつ公開APIはJSON APIで提供する、みたいなことが簡単になる。 なお、gRPCそのものについては mattnさんの記事 が参考になる。 背景 gRPCの良い点はいくつもある。 データはデフォルトでprotocol buffersで直列化される。ベストではないにせよ十分にコンパクト且つ高速だし、サイズで言えばJSONとは比べるべくもない。 簡単に複数の言語でサーバーのテンプレートやクライアントを生成できる。通信の詳細はgRPCにまかせて開発者はサーバーロジックの実装に注力できる。 design by Googleという安心感。 gRPCの素晴らしさは認めるものの、一方では欠点もある。まず、クライアントライブラリの多く
Dockerで何が変わるのか - 世界線航跡蔵
DockerCon 2014 に行ってきた。 この会期中には各社からいくつもの製品が紹介/発表された。そして、それによってクラウドという技術は次のステージに移行したと言っても過言ではないだろう。 より自由にユーザーがクラウドベンダーを選べる時代へ。どうやってクラウドにうまくデプロイするかではなく、アプリケーションそのものに注力できる時代へ。 Dockerとは Docker とはいわゆるコンテナ技術の1つで、Linuxホスト環境の中に隔離された別のLinux環境を作ってくれる技術だ。 軽量仮想マシンと呼ばれたりもする。 Solaris Container とも似ている。 新しくないDocker 1つ述べておくとDockerは技術的には新しくない。Dockerの価値は技術以外にある(とDockerのCEOもDockerConで言ってた)。 技術的にはSolarisにはSolaris 10の頃か
DISQUSに移行 - 世界線航跡蔵
このサイトのコメントシステムを TypePad Connect から DISQUS に移行した。幸いなことに(?)、まだコメントは頂いていなかったのでデータ移行は問題ない。 移行の理由は2つ。 もう1つは、DISQUSのほうがメジャーな雰囲気なので。この手の囲い込みサービスは結局勝ち馬に乗るのが良い。 API が用意されていて、あとで追加開発すればコメントのデータは自前で持てそう、というのが1つ。データを外部サービスに完全に依存して移行の方法もないのはやっぱりちょっと気持ち悪い。 スパムへの対処はもういい加減しんどいので、この手の外部サービスにコメントを管理させる流れは方向性として間違っていないと思う。それに、利用者としてもこうやって自分があちこちに付けて回ったコメントが自分のアカウントで一元管理される仕組みはうれしい。そして、DISQUSへのログインはFaceBookやGoogleのアカ
フィルタリングの技術的問題点を知らしめる活動 - 世界線航跡蔵
若年者(年齢の線引きはおいといて)のように価値判断が未発達な人間に見せないほうが良い情報があることは認めよう。それにしても、側にいる大人が日常的な指導や適切なフォローをすればカバーできるとは思うけどね。 技術的時期尚早 でも、何度でも言うけど、現在の技術的な水準では、webコンテンツのうち「有害」なものを検出するには無理がある。もしそれを完璧にできるって言う人間がいるなら、その人に国がちょっとした助成金を出すべきだ。そうすれば、みるみるうちにgoogleやmicrosoftやyahooなんか霞んでしまうはずだから。 つまりは、それぐらい、「有害」なものを検出するというのは技術的に難しい。貴重な情報を誤って「有害」と見なしてしまったり(false positive)、そのくせ露骨な性暴力コンテンツみたいなのを「有害でない」とみなしてしまう(false negative)。これが現代の技術の限
無断リンクを禁止する移民たち - 世界線航跡蔵
「 無断リンク禁止は、WWW をどう考えているかの問題あたりらへん 」を読んだ。 え、何? また「無断リンク禁止」が問題になってるの? これ、何周目の議論だろ。WWW日本語圏に限っても5周や6周じゃ済まないよね。ただ、私にとってはその繰り返しもまったくの無意味ではなかった。無断リンクを禁止したがる人々にとってのWWW、彼らが感じているWWWというものがいくらかは分かってきたのだ。彼らの「ほーむぺーじ」も「ぶろぐ」も「ぷろふ」も発信者個人のアイデンティティと極めて密接に結び付いた感情表現の集積であり、リンクが成す生態系それ自体も彼らの感情ネットワークの反映であり、そこに土足で暴力的なリンク(=感情)が割り込んできては困るのだ。 昔々、書いたことがある けれども、これはどうやら文化の違いらしい。何を見るのか、何を感じるのか、思考の枠組、その違い。見ているものがちがうのだから、まずそこからすり合
Webの終わる日 - 遥。これ以外の何か - 世界線航跡蔵
先日、 id:uzuki-first さんにworld wide webの終わる日についてちょっと話した。 まぁ、webはいつか終わる。ブラウザベースの枠に押し込められたユーザーインターフェースは決して完全なものではないからだ。じゃあ、どう終わるかね。私たちはその中でどうするかね。 ちょっと長くなるけど、そんなことをつらつらと書いてみる。 webアプリケーションの発展 いくつかの利点からwebアプリケーションは支持され、発展した。まず、静的なページに基づくWebサイトと動的なアプリケーションとの境界をあいまいにできるということ。これは「いんたーねっと」ブームで入ってきたライトユーザーが、「リモートに情報を送信しリモートで実行される処理を利用する」というモデルに段階的に慣れて移行することを可能とした。最初は単なる検索フォームぐらいのものを利用していて静的なページと大して変わらなかったかもしれ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
