カテゴリー別アーカイブ: 日記

IIJmio/D SMSでGALAXY NEXUS SC-04Dのセルスタンバイ問題が解決

10月7日から提供が開始されたIIJmio高速モバイル/DサービスのSMS機能により、GALAXY NEXUS SC-04Dのセルスタンバイ問題が解決しました。

これまで、GALAXY NEXUS SC-04DにIIJmio高速モバイル/DのSIMカードを使用していましたが、アンテナピクトが表示されず、deodexedなカスタムROMやその後はroot化不要の方法等でパッチによる対策をしていました。今回SMS機能付きに変えたところ、標準ROMの状態でアンテナピクトが表示されるようになりました。

Screenshot_2013-10-12-22-30-14.png

その結果、セルスタンバイの電池消費量を抑えられています。

Screenshot_2013-10-12-22-11-09.png

ROMは、テザリングを使用したいため、docomo純正ではなくGoogleが提供しているFactory Imageのyakjuを使用しています。これまでは4.2.2を使っており、今回SIMカードの変更と合わせて4.3を焼き直したのですが、APNが自動で設定されました。

Screenshot_2013-10-12-22-30-40.png

キャリアに依るものかROMの設定に含まれていたのかはよく分かりませんが、ROMを焼いただけの初期状態にSIMカードを挿すだけで、SMS送受信とデータ通信が可能です。また、最近のFactory Imageには中華フォントだけでなく日本語フォントが含まれているようで、docomo純正ROMから抜いたフォントをコピーする必要は無く、Google playからGoogle日本語入力等のIMEアプリをインストールすれば、日本語環境も問題ありません。初期の頃から比べると格段に便利になってきています。

壊れたインターホンの応急処置

インターホンが夜中に突然「ピンポーン」「ピンポーン」と繰り返し鳴る…玄関を見ても誰もいない…怖っ

どうやら玄関子機が壊れてしまったようです。
仕方ないので、インターホン親機との結線を外して対処していたのですが、やっぱりインターホンが無いと不便です。
試しに2本の結線を直結してみたら「ピンポーン」と鳴りました。映像や音声の信号も流れるのに意外と単純ですね。鳴らないよりはマシなので、応急処置でスイッチを付けてみました。親機まで壊れてしまうかもしれませんが、買い換えるまでは持ってくれるかな。

IMG_20130521_233921.jpg

赤いスイッチを押すと、インターホン親機が鳴ります。このレトロな感じがなかなかおもしろい。夜中に取り付けて、妻と2人で笑ってました。

使った部品は、電気屋さんで買ってきた一番安いスイッチと、既存配線を傷つけないためのみの虫クリップ、計149円。あと、昔100円均一で買ったものの使っていなかったミニプラグ延長ケーブル。

IMG_20130521_220922.jpg

これらをはんだでつなげてグルーガンで固めただけ…

導通もOKで、玄関子機の結線を外してみの虫クリップに繋ぎ、完了。ひさしぶりの工作でした。

IMG_20130521_225020.jpg

さて、次のインターホンはPanasonicにしようか、インターホンぐらい「アイホン」にしようか。。

GALAXY NEXUS SC-04Dの電池消費量の比較

データ通信のみのMVNOのSIMカードをAndroidスマートフォンで使用した場合に、セルスタンバイが電池を大量に消費するという事象があり、程度は機種に依るようです。

手元にあるGALAXY NEXUS SC-04DとIIJmio高速モバイル/DのSIMカードを使って、電池消費量を確認しています。

電池消費量の平均値

IIJmio  (昼間): 9.95%/12時間
IIJmio  (夜間): 5.57%/12時間
音声のみ(夜間): 4.68%/12時間
SIM無し       : 2.94%/12時間

続きを読む GALAXY NEXUS SC-04Dの電池消費量の比較

.mailfilterでケータイへの転送メールを一部制限(さくらのレンタルサーバを使用)

NTTドコモの「メール使いホーダイ」を契約したので、メールだけはパケット代を気にせずケータイで送受信できるようになりました。PCで使っているメールもケータイに転送設定しておくと便利♪ではありますが、メールアドレスをWebにさらしているために迷惑メールがハンパない訳で、これが全部ケータイに転送されるととっても困ります。
そこでちょっと工夫が必要になりました。

メールサーバ内でSpamAssassinが動いてくれているので、これを使ってケータイへの転送を振り分けてみます。SpamAssassinが迷惑メールの程度をX-Spam-Levelで示してくれる(「*」が多いほど迷惑メールである可能性が高い)ので、まずその程度を決めてみました。
PCのThunderbirdで受け取っているこれまでのメールを「メッセージの検索」で検索してみます。カスタムヘッダで「X-Spam-Level」を追加して「**」で検索すると、迷惑メールではないメールがちらほらとヒット。「***」で検索してみると迷惑メールのみになったので、X-Spam-Levelが3未満のメールをケータイに転送する事にしました。

