SIMフリーなiPhone4Sを個人輸入してはや2年。海外では大活躍してますし、国内ではIIJmioのSIMとガラケーの2台持ちで月々計¥2,200円台で運用できており、すでに元は取っていると思いますが、2013/12/17付でドコモメールでPCのブラウザからもキャリアメールにアクセス可能に！今までもiモード.netでもできていたようですが運用が面倒なようでした。

ブラウザから@docomo.ne.jpできるということは、つまりSIMフリー端末でも可能ということですね。まあすでにキャリアメールなんてっていう時代ですが、昔から使用していたりするアドレスですと仕事関係などやはりマルチデバイスで運用したいですよね。できればweb(ブラウザ)でもiPhoneのメールクライアントでも！
ってことで、いろいろ調べてみました。
まず現在の所有端末の状態は以下の通り

1. ｓｐモード（ｉモード契約可）の契約追加
   ドコモメールにするにはspモード契約が必要ということで、Mydocomoから「ｓｐモード（ｉモード契約可）」を追加しました。
   確認事項でISPセット割(iモードは契約済のため)が適用される旨が記載されており、料金はspモードを追加しても\315円のまま据え置きでした。

2. docomo IDの登録
   次にドコモメールはdocomo IDを取得する必要があるので、docomo IDを登録。IDはiモードのメールアドレスにしました。

3. ブラウザからログイン
   早速ブラウザからドコモメールのサイトの「ドコモメール（ブラウザ版）」をクリックしログインしますが、「spモードメールをご利用中のため、ドコモメールをご利用いただけません。(1301_lwprap26)」という以下のエラーダイアログが出てログインできませんでした。Mydocomoからiモードとspモードのアドレスを入れ替えたりもしましたがNGでした。
   
   

ググりますと、どうもspモードメールを取得できる環境なければならないようです。すなわちドコモのスマホでかつドコモキャリア回線でspモードメールからドコモメールに移行してあげる必要があるようです。ということはガラケー所有者のiモードメールではドコモメールは使えないということになります。私にはこの環境がないのでNGでした。IIJmio回線でFireFoxのUserAgent(UA)をiPhoneに偽装しDメニューに入り、「プロファイル設定」 > 「iPhone初期設定」(spmodeprofile.mobileconfig)ボタンまでは表示できたのですが、クリックするとドコモ回線ではないと怒られエラー。

後でわかったことですが、ドコモメールが必須なわけではなく、今秋に始まった「spモードメールがキャリア以外からでも可能になった」ことが重要で、これが実現できれば別にブラウザでなくともiPhoneの標準メーラで@docomo.ne.jpが運用できるわけです。（←目指していたところはここ）
ドコモメールはクラウド化して”ブラウザ”からもアクセス可能になったということですかね（IMAPならば必須かも）。

iモードメールでも「iPhone初期設定」(spmodeprofile.mobileconfig)のプロファイルのパスワードを取得できるようにしてほしいですね、ドコモさん。って無理か。
ちなみにiモードのフルブラウザを使って試してもみましたが、Dメニュー＆ログインは可能で「ドコモアプリwi-fi利用設定」は有効にできました。しかしspモードメールにはログインボタンをクリックしても反応しませんでした。どのみち「iPhone初期設定」プロファイルはUAがiPhoneでないと表示されないため、ガラケーでは取得できるはずもなく意味なしです。おかげでフルブラウザの操作だけで12,000パケット(¥2400円)もかかってしまいましたorz。

つまるところ、ガラケーSIMをスマホやタブレットに刺してspモードメールやdメニューにアクセスする必要があるわけです。SIMフリーiPhoneに刺すのが一番手っとり早いかもしれません。繋がるかは不明ですが。あとは手ごろな白ロムなドコモスマホorタブレットを入手するぐらいですかね（この場合iPhoneではないので要UA偽装）。どちらもその間のパケホーダイは必須ですね。またMicroSIM(miniUIM)への変更(¥2,100円)も必要かな。面倒なので様子見にします。

結局「ドコモメール」とは“iモードユーザは切り捨て御免”ってことなんですね。

自宅にサーバを置かなくなり固定IPを止めて久しいですが、SlingboxやNAS、VPNなど海外や出先から自宅ルータ経由の接続は必須なため、ここ数年DDNSでお馴染みのDynDNSのお世話になっていたのですが、2013年5月にSLAを変更し有料化されてしまいました。（お試し期間30日）
DynDNSのよいところは、元々BuffaloのルータにDynDNSのIP自動通知機能があってそれを使用すればルータが勝手にIPを通知してくれるというものでした。常時電源ONのルータで無料でDDNS運用できるという節電(サーバ不要)のメリットもありました。まあDynDNSがよいのではなくBuffalo側が対応していたのが良かった点ですね。
ところが昨年から1ヶ月に1度「あと5日でDNSの有効期限が切れるぞ！」という脅しにも似たメールをDynDNSから頂戴するようになり、その度にDynDNSのHPへ行き手動更新するとなぜか継続できていました。ただ一度忘れて本当に期限切れになったことがあり同一名で再登録した経緯があります。

まあ1ヶ月に1度ならまあよいかと思いますが、長年無料でノーメンテだったサービスが突如改悪になってしまったため、MyDNSへ乗り換えることにしました。MyDNSはjpドメインを無料で運用できる点でなかなかよいですね。

早速MyDNSに登録してみました。DDNSの通知方法をどうしようか、ここが一番のポイントなのですが、MyDNSはBuffaloのルータでは対応していません。
しかし、MyDNSにはいろんな通知方法がありHTTP-BASIC認証やPOP/SMTP/FTPなどもできるようです。HTTP-BASIC認証ならwgetやcurlなどに任せれば自動通知できそうですね。

ってことでrootハックしたLS-VLのcronに以下を仕込んでみました。LS-VLはBuffaloのNASですが、rootハックすればいわば小さな自宅サーバですので一石二鳥です。

• /etc/cron/cron.d/ddns.sh
  /etc/cron/cron.d/配下の適当なShellをddns.shでコピーし、viで中身を以下に書き換えます。

  #!/bin/sh
  #
  # update ddns
  #
  
  # MyDNS
  wget -O - --http-user=yourname --http-password=xxxxxxxx http://www.mydns.jp/login.html
  

• crontab -eにてcronに登録

  12 4 * * * /etc/cron/cron.d/ddns.sh
  

数日経過後、MyDNSのHPにログインしLOG INFOを確認しますと正常に更新されているのが確認できました。ログ日付が1日飛んだり飛んでなかったりしているのは、MyDNSのロギング仕様が過去24時間以内はログ記録しないためです。

2013/10/21 04:12:02 JST  	IPv4 UPDATE : yourname xxx.xxx.xxx.xxx (xxx.xxx.xxx), http, jpn 
2013/10/19 04:12:16 JST  	IPv4 UPDATE : yourname xxx.xxx.xxx.xxx (xxx.xxx.xxx), http, usa 
2013/10/17 04:12:03 JST  	IPv4 UPDATE : yourname xxx.xxx.xxx.xxx (xxx.xxx.xxx), http, jpn 
2013/10/15 04:12:09 JST  	IPv4 UPDATE : yourname xxx.xxx.xxx.xxx (xxx.xxx.xxx), http, usa 
2013/10/14 04:12:07 JST  	IPv4 UPDATE : yourname xxx.xxx.xxx.xxx (xxx.xxx.xxx), http, usa 

後日、DynDNSの更新仕様はどうも1か月に1度Webログインが必要なことがわかりました。これでHPから手動で更新すると継続される謎も解けました。すでにMyDNSのお世話になっているので不要なのですが、それならDynDNSのWebログインもLS-VLのcronに任せてみたらってことで、ddns.shにDynDNSの行を追加。なおBuffaloルータのDynDNSのIP通知機能は有効のままです。これで来月期限切れ通知メールが来なければOKですね！

• /etc/cron/cron.d/ddns.sh

  #!/bin/sh
  #
  # update ddns
  #
  
  # MyDNS
  wget -O - --http-user=yourname --http-password=xxxxxxxx http://www.mydns.jp/login.html
  
  # DynDNS
  wget -O - --no-check-certificate --post-data="username=yourname&password=xxxxxxxx" https://account.dyn.com/
  

2013/11/23追記
昨日Dynから以下のようなメールが届きました。

手動でログインしないとやはりNGなんですかね。UA(User Agent)なども見てるんでしょうか。
取り急ぎ、12/1まで待ってみます。

2013/12/05追記
結局、昨日「expire in 5 days」メールが届きました。やはり、自動ログインスクリプトだけではNGでした。FireFoxのiMacrosで自動ログインを仕込むしかない感じです。UAやログイン時刻なんかも見てるんですかね。MyDNSがあるのでDynDNSは諦めます。

セリーグはあまり感動しなかったですが、今日の楽天優勝は感動しましたね。高校球児だった頃のユニフォームがエンジ、前草野球のユニがこれまたエンジでしたので人ごととは思えない。なおかつレプリカユニも持ってるって、楽天ファンではないですが。。。マー君の最後の投球はオールストレート、流石でした。最後の一球は私の予想はスライダー予想でしたが、渾身の直球。やはりスポーツはメンタルなんですね！おめでとう、東北楽天！
WBCをSFO観戦した身としては準決を田中で行って欲しかった！今更ですが。。。来年はメジャーで投げてるんだろうなー！
三木谷がなんで胴上げなんだとツッコミたくなりますが（どうせなら上着はユニにしろって）、とにかく今日はおめでとう！の一言。
被災地のためにも、今年はぜひ日本一になってほしい！

先日、いつものようにプラグイン更新が通知されていたので、NextGEN Gallery(1.9.10⇒2.0.27)を含めいくつか更新したのですが、その後サイトが遅くなる事象が発生。結論から先に言うとNextGENが犯人だったのですが、当初はなにが悪いのかさっぱりわからず、結局調査するハメに。

■事象

ここ1週間、遅くとも表示に3秒以内で返っていたサイトが急に倍の6秒以上かかるようになった。

■調査

1. まずはレスポンス（応答）で待たされているので、レンタルサーバの負荷ではないかと収容先に問い合わせましたが問題ないと。むしろ「CPU使用時間が長い」と指摘される始末。これには思い当たる節があるので納得。決して「CPU使用率が高い」わけではないです。「CPU使用時間が長い」原因は管理画面でDNS逆引きをしている箇所があり、ここで時間がかかっているんですね。サイトが遅い原因はここではないです。

2. 次にターミナルでログインし、自分のプロセスをtopしながら、サイトにアクセスすると「php-cgi-mysqlx.x」プロセスが数秒かかっているのが目視でわかりました。ということはデータベース。データベースの負荷が高いか、自サイトのSQLに時間がかかっているかになりますね。こうなると普通は自サイトを疑いますよね。

3. ってことでSQLをデバッグすることにしました。お約束？の以下の２つを追加。
   1. wp-config.php

      define ('SAVEQUERIES', true);
      

   2. footer.php

      <?php
      if (current_user_can('administrator')){
          global $wpdb;
          echo "<hr><br><pre>";
          print_r($wpdb->queries);
          echo "</pre>";
      }
      ?>
      

   おー、出ますねー。凄い量。トップの１ページだけで300以上もSQLが発行されてます。ありえんWP。まあSQLを診るとゴミみたいなSQLが山ほど発行されてます。SQLをチマチマ発行するより、一度のSQLである程度レコードをまとめて取得してphp側でゴニョゴニョするほうがほよっぽど速いですから。SQLをオブジェクトと同じ感覚でプログラミングしてるようにしか見えないですね。
   [cc lang=”dos”] Array
   (
   [0] => Array
   (
   [0] => SELECT option_value FROM options WHERE option_name = ‘rewrite_rules’ LIMIT 1
   [1] => 0.0101861953735
   [2] => require(‘wp-blog-header.php’), wp, WP->main, WP->parse_request, WP_Rewrite->wp_rewrite_rules, get_option
   )

   [1] => Array
   (
   [0] => SELECT SQL_CALC_FOUND_ROWS posts.ID FROM posts WHERE 1=1 AND posts.post_type = ‘post’ AND (posts.post_status = ‘publish’ OR posts.post_status = ‘private’) ORDER BY posts.post_date DESC LIMIT 0, 5
   [1] => 0.00300097465515
   [2] => require(‘wp-blog-header.php’), wp, WP->main, WP->query_posts, WP_Query->query, WP_Query->get_posts
   )
   ……………….
   [332] => Array
   ……………….
   [/cc]

   ３回ほどアクセスしSQLデータを収集。このArrayの「[1] => 」のSQL実行時間(duration)をgrepしExcelに張り付け、グラフ化。
   

   すると以下の特定のテーブルのSQLが処理に時間がかかっているのがわかりました。これ、まさしくNextGenのテーブルですよね。
   [cc lang=”dos”] SELECT image_slug FROM ngg_pictures WHERE image_slug = ‘xxxxxxxxx’ AND NOT pid = 0 LIMIT 1
   [/cc]

   ってことで、やっとここでNextGENのプラグインをアップデートしたのを思い出しました。1.9.10⇒2.0.27だったのですが、なんで今頃アップデート通知されたん！？。
   １回目と２、３回目でSQL実行数が違うのはget_option()などのキャッシュが効いたものと思われます。

いやはや、実力通りの結果でしたね。課題が明確になった気がします。人数をかけた時のパスワークは素晴らしいのひとこと、ただ敵陣ペナルティエリアまで行ってなぜかキーパー川島まで戻ってしまう不思議なパスワーク。
本田は「格」と言ってましたが、技術的なことは素人が言っても始まらないので、これだけはやめてほしい。

・ノープレッシャーの無意味（怖がり）な横パス、バックパスは禁止、もしくは罰金。
・ゴール前で「どうぞ、どうぞ！」のフィニィシャーの譲り合い。

前を向いて自信に満ち溢れたボールキープを全員ができるようになったら、、、まあ、１年じゃ無理ですが。

現地観戦されたみなさん、本当にお疲れ様でした。来年は参戦します。