2014年5月アーカイブ
どうも。
献身的という言葉がありますね。
ハシモトです。
本日のはまったポイントのお時間です。
<%= form_for @inquiry, url: { action: :confirm } do | f | %>
....(略)....
<% end %>
こんなformを用意したわけですね。でviewのspecを書いたワケですよ。
require 'spec_helper'
describe "Inquiries/index" do
before(:each) do
assign(:inquiry, stub_model(Inquiry).as_new_record)
end
it "should be rendered" do
render
end
endNo route matches {:action=>"confirm", :controller=>"Inquiries"}
動かない....
ブラウザでは動いてるんです。言い訳ではなく。
んでdebugger様と二時間ほど格闘ですよ。
で分かったのは以下
actionpack-4.0.4/lib/action_view/routing_url_for.rb
91 def url_options #:nodoc:
92 return super unless controller.respond_to?(:url_options)
93 controller.url_options
94 end
ここが、ブラウザからだと
{:host=>"localhost", :port=>3000, :protocol=>"http://", :_recall=>{:action=>"index", :controller=>"inquiries"}, :script_name=>""}
こうね。
でrspecからだと
{:host=>"localhost", :port=>3000, :protocol=>"http://", :_recall=>{:action=>"index", :controller=>"Inquiries"}, :script_name=>""}
controllerのキーが違う！
そもそもview specからどうやってcontrollerを判断してるんだ？って思ったら、ここですよ
describe "Inquiries/index" do
まさか、ですよね。
rails g で自動生成させると頭文字大文字っすよ？！
こんなんで良いの？
describe "inquiries/index" do
とりあえずこれでテストは通った。
寝る。
ではでは。
どうも。
awsに手こずり続けています。ハシモトです。
本日遭遇した問題はこちら。掲題の通り。
何やらファイルがアップロード出来ないとユーザーからの連絡。
またnginxの何かなのかと思いログを確認すると
pwrite() "/var/lib/nginx/tmp/client_body/0000000013" failed (28: No space left on device)....."
ｵｳﾌ
ディスクが足らんぜよ。
いや、待て。
足らんは足らんのだがAPサーバーにファイルを貯めるような設計にはしていない。
なぜ。
....
何がディスクを食っているのか
# sudo du -mh -d 1
4.0K ./mnt
2.4G ./tmp
32M ./boot
12M ./sbin
0 ./misc
1.3G ./usr
379M ./home
55M ./srv
6.0M ./root
4.0K ./vol
20K ./dev
0 ./sys
343M ./var
8.2M ./bin
4.0K ./local
16K ./lost+found
66M ./lib
55M ./media
7.5M ./etc
8.0K ./.pki
0 ./net
4.0K ./selinux
22M ./lib64
114M ./opt
と。
2.4G ./tmp
一時ファイルのようだ。
# ll
合計 2502188
-rw------- 1 deploy nginx 589325066 5月 24 08:44 RackMultipart20140524-20893-1mdoxlx
-rw------- 1 deploy nginx 19649 5月 24 08:09 RackMultipart20140524-20893-1xywkk7
-rw------- 1 deploy nginx 19649 5月 24 11:40 RackMultipart20140524-20893-53o1ni
-rw------- 1 deploy nginx 656523099 5月 24 07:55 RackMultipart20140524-20893-mbwi24
-rw------- 1 deploy nginx 19649 5月 24 11:39 RackMultipart20140524-20893-ryw5u6
-rw------- 1 deploy nginx 3227648 5月 24 09:05 RackMultipart20140524-20896-1stmxwg
-rw------- 1 deploy nginx 656524024 5月 24 08:14 RackMultipart20140524-20896-ch0zd5
-rw------- 1 deploy nginx 656525063 5月 24 08:33 RackMultipart20140524-20896-fh4grr
-rw------- 1 deploy nginx 19649 5月 24 08:10 RackMultipart20140524-20902-a87c8o
RackMultipart....
アプリの問題か....
んでゴニョゴニョとgoogle先生にお伺いを立てると、どうやらGCやrubyの処理系の再起動時にtempfileは消えるらしいが、そんなの待ってられるビジネス要件ではない(600Mとかのファイルがバンバン上がる)ため方法を探る。
どうやらFile.unlinkでリンクを切ってしまえば良いらしい。
ということで
File.unlink(tmp_path) if File.exists?(tmp_path)
てな感じで事無きを得た。
最近疲れてばかりだ。
ではでは。
どうも。
awsのruby-sdkからhtmlを上げたら、html内部に書かれたtwitter cardが反応しないどころか、twitter card validatorにinternal errorとか言われて阿鼻叫喚なハシモトです。お疲れ様です。
internal errorとか言われてしまうとawsの設定かなんなのかわからなくてstack over flowを彷徨い続けるデスマーチにハマり込んでいたわけですが、s3のコンソールと数時間にらめっこをした結果、アップロードしたhtmlファイルのcontent-typeがimage/jpegとかなってて驚愕したわけですね。
AWS SDK for RubyでアップロードしたS3オブジェクトからContent-Typeヘッダが取れない
Qiitaにこんなポストがあって救われたわけですよ。ruby-sdkからやるとどうやらcontent-typeがnullな状態らしく、content-typeがnullなhtmlをtwitter cardは認識出来なかったという結果でした。
objectのwrite時に
:content_type => "text/html"
な引数を渡してあげて解決。
いやぁ、疲れた。
ではでは。
