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の呼出を介してコマンド
Slugbuilder - r7km/s
ここで言っている実行可能な形式とは、Heroku上で slug と呼ばれているもので、ソースコード・依存ライブラリ・実行環境をtar形式にまとめてGzip圧縮したものである。 使われ方 flynnでは、コンテナで実行させたいアプリがgit pushされたときにslugbuilderが実行され、 アプリ用のslugが生成され、shelfと呼ばれるファイルサーバ経由で配布され、sluglunnerで実行される。 discoverd & flynn-host を使ってコンテナを動かすホスト群のクラスタが形成される gitreceived を使ってGitサーバが git-push(1) を待ち受ける gitreceived が git-push(1) に呼応してflynn-receiveを実行する flynn-receive が slugbuilder を利用してslugを作成する slugrun
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された
Atom Contribution Guideline - r7kamura per second
Atomの開発者向けガイドライン で紹介されている、汎用的に適用出来そうな項目をまとめた。 Pull Request 出来るだけスクショやアニメGIFを貼ろう 期待する挙動を書こう 似た機能をどこかで見たことがあれば紹介しよう 言語ごとのガイドラインに従おう コードにドキュメントを書こう 良い文章を伴った構造化されたテストを書こう ファイルの末尾には改行を入れよう プラットフォーム依存のコードは避けよう Commit Message 現在時制で書こう 命令形で書こう 1行目は72文字以内に収めよう 関連するIssueやPull Requestに参照を貼ろう 形式的なものには絵文字を使おう (整形、速度改善、ドキュメント更新など)
OAuth Sign - r7kamura per second
OAuth 2.0 への理解を深めるため、自分がOAuthをどう捉えているかを整理します。 多分に誤解が含まれている可能性があるので悪しからず。 OAuth 2.0 OAuth 2.0を利用してリソースサーバ(=Web API)と通信を行う場合、 以下の処理が行われます。 ユーザは認証情報を認証サーバに渡してアクセストークンを発行してもらう ユーザはリソースサーバと通信する際にアクセストークンを一緒に渡す リソースサーバは受け取ったアクセストークンからユーザを識別する リソースサーバは識別結果をもとに適切な処理を行いレスポンスを返す 認証情報 認証情報には幾つかのパターンがあり、以下の情報が含まれます。 アプリケーションを識別するための情報 ユーザを識別するための情報 認証方法などを表すメタ情報 認証サーバとリソースサーバ 認証サーバは、アプリケーションを登録したり、アクセストークンを発
faraday-lazyable - r7kamura blog
faraday-lazyableという、 HTTPリクエストを遅延評価させるためのライブラリを作った。 遅延評価はある種の複雑性を持ち込むが、ビジネスの要求に合わせて正しく使っていきたい。 遅延評価 HTTPリクエストにおける遅延評価とは何か。 遅延評価というのは、評価しなければならない値が存在するとき、 実際の計算を値が必要になるまで行わないことをいう。 HTTPリクエストを遅延評価するというのは、つまりHTTPクライアントはすぐにレスポンスオブジェクトを返すが、 レスポンスオブジェクトに対してメソッドが呼ばれたときに初めてHTTP通信を発生させるということを意味している。 Faraday Faradayとは何か。 faraday-lazyableは、FaradayというRuby製のHTTPクライアントのプラグインとして実現されている。 FaradayはRackのようにプラグイン(=この
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