.mailfilterに以下を設定。

if ( ! ( /^X-Spam-Level: *{3,}/ ) )
{
        cc "!ケータイのメールアドレス"
}

これでめでたく迷惑メールでないメールだけがケータイに転送されるようになりました。

の、 はずだったのですが、それでも次々に転送されてくる迷惑メール。どのメールも、件名に「=?koi8-r?B?~」とケータイでデコードされない MIME。koi8-rってどこ?(ロシア、でした。)このメールだけはX-Spam-Levelが3以上にならないので、仕方なく個別に転送を拒否します。

if ( ! ( /^X-Spam-Level: *{3,}/ || /^Subject: =?koi8-r?B?/ ) )
{
        cc "!ケータイのメールアドレス"
}

ひとまずこれに落ち着きました。

しばらく経って、少し変更。
ケータイ側のメールサーバの仕様をいまいち把握していなくて、もし何らかの理由でケータイ側のメールサーバに転送メールの受け取りを拒否されると、エラーメールが送信元に行ってしまうなぁ、と。
メールの転送ではよく聞く事例ですが、このエラーメールには転送先のメールアドレスとそれに配送できなかった理由が記載されるので、つまりメールの送信者に転送先の(ケータイの)メールアドレスを知られてしまいます。それが迷惑メール送信者だったらもうサイテーです。

なので、メールを転送する時にenvelope sender、いわゆる送信元(Envelope-FromやSenderとも)を変更する事にしました。

if ( ! ( /^X-Spam-Level: *{3,}/ || /^Subject: =?koi8-r?B?/ ) )
{
        cc "| /usr/sbin/sendmail -i -f 送信元メールアドレス ケータイのメールアドレス"
}

直接ケータイのメールアドレスを指定して転送させるのではなく、メールをsendmailに渡してケータイに送信させます。その際にsendmailの-fオプションで送信元のメールアドレス、つまりエラーメールの送信先とするメールアドレスを指定します。
メールの本文に先頭が.(ドット)の行があってもそのまま転送できるよう-iも指定しています。間違っても-tは付けないように!

これで、配送エラーが発生した場合のエラーメールは、元の送信者に送信される事なく、指定した送信元メールアドレス宛に届くようになりました。(指定するケータイのメールアドレスを存在しないメールアドレスに変えて試してみると確認できます。)メールのループが発生しないよう、送信元メールアドレスには転送設定をしない別のメールアドレスを指定しましょう。

メールをトリガーに任意のPerlスクリプトを実行する(さくらのレンタルサーバを使用)

ケータイのパケット定額サービスの料金は数千円とまだまだ高く契約を躊躇してしまいます。でも外出中にネットにつなげられるとやっぱり便利ですよね。
そんな中、NTTドコモの「メール使いホーダイ」を発見。メールだけならお安いのね。例えば件名「web」本文にWebアドレスを入力してメール送信したらページ内容がメールで送られてくる、とか、件名「google」本文に検索したい文字列なら検索結果、とか、「whois」とか、「nslookup」とか、何とかかんとか、いろいろできそうやん!と、セコい考えを思い立ってしまったわけです。

ひとまず、メールを受信してPerlスクリプトを実行するところまでをざーっと作ってみました。

スクリプトファイルをサーバに置く

末尾のスクリプトをサーバに置いてください。これ以降、以下の条件で記載するので適宜読みかえてくださいね。

アカウント名                : ACCOUNT
スクリプトファイルを置く場所: /home/ACCOUNT/www/bin/
スクリプトのファイル名      : run.pl
メールアドレス              : run

安全のため、http経由では実行できないよう、スクリプトファイルを置く場所には以下のよう設定しましょう。.htaccessでアクセス制限しておくとより安心です。

% chmod 700 /home/ACCOUNT/www/bin

run.plには実行フラグを付与します。

% chmod +x /home/ACCOUNT/www/bin/run.pl

run()の中に任意の処理を書く

run.pl先頭部のrunサブルーチンの中に、実行したい処理を書いてください。第1引数にメールの件名、第2引数にメールの本文が渡されます。
メールの文字コードに依らず、いずれもUTF-8に変換され、UTF8フラグも付きます。

メールアドレスを作成する

サーバコントロールパネルでrunというメールアドレスを作成してください。

.mailfilterを作成する

作成したメールアドレスに.mailfilterを設定します。

% vi /home/ACCOUNT/MailBox/run/.mailfilter

以下の内容を記述してください。

if ( (1) )
{
        to "| /home/ACCOUNT/www/bin/run.pl"
}

if文で囲んだのは、サーバコントロールパネルからメールの設定変更をしても内容が上書きされないようにするためです。それをしないのであれば、toの行だけでも良いと思います。

