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の頃か
予約語考: 或るRuby厨の意見 - 世界線航跡蔵
Pythonは予約語が少ないらしい 。 Rubyは実はメソッド名には予約語を使えるので、APIを設計するという意味では予約されててもあまり困らない。 class C def end :end end end c = C.new p c.end #=> :end p RUBY_VERSION #=> 1.8.4 ただし、文脈によってはうまくparseしてくれないので、Module#define_methodで代用するテクニックが必要だったり。メソッドを使う側はいいとして、書く側は面倒かも。それから、呼ぶときもレシーバを明示的に書かないとparse errorになる場合もあるけど。 でも、本当に身内で使うようなメソッド、privateなメソッドは、予約語を避けて命名してもあまり困らないしなー。そして、publicなメソッドはどのみちレシーバを指定するわけだし。 それにしてもさすがにメソッドをi
Rubyの力、すなわちブロックなり - 世界線航跡蔵
Rubyの力はブロックにありと常々主張している。その文脈導入の力。そして、それを陰から支えるのが継続である。 Rubyの力はブロック構文にある。これを単なるlabmdaだとかコールバックだとか言ってしまうのは簡単だが、こういう構文の形をしていることに意味がある。まつもとさんは IPA未踏 千葉滋PM案件報告会 において、「DSLにおいてコンテキストを生成する」という点に着目してこれを説明した。例えば、Rakefileにおけるターゲットがそうであるし、Railsのconfig/routes.rbがそうである。 まつもとさんの言う視覚的に明確な形でコンテキストを導入する力としてのブロックに含まれてしまうのだが、私が常々主張してきたのは File.open のようなリソース管理の方法としてのブロックである。 先日ついつい 愚痴 を書いてしまったけれど、GCな世界で育った初心者はどうもリソース管理
はまちちゃんと脆弱性報告のあり方 - 世界線航跡蔵
はまちちゃん がいつものごとく、AmebaなうにCSRF脆弱性を発見して いたずらを仕掛けた 。そして、何故か今回だけ「それは迷惑行為だ」とかなんか騒がしい。 私はそもそも、はまちちゃんのいたずらを「隙があったからカンチョー」に喩えるのが程度がおかしいんじゃないかと思う。それで非技術者には話が通じていないのでは? CSRFやSQL Injectionを許していたら、何よりも守るべきユーザーの情報が危険だ。そしてAmebaがそういう脆弱性を持っていると言うことは、生越さんが指摘するように首相官邸からの公式情報を操作できるという意味だ。これは「隙があった」んじゃないだろう。「開腹したまま内臓が露出している」んだ。 ところが、どうも現実の医師とは違ってこの世界の、特にAmebaみたいな大きな会社の開発者はその辺の意識が甘い。「手術したけど、まー、内臓が見えててもすぐに死ぬ訳じゃないし、適当に皮被
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
