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イメージのフォーマット - 世界線航跡蔵
問: Dockerイメージはどういうフォーマットなのか 答: 特定のフォーマットはないが転送時はtar 以前の記事 では、Dockerはアプリケーション動作環境のファイルステムをまとめて差分転送できると書いた。 ではこのディスクイメージはどういうフォーマットなのだろう。 実装こそ違うが実態としては仮想マシン環境に似ているという点を鑑みると、qcowとか何かその類いのファイルフォーマットなのかもしれないという想像も成り立つ。 しかし実際には特定のフォーマットというものはない。 Dockerホスト環境では、ディスクイメージは動作に適した形で保存されている。このため保存形式はdocker daemonの -storage-driver オプションによって異なる。 つまり --storage-driver=aufs で走っているならローカルファイルシステムのサブディレクトリ内に展開されているし、
Dockerで何が変わるのか - 世界線航跡蔵
DockerCon 2014 に行ってきた。 この会期中には各社からいくつもの製品が紹介/発表された。そして、それによってクラウドという技術は次のステージに移行したと言っても過言ではないだろう。 より自由にユーザーがクラウドベンダーを選べる時代へ。どうやってクラウドにうまくデプロイするかではなく、アプリケーションそのものに注力できる時代へ。 Dockerとは Docker とはいわゆるコンテナ技術の1つで、Linuxホスト環境の中に隔離された別のLinux環境を作ってくれる技術だ。 軽量仮想マシンと呼ばれたりもする。 Solaris Container とも似ている。 新しくないDocker 1つ述べておくとDockerは技術的には新しくない。Dockerの価値は技術以外にある(とDockerのCEOもDockerConで言ってた)。 技術的にはSolarisにはSolaris 10の頃か
fluentdを勉強中 - 世界線航跡蔵
最近はlog collectionというと fluentd が話題らしいというので、少し触り始めている。 多少は分かってきたように思うので理解したことと、理解できていないところをまとめてみようと思う。 fluentdとは何か オフィシャルサイトには"tool to collect events and log"と書いてある。 要するに、サーバー群から継続的に情報を吸い上げるための仕組みを提供するdaemonである。 この「情報をかき集める」という枠組みは今時のサーバーサイドでは頻出パターンだ。 データベースサーバ、アプリケーションサーバー、フロントエンドキャッシュサーバー, ...と役割分担をするのが普通だし、 アプリケーションサーバーだって負荷分散のために複数インスタンスを持つのが当たり前だ。 そしてこれらサーバー群をきちんと管理するためには様々な情報をかき集めてきて一カ所に保存したり集
転職のお知らせ - 世界線航跡蔵
世間は地震により慌ただしい。震源地近くの被災者の方にはお見舞いを申し上げる。 この最中に、個人的な報告を投下するのはちょっと憚られるものもあるのだけれども、あまり時期を外しても書く機会を逸するので思い切って書くことにしよう。 1月一杯で約3年務めた 株式会社スケールアウト を辞め、3月1日から Google Japan で働き始めた。twitterでは大勢の方に祝っていただき有り難い限りである。 Googleについては特に語ることはない。みんなが知っているし、私もまだみんなが知っているようなことの他は僅かしか知らない。だからスケールアウトについて語ることにしよう。 株式会社スケールアウト スケールアウトは広告配信エンジン/広告在庫管理システム/広告入稿システム/広告案件管理システムをフルスタックの製品「ScaleAds」を提供するスタートアップである。 創業 創業者の山崎大輔さんは、元はY
はまちちゃんと脆弱性報告のあり方 - 世界線航跡蔵
はまちちゃん がいつものごとく、AmebaなうにCSRF脆弱性を発見して いたずらを仕掛けた 。そして、何故か今回だけ「それは迷惑行為だ」とかなんか騒がしい。 私はそもそも、はまちちゃんのいたずらを「隙があったからカンチョー」に喩えるのが程度がおかしいんじゃないかと思う。それで非技術者には話が通じていないのでは? CSRFやSQL Injectionを許していたら、何よりも守るべきユーザーの情報が危険だ。そしてAmebaがそういう脆弱性を持っていると言うことは、生越さんが指摘するように首相官邸からの公式情報を操作できるという意味だ。これは「隙があった」んじゃないだろう。「開腹したまま内臓が露出している」んだ。 ところが、どうも現実の医師とは違ってこの世界の、特にAmebaみたいな大きな会社の開発者はその辺の意識が甘い。「手術したけど、まー、内臓が見えててもすぐに死ぬ訳じゃないし、適当に皮被
プログラミング言語の進化の方向 - 世界線航跡蔵
セキュリティ&プログラミングキャンプ のBoFで、笹田さんがやってたセッションで話したことがある。言語の進化はベストプラクティスの取り込みにある、と。 ベストプラクティス取り込みの歴史 計算可能である事柄を計算するだけが問題であるなら、チューリング完全な言語なら何でも良いということになるし、不完全な言語は出る幕すらない。ラムダ計算からの自然なマップを考えるならS式で書いて何か実行すれば良いんだし、最小のプリミティブから出発するのが目的ならLazy Kなんかもいいかもしれない。 でも、工学的要請からは、計算可能関数が等しく計算の対象となるわけではない。そして、ある種の計算の傾向、パターンに対して「こうすればいい」「こう考えればいい」「こう設計すればいい」というベストプラクティスが生まれてくる。プログラミング言語の歴史を眺めていると、経験の中から立ち現れるベストプラクティスを取り込んだものが多
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
