ニコニコ動画(9)になってニコニ・コモンズカテゴリが廃止された

ネットニュースなどでは見かけなかったのだが、ニコニコ大百科を見ると、以前作成していたRSSフィード一覧の中ではニコニ・コモンズとひとこと動画カテゴリが廃止されたようだ。

ニコニコ動画（9）のバージョン移行に伴い、カテゴリタグとしての機能が廃止された。

その他の新設・廃止されたカテゴリタグについても記載があった。

このカテゴリのRSSフィードや、今回新しく出来たカテゴリグループのランキングRSSフィード(従来どおり、URLの後ろに?rss=2.0をつけhttp://www.nicovideo.jp/ranking/fav/daily/g_popular?rss=2.0 のような形になっているようだ)も、NicoBrowser 2009/05/24版で対応できているように見える。

ところで、上記のようなシステム寄りの設計を以って、「汎用性・拡張性が高い」と主張する意見を、業務で何度か聞いたことがある。

しかしながら、個人的にはユーザビリティを無視してシステムの都合だけで決めたようなインタフェースに対して、より価値が高いように聞こえる上記意見は、聞くたびに疑問に思っていた。

何が言いたいかというと、NicoBrowserって使い勝手微妙ですね、ということだけなのだが。

転居時のNTTフレッツ光解約はそんなに面倒ではなかった

転居時に一番大変なのは、ごみの処理についてではないかと考える。

粗大ごみ(大型ごみ)はあらかじめ自治体へ回収の申し込みを行い、コンビニ等で粗大ごみ処理券を購入した上で、指定された日時に指定された場所へ出しておく必要がある(東京都新宿区の例)。

また、自治体によっては、回収点数や回収間隔に制限を設けている場合もある(千葉県市川市の例)。

1回の申し込みで5点まで収集します。申し込みの間隔は7日間以上あけてください。

その他、上記例の中に記述されている通り、テレビ・冷蔵庫など(家電リサイクル法による)やPCなど(資源有効利用促進法による)は、粗大ごみとして扱えないため、別途会衆を依頼するなどの作業が必要である。

可燃ごみ等の通常ごみについても、一度に大量のものを出すことはマンションの取り決めなどで禁じられていることもあり、計画的にごみ出しを行わないといけない場合がある。

民間のリサイクル業者に任せると上記の問題が解消される場合もあるが、いわゆる悪徳業者の判別が必要になるだろう(東京都練馬区)。

チラシなどの宣伝で、「家庭で不要になった家具等の粗大ごみを処分する」などと言って、高額な処理費用を請求したり、無料で引き取るといいながら、処理費用を請求する業者がいますので、ご注意ください。(粗大ごみは、区の収集(申込制・有料)に出すのが正しい処分の方法です。)

引越し業者によってはごみ処理サービスを提供しているところもある(ハート引越センターの例)が、業者を決めてからごみ処理方法を考えるのは、時期的に厳しくなったり、金銭面で有利に働かなかったりするのではないかと思う。

…とここまで書いたが、今回の私の転居では粗大ごみは1つも出さなかった(普通ごみを引越しのかなり前から小分けにして出したくらい)ので、自治体に相談すれば案外簡単に解決する問題である、という可能性もある。ただし、上記のような背景があると知った上で、なるべく早めに行動する必要はあるだろう。

一方で、GIZMODO JAPANの記事にある、NTTフレッツ光の解約はそんなに大変ではなかった。

以前のエントリでは記載し忘れていたが、転居に伴い新聞購読の解約も行った。

電気・水道・ガス会社とは異なり、インターネット接続や新聞は、ある地区で複数のサービス提供会社が並存する、つまり競争が発生する。

また、今までインターネット接続や新聞購読のサービスを受けていた人は、転居後も速やかに同サービスを受けたいと考えるのではないかと思う。

従って、転居の連絡時に、転居先でも同社の契約を続ける提案を行うのは、どちらから見てもメリットになることが多いのではないかと思う。

実際、私の転居の際も、NTTだけでなく新聞の解約時にもサービス継続の勧誘を受けた。私の場合はどちらも断りすんなり済んだが、新規勧誘の煩わしさから、NTTよりも新聞の方がしつこいイメージがある。

モデム返却については、転居先から返送したが、キーボードやブロードバンドルータなどの周辺機器と一緒に箱詰めすることになるので、転居先へ持っていくことについては特に問題だとは感じなかった。

Holux m-241のログを編集するTRLログエディタ1.0a

Wireless GPS Logger M-241

以前も記載したが、Holux M-241のファームウェアバージョン1.13では、ファイルフォーマットが変更になっている。

付属のユーティリティ(HoluxUtility.exe)もバージョンアップしているのだが、1.13対応のファイルコンバータでは、1.12以前のtrlファイルを正常に扱えない。このため、1.12以前で記録したログを扱うためには、ユーティリティも手元に残しておく必要がある。

この問題を解消するため、TrlLogEditor Ver.1.0aでは、trlファイルをオープンする際にバージョンを自動で識別し、どちらのバージョンのファイルも開き、編集できる機能を追加した。

上記機能を含め、主な機能は以下の通りとなる。

• 1.12以前、1.13どちらのファイルフォーマットも意識することなく開くことができる
• 1.12以前、1.13のファイルフォーマットへの保存が指定可能。
  1.12以前で記録したログを1.13フォーマットで保存する場合、速度情報は全て0になる。
• 2ファイル以上に分かれているログの連結。
• 間引き機能。例えば1秒毎に記録しているログを10点につき1点に間引くことで、10秒毎のログを作成することが可能。

現在、保存できるフォーマットはtrlのみであるが、いずれkmlやその他フォーマットにも対応していきたい。

実行環境はJava6以降。例によってWindows XPでしか動作確認していないが、他のOSでも動作すると考える。

ファイルフォーマットを独自で解析している都合上、このプログラムで保存したファイルが正しくない結果になる可能性がある。このため、オリジナルのログファイルは別途保存しておくことを強く推奨する(技術的な説明については次エントリに記載予定)。

TrlLogEditor.jar Ver.1.0aをダウンロードする

Wi-Fiから取得できる位置情報が誤っている

iPod touch(iPhone)、Androidは双方ともSkyhook Wireless社のサービスを利用して無線LANアクセスポイントから位置情報を取得しているらしい。

今回、このサービスがカバーしている地域からカバーしていない地域へ引っ越した。ところが、引越ししたにもかかわらず、自宅の無線LANアクセスポイントに接続すると、昔の住所を指してしまう。

Track My LifeというAndroidアプリを常用しているのだが、上記理由でトラッキングが全く不正確で役に立たなくなってしまった。

MACアドレスと位置情報を同社に送信すれば補正できるのかもしれないが、そのような情報を送っても良いものか。

なお、この技術はWi-Fiポジショニングと呼ばれている技術らしく、他のいくつかの会社も同様のサービスを展開しているようだ(互換性は無いのだろう)。

[離職]リクナビNEXTにプレミアムサービスというものがあるそうだ

昨年の年収をリクナビNEXTへ反映したところ、「プレミアムサービスのご案内」というプライベートオファーが届いた。

曰く、

本サービスは全ての方にご案内しているわけではなく、限られた方のみご利用いただけるサービスとなります。

ということで、年収700万円以上の人が対象のサービスだそうだ。

年収というのはカテゴライズするのに適当な指標なのだろうか。基本給与は所属している会社の給与体系に依存するところも大きく、また、残業代をどれだけつけられるのかは上司やプロジェクトの状況(赤字出しているプロジェクトだとつけづらい、など)に左右されるだろう。

私自身、早朝深夜休日出勤は自分自身の成長のために行っているものとして、正確に測っていたわけではないが、実際の1割も申告していないはずだ。つまり本人の意識に依るところもあるだろう。

つまり何が言いたいかというと、前職の収入で実力を推測されるのは不本意であるなあ、と。

Googleの検索結果によると、冒頭に記載したサービスのトップページはこちら。リクナビNEXTのサイトにあるが、リクルートエージェントのサービスだそうだ。

[離職]職業安定所へ雇用保険の手続きへ行く

雇用保険に関する手続きは職業安定所で行う必要がある。手続きの流れはハローワークインタネットサービスのサイトの他、検索すれば数多く見つかる。今回は、このリンク先にある流れ図のうち、「離職」「受給資格決定」について記載する。

離職

雇用保険被保険者証は、退職日までに、年金手帳と一緒に会社から受け取った。受け取ったのだが、今のところ一度も提出する機会は無いままだ。

雇用保険被保険者離職票-1、雇用保険被保険者離職票-2は、同時に、退社してから約半月後に受け取った。webにある情報を見てみると、もう少し早く届いても良さそうに思う。

上記離職票が手元に届いた後、職業安定所へ手続きを行いに向かうことになる。

受給資格の決定

手続きを行う際に必要になる書類等は上記リンク先にあるが、職業安定所でもらった用紙にはもう少し細かく記載されていたので転記しておく。

受給手続きに必要なもの

1. 雇用保険被保険者離職票-1・離職票-2
2. 雇用保険被保険者証
3. 運転免許証又は住民基本台帳カード(写真付き)
   運転免許を取得されている方は必ず運転免許証をご持参ください。
   運転免許証をお持ちでない方は、
   1.旅券(パスポート)
   2.住民票記載事項証明書(住民票の写し・印鑑証明書)
   3.国民健康保険被保険者証(健康保険被保険者証)
   のうち、いずれか2種類をご持参ください。
   いずれもコピーは不可。
   (住民票記載事項証明書は、雇用保険の受給手続を使用目的として申請した場合に、市町によっては、条例により無料になることがあります。)
4. 印鑑
5. 最近の写真2枚(たて3cm×よこ2.5cm、正面上半身のもの)
6. 本人名義の普通預(貯)金通帳
   離職票-1の金融機関指定届に金融機関の確認印があれば通帳は必要ありません。

上記について補足する。

2.の雇用保険被保険者証については、前述の通り、提示する機会が無かった。

3.については、私は運転免許証を提示した。離職票に記載している住所と同じか確認していたので、退職時に転居も行っている場合には、事前に警察署へ免許証の書き換えへ行っておく必要があるだろう。あるいは、市役所へ転入届を提出する際に、写真付き住基カードを作成しておいても良いかもしれない。市役所本庁で申請すれば即日発行してもらえた。

4.の印鑑についても、私用する機会は無かった。印の代わりに署名で良く、受け付けの人からも署名するよう促されたため、敢えて押印しようとも思わなかった。

5.の写真については、持参するのを忘れていた。次回職業安定所へ向かうことになる雇用保険受給者初回説明会の際に持って来ればよいと言われた。

6.の預金通帳については、在職時使用していたものは引越し荷物に含めてしまっていたため手元に無かった。実家に親が私名義で作成していたものがあったのでそれを用いた。銀行名、支店名、口座番号の記入と確認に利用するので、もしかすると銀行のカードがあれば良いかもしれないが、確かカードには支店名が記載されていないので、どうなるかはわからない。引越しを伴う場合は、通帳は手荷物に含めておくべきだろう。

手続きの話に戻る。失業給付を受け取るための要件のひとつとして、職業安定所へ求職の申込みを行う必要がある。これは、実際に職業安定所で求職活動を行うか否かに関わらず必要だ(後で職安のシステムを利用してみたが、案の定私が希望する職種の登録は皆無だった)。「求職申込書」へ必要事項を記入し、提出することになる。

この際、受け付けの方が記載内容を参照した上で職業分類コードを決定し、確認を求めてくるのだが、これがわかりにくい。コード一覧が記載された電話帳のようなものを見せられ妥当か尋ねられても、指されたコード値が、全コードの中で最も適切なものかどうか即座には判断しようが無い。

私の場合、「希望する仕事」に”情報工学～～”やら”ソフトウェア～～”を記入していたせいかシステムエンジニアのコード値を提示されたのだが、結局、これは誤っていた。その電話帳めいた本を貸してもらって辛うじて探し出したが、少し離れたページにあったので見つけるのに少し時間がかかった。

後で検索してみたところ、このコード体系は労働省編職業分類(ESCO)というものらしく、電話帳はこれ(pdf)だ。わたしのしごと館のwebサイト内にある”ジョブジョブワールド”では、職業分類やその他いくつかのカテゴリで絞り込むことができる。例えばシステムエンジニアであれば061-10になる。

全くの余談になるが、同じようなコード体系として、上記の労働省(厚生労働省)が定めたものの他、総務省が定めたJSCO(国勢調査などで用いられるようだ)、国際標準のISCOといったものがあるらしい(参考pdf)。

求職申し込みを終えた後、受給資格の確認を受ける。働く意思があるかなど(サイトに記載されている条件と同一だ)が書かれた用紙のはい/いいえに○をつけるだけだ。これでOKが出れば口座番号等を記入して終了。

「雇用保険の失業等給付受給資格者のしおり」、「ハローワークカード」を受け取る。また、次回出席する必要がある「雇用保険説明会」の日程などの説明も受ける。

[離職]健康保険

退職後の健康保険の加入方法は「1.健康保険任意継続被保険者になる」「2.家族が加入している健康保険の被扶養者になる」「3.国民健康保険の被保険者になる」3種類あるそうだ(参考：社会保険新報 平成19年2月号)。

	申し込み期限	保険料
健康保険任意継続被保険	20日以内	在職時と同じ(上限あり)
健康保険の被扶養者	なし？	0
国民健康保険	(14日以内)	市区町村により異なる

国民健康保険は、私の市のサイトを見ると年間70,000円弱のようだが、計算があっているのか自身はない。

その他、上表も色々と注釈が必要なのだが、詳しくはリンク先などを参照のこと。

サーバ移転完了

10/5に告知したサーバの移転が完了しました。サンプルコードのダウンロードなどができるようになっています。

[離職]転居手続き(2) 転入先での手続き

転居に関わる転入先での手続きを行ったのは、市役所と警察署になる。

市役所では転入届、国民年金保険、住民基本台帳カードに関わる手続きを行った。国民健康保険に加入する場合も市役所で手続きを行うようだ。

自宅から歩いていける距離に市役所の分所のような、サービスセンターと名づけられた窓口があったため、転入届と国民年金保険の手続きはそこで行った。警察署での手続きの際に住民票が必要になるため、なるべく早く転入手続きを済ませたかったからだ。ただし、システムへの登録は結局本庁の方が行うそうで、即座に住民票は発行できず、1時間程度後になった。通常は数日かかるというような話もしていた。

住民基本台帳カードについては、市役所本庁で申し込めば即日発行できると聞き、後日、本庁で手続きを行った。

写真付きのものを発行してもらう場合、縦4.5cm×横3.5cmの証明写真を用意する必要があると書かれていたが、情報処理技術者試験用に撮った4cm×3cmのものしかなかったのでそれを持参した。規定のサイズより小さいものだったが、特に手続き上問題なかった。

発行手数料は無料としているところもあるようで(総務省の資料(pdf)によると平成20年時点で329団体だそうだが、全体の何%なのかはわからない)、私が手続きを行った自治体も無料発行していた。ただし、電子証明をつける際に500円が必要だった。

また、転入届と同時に、本籍変更の手続きも行おうとしたが、結婚時でないと無理だということで断られた。しかし、後日インターネットで検索してみると、成人していれば申し込み可能なようだ。

警察署では、運転免許証の住所更新を行った。本籍地の名称変更(市町村の合併やら名前をひらがなに変えたりしている、何年か前からの流行に伴うもの)もあったため、住民票は本籍地が記載されてものを出力してもらっていた。

住所変更の際、webサイトでは写真が必要である旨記載されている場合があるが、どうも、免許証の裏書が一杯で、新規に作り直す必要が出たときのみに必要なようだ。私の場合、写真を提出する必要はなかった。

[離職]転居手続き(1) 転出元での手続き

引越し前に行った手続きは、以前のエントリ(転居届けを出す, 電気・水道・ガスの停止申し込み, 転居)の他、ISP(@nifty)の光接続のみの解約、NTTの解約、市役所への転出届の提出、がある。

転入先には既に別ISPと契約したインターネット接続サービスがあり光接続は不要になるが、@niftyアカウントは残す、という状況のため@niftyとNTTへの手続きは上記のようになっているが、転入先でも同じサービスを受ける場合は異なる手続きになるだろう(参考)。

転出届については、住民基本台帳カードの発行を受けていれば、付記転出届という特例の手続き方法で、転出元の市役所に出向かなくても郵送で手続きが行えるようだ。私は郵送の方が面倒だと考え、転出前日に窓口で手続きを行った。

転出届提出時、住基カードを返却する必要があるのか窓口で尋ねたところ、転入先まで持って行き転入先で返却するように言われた。ただ、転入先の市役所でその旨を伝えたところ、ここでの手続きはそのようになっていない、とのことだった。結局現在手元には2枚の住基カードがある。検索したところ、転入先で処理する(ICチップ部にパンチで穴を開けるなど)のが通例のようだ。

その他、郵便物の転送届けについては、民営サービスを利用しているのであればそちらへの届出(参考、クロネコメール便の場合: 転送届け、クロネコも忘れずに！ - nobilog2)も行っておく方が良いだろう。例えば、楽天レンタルのようなメール便を用いるサービスを利用している場合は、楽天の登録者情報を更新すると共にヤマトへも届けておいた方が誤りがないと考える。ちなみに楽天レンタルの送付先住所は、午前0時時点での「通常の本人連絡先」になるそうだ。こんなきわどいタイミングで返却する必要も無いと思うが、荷造りを行っていると面倒になりそうなことはさっさと済ませたいと考え何も考えずに返却してしまう(そして自動で次のレンタル品が送付される)ことも有り得る。

余談。前出のリンク先www.juki-card.comは住民基本台帳カードの公式サイトだと思う(市役所にもこのURLが掲示されていた)のだが、go.jpなど、ドメインを見ただけで信頼できると判断可能なものにはできないのだろうか。地方自治情報センターという財団法人が運営しているようなので、or.jpかlg.jpが適切なのか。というか地方自治情報センター自体lg.jpの設立に関わっているじゃないか。

Google ChromeでPDFをインライン表示できなくなった

OSを再セットアップしたところ、Google ChromeでPDFが見られなくなっているのに気付いた。

にちゃんねるのスレッドを見ると、最近発生するようになった一般的な事象であり、セットアップ方法に問題があったわけではないらしい。

bug reportにはいくつか重複して報告されているようだが、そのうちのひとつ、Issue 24883:    With the new Acrobat Reader 9.2, no PDF appears in old Chrome windows によると、下記いずれかの方法を実施することで回避できるようだ。ただし、環境によっては回避できない場合もある模様だ。

• PDFを開いたウィンドウをリサイズする(ウィンドウの縁をドラッグ/いったん最大化するなど)。
• 同じウィンドウや新しいタブで開くのではなく、新しいウィンドウで開く。リンク先PDFに対し右クリックのコンテキストメニュー「新しいウィンドウで開く」を選択したり、Shiftキーを押しながらクリックすれば良い。
• PDFをインライン表示しないようにする。Adobe Readerを起動し、編集 > 環境設定メニューより設定ダイアログを開き、分類: インターネットで「PDFをブラウザに表示」のチェックを外す。ただしこれは他のブラウザでPDFを閲覧する場合の挙動も変えることになる。

追記:

2009/11/05時点の最新正式バージョンである4.0.223.16では、表題の問題が解消されたように見える。

google chromeは自動で(勝手に)アップデートされるようだが、手動アップデートを行うには、ウィンドウ右上のモンキーレンチアイコンから「Google Chromeについて」を選択する。上位バージョンがあればこのダイアログに更新ボタンが表れる。

追記2:

…と思ったのだが、どうも別の問題が発生するようだ。pdfページを開こうとすると、エラーダイアログが表れ、コンテンツが表示されない場合があるようだ。これは、ページをリロードすることで解消できるようだが。

[離職]退職までの手続き

退職前後の手続きについては、リクナビNEXT他、検索すれば情報が載せられているサイトは多く見つかる。ここでは、退職日までの手続きについて、記憶に残っていることを留める。

退職届については、私は自前で縦書き用の便箋を用意し(今日たまたま見ていたドラマ「白い巨塔」で江口洋介演じる里見先生が使用していたものと同じだった。そもそも文具屋に一種類しか置いていなかったのだが)提出したが、会社が規定した退職願の様式があったため、後日そちらに書き直し再提出した。

退職届と退職願の機微について解説しているサイトもあるが、実際のところこの程度なのだろう。

また、自己都合退職と会社都合退職では失業給付を受けられるタイミングや給付金額が異なり、会社都合のほうが好条件なため、なるべく会社都合で退職することを支持しているサイトもあるようだ。これについては興味が無かったので調べていないが、もしかすると退職届/願の書き方にも工夫があるのかも知れない。

退職届の宛て名は、退職しようとしている会社の代表取締役社長になる。今時の会社であればwebサイトのひとつも持っていると思うので、そこから企業情報を見れば社長の名前がわからないと悩むことも無いだろう。会社指定様式があるのであれば更に気楽だ。

その他、退職前に会社に提出した書類として、退職所得の受給に関する申告書(pdf)、企業型確定拠出年金(いわゆる日本版401k)に関する確定拠出年金加入者口座属性変更通知書がある。

退職所得の需給に関する申告書は、表面(リンク先pdfでは1ページ目)下部の注意書きを読むと、退職金に対する源泉徴収に関わる書類ではないかと思う。この書類を提出しなかった場合は、退職金に対し税率20%の源泉徴収が行われ、なおかつ次回確定申告が必要になるらしい(正確には、20%で不服が内容であれば確定申告は不要なようだが)。

ただ、離職状態のまま年を越すと年末調整が自動的に行われるわけではないため、いずれにせよ確定申告は必要だろう。

結局のところ、なんのために提出するのかわからない書類だが、拒む理由も無い。

401kの手続きについては、転居のため、取り敢えずは住所変更通知を行った。その後、参考リンク先にある通り、6ヶ月以内に何らかのアクションをとる(あるいは何も行わないと決定する)必要がある。

企業型確定拠出年金に個人別管理資産がある方が、その加入者の資格を喪失した場合、その資産を個人型または他の企業型の確定拠出年金に移換するか、脱退一時金の請求の手続を６か月以内に行わないと、その資産は現金化され、国民年金基金連合会に自動的に移換されることになっています。（確定拠出年金法第８３条）

こちらについては、まだ詳細を確認していない。

退職日までに返却する必要があるもののうちのひとつに、健康保険被保険者証がある。このため、歯の治療など通院が必要なものは早めに済ませておくべきだろう。あるいは快復するまで退職は留まるべきか。私の場合は使い捨てコンタクトレンズ確保のため眼科へ処方箋を貰いに行った。

なお、退職後の健康保険の加入方法についてはいくつか選択肢があり、ものによってはすぐには手続きが進められないことに留意が必要だ。これについては次回以降に記載できれば、と考える。

退職後に行う手続きについてはこちらの一覧にある。最終的にはここに記載されている書類が必要になるが、退職日までに受け取った書類は、このうち、年金手帳と雇用保険被保険者証の2書類だった。

[離職]会社を退職した

先月(2009年9月)末をもって新卒で入社した会社を退職した。

webで見かける退職報告や、同期、上司を見ると、退職前に転職先を決定している人ばかりだ。

私の場合は上のような方々とは異なり、次の職業を決めずに退職した。

したがって、私の状況は少数派ではないか、ということで、退職後の手続きやらをwebに記録していくことも意味があるのではないかと考えている。以降のエントリでは、この辺りについても含めていこうと考えている。

今回の退職に伴い、県外への転出を行っている。つまり、市役所や警察署の管轄が異なる場所へ引っ越しているため、そちらの手続きも含むことになる。

FEST-Swingを利用する(5) EDTで発生した例外をJUnitで検知する

前回で実際のソースコードを用いた例が終了してしまい、NetBeansもあまり関係なくなったのでタイトルを変更した。

EDTで例外が発生すると、Swingのデフォルト動作では、エラー出力にトレースを出力し、EDTを再起動させるようになっているようだ。

アプリケーションを稼動させている場合だと、自動で復旧してくれるこの動作は、有難い状況が多い。しかし、ユニットテスト中はエラーが発生したことを検知できず問題の発見が遅れる場合がある。ここでは、デフォルト動作を変更し、JUnit実行時にEDTで例外が発生した場合でもJUnit上でテスト失敗として出力する方法を述べる。

今回のサンプルはこちら。

JUnitスレッドで実行されるメソッドで発生する例外

public class MyClass {

    public void myMethod() {
        throw new UnsupportedOperationException("未実装");
    }
}

上記のようなクラスに対して、下記のJUnitテストケースを作成する。

public class MyClassTest {

    @Test
    public void testMyMethod() {
        new MyClass().myMethod();
    }
}

このテストケースを実行すると、myMethodメソッドで例外が発生するため、JUnitでは想定どおり失敗とみなされる。

EDTで実行されるメソッドで発生する例外

次に、EDTで例外を発生させてみる。ボタンの押下イベントハンドラbuttonActionPerformedで例外を発生させるコードを記述する。

public class MyFrame extends javax.swing.JFrame {
...
    private void initComponents() {
...
        button.addActionListener(new java.awt.event.ActionListener() {
            public void actionPerformed(java.awt.event.ActionEvent evt) {
                buttonActionPerformed(evt);
            }
        });
...
    }

    private void buttonActionPerformed(java.awt.event.ActionEvent evt) {                                       
        throw new UnsupportedOperationException("未実装");
    }
...
}

これに対するJUnitテストケースを作成する。

public class MyFrameTest {
...
    @Test
    public void testOkButton() throws Throwable {
        frame.button().click();
    }
}

このテストケースを実行すると、Exception in thread "AWT-EventQueue-0"から成るスタックトレースが標準エラー出力に表示されるが、テストケース自体は正常で完了する。つまり、JUnitの結果を見ただけでは、コードに問題がないのかどうか判断できないということになる。

問題点の解消その1 異なるスレッドで発生した例外を取得する

JUnitスレッドとイベントディスパッチスレッド(EDT)は異なるスレッドであるため、try-catchではもちろん捕捉できない。今回は静的変数edtThrowableを用いてEDTで発生した例外をJUnitスレッドに受け渡すことにした。

public class MyFrameTest {
    private static Throwable edtThrowable;
...
    @Before
    public void setUp() {
        edtThrowable = null;
...
    }

    @Test
    public void testOkButton()  {
        frame.button().click();
        Thread.yield();
        if (edtThrowable != null) {
            throw new RuntimeException(edtThrowable);
        }
    }
...
}

テストケースの最後にedtThrowableに値がセットされているか確認し、セットされていればそれをJUnitスレッドで送出することで、JUnitテストケースを失敗させる。

次に、EDTで例外が発生した際に、この変数に例外情報をセットするコードを記述する。

問題点の解消その2 EDT例外時動作を変更する

EDTで例外が発生した状況をデバッガで追っていくと、EventDispatchThread.javaのhandleExceptionメソッドに以下のようなコメントが見つかる。

Handles an exception thrown in the event-dispatch thread.

If the system property "sun.awt.exception.handler" is defined, then when this method is invoked it will attempt to do the following:

1. Load the class named by the value of that property, using the current thread's context class loader,
2. Instantiate that class using its zero-argument constructor,
3. Find the resulting handler object's public void handle method, which should take a single argument of type Throwable, and
4. Invoke the handler's handle method, passing it the thrown argument that was passed to this method.

これに沿ったクラスEDTExceptionHandlerを作成し、@BeforeClassでハンドラの設定を行う。このクラスのhandleメソッドで、前述の静的変数edtThrowableに設定を行っている。

public class MyFrameTest {
    public static class EDTExceptionHandler {

        public void handle(Throwable ex) throws Throwable {
            edtThrowable = ex;
            throw ex;
        }
    }

    @BeforeClass
    public static void setUpClass() throws Exception {
        System.setProperty("sun.awt.exception.handler", EDTExceptionHandler.class.getName());
    }

    @AfterClass
    public static void tearDownClass() throws Exception {
        System.setProperty("sun.awt.exception.handler", "");
    }
...
}

改良したテストケースの実行

上記で作成したテストケースを実行すると、JUnitは想定どおり失敗を通知する。

補足

• 上記はコードを単純化するために、マルチスレッドプログラミングについてはあまり考慮していない。JUnitスレッド側で実行しているThread.yieldで確実にEDTが実行されるとは限らず、また、edtThrowableへは両スレッドがアクセスするため同期化が必要だろう。
• 実際に私がコーディングしていた際には、前準備や後処理は抽象クラスにまとめ、それを継承した具象テストクラスを作成していた。ただ、この方法をとると、NetBeansが自動で実行してくれるテストでは、抽象クラスも実行しようとしてしまい、テストメソッドがないと怒られるようだ。

参考

• AWT/Swing でエラーダイアログを表示する。(Sunの実装限定) - おいしい大麻味噌の熟成日記
  ThreadGroup.uncaughtExceptionを利用する場合のリンクあり。

NetBeansでFEST-Swingを利用する その4 テストケースの更新

ここでは、現在のテストケースを更新し、新しい仕様を満たすことを確認するテストケースを作成する。

今回の変更点は以前述べたとおり速度情報の追加であるため、この点に絞ってテストケース作成を説明する。

準備

• 前回使用した、2008年7月時点のソースコード(TrlLogEditor_src2.zip)

現時点の仕様確認コード準備

• 起動時、テーブルが表示され、”行”,”保存”,”日時”,”緯度”,”経度”,”高度”列ラベルがこの順で表示される。
• 起動時、テーブルの内容は空である。
• trlファイルを開くと、テーブルに内容が表示される(空ではなくなる)。

上記のテストケースは以下のようになる。1つめのテストtestOpenでは1点目と2点目を、2つめのテストtestOpenFileでは3点目を確認している。実際のソースコードはこちら。

// import static org.fest.assertions.Assertions.*;
// import static org.fest.swing.core.matcher.JButtonMatcher.withText;
// import static org.junit.Assert.*;

    @Test
    public void testOpen() {
        assertEquals(0, table.columnIndexFor("行"));
        assertEquals(1, table.columnIndexFor("保存"));
        assertEquals(2, table.columnIndexFor("日時"));
        assertEquals(3, table.columnIndexFor("緯度"));
        assertEquals(4, table.columnIndexFor("経度"));
        assertEquals(5, table.columnIndexFor("高度"));

        assertEquals("起動時のテーブルは空", 0, table.rowCount());
    }

    @Test
    public void testOpenFile() {
        final File file = new File("testdata/ver112.trl").getAbsoluteFile();

        window.button(withText("開く...")).click();
        JFileChooserFixture chooser = new JFileChooserFixture(robot);
        chooser.selectFile(file);
        chooser.approve();

        assertThat(table.rowCount()).as("ファイルの内容が表示される").isGreaterThan(0);
    }
}

新仕様対応確認テストケースの作成

こちらに記載したとおり、Holux M-241のファームウェアVer1.13では、速度情報が記録される。従って、更新後のプログラムの動作が次のようになればOKとする。

• 起動時、テーブルが表示され、”行”,”保存”,”日時”,”緯度”,”経度”,”高度”,”速度”列ラベルがこの順で表示される。
• 起動時、テーブルの内容は空である。
• trlファイルを開くと、テーブルに内容が表示される(空ではなくなる)。
• Ver1.12以前のファイルを開いた場合は、速度列は空欄とする。

太字部分が追加・更新した仕様である。

上記を満たせばOKとなるように、テストケースの差分は以下のようになる。ソースコードはこちら。

// import static org.fest.swing.data.TableCell.row;

    @Test
    public void testOpen() {
...
        assertEquals(6, table.columnIndexFor("速度"));
...
    }

    @Test
    public void testOpenFile() {
...
        final int colSpeed = table.columnIndexFor("速度");
        table.cell(row(0).column(colSpeed)).requireValue("");
    }
}

これを実行すると、実プログラム修正を行っていない今の時点ではもちろん失敗する。

このような形でテストケースの作成し、テストケースに適合するように実プログラムを更新していく。

情報処理技術者試験の受験票を紛失したので再発行してもらう

