Sinatra で拡張子ごとにMIME-Type (と対応するContent-Type) を設定する

*.bin　拡張子のファイルを"audio/mpeg"としてサーバからヘッダを返さないとiOSで動画が再生されないという仕様のサービスがあり、Sinatraとthinで動かしているシステムの調整が必要になりました。

結論としては

configure do
  mime_type :bin, 'audio/mpeg'
end

と書けば解決しました。書式は

mime_type :<extension name>, '<mime type name>'

のようです。

Middlewareを間に挟んで調整するかthinもしくは.ruファイルを編集する必要があるかと考えたのですが、現在Sinatraはモジュールタイプで動かしていないので面倒です。しかし、とても簡単にSinatra上でメソッドが提供されていました。SinatraはMiddlewareとしても利用できるという話ですが、さすが httpヘッダ を調整するのは簡単にできるようです。

メソッドチェーンをRSpecでテストする

RSpecでメソッドチェーンをテストするのにどうやったものか手間取りました。

例えば

obj.do1.do2.do3

とあったときには

一気に

obj.stub(:do1.do2.do3)

とstubできないので、

res1 = stub()
res2 = stub()
obj.stub(:do1).and_return(res1)
res1.sbub(:do2).and_return(res2)

とそれぞれstubを作る必要がある様です。

メソッドチェーンはRuby（とRSpec）では推奨されないやり方なのでしょうか…

複数言語が入り交じったの家庭の大人は頭が良い？

以前複数言語が入り交じったの家庭のこどもは常に脳がトレーニング状態にあるため、一般に頭が良いという記事をどこかで読みました。

これは複数言語が入り交じったの家庭に生きる大人にも当てはまるのでしょうか？私はこの大人が”諦めなければ”という条件付きで可能な説だと思います。


がんばれ大人です。

モデルとコントローラーのバランス

Skinny controller, fat modelというようにコントローラはできるだけ小さくするのがMVCの良いプラクティスなようです。

コントローラは「何を」するのか知っているが、「どうやって」それをするのか知らない状態が一つの目安。

BDDのコアコンセプトは？

BDDのメソッドは何となく面白いので使ってみたいと思うのですが、その基本となるコンセプトは何か私なりにまとめてみました。

 

上のメモのように、つまりユーザー(もしくはオブジェクトなど)のリクエストというbehaviourが発生した時にソフトウェア(API、オブジェクトなど何でも) がどのようなレスポンスを返すかということに集中して開発をするということだと理解しました。

 

データベースのリレーションや、ソフトウェアのロジックは後回しにして、これをするとこういう動きが返ってくるべきだという地点から全てを開始するということですね。

 

Ruby " と ' の違い

特に　"（ダブルクオート）　と ' （シングルクオート）の違いを意識せずに使用してきたのですが、本当は " と ' はどう違うのか？と今更調べたのですが、さっと出てきた結果では ' で囲った文字列の特殊文字は解析されないということです。例えば

name = "Sam"

として、

puts "Hi #{name}!"

では

Hi Sam!

と出力されるのに対して、

puts 'Hi #{name}!'

では

Hi #{name}!

と出力されます。

もしくは

puts "a \n b \n c"

では改行が入り、

puts 'a \n b \n c'

だと

a \n b \n c

と表示されます。

ユーザに表示させる文字列には " を使い、そうでないのは ' を基本的に使う方が便利かな？？？というところですね。

失敗しないと半人前？

以前にインド人両親を持った香港育ちの知り合いが、香港ではビジネスに失敗したことが無い人は半人前に見做されるという話をしていました。この人たちはタフだなと思いました。

先日DNS移行の失敗でクライエント側でメールを２営業日使用できなくなるという失敗をしました。メールに対する影響のことが念頭に無く、ドメインを管理するDNS自体を移行してしまったことが原因です。メールが届かなくなったという報せを受けて調査をし、DNSの問題だということに気がつき慌てて元のDNSサーバにドメインの管理を戻してホスティングサーバのAレコードだけを書き換えて移行は完了しました。

クライエントの方には迷惑をかけましたが、コミュニケーションの問題があったことなど今回の問題の主因ではない問題も浮き彫りになりました。サイト運営の方針を転換する機会でもあると感じます。

仕事をしている身として、ミスをすることはロスをもたらすことになるので本来は起きない様にするのが第一です。しかし、ミスをしてそれを解決したことによる経験とコミュニケーションの改善というのは同時にとても貴重であることを感じました。

全てゼロに戻っても立ち直るさという割り切り、諦め、自信などが混沌とした様子です。