Flynn Overview - r7km/s
Flynn という、コンテナを複数ホストで動作させるPaaS実装の全体像。 strowger リバースプロキシ。 ユーザからTCP/UDPリクエストを受け付けて適切なホスト (の中で動いているDockerコンテナ) に委譲する。 HAProxyやNginxのようなものだが、再起動や設定ファイルの再読込無しで動的に設定が変更できるという特徴がある。 controllerからHTTP経由でリクエストを受けて、ルーティング情報を表示したり変更したりする。 gitreceived git-push(1) を受け付けて適当な処理を行うためのSSHサーバ実装。 受け取ったコードをslugbuilderというツールで実行可能な形式 (=slug) にコンパイルしたあと、Shelfと呼ばれるファイルサーバにslugをアップロードする。 アップロード後、controllerに対してアプリがpushされた
SQL Translator - r7km/s
SQL::Translator という、 SQLの構文解析器 + これを利用した便利なツール群を読んだ。 SQL::Translatorの使い方 とりあえずSQL Translatorの使い方を知らないことにはどうにもならないので、 使い方を調べて小さな動くコードを書くことに。 まず手元にbefore.sqlとafter.sqlという2つのSQLのファイルを用意した。 before.sqlでusersテーブルを作成し、更にafter.sqlでitemsテーブルを作成している。 $ cat before.sql CREATE TABLE `users` ( `id` integer(10) unsigned NOT NULL AUTO_INCREMENT, `name` char(16) NOT NULL, PRIMARY KEY (`id`) ); $ cat after.sql CREA
Discoverd - r7km/s
flynn/discoverdという、Golang製のService discovery systemを読んだ。 何ができるのか クラスタ内の全ホストでdiscoverd(とetcd)を動作させておくことで、 各ホストのアドレスやメタ情報、クラスタへのホストの追加や削除などの情報が簡単に購読できるようになる。 各ホストは名前ベースで管理されるため、同じ名前を持つホストを群として一律に扱うこともできる。 具体的には discoverdは各ホストから発行されるRegisterイベントとUnregisterイベントを検知し、 discoverdに対してsubscribeしていたクライアントにこれらのイベントを伝える機能を持っている。 例えばdiscoverdを動作させているあるクラスタにsubscribeしているクライアントは、 10.0.0.1と10.0.0.2のホストがこのクラスタに参加(=
OAuth Sign - r7kamura per second
OAuth 2.0 への理解を深めるため、自分がOAuthをどう捉えているかを整理します。 多分に誤解が含まれている可能性があるので悪しからず。 OAuth 2.0 OAuth 2.0を利用してリソースサーバ(=Web API)と通信を行う場合、 以下の処理が行われます。 ユーザは認証情報を認証サーバに渡してアクセストークンを発行してもらう ユーザはリソースサーバと通信する際にアクセストークンを一緒に渡す リソースサーバは受け取ったアクセストークンからユーザを識別する リソースサーバは識別結果をもとに適切な処理を行いレスポンスを返す 認証情報 認証情報には幾つかのパターンがあり、以下の情報が含まれます。 アプリケーションを識別するための情報 ユーザを識別するための情報 認証方法などを表すメタ情報 認証サーバとリソースサーバ 認証サーバは、アプリケーションを登録したり、アクセストークンを発
Apiary - r7kamura per second
API(とそれに携わる開発者)の規模が拡大してくると、ドキュメントの整備や、仕様と実装の一貫性の維持、 クライアントとの知識の共有など、考慮すべき問題が沢山出てくる。 これらの問題に対する現実的な解決策を探るため、 ApiaryというAPI開発支援用のサービスを簡単に俯瞰することにした。 ここでは紹介しないが、他に RAML、 JSON Schema、 Swagger、 WADL、 Autodoc などが関連するものとして挙げられる。 Apiary http://apiary.io/ Apiaryは、API Blueprintと呼ばれる言語でAPIのインターフェース仕様書を記述する、という開発方法を提唱している。 API BlueprintはMarkdownを拡張した言語で、特殊な記述を用いて幾つかのメタ情報を付与出来る形になっている。 Markdownを採用することで人間にとって読み書き
Device Specific API Design - r7kamura per second
The Netflix Tech Blog: Embracing the Differences : Inside the Netflix API Redesign Netflixの開発者ブログで触れられているように、Netflixは以下の4つの方針に沿って彼らのAPIを再構築した。 デバイスごとの差異を受け入れる コンテンツの収集と整形を分ける クライアントとサーバの境界線を再定義する 変化を促進する デバイスごとの差異を受け入れる REST APIのように1つの汎用的なインターフェースで全ての要件を満たそうというアプローチは、 APIへの理解が簡単になる一方、後から変更することは難しくなり、また非効率な処理を生み出しやすくなる。 この手のアプローチが重視しているのは、API提供者側の開発コストを下げることであり、 API利用者の利便性を第一に考えたものではないと彼らは考える。 API
Includable YAML - r7kamura per second
YAMLの定義内で別のファイルに書いたYAMLを参照出来るようにしてみた。 YAMLに加える変更 YAMLの各要素には任意のタグを埋め込むことができ、またその振る舞いを定義出来る。 # test.rb require "yaml" YAML.add_domain_type(nil, "include") do |type, val| YAML.load_file(val) end # 折角なので再度YAMLに加工して出力してみる puts YAML.load_file("api.yml").to_yaml Includeする側 例えば、レシピデータを返すREST APIの仕様をYAMLで定義するというユースケースを考える。 レシピのスキーマをrecipe.ymlに書いて、各APIから定義を使い回すことにする。 # api.yml /recipes: GET: response: array
Autodoc - r7kamura blog
闇Advent Calendar 1日目の記事として、最近の開発における心の闇に触れます。 最近開発した Autodoc というツールについて簡単に説明した後、 この手のツールの開発にあたって考えていた、 創作活動の在り方や、社会の斥力、25歳定年説などについて触れようと思います。 Autodocとは Rack applicationで実装されたAPIに対して、RSpecで書かれたテストを元にAPIドキュメントを生成するもの。 テストを実行すると、テスト中に発行したリクエストやレスポンス、そのテストに付けられたメッセージを元に、 良い感じに情報をまとめ、Markdown形式でAPIドキュメントを記したファイルを生成してくれる。 例えばGitHubではMarkdownファイルを適当に描画してくれるので、 下図のようにGitHub上で簡単にドキュメントを閲覧出来るようになる。 テストの書き方
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
mmd.js