WWW::Salesforceを使ってAPIでsandboxにアクセスする時にはまったのでメモ。

ログイン時に


$port = WWW::Salesforce->login(
'username' => 'YourUserName',
'password' => 'YourPassword',
'clientID' => 'YourCilent'
'serverurl' => 'https://test.salesforce.com/services/Soap/c/10.0'
);
みたいに渡してやればOKです。

キモは


'serverurl' => 'https://test.salesforce.com/services/Soap/c/10.0'
のところ。

WWW::Salesforceのソース(Ver.0.11)を見ると、デフォルトで


$SF_PROXY = 'https://www.salesforce.com/services/Soap/u/8.0';
と設定されていてこれが本番用のserverurlになります。
普通にログインする分にはserverurlの指定はいりません。

しかし、sandboxにアクセスしたい時はserverurlも渡してやる必要があります。

ちなみにurl末尾の数字はSoapのバージョンなので、
本番にアクセスするけど違うバージョンを使いたいというときにも有効。
バージョンによってサポート期間が違うと思うので、サポート期間が過ぎたらここを指定するだけで他のコードはいじらなくて済みます。

UQ WiMAXを解約しました。
モニター期間の4ヶ月間割といい仕事をしてくれたと思います。

もともとe-mobileがあるので使い続ける気は全くなかったですが、
不可解な圏外以外は概ねe-mobileより上なのかもしれません。

電波の性質の都合上、例え屋外が見えているような場所でも圏外になったりしていましたが、
かと思いきや窓から遠い密閉空間のようなところでも通じたりと、
どこで使えるのかいまいちわからないのが問題ですね。

とはいえ、スピード面ではe-mobileよりも優秀な場所が多かったので、
うまいこと抱き合わせ販売すれば意外といい線いけるのかもしれませんね。
屋内でストレスなく使える場所限定ですが。

まだまだWiFi対応の場所が少ないので、
普及しきる前に潰れないといいのですが。

はまったところなのでメモしておきます。
ハッシュの配列の特定の要素を削りたい、けれど配列の要素の順序は一定とは限らないし追加もあるかもしれない。
なんて時にgrepが有効です。

ハッシュの配列があって、


my @hoge = [
{
id => 1,
name => 'hogehoge'
},
{
id => 2,
name => 'mogemoge'
},
{
id => 3,
name => 'hogemoge'
}
];

idが2以外のものがほしいときは以下のように処理します。
@hoge = grep ( $_->{id} != '2', hoge);

これをprintすると、中身は


[
{
id => 1,
name => 'hogehoge'
},
{
id => 3,
name => 'hogemoge'
}
]
となるはずです。

用事で赤羽駅まで来たので測定してみました。

駅のすぐ横のマックの外の席です。

6.663Mbps

最高記録更新ですね。

やはり屋外だと使いやすいというのは自明です。

でもやっぱり建物の中で使えてこそ無線の意味があるので、
ぶつぶつ切れる状況は改善してほしいです。

最近サボり気味だったので報告をしましょう。

牛田駅横のマックにて。

2.037Mbps

まぁまぁ使えますね。
特にストレスもなく。

自宅のサーバーとの通信はこのくらい出てるとかなり快適です。
ブラウジングもいい感じ。
外でこのくらい使えればいいんじゃないでしょうか。

それでもE-MOBILEと比べると遅いし安定感がないのはまだしょうがないでしょうか。
建物の中でも快適に使えるようになればいいんでしょうけど。
ちょっと外と中の差がありすぎて微妙です。

4.4Mbps!!!

今までで最高の数字が出ました。
さすが開けた外の公園ですね。

ここの公園は広場とグラウンドがあって、
さらにテニスコートもあります。
区営なので駐車場もタダだし、テニスコート脇の更衣室は温水シャワー付です。
フットサルの練習にキャッチボールとフリスビーまでいろいろできて、
お弁当持ってピクニックにももってこい、さらにWiMAXも入るとなれば至れり尽くせりですね。

書いててちょっとはまりました。

まず<table>タグ内でDBから引いてきた項目を復元して表示させていたときに困ったこと。
最近のブラウザは単語の切れ目を自動的に判断して、
幅が足りなくなりそうだったら自動的に改行してくれるようになっているんですが、
単語の切れ目として認識されないものがあります。

http://hogehoge.hoge

みたいなURLや、

hogehoge@hoge.moge

みたいなメールアドレス。
さらに、

aaaaaaaaaaa

みたいな単語になっていないもの。

この辺は自動的に改行されてくれません。
なので、こういうもので長い文字列のものが<table>内にあると、
CSSできれいに表示されるように設定していても、
激しくレイアウトが崩れてえらい事になります。

そこで調べていたところ、
IEについては、

<table style="word-break:break-all;">

みたいにタグに直接指定するか、CSSに指定してやれば回避できることが判明。
しかし、Firefoxはこれでは無理なので、他に方法を探すことに。
いくつか方法があったんですが、
データ量も少ないし、復元直前にデータを加工すればいいということで、
<wbr>タグを使うことにしました。
本来は<nobr>タグの中で使うものだけど、単独でもいけるということで単独で。
Javascriptでもよかったんだけど、日本語の文字列もあったりするので、
サーバサイドで加工することにしました。

んで、はまったこと二つ目。
初心者なので日本語の引っ掛け方がよくわからない。
正規表現で1文字ごとに<wbr>タグを追加することにしたんですが、
日本語はマルチバイトなので普通にやったら引っかからない。
UTF8でコーディングしているのですが、
そのままではマルチバイトを一文字と認識してくれないらしいです。

というわけで取った解決策は、UTF8フラグを立てること。
SJISとかEUC-JPからUTF8にしてマルチバイトでマッチングさせる方法は結構見つけたんですが、
元々UTF8だとどうやったらいいか載っているところが見つからなかったです・・・
というわけで、基本に立ち返ってCPANでモジュール探し。
Jcodeでもよかったんですが、動かしている環境では簡単にモジュールを追加できないので、
標準モジュールであるEncodeを使うことにしました。

やり方はかなり簡単。
Encodeをuseして、UTF8フラグを立てて、マッチングして<wbr>タグをつけて、UTF8フラグを取る。
めんどくさいですが・・・

特定の箇所しか使わないので、メソッドを作ってそれを呼び出す形にしました。


sub wbr_tag_add {
my ($str) = @_;
eval "use Encode";
decode("utf8", $$str);
$$str =~ s/(.)/$1<wbr>/g;
encode("utf8", $$str);
}

リファレンスで渡すことにしたのでこれでOK。
グローバルで使うなら頭で

use Encode;

してもいいんですが、ここでしか使ってないのでevalですませました。

う〜ん、全体通してもっとスマートにやりたいけど、これが今の限界です。


上野恩賜公園で花見の場所取りしながらこれ書いてました。
上野恩賜公園でのWiMAXの状況は、

1.046Mbps

なかなか良好です。
外だということを考えればよくないのかもしれないけど。

先週行った会社の近くのPRONTもEXCELSIORも圏外で状況を更新できませんでした。
ユーザー会的なものが開催されるらしいので、行ってみようかどうか思案中。
仕事の状況次第ですがね・・・