APIデザインケーススタディ —— Rubyライブラリを移植する前に読む本 - 世界線航跡蔵
『 APIデザインケーススタディ 』という本を頂戴したので読んでみた。 ライブラリ作者に向けて この本はRuby標準ライブラリを題材にして、分かりやすく、多様な機能をサポートして、互換性を保つAPIの設計をするにはどのように考えるべきかを教えてくれる。 ここでAPIと言っているのは、一般的なRubyのクラスとオブジェクトとメソッドから成るライブラリをどうデザインするか、という話である。 別にChef RecipeやRSpec DSLのようなちょっと変わったDSLを設計するとかそういう話ではない。確かにその種の言語内DSLのデザインには固有のセンスが必要とされるし、 Ruby DSL Handbook なんて本が書かれているように実装にあたってもある種のテクニックが必要なのも確かだ。でも、それ以外の「ふつう」のライブラリのデザインは果たして簡単だろうか。 適切な粒度のクラスを定義する。必要な
Automation Accountパターン - 世界線航跡蔵
コンテキスト あなたが開発しているサービスはユーザー向けにAPIを提供している。そして、APIを利用するにはユーザーは短寿命の認可情報(たとえばOAuth2トークン)を提示しなければならない。 ユーザーは認可情報が紐付いているアカウントの権限でリソースを読み取ったり、作成したり、所有したり、編集または削除したりする。 ここで、ユーザーは人間(が操作するユーザーエージェント)であることもあるが、人間の手を離れてバックグラウンドで自動実行されるプログラムかもしれない。 また、あなたは悪用目的でアカウントが大量登録されるのを防ぐためにCaptchaを利用したいと思っている。 さらに、課金目的で請求書送付先を登録させたいとも思っているかもしれない。 問題 プログラムが利用するアカウントを安全に管理するのがユーザーにとって困難である。 プログラムは自分でCaptchaを解いたりEメールを受け取るのが
Dockerで何が変わるのか - 世界線航跡蔵
DockerCon 2014 に行ってきた。 この会期中には各社からいくつもの製品が紹介/発表された。そして、それによってクラウドという技術は次のステージに移行したと言っても過言ではないだろう。 より自由にユーザーがクラウドベンダーを選べる時代へ。どうやってクラウドにうまくデプロイするかではなく、アプリケーションそのものに注力できる時代へ。 Dockerとは Docker とはいわゆるコンテナ技術の1つで、Linuxホスト環境の中に隔離された別のLinux環境を作ってくれる技術だ。 軽量仮想マシンと呼ばれたりもする。 Solaris Container とも似ている。 新しくないDocker 1つ述べておくとDockerは技術的には新しくない。Dockerの価値は技術以外にある(とDockerのCEOもDockerConで言ってた)。 技術的にはSolarisにはSolaris 10の頃か
Rails SQLServerでクエリがシンタックスエラーな件
$KCODE = 'u'でrailsを動かすとSQLServerへのクエリがエラーを起こすんだが。 前にメーリングリストでも見かけたことがあったような。で、$KCODE = 's'で我慢しるってことだったような。 ちょっと試してみた。 どうも、ADODBをラップしてるWin32OLEのRuby StringとBSTRの変換が問題なような感触。 require 'dbi' require 'iconv' $KCODE = 's' value = 'てすと' sql = "INSERT INTO hoge(val) VALUES('#{value}')" usql = "INSERT INTO hoge(val) VALUES('#{Iconv.conv('UTF-8', 'CP932', value)}')" DBI.connect(connect_string).execute(sql)
Ruby1.9 のクラスのメタ階層とかevil-rubyとか - 世界線航跡蔵
sumimさんの「 Ruby1.9のクラスのメタ階層を整理する 」という記事、Rubyの型階層は雑然としているというのは、なんかsumimさんの図が悪いような気もするなぁ。整理すればもうちょっと情報を引き出せるよ。あと、モジュールのせいもある。 前提知識 Rubyは基本的には単一継承のクラスベースオブジェクト指向言語なのだけれども、幾つか注意すべき処がある。 クラスはClassクラスのインスタンスである。 モジュール 制限付きの実装多重継承をもたらす仕組み。内部的には、モジュールの「化身」となるクラスを継承階層を挟み込むことで実装されている。 以下、モジュール M に対してその化身クラスを I(M) と表記する。 詳しくは 以前の記事 を参照。 特異クラス 特定のオブジェクトに専属するクラスのこと。特定のオブジェクトにだけ存在するメソッド「特異メソッド」を定義すると、内部的には特異クラスを
passengerとmod_autoindex - 世界線航跡蔵
Passenger を使っていて、ディレクトリのautoindexが効かなくて困った。 Passengerもいくらか枯れてきている感じなので先日試したところ、確かに管理が楽なので最近気に入っている。ちょっと前まではRailsアプリケーションのデプロイと言えばmongrel+mod_proxy_blancerだったのだけれども、最近はpassengerの人気が上がっている。 passenger人気の理由はいくつかある。 Rack という汎用の仕組みをサポートしていること。だから、passengerがあればrailsだけでなくmerbもsinatraも動く。 デプロイが楽なこと。SSHでサーバーに入ってアプリケーションサーバーを再起動、とかやらなくて良い。まーこれはcapistranoやvladでデプロイしている私にはあまり関係ないけど、PHPアプリケーションやJava EE warの「ディレ
ターミナルまるごとコード変換 - 世界線航跡蔵
先日の東京・関東Rubyist忘年会の席で、「UTF-8で日本語を記述したRspecをwindowsで動かすと文字化けして困る」という話があった。 で、「それcocotでできるよ」と言おうとしたのだけど暫く使ってなかったのでとっさに"cocot"の名前が出てこなかった。 cocot は「端末(tty)とプロセスの間に割り込んで、文字コード変換を行うツール」。だから、cocotの下でシェルを動かしてしまえばあとは意識せずにコード変換してくれる。 シェル丸ごとだと今度は標準コマンドの出力が化けるかも知れないけど、だったらalias spec="cocot -p UTF-8 spec"とかすればいい。
Rails勉強会@東京 第2回 (1) - 世界線航跡蔵
前回 に続いて、12/28、 Rails勉強会@東京第2回 に行ってきた。今回も秋葉原某所にて開催。 集合 駅前広場を見渡すと、shachiさんが最初に来ていたみたい。御挨拶して、2人して目印の AWDwR を取り出すと、すぐにもう御一方やってきた。目印を見るまでshachiさんが分からなかったみたい。 そんな感じでしばらくすると半分ぐらいは集まってきて、でもそれ以上は人が増えない。中央線で事故があった影響だろうか。 前回と同じく、このなんだか妙な集団を見て、何の集まりだろうと寄ってきてはAWDwRを見て不可解といった様子で去っていく人が数人。「（寄ってきた人が）もっと面白いパフォーマンスしてくれればネタにしようもあるのにね」って誰かが言っていたけれど、そりゃ酷だ。 会場 とりあえず前半セッションの準備っていうことで、数人残って遅れている人を待ち、残りは会場に移ることになった。 今回も オ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