手荷物の中に受験票を入れていたはずなのだが、無くしてしまった。

「平成21年度秋期試験の受験票発送について」に書かれているとおり、支部へ連絡したところ、再発行してもらえるようだ。

このとき本人確認として必要だった情報は以下のとおり。

• 生年月日
• 氏名
• 住所

試験申し込み当時と住所が変更になっているため、住所変更も行ってもらい、現在の住所へ送付してもらえる事になった。

転居

自宅のサーバも移転作業があるため、2週間程度不通になります。本blogからリンクしている自作サンプルコードやプログラムもこの間アクセスできません。

関東から関西への転居になる。引越し荷物の輸送方法には、直送と相乗りの2種類があるらしい。直送の場合は自身の荷物のみ輸送するため、荷物を転出してから転入するまでの期間が短くて済む。一方、相乗りの場合は、相手を探してからまとめて輸送するため、前者と比べて、荷物を受け取れるまでの期間が長くなる。

今回は、転出から転入までの期間制限を2週間としてもらい、60,000円だった。

今日では、インターネットでの一括見積もり申請も可能で、昔ここに越してきたときよりは楽になったと思う。

ただ、長距離に対応している業者はそんなに多くないようだった。また、インターネット見積もり申請を行っても、そのまま金額を提示してもらえる業者も少ない。これについては、実際に荷物を見てもらわないとこちらも不安なので、いずれにせよそれぞれの業者には実際に来てもらって良かったと思う。インターネット申請は、業者を探す手間、電話をこちらから行う手間が省ける、程度に考えている方が良いだろう。

