はてなブックマーク

単一ホスト用のリバースプロキシを実装する net/http/httputilで、HTTP用のReverse Proxyを実装するためのライブラリが提供されている。 下記のコードで、http://127.0.0.1:3000 から http://127.0.0.1:9292 にHTTPリクエストを委譲するReverse Proxyが動作する。 httputil.NewSingleHostReverseProxyはhttputil.ReverseProxyのインスタンスを返す。 このインスタンスはhttp.Server互換の (.ServeHTTPメソッドに呼応できる) オブジェクトであるため、 http.Serverを利用してHTTPサーバを動作させられる。 // main.go package main import( "net/http" "net/http/httputil" "net

Schemanという、Ruby製のSQLパーサをつくった。 例 文章で説明するより見たほうが早いだろうということで、例を用意した。 require "scheman" require "yaml" parser = Scheman::Parsers::Mysql.new schema = parser.parse(<<SQL) CREATE TABLE `users` ( `id` INTEGER(11) NOT NULL PRIMARY KEY AUTO INCREMENT, `name` VARCHAR(255) NOT NULL ); SQL puts schema.to_hash.to_yaml 構文解析結果はHash, Array, Symbol, Stringの組合せで表現される (※可読性のためにYAML形式で表示した) --- - :create_table: :name:

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

OAuth 2.0 への理解を深めるため、自分がOAuthをどう捉えているかを整理します。 多分に誤解が含まれている可能性があるので悪しからず。 OAuth 2.0 OAuth 2.0を利用してリソースサーバ(=Web API)と通信を行う場合、 以下の処理が行われます。 ユーザは認証情報を認証サーバに渡してアクセストークンを発行してもらう ユーザはリソースサーバと通信する際にアクセストークンを一緒に渡す リソースサーバは受け取ったアクセストークンからユーザを識別する リソースサーバは識別結果をもとに適切な処理を行いレスポンスを返す 認証情報 認証情報には幾つかのパターンがあり、以下の情報が含まれます。 アプリケーションを識別するための情報 ユーザを識別するための情報 認証方法などを表すメタ情報 認証サーバとリソースサーバ 認証サーバは、アプリケーションを登録したり、アクセストークンを発

データベースの暗号化界隈の話を調べたのでQ&A形式でまとめた。 なぜ暗号化を行うのか？ 一般的には、以下の様な情報の漏洩を防ぐため。 個人が識別できる情報 個人の行動履歴 財務情報 知的財産 財産 その他開示されていない情報 最近日本で大きな情報漏洩被害にあった企業例は？ Sony (PlayStation Network) Yahoo! Japan LINE 2ch @PAGES データベースの暗号化におけるベストプラクティスは？ StackOverflow等の意見を集めた限り、この辺を全部やるというのがベストプラクティスという雰囲気。 通信データの暗号化: SSL 格納データの暗号化: FDE + TDE (後述) 格納データの暗号化機能を提供しているサービスの例は？ Amazon RDS for Oracle Amazon RDS for SQL Server Amazon S3 G

gitreceive という、git push時に任意の処理を実行する為のツールがある。 Dokku の中で同様の仕組みが使われており、 git push時にbuildpacksでアプリをbuildしDockerコンテナの中で動かす、 という機能を実現している。 認証機能 gitreceiveはSSH公開鍵登録用インターフェース、 及び公開鍵を利用した簡易的な認証機能を持っているが、 公開鍵を登録したユーザからのPushのみを許可するというもので、 Pushするアプリケーションごとに別々の権限を与えるということは出来ない。 forced command gitreceiveはSSHのforced commandと呼ばれる機能を利用している。 forced commandを使うと「SSH接続時に何をするか」という情報を、 クライアント側ではなくサーバ側で指定出来る。 OpenSSHでは、au

API(とそれに携わる開発者)の規模が拡大してくると、ドキュメントの整備や、仕様と実装の一貫性の維持、 クライアントとの知識の共有など、考慮すべき問題が沢山出てくる。 これらの問題に対する現実的な解決策を探るため、 ApiaryというAPI開発支援用のサービスを簡単に俯瞰することにした。 ここでは紹介しないが、他に RAML、 JSON Schema、 Swagger、 WADL、 Autodoc などが関連するものとして挙げられる。 Apiary http://apiary.io/ Apiaryは、API Blueprintと呼ばれる言語でAPIのインターフェース仕様書を記述する、という開発方法を提唱している。 API BlueprintはMarkdownを拡張した言語で、特殊な記述を用いて幾つかのメタ情報を付与出来る形になっている。 Markdownを採用することで人間にとって読み書き

The Netflix Tech Blog: Embracing the Differences : Inside the Netflix API Redesign Netflixの開発者ブログで触れられているように、Netflixは以下の4つの方針に沿って彼らのAPIを再構築した。 デバイスごとの差異を受け入れる コンテンツの収集と整形を分ける クライアントとサーバの境界線を再定義する 変化を促進する デバイスごとの差異を受け入れる REST APIのように1つの汎用的なインターフェースで全ての要件を満たそうというアプローチは、 APIへの理解が簡単になる一方、後から変更することは難しくなり、また非効率な処理を生み出しやすくなる。 この手のアプローチが重視しているのは、API提供者側の開発コストを下げることであり、 API利用者の利便性を第一に考えたものではないと彼らは考える。 API

Asciinemaの使い方、使われ方、使い勝手について。 使い方 Asciinemaという、端末上の操作を録画するツールとそのホスティングサービスがある。 「Record and share your terminal sessions, the right way」とのこと。 ざっくり言うとTerminal版Gifzoみたいなもので、こういう感じで利用できる。 # install sudo easy_install pip sudo pip install asciinema # usage - 新しいsessionが立ち上がり、exitするまで記録される asciinema rec 使われ方 例えば、AsciinemaはDockerのTutorialで使われている(またDockerか)。 Dockerは自分にとって新しい概念を導入するものだったので、 入力と出力の様子を見ながら外側から

Rack::Multiplexerという、複数のRackを束ねるものをつくった。 Plack寄せ この前Perl界隈の人達と鍋を囲む機会があって、 !!1;の話、livedoor BlogのPlack化の話、ISUCONの話、 各社古いアプリ抱えていて辛いね苦しいね頑張ろうね若者に1日で書き換えさせようといった話をして、 結局、何となくこの界隈は全体的に「Plack寄せ」が進んでいるねという話に落ち着いた。 Rack寄せ 一方Ruby界隈だと比較的皆Rackに寄っている傾向にはあると思うけど、 もっと寄せてみると面白いんじゃないかと思って、Rack::Multiplexerをつくった。既にありそう。 Rack::Multiplexerは、所謂WebアプリのRouter(=Dispatcher)の処理を行うための実装で、 メソッドやパスの規則に従って受け取ったリクエストを別のRack app

[Sitespec](https://github.com/r7kamura/sitespec)という静的サイト生成ツールを作り、このブログを移行した。 ## Sitespec Sitespecは、Webアプリとテストから静的サイトを生成するためのツール。 WebアプリにはRackを、テストにはRSpecを使う。 Rackを使った適当なWebアプリを用意し、 RSpecでHTTPリクエストを発行するように記述したテストを実行すると、 レスポンスの内容から静的ファイルが生成されるという仕組みになっている。 参考までに紹介しておくと、静的サイト生成ツールには他に [Middleman](http://middlemanapp.com/)や[Octopress](http://octopress.org/)、[Movable Type](http://www.movabletype.jp/) な

「おれはブログをGitHubに置いていたと思ったらPull Requestをもらっていた」 おれは今オープンソースのブログをほんのちょっぴりだが体験した。 いや、体験したというよりはまったく理解を超えていたのだが。 何を言っているか分からないと思うが、おれも何をされたのか分からなかった。 ホスティングサイトだとか、バージョン管理だとかだとか、そんなチャチなもんじゃ断じてない、 もっと恐ろしいものの片鱗を味わった。 人最高 自分のプロダクトに対してPull Requestを生まれて初めてもらったのは、確か去年の夏のことだった。 当時すごく嬉しかったことは今でも覚えていて、 それは「黒い画面のログをブラウザに流せるようにして、しかも工夫次第で音とか流せるようにしました、ゲラゲラ」 みたいなプロジェクトで、それをわざわざ拙い英語を見てインストールしてくれて、 しかも僕のミスで何か不具合があって動