Salesforce.com Certified Administrator Winter'13 Release Exam (リリース試験)
Spring'13リリース試験受けてね、とメールが来ました（それも結構前だけど・・・）
つい先日、放置してたWinter'13のリリース試験受けました。
15問中11問以上正解で合格。制限時間30分。
Winter'13のリリースノートを見ながら（検索かけまくりながら）・・・
半分くらい記憶に無いなぁと不安ながら、制限時間いっぱい使って回答。
なんとか（？）合格しました・・・。点数でないのでよくわかりませんが。
Developerもあるので、Winterをあと1本、
Springも2本受けないといけない。
これはなかなか体力を消耗するな・・・
Herokuのrake db:migrateで already exists
マイグレーションファイルを追加したので、Herokuにmigrateする必要が出ました。
開発中なので、たまには一回全消しして改めてmigrateしてみようと思いました。
heroku run rake db:drop
heroku run rake db:migrate
これでいけるつもりでしたが、
PG::Error: ERROR: relation "xxxxxxx(Table名)" already exists
となりました。
これで解決しました。
heroku run rake db:reset
heroku run rake db:migrate
dropとresetの違いが良くわかってないので確認。
つまりあれか。createしないといけないのか。
RubyMineではしてないな。どっかで勝手にcreateが走ってるのかな・・・。
Rakeタスクの確認にはこちらを参考にさせてもらいました。
HerokuでRMagick
処理に応じて任意の２つの画像を合成したくて、RMagickを使ってみました。
ローカルではGemfileに
gem 'rmagick', '~> バージョン'
と書くだけでしたが、HerokuにPushすると、これだと動きません。
エラーとしては、以下のエラーがでました。
2013-03-01T17:18:54+00:00 app[web.1]: Completed 500 Internal Server Error in 1ms 2013-03-01T17:18:54+00:00 app[web.1]: 2013-03-01T17:18:54+00:00 app[web.1]: app/controllers/XXXXX.rb:47:in `xxxxxxxx' 2013-03-01T17:18:54+00:00 app[web.1]: 2013-03-01T17:18:54+00:00 app[web.1]: NameError (uninitialized constant XXXXXController::Magick):
以下２カ所で記述の追加が必要でした。
gem 'rmagick', '~> バージョン', :require => 'RMagick'
※ requireのRMagickは、RMとキャピタライズを意識にしないと動かないようなので注意！
Controllerなど、RMagickを必要とするソースで、
require 'RMagick'
これでうまくいきましたー
Amazon S3にjquery_file_uploadでファイルをアップしたら動かなくなったよ
jQuery_file_uploadを利用して画像ファイルをS3にアップする仕組みを作ってみました。
一旦アプリケーション配下にアップロードする方式で実装。一通り要件通り動作することを確認。
Herokuを使って動かす想定。Herokuはアプリ内のpublicとかにファイルを保存できないことから、S3を利用するように書き換えを開始・・・。
このあたりの設定とかは色々なサイトで説明が書かれていますね。ここのサイトを参考にさせてもらいました。アップロードと、uploadTemplateでのサムネイル表示あたりまでは順調に書き換えできました。
downloadTemplateが全然うごかない・・・
Amazon S3にpaperclipでファイルをアップロードしたあとの戻りの値がローカルに保存した場合とは異なっているようです。また、サーバからjsonで返してくるレスポンスもとれていないようでした。
done:を自分で作成することにします。
※最終的なdoneのコードは記事の末尾にのせてます。
こんな感じにして、jqXHRからレスポンスをTextで取得。
JSON形式に変換して、renderTemplateしてあげる。
var res = data.jqXHR.responseText; var jsonData = $.parseJSON(res); template = fu._renderDownload(jsonData) .appendTo($('#fileupload .files'));
これでdownloadTemplate問題が解決しました。
続いて、アップロードが終わったあとにuploadTemplateが消えない問題が発生。
どうも、レスポンスのdata.contextに、uploadTemplateが格納されているようです。
なので、こんな感じにしてみました。
$(data.context).remove();
jquery_file_uploadのソースの中にはこんな記述は無いため、もっと良い書き方がありそうですが・・・
$.Deferred()を利用して制御しているように見えましたが、うまく再利用できませんでした。
ということで、最終的にはこうなりました。（他の部分は割愛）
<script type="text/javascript" charset="utf-8"> $(function () { // Initialize the jQuery File Upload widget: $('#fileupload').fileupload({ done: function(e, data) { // Load existing files: var fu = $(this).data('blueimp-fileupload') || $(this).data('fileupload'), template; var res = data.jqXHR.responseText; var jsonData = $.parseJSON(res); // Render DownloadTemplate template = fu._renderDownload(jsonData) .appendTo($('#fileupload .files')); // Force reflow: fu._forceReflow(template); // downloadTemplate Fade-in template.addClass('in'); // remove upload $(data.context).remove(); // remove loading $('#loading').remove(); } }); }); </script>
解決するのに５時間くらいかかった・・・
アウトバウンドメッセージ通知
アウトバウンド再び。
ここにあるそうです。
あなたの名前 | [設定] | [監視] | [アウトバウンドメッセージ通知]
この機能では、
・「２４時間、送信を失敗し続けたアウトバウンドメッセージがあるよ」というリストことを、最大５人のSalesforceユーザに通知できる。（２４時間に１回、リストが通知される）
・２４時間エラーのメッセージを、最大７日間[失敗したアウトバウンドメッセージ] 関連リストに保持できる。
・[失敗したアウトバウンドメッセージ] 関連リストに保持されてる間は、削除と再試行が要求できる。
再試行すると、もっかい送信キューに入るのかな？？
そしたらまた、２４時間＋７日間残るのかな？？
ちょっとヘルプからはわかんないな。
ていうか、２４時間経つまで連絡来ないのか・・・リアルタイムに見たいと思うと、監視は目視な感じかなぁ。
なお、
このオプションが表示されない場合は、組織がアウトバウンドメッセージを有効にしていません。アウトバウンドメッセージを有効にするには、salesforce.com に連絡してください。
だそうです。オープンオンラインヘルプより。
アウトバウンドメッセージ仕様：２回以上送られることがある・・・順序不定・・・キューイング後も更新可・・・２４時間失敗すると消滅する
なにこの仕様。こわい。
• エンドポイントが利用できない場合、メッセージは正常に送信されるまで、または 24 時間が経過するまでキューに留まります。24 時間を過ぎると、メッセージがキューから削除されます。
• メッセージが配信できない場合には、再試行の間隔が、最長 2 時間まで大幅に増えます。
• メッセージは、キュー内の順番とは無関係に再試行されます。そのため、メッセージが順番に配信されない場合があります。
• アウトバウンドメッセージを使用して監査履歴を作成することはできません。どのメッセージも 1 回は配信される必要がありますが、2 回以上配信される場合もあります。また、24 時間以内に配信できない場合には、まったく配信されないこともあります。さらに、上述のとおり、通知がキューされた後でも送信される前であれば、ソースオブジェクトの変更が可能です。エンドポイントは、途中の変更内容ではなく、最新のデータのみを受信します。
• メッセージが複数回送信される場合があるため、リスナークライアントでは、処理を実行する前に、通知内で配信された通知 ID を確認する必要があります。
参照：SOAP API開発者ドキュメント P.1351（Summer '13）