電気・水道・ガスの停止申し込み

インターネットの手続きでは本人確認のためお客様番号、あるいはそれに相当するものが必要だった。

これは毎月送られてくる請求書に記載があるようだが、そういったものは既に一切合切廃棄してしまっていたため、電話で申し込むことにした。

電話でもこの番号を確認されるが、分からなくてもそのほかの情報、私の場合は引き落とし口座番号、で代替できた。

インターネットでの申し込みでは、3営業日後以降のものしか受け付けられないようだったが、電話では翌日でも問題なかった。

一般的な話か分からないが、今回、それぞれの申し込みで以下のように違いがあった。

• 電気
  引き落とし口座番号で本人確認。利用最終日にメータ確認を行うとのこと。立会いは必要ないが、マンションがオートロックの場合、玄関を開けるために在宅が必要、とのこと。
• ガス
  本人確認は特に行われなかった。利用最終日にメータ確認を行うとのこと。立会いは不要らしい。
• 水道
  お客様番号は分かっていたのでそれを通知した。利用最終日の翌日にメータ確認を行うとのこと。立会いは不要。

転居届けを出す

引越しを行う際、郵便物を転送してもらうために郵便局へ転居届けを出す必要がある。

申請方法としては、直接郵便局へ出向く、郵便局にあるハガキを貰ってきて郵送する、インターネットで申し込む、の3パターンあるようだ。

いずれにせよ本人確認が必要であるらしい。

窓口にお越しになれない場合は、転居届にご記入の上、切手を貼らずにポストに投函していただくか、またはインターネットでお申し込みください。

この場合、社員が配達の際、転居の事実の確認のため訪問させていただくことがありますので、ご了承願います。

また、インターネットで申し込む場合には、本人確認のため、クレジットカードが必要との記載がある。

このクレジットカード認証も曲者で、私の所有している3枚のクレジットカードのうち、認証に使用できたのは1枚だけだった。プロパーカードでも認証できないものがあった(三井住友VISA)。ちなみに認証できたのはローソンパスカード(VISA)。

カードで認証できないとインターネットでの申し込みが出来ないので、早めに自分のカードが通るか確認する必要があるだろう。

また、指定できる転送開始日は3日後(3営業日後？)以降となっていた。申し込みハガキの方には、3～7営業日かかると書いてある。

電気・水道・ガスについては、東京電力のサイト「引越コンシェルジュ」が利用できそうだ。関東以外の会社の対応状況は、関東と比べると悪いようだが。

受付可能な期間(引越し日から何日前から何日前まで受付可能か)が、会社によって若干異なるようなのでこれにも注意が必要だ。

免許証は転入先での手続きとなるようだ。

市役所へは、転出元で転出届を、転入先で転入届を出す必要がある。転出届は郵送でも出来るようなので、引越し後でも可能なのだろうか。

NetBeansでFEST-Swingを利用する その3 JUnitテストケース作成

実際のプログラムを用いてFEST-Swingを利用していく。元となるソースコードは、2008年7月に作成したもの(TrlLogEditor_src.zip)を用いる。

準備

• 上記TrlLogEditor_src.zipをダウンロード、展開し、NetBeansへプロジェクトとして追加する。。
• 前回までに述べたNetBeansの設定を行う。

テストケースクラス作成

今回テスト対象とするクラスはyukihane.gps.gui.MainWindowである。そこで、プロジェクトウィンドウ上の、ソースパッケージ以下にあるMainWindow.javaを右クリックする。コンテクストメニューで ツール > JUnitテストを作成 を選択し、ウィザードを進める。JUnitのバージョンは4.xを選ぶ。

ウィザードを完了させると、テストパッケージ以下にMainWindowTest.javaが作成される。

初期処理、終了処理の追加

まず、Robotインスタンスを生成する。Robotは1テスト内では1つのインスタンスを使いまわす必要があるため、setUpメソッドで生成し、フィールドとして保持する。また、今回は、テストごとにメインウィンドウを起動させるようにする[1]ので、こちらもsetUpに含める。

public class MainWindowTest {

    private Robot robot;
    private FrameFixture window;

    @Before
    public void setUp() {
        robot = BasicRobot.robotWithNewAwtHierarchy();
        window = new FrameFixture(robot, new MainWindow());
        window.show();
    }
}

終了時にはcleanUpメソッドを呼ぶ必要がある[1, 2]。

    @After
    public void tearDown() {
        robot.cleanUp();
    }

ダミーのテストメソッドを作成し、うまく動くか試してみる。以下のメソッドを追加した後、Ctrl+F6でこのファイルを実行する(以前記載したとおり、JButtonMatcher.withTextをstatic importする)。

    @Test
    public void testOpen() {
        window.button(withText("開く...")).click();
    }

備考：実行時間について

上で作成したテストケースを実行すると、私の環境では2秒強かかる。これに対し、メソッド内の処理を全てコメントアウトした場合では0.1秒程度で、差は2秒ほどとなっている。これが意味するところは、"GUIの自動テストにはかなりの時間がかかる"ということである。今日のGUIアプリはスタンドアローンでは無くサーバとの通信機能を持っていることも多いと思うが、このテストのためにモックオブジェクトを利用しリフレクションを多用するなどしていると、更に実行時間は延びてくる。

また、実行時のマウスカーソルの動きを見れば分かるとおり、FEST-SwingはGUIイベントを擬似生成するのではなく、Robotを用い実際にボタンを押し、ユーザが画面操作を行うのと同じ仕組みでイベントを発生させる。従って、テスト実行中は端末で他の作業が行えない。

これらを踏まえると、規模がそれなりに大きいものに適用する際には、テスト専用の端末を用意しておくか、夜間にAntで自動実行するような仕組みを検討しておくべきだと考える。

参考

• [1]Guidelines for Writing Tests with FEST-Swing
• [2]Getting Started

Windows Live Writerでココログに投稿してもトラックバックが反映されない

Windows Live Writerを14.0.8089.726 jaへアップデートした(本家サイトよりバージョンが新しいのは何故なのだろう)のだが、ココログへ投稿時、トラックバックが送信されていないようにみえる。

この機会に、xfy Blog Editor LE 無償版 1.2.2.0へ乗り換えてみた。

• Windows Live Writerにはあった、pingサーバの設定機能がxfy Blog Editorには無いようだ。
• 添付した画像ファイル名にセンスが無い。
• 過去投稿した記事の編集を行おうとしても、インポートできない。

2点目については、画像ファイル名にIDを含めてしまうという過去の不具合の対応に因るものかもしれない。オリジナルのファイル名をもじるか、記事のパーマリンクをもじるかすれば良いと思うのだが、昔からの設計思想上こうなっているということなのだろう。

3点目については、おそらく有償版の「画像を含むブログ記事のインポート/エクスポート機能」が該当するのだろう。

追記

再度Windows Live Writerを試してみたところ、トラックバックに関して問題なく送信できていた。

Windows Live Writerをバージョンアップしたことにより、プラグインがいくつか対応できなくなり、Exception発生のダイアログが表示されていたが、これが問題だったのかもしれない。該当プラグインを無効にしたところ、前述のとおり正常に動作した。

FEST-Swing1.2a3の新機能で気付いたこと

今まで1.1を使用しており、今回初めて1.2a3を利用してみているのだが、コンポーネントのtextでコンポーネントを探すことができるようになっているようだ。

従来より、FEST-Swingはコンポーネントをnameにより識別する方針を採っている。

例えば”適用”ボタンがあったとすると、このボタンのnameは”適用”ではなく、別途設定する必要がある。ちなみに、このときの”適用”は何かというとtextプロパティである。

確かに国際化を考えると、”適用”でコンポーネントを識別することには問題がある(例えば英語化したときは”Apply”ボタンになるだろう)が、過去作成したプログラムのテストを自動化したいという理由だけではソースコードの修正が行えない場合もあり、また、そもそも全部のコンポーネントに今からnameを設定するのはコストが高い場合も多い(命名規則を作って、仕様書に1列追加して、...云々)。

1.1では、このような場合どうしたかというと、国際化する際のことは取り敢えず忘れて、こちらのエントリ後半に記載しているようにGenericTypeMatcherを使用して、textプロパティで識別を行っていた。

1.2a3では、この方法がライブラリで提供されるようになったようだ。JButtonMatcher.withText(String)を使用し、以下のような記述ができる。

// import static org.fest.swing.core.matcher.JButtonMatcher.withText;
window.button(withText("適用")).click();

レガシーコードに対しても、直感的なコーディングができるようになったのではないだろうか。

以下、余談で国際化について。

メニューから呼び出される昨日のテストを行う際、どのメニューアイテムを選択するか特定する必要があるが、この特定方法はmenuItemWithPathメソッドの引数に、メニューアイテム名を指定する必要があり、いずれにせよ国際化済みプログラムのテストが実現できなかったと当時は考えたのだが、本来はどうあるべきなのだろうか。

参考

• Common-Use Component Matchers

NetBeansでFEST-Swingを利用する その2 JavaDoc作成

わき道に逸れるが、FEST-SwingのパッケージにJavaDoc(webではここで参照できる)が含まれていないようなので、作成しておくことにする。

AntのJavadocタスクを作成しても良いが、ここではせっかくなのでNetBeansで作成してみる。

まず、作成対象のソースコードを展開する。展開はjarコマンドを用いてコマンドプロンプトから jar –xfv fest-swing-1.2a3-sources.jar 等のように実行するか、一旦拡張子を.jarから.zipに変更し、zipが解凍できるユーティリティを使用すれば良い。なお、WinRARのように.jarのまま解凍できるものもある。

次に、NetBeansで新規プロジェクトを作成する。このとき”既存のソースを利用するJavaプロジェクト”を選び、ソースパッケージフォルダには先ほど展開したソースディレクトリを含める。

含めるファイルは**,除外するファイルは**/META-INF/**としておけば良い。

プロジェクトが作成されたら、コンパイルが通るようにするため、文字コードの変更を行う。プロジェクトを右クリックし、プロパティーを選択、プロジェクトプロパティーダイアログを開く。その後、ソースを選択し、エンコーディングにISO-8859-4を指定する。

最後に、プロジェクトプロパティーダイアログを閉じ、プロジェクトを右クリック、”Javadocを生成”を選択して完了。

生成されたjavadocディレクトリを適切なディレクトリに移し、ライブラリマネージャでFEST-Swingのjavadocにそのディレクトリを指定する。

今回作成したプロジェクトや展開したソースコードはもう不要であるため削除してしまってよい。

NetBeansでFEST-Swingを利用する その1 インストール

一度FEST-Swingについて記載したことがあるが、もう少し実用的なエントリを書きたいと思う。ちょうど、GUIを持つアプリケーションを修正する必要が出たので、このアプリにおける、実際の利用方法を記述していく。

ここでは、NetBeans上でライブラリとして扱うための準備について記載する。

FEST-Swingの最新バージョンであるfest-swing-1.2a3.zipをダウンロードし、適切な場所に展開する。

NetBeans6.7.1を起動、メニューの ツール > ライブラリ を選択し、ライブラリマネージャを起動する。

ダイアログ左下のボタン”新規ライブラリ”を押し、新規ライブラリを作成する。ライブラリ名は”FEST-Swing”とでもしておき、ライブラリの種類は”クラスライブラリ”を選ぶ。

ライブラリマネージャダイアログ左部のツリービューで、作成したFEST-Swingを選択し、ダイアログ右部のクラスパスタブ内リストへ、先に展開したfest-swing-1.2a3.jar及び libディレクトリ内のdebug-1.0.jar, assert-1.1.jar, fest-reflect-1.1.jar, fest-fest-util-1.1.jar, jcip-annotations-1.0.jarの6ファイルを追加する。

同様に、ソースタブ内リストへ上記に対応するxxx-sources.jar 6ファイルを追加する。

“了解”ボタンを押し、ライブラリマネージャダイアログを閉じる。

以上でNetBeansでFEST-Swingを利用できる設定が行えた。続いてプロジェクトでFEST-Swingを利用する設定を行う。

画面左上部のプロジェクトツリーで該当のプロジェクトを右クリックし、プロパティーを選択する。

表示されたプロジェクトプロパティーダイアログで、”ライブラリ”を選択し、”テストをコンパイル”タブ内のリストへ、先ほど作成したライブラリFEST-Swingを追加する。追加は”ライブラリを追加”ボタンから行う。

以上でこのプロジェクトからFEST-Swing APIが呼び出せるようになった。

Holux M-241 ファームウェアがVer1.13になっていた

Wireless GPS Logger M-241

Holux M-241のファームウェアが更新され、Ver1.13になっていた。

前バージョンからの更新点は、速度が新たに記録されるようになったことだそうだ。

これに伴い、以下の点も変更になっている。

• 記録できる最大ポイントが、130,000ポイントから104,000ポイント強へ減少した。
• ログファイル(.trl)のフォーマットが変更になった。

また、付属ユーティリティでtrlフォーマットを他のフォーマットへ変換できるのだが、この変換後ファイルのフォーマットも、速度が追加になっているのだが、それ以外の箇所も変わっているようだ(理由は未調査)。

前者の記録ポイント数が減少したことについては、1秒毎に記録したとしても36時間(13万ポイント) –> 28時間(10万ポイント) の変更であり、実際には10秒毎程度で利用しているため問題にはならない。ただ、速度の記録もあまり必要な機能であるわけではない。

後者のフォーマット変更については、従来フォーマット対応アプリでは読み込めなくなるため、運用次第で問題になることがあるだろう。私が以前作成したユーティリティもVer1.13のフォーマットに対応させようと思う。

ファームウェアアップ時には、本体内のログは全て消去されるため、必要であれば事前にPCへ移しておくこと。

その他、姉妹製品としてM-241cというものも出たようだ。こちらはM-241からBluetooth機能を省略したものらしい。Amazonでは2,000円ほどの価格差となっている。

Android EmulatorでSDLを実行してみる

本文最後に記載したサイトを参考に、SDLをリンクしたAndroidネイティブバイナリを作成してみた。

ビルド及び実行環境は前回エントリと同様。Portable UbuntuでSDLライブラリをビルドし、このライブラリをリンクした実行バイナリを作成する。その後、Windows上で動かしているEmulatorで実行する。

準備

新たにインストールしたものは以下の通り。

• SDL version 1.2.13

SDLビルド

SDL-1.2.13/src/video/fbcon/SDL_fbvideo.c を開き、191行目, 及び499行目にある、"/dev/fb0"を"/dev/graphics/fb0"に書き換える。

その後、SDL-1.2.13ディレクトリで以下のコマンドを実行する。(追記：以下をそのままコピー&ペーストすると、行末に半角スペースが含まれてしまいうまく実行できないようだ。オリジナルをコピーした方が良いだろう。)

./configure \
CC=arm-none-linux-gnueabi-gcc \
--host=arm-linux \
--enable-audio=no \
--enable-video=yes \
--enable-cdrom=no \
--enable-joystick=no \
--enable-threads=no \
--enable-timers=no \
--enable-loadso=no \
--enable-video-fbcon=yes \
--enable-shared=no \
--enable-sdl-dlopen=no \
--enable-video-x11=no \
--enable-x11-shared=no \
--enable-dga=no \
--enable-video-dga=no \
--enable-video-x11-dgamouse=no \
--enable-video-x11-vm=no \
--enable-video-x11-xv=no \
--enable-video-x11-xinerama=no \
--enable-video-x11-xme=no \
--enable-video-x11-xrandr=no \
--enable-video-x11-dpms=no \
--enable-video-photon=no \
--enable-video-carbon=no \
--enable-video-cocoa=no \
--enable-video-fbcon=yes \
--enable-video-directfb=no \
--enable-video-ps2gs=no \
--enable-video-ggi=no \
--enable-video-svga=no \
--enable-video-vgl=no \
--enable-video-wscons=no \
--enable-video-aalib=no \
--enable-video-qtopia=no \
--enable-video-picogui=no \
--enable-video-xbios=no \
--enable-video-gem=no \
--enable-video-dummy=no \
--enable-video-opengl=no \

SDL-1.2.13/build/.libs ディレクトリに libSDL.a が作成される。

実行ファイル作成

以下の内容を持つsdlsample.cを作成する。

#include "SDL.h"

int main(int argc, char * argv[])
{
    SDL_Surface * scr;
    SDL_Rect rect;
    int i, j;
    static int k;
    Uint8 r, g, b;

    /* Init SDL: */
    printf("about to init\n");
    printf("test point %d\n", 1);

    if (SDL_Init(SDL_INIT_VIDEO) < 0)
    {
        fprintf(stderr, "Can't init: %s\n", SDL_GetError());
        exit(1);
    }
    printf("test point %d\n", 2);

    /* Open screen: */
    scr = SDL_SetVideoMode(320, 480, 16, SDL_HWSURFACE);

    printf("test point %d\n", 3);
    for (i = 0; i < 16; i++)
    {
        /* Determine where to draw rect: */

        rect.x = i * 10;
        rect.y = i * 7;
        rect.w = 100;
        rect.h = 50;

        /* What color should it be? */

        r = (i * 4);
        g = ((64 - i) * 4);
        b = (i % 4) * 64;

        /* Draw a rectangle on the screen: */

        SDL_FillRect(scr, &rect, SDL_MapRGB(scr->format, r, g, b));

        SDL_UpdateRect(scr, rect.x, rect.y, rect.w, rect.h);

        /* Wait five seconds: */

        // SDL_Delay(1000);
        for (j = 0; j < 100000; j++)
        {
            k = j;
        }
    }
    printf("about to quit\n");

    /* Quit: */
    SDL_Quit();
    return (0);
}

これをコンパイルする。

$ arm-none-linux-gnueabi-gcc sdlsample.c -o sdlsample -static -ISDL-1.2.13/include -LSDL-1.2.13/build/.libs –lSDL

この後の実行までの流れは前回と同様。

補足

上記を実行してみるとわかるが、画面描画は行われているが、タイミングがかなり速くなっており即座に終了する。ソースコード中のコメント Wait five seconds 以下に問題がありそうだ。

上記の例ではSDLのビルドオプションで--enable-timers=noを指定しているが、有効にしても問題ないようなので、このオプションを削除しSDLを再ビルドする。

この上で、ソースコード中のコメントアウト行SDL_Delay(1000);を復活させ、その後ろのforループを削除したものを実行すると、想定通り(と思われる)結果が得られる。

その他のビルドオプションも再検討の余地がありそうに感じる。

参考

• Android G1 native c and SDL – HackingHardware
  SDLのビルドオプション及びサンプルコード。
• Port OpenGL/SDL/TinySDGL to android with native C
• Building SDL - Android Programming

Portable Ubuntu RemixでAndroidバイナリを作成する

Portable Ubuntuのプロジェクト成果物が、以前と変わっているようだ。

以前のPortable Ubuntu for Windowsに相当するものは”Portable Ubuntu Remix Version UNO”という名前になっており、新しく”Portable Ubuntu Remix Version DOS”というものがあった。

違いはよく分かっていないが、Version DOSの方はCygwinを利用しているようだ。また、ベースとなるUbuntuのバージョンが、UNOでは8.04, DOSでは9.04のようだ。

また、ホームドライブの容量拡張方法も変わっており、Version DOS release 4以降ではToporesizeというアプリから行うように記載されている(入手はここから)。試しに実行してみたが、容量の変更に失敗しているようにみえる場合もあり、バックアップをとってから実行した方が良いように思う。

今回、このPortable Ubuntu Remixに、Androidネイティブバイナリのビルドを行うための環境を構築した。長期的に利用するのであれば、おそらくPortable UbuntuよりCygwin上に構築する方がWindows環境との親和性が高く良いと考える。ただ、今回後述のライブラリ”Sourcery G++ Lite”がCygwinへはうまくインストールできなかったためこちらを利用することにした。

準備

• Windows上へのインストール
  • Portable Ubuntu Remix Version DOS release 4
  • Android 1.5 SDK, r3
• Portable Ubuntu Remix上へのインストール
  • Sourcery G++ Lite for ARM GNU/Linux 2009q1-203 (IA32 GNU/Linux Installerを利用)

なお、以下ではPortable Ubuntu Remix(以降、Portable Ubuntu)設定作業についてのみ記述する。Android SDK及びAndroid Emulatorの設定についてはこちらなどを参考に、SDカードを持ったAVDを作成し起動しておく。

共有ディレクトリ設定

インストール時に作成されるファイルPortable_Ubuntu_DOS\config\portable_ubuntu.confで設定を行う。

ファイルを”shared_folder”で検索しヒットした箇所の例の通り記述すれば良い。

Portable Ubuntu上では /media/cofsX にマウントされる。

日本語化

必須というわけではないが、取り敢えず行っておく。

1. Portable Ubuntuを起動する。
2. 画面上部に表示されるパネルから、System > Administration > Language Support を選択する。
3. 表示されたLanguageダイアログの最下部ボタン Install / Remove Languages... を押す。
4. 表示されたInstalled Languagesダイアログで、japaneseにチェックをつけ、Apply Changesボタンを押す。
5. Languageダイアログに戻り、日本語を選択して完了。

Sourcery G++ Lite for ARM GNU/Linux インストール

$ sh arm-2009q1-203-arm-none-linux-gnueabi.bin

を実行し、表示されたとおりに進めればよい。rootのデフォルトパスワードは123456。

上記インストーラでインストールすると、~/.bash_profile ファイルが作成される。クロスコンパイラのPATH設定を行うためのものであるが、.bash_profileが存在すると.profileが読み込まれず、次回起動時に不具合が出る。このため、.bash_profileは(必要であればバックアップをとった後)削除し、PATH設定は.profileに追記しておく。

再起動して、起動できてPATH設定も正しいことを確認できれば完了。

バイナリ作成

androidネイティブバイナリを作成する。ライブラリダイナミックリンク版も作成できるようだが、ここでは簡単なスタティックリンク版を作成・実行する。

hello worldコードをhello.cに記述し、以下のコマンドを実行すれば良い。

$ arm-none-linux-gnueabi-gcc hello.c -o hello –static

fileコマンドで確認すると、ARM用バイナリであることがわかる。

$ file hello
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.14, not stripped

バイナリ実行

今回、Android EmulatorはWindows上で起動しているため、共有ディレクトリ経由でWindowsに上記で作成したバイナリを持って来る。

その後、EmulatorのSDカードにバイナリを置く。コマンドプロンプトで下記コマンドを実行すればよい。

> adb push hello /sdcard

次にEmulatorのshellを起動する。

> adb shell

ただし、/sdcardはnoexec付きでmountされているため、このままでは実行できない。

# mount
/dev/block//vold/179:0 /sdcard vfat rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1000,fmask=0711,dmask=0700,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8 0 0

このため、Emulatorを起動して初回実行する前に、下記のコマンドを実行し、実行可能なようにマウントし直す。

# umount /sdcard
# mount –t vfat /dev/block//vold/179:0

これで作成したプログラムを実行できる。

# /sdcard/hello

参考

• Port OpenGL/SDL/TinySDGL to android with native C
  Sourcery G++ Lite for ARM GNU/Linuxについて。
• Android Dev Phone 1 その2 – splhack
  sdcard上のバイナリ実行について。