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
Scheman - r7km/s
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:
GHQ - r7km/s
ghqというレポジトリ管理ツールを使ってみた。 Installation Goがインストールされていてかつ環境変数$GOPATHが設定されている環境で、go getを使ってインストールできた。 手元の環境を調べてみると、Goのversionは1.2.1、環境変数$GOPATHは$HOME/.goに設定されていた。 $ go get github.com/motemen/ghq $ go version go version go1.2.1 darwin/amd64 $ echo $GOPATH /Users/r7kamura/.go $ cat /Users/r7kamura/.zshrc.local | grep GO export GOPATH=$HOME/.go export PATH=$PATH:$GOPATH/bin $ which ghq /Users/r7kamura/.go
Gitreceived - r7km/s
git pushに対応することに特化したSSHサーバ Gitreceived を読んだところ、幾つかの知見が得られた。 git-shell Git付属のシェル git-shell がGitreceivedで利用されている。 git-shellはGitに関する作業しかできない制限付きのシェルである。 GitreceivedはSSH経由で入力された任意のコマンドを外部コマンドとして実行しようとするが、 このとき外部コマンドはgit-shellを利用して実行される。 つまり、任意のコマンドと言えどGitに関する作業しか実行できないように制限されている。 git push クライアントでgit push origin masterが実行されたとしよう。 このときGitは、サーバへのSSH接続を開始する send-pack プロセスを実行する。 サーバ側では、以下のようなSSHの呼出を介してコマンド
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上で簡単にドキュメントを閲覧出来るようになる。 テストの書き方
Rack::Multiplexer - r7kamura blog
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 - r7kamura blog
[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/) な
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