あと、ファイルモードを600にしないといけません。

% chmod 600 /home/ACCOUNT/MailBox/run/.mailfilter

※この.mailfilterの設定が重要なのですが、公式な機能では無いと思いますので、行う場合は自己責任の下でお願いします。設定方法は「さくらのレンタルサーバ非公式FAQ」を参考にしました。感謝です!

※でも、カスタマーセンターから.mailfiterに関する回答の引用があったり、あと実際に公式のFAQにも.mailfilterの記載があったり、と実は公式な機能なのかもしれません。

完了!

これで、run宛にメールを送信したらrun.plが実行されます。

スクリプト

#!/usr/bin/perl

use strict;
use warnings;

sub run {
    my ($subject, $body) = @_;

    # ここに任意の処理を書いてください。メールを受信する度に実行されます

    # $subject と $body はいずれも UTF-8 で、UTF8フラグも付いています

}

#
# メールを解析して Subject と body を取り出し、run() に渡す
#

# 標準エラー出力は /dev/null 行き
BEGIN { open STDERR, '>', '/dev/null' }

# カレントディレクトリを run.pl と同じディレクトリに移動する
use FindBin qw( $Bin );
BEGIN { chdir $Bin }

require Encode;
require MIME::Parser;

my $parser = MIME::Parser->new;

# 用途上、メールのサイズはそんなに大きくならないので、オンメモリで処理する
$parser->output_to_core(1);

my $entity = $parser->parse(*STDIN);

#
# まず Subject
#

# Subject を取り出して、UTF-8 にする
my $encoded_subject = $entity->head->get('Subject');
my $subject = eval { Encode::decode('MIME-Header', $encoded_subject) };

if ( $@ ) {
    # MIME-Header の decode に失敗したら、仕方ないのでそのまま
    $subject = $encoded_subject;
}

# 余分な空白文字が含まれる事があるので除去
$subject =~ s/A s+ | s+ z//gxms;

#
# 次に body
#

# multipart の場合は最初のパートのみを対象にする
my $first_part = $entity->is_multipart ? $entity->parts(0) : $entity;

# body を取り出して、UTF-8 にする
my $charset = $first_part->head->mime_attr('Content-Type.charset');
my $encoded_body = $first_part->bodyhandle->as_string;
my $body = eval { Encode::decode($charset, $encoded_body) };

if ( $@ ) {
    # Subject と同様、失敗したらそのまま
    $body = $encoded_body;
}

#
# 処理を実行
#

run($subject, $body);

exit;

ASCIIコード表

    0x    1x  2x 3x 4x 5x 6x 7x
 x0 NULL  DLE SP 0  @  P  `  p
 x1 SOL   DC1 !  1  A  Q  a  q
 x2 STX   DC2 "  2  B  R  b  r
 x3 ETX   DC3 #  3  C  S  c  s
 x4 EOT   DC4 $  4  D  T  d  t
 x5 ENQ   NAC %  5  E  U  e  u
 x6 ACK   SYN &  6  F  V  f  v
 x7 BEL   ETB '  7  G  W  g  w
 x8 BS    CAN (  8  H  X  h  x
 x9 HT    EM  )  9  I  Y  i  y
 xA LF/NL SUB *  :  J  Z  j  z
 xB VT    ESC +  ;  K  [  k  {
 xC FF    FS  ,  <  L    l  |
 xD CR    GS  -  =  M  ]  m  }
 xE SO    RS  .  >  N  ^  n  ~
 xF SI    US  /  ?  O  _  o  DEL

プログラム開発での「再利用」はすでに破たんした考え方

Ajax、それはWeb2.0へと続く道 - @IT

プログラム開発での「再利用」という考え方は特にオブジェクト指向プログラミングの世界で強調されてきたものですが、これはすでに破たんした考え方だと私は見なしています。なぜかといえば、未知の未来のプログラムで再利用可能となるようにクラス等を開発する手間は極めて大きくなるのに対して、それだけの手間を掛けたものを再利用しようとしても、うまく使えない事例が多いからです。つまり、手間に比して得るものが少な過ぎるのです。ちなみに再利用(=未知の未来に備えること)を戒める標語がYAGNI (You Aren’t Going to Need Itの略。「それは必要にならない」)だろうと思います。

これはOpen Source JapanのArax採用に関するプレスリリースへのコメント。

Open Source Japan – Ajaxの弱点を克服した開発手法Araxを採用したWebシステム向けリッチクライアント開発技術「ダイナミック・コックピット」を発表

Web システムのリッチクライアント技術として、 現在 Ajax(Asynchronous JavaScript and XML)が注目を集めているが、 これは膨大な開発工数を要し、 また Web ブラウザへの依存度が高く、再利用が難しいなどの問題がある。