壊れたNAS内のファイルを救出する
家でBuffaloのNAS「LS-H1.0TGL」を利用してバックアップしていたのですが、壊れてしまいました。
・何度か起動し直すと電源がちゃんと入る場合がある。
・起動したときに、ファームウェアを入れ直すと正常に動作することがある。
・正常に動作すれば、ファイルにはアクセスできる（ファイルは壊れていない）。
という状態だったので、おそらく実際に壊れたのは、HDDではなく、NASの仕組みを動かしている部分のようでした。（基盤まわりの何か？）
うかつにも１ファイルだけ、NASにしか無いファイルがあり・・・これをなんとか救済したいなぁと思いました。HDDが壊れていないのであれば、OSからファイルシステムさえ認識できれば、ファイルを救済できるはず。と考えました。
まず、BuffaloのNAS「LS-H1.0TGL」のファイルシステムが何かを調べてみました。
「LS-H1.0TGL ＋ ファイルシステム」でグーグル先生に聞いてみた。
色々な話がひっかかりました。結構みんな救済したいと考えていたようでw上のYahoo!知恵袋が詳しかったので、リンク紹介させていただいてますが、
BuffaloのNAS「LS-H1.0TGL」のファイルシステムはLinuxのもので、ReiserFSのようです。
ReiserFSはLinuxのファイルシステムでは主流のものではないので、対応していないLinuxディストリビューションもあり・・・という話はありますが、Linux機を立てたり、VMからディスクマウントしたりするのはめんどくさいので、この場合ReiserFSに対応しているKnoppixのCDブートが楽でしょう。
ということで、Knoppixをダウンロードし、
CD-Rに焼きます。Knoppixは700MB程あるので、CD-Rの容量の大きい物を用意してください。確か何種類かあるはず・・・
LS-H1.0TGLから取り出したHDDをSATAでデスクトップPCに接続し、CDブートでKnoppixを起動します。
ここが詳しいです。
Knoppixを起動すると勝手にHDDがマウントされるので、そこから別HDDにインストールされているWindows機のファイルシステムにコピーし、データを救済できました。
まとめ
救済対象
・BuffaloのNAS「LS-H1.0TGL」
・ファイルシステム：ReiserFS
救済に必要なもの
・Knoppix（ダウンロードする）
・CD-R（Knoppixが焼ける容量をもつもの）
・SATA接続ができる環境（デスクトップPCとか）
・救済時の退避先（１ファイルとかならメールで送ればいいけど、数GBとかなら何か考えましょう）
※故障時の「LS-H1.0TGL」HDDの状態によっては、データが消えたりすることもあるようです。自己責任でお願いします。
Ajaxでリクエストが２回呼ばれる！？ −＞ jQueryのせいでした。
単一画面で作成していた機能を、タブ表示に統合していたとき、リクエストが２回よばれるページがあることに気づいた。
ダイアログ：「削除してもよろしいですか？」
おれ：「はい」
ダイアログ：「削除してもよろしいですか？」
おれ：「はい・・・」
的な感じ。
どうもおかしいので、ぐぐってみると、
RailsでAjaxリクエストが2回行ってしまうときにチェックすべき3つの事
というようなことがあるらしい。
これの、【jQueryを２回読み込んでないか？】
というのに該当していた。
別画面構成の時の既存のlayoutをまとめた画面分、複数呼んでいたので、その都度jQueryを呼ぶつくりのままになっていた。
計３回も呼んでいた・・・w
ということで、これを取り除いて解決した！
簡単に解決してよかった。
:remote => true のAjaxが動かない
layoutsのapplication.html.erbを使わないようにしてから、時々
:remote => true
でAjaxするコードが「Missing Templete」で動かなくなることがあり、原因がよくわかりませんでした。
<%= form_tag({:controller => 'CONTROLLER NAME', :action => 'ACTION NAME'}, :remote => true) do %>
で
ACTION NAME.js.erb
の中で
$('#書き換えたいとこのID名').html("<%= j(render(:partial => '/部分テンプレート名')) %>");
とかやるやつの話です。
解決したっぽいので、メモ！
結論としては、「jquery_ujs.js」を読み込んでいないことが原因でした。
この仕組みはjQueryで動いているらしく、
そもそもRailsでjQueryを使うためには、「jquery_ujs.js」が必要らしいです。知らなかったわ。（初心者です）
参考：http://takuyan.hatenablog.com
なので、<%= javascript_include_tag "JSファイル名" %>
で読み込んだjsファイルの中で、
してあげて、解決しました。
よかったーーー。
続：8GBにするつもりが、4GBに・・・ → からの〜3GB・・・
以前、8GBにするつもりが、4GBに・・・ - Mercyのφ(．． )メモメモ で書いたエントリですが、最終的に3GBで落ち着きました・・・1,000円くらい無駄になった。
動作不良の原因は、マザーボードのバス速度が1067MHzのところ、1333MHzで動作していることでした。。。
下位互換に期待して1333MHzのメモリを購入しましたが、どうも「バス速度には下位互換しない」、「同時に設置されている他のメモリに下位互換する」ということだったらしい。
そうだったっけ・・・と思いつつも、もともと刺さってた1GBのメモリ（PC-8500 1067MHz）のメモリと、今回購入した2GBのメモリ１枚を刺して、安定動作中です。
無駄になったけど、とりあえず今使ってる範囲では快適だから、
１、２年後を目処に買い替えるかーという方針でこのままいこうと思います。余った１枚は予備だな・・・永遠に日の目を見ない気もするが。。。
ということで、こうなった。
後から刺す方が右側のようです（笑）
価格帯参考に下記をどうぞ。
※購入の際にはバス速度、メモリ量を確実にご確認ください（私のようにならないように）
Salesforceのデータはグリニッジ標準時（GMT）で管理される！
言われてみればそうだね、という話ですが、気づかないと大変なことになるので書いておきます。（大変なことになった、という話は聞いた事がある・・・）
詳細な情報は、ヘルプから検索できる、下記ナレッジ記事に書いてあります。アカウントを取得して、ログインして確認してください。ここでは概要だけ。
AppExchange データローダで日付データをインポートすると１日前の日付が登録される
ナレッジ記事番号: 000047804
Saleforceのデータベースでは、日付型、日付時間型項目のデータは内部的に全てGMT（グリニッジ標準時）に変換され格納される仕様になっている。
なので、日本国内で普通に利用しているデータベースのデータを何も考えずにインポートすると、９時間早い時間になることになる。同様に、落としてきたデータは９時間遅い。ズレが生じる。
この制御はデータ形式のタイムゾーン設定により行われるため、タイムゾーンを正しく設定した形式でデータ連携を行えば、問題は生じないようだ。
以下は例外らしい。（ナレッジより引用）
なお日付時間型項目に関しては、GMT変換後の値が時・分単位を含め格納されており、画面から参照される場合には再度ユーザ毎のタイムゾーン設定を考慮して時差変換されますため、日付がマイナスされて見えるという現象が起きません。
以下は対応例の引用
＜「2011/09/01」をSalesforceに登録する方法＞
・１日足した日付をインポートする: "2011-09-02"
・９時間足した日時をインポートする： "2011-09-01T09:00:00"
・GMT指定でインポートする： "2011-09-01T00:00:00.000Z" (※「Z」はGMTをあらわします)
・データローダのタイムゾーンを（GMT）グリニッジ標準時に設定してインポートする (下記の手順を参照下さい)＜データローダのタイムゾーン変更手順＞
１）データローダのツールバーからSettingsを開く
２）Time Zone に"GMT" を入力する。（日本標準時にするためには"GMT+9:00"あるいは"Asia/Tokyo"と入力する）
３）OKボタンをクリックして設定を保存する。
※詳細はナレッジを見た方が良いかと思います。
8GBにするつもりが、4GBに・・・
動作が不安定のため、後日レポートを書きました。
後日レポートはこちら → 続：8GBにするつもりが、4GBに・・・ → からの〜3GB・・・ - Mercyのφ(．． )メモメモ
ホントは8GBにするつもりで買ったんですが、平日ふつーに仕事したあとの朝４時くらいで眠かったせいか、4GB（2GB×2枚）のものを買ってしまった・・・
パッケージに4GBって書いてあって、２枚メモリが入っていたら、4GB×2枚だと思わないか？（思わないか・・・
ともかく、結果的には、2GBだったメモリが4GBになり、なぜか1067MHzのバス速度が1333MHzで動作しているのもあり、めっちゃ快適になりました。これで１、２年凌いで、新しいの買えばいいか。
ということで、せっかくなので動作確認報告と、簡単な交換方法などを記録しときます。
Mac Book Pro
Mac Book Pro 5, 5 (13 inch, Mid 2009)
Core 2 Duo 2.26GHz
2次キャッシュ 3MB
DDR3 1067MHz
※左上のリンゴマークの、「このMacについて」で確認。
購入メモリ
Silicon Power（シリコンパワー）メモリモジュール 204Pin SO-DIMM DDR3-1333（PC3-10600） 2GB×2枚組 SP004GBSTU133V22
Macのバス速度は1067MHzですが、下位互換するだろうからいいか、と思って買いました。1333の方が全然安いので。
まず、100均とかに売ってそうなものでいいので、＋ドライバーを使って裏側のフタを開けます。外したネジの位置はわかるようにしておきましょう。
写真の真ん中にある、緑のものがメモリです。
メモリの両端にある黒いクリップを、同時に外側に軽く引くと、メモリが持ち上がって外れるので、引き抜きます。重なって設置してあるので１枚しか見えませんが、外すと２枚見えます。
２枚とも外し、新しいメモリに差し替えます。差し替えるときは、30-45°くらいの斜めにして差し込みます。でっぱり（ノッチ）の位置に気をつけて差し込んでください。
クリップにうまくはまって押さえられていることを確認してください。うまくいくと、カチッと音がします。（しないこともあるけど。）
２枚目も取り付け、裏フタを閉めたらMacを起動してみましょー。
私の場合は１回でうまく起動せず、メモリの上下を入れ替えて再起動したらきちんと動作しました。
ちゃんとささってなかっただけかと思いますが。
ちなみに、Macのメモリ交換方法は、Appleの公式サポートページに丁寧に書いてあるので、それを確認しながらやるとよいでしょう。
最終的にはこうなりました。なぜか1333MHzで動作しているように見える。
ちなみに、同型のMac Book Pro で、4GB×２枚の動作実績は多数あるようです。Google先生に聞けば「あるよ」とばかりにブログ等、たくさん見つかります。この製品がよく紹介されてます。
なお、8GB×２枚での動作実績は見当たりませんでした。（海外サイトで、１件だけ、動いた的なことを書いている掲示板投稿は見かけた。製品は不明。）
