Bad arg length for Socket::pack_sockaddr_in - tcp socket communication by Perl

http://www.perlmonks.org/?node_id=642313

Perl を久々に触っていて、TCP 通信のコードを書こうと思った。ただ、自分がHACKしようと思っているソフトウェアはモダンなライブラリを使っておらず、低レベルなAPIを使っていたのでそれに合わせることにした。

そこで書いたのが以下のコードである。


このコードを実行すると「Bad arg length for Socket::pack_sockaddr_in, length is 14, should be 4 at invalid_tcp_code.pl line 15.」というエラーになる。なんでやねんと数十分悩み、よくよく pack_sockaddr_in関数のドキュメント を読んでみると、以下のようになっていた。第2引数には inet_aton 関数の戻り値を渡せとある。

Takes two arguments, a port number and an opaque string (as returned by inet_aton(), or a v-string).

要するにドキュメントはよく読みましょうね、、ってことで。。
動くコードの全体は以下の通りである。www.google.com に HTTP通信するコードだ。エラー処理は省略しているので注意。

[memo] Apache Core Dump on CentOS

CentOS で Apacheモジュール のデバッグをしていて、 Core Dump を吐かせようと思ったときに少し迷ったのでここにメモしておく。

Core Dump はプログラムがクラッシュしたときのメモリの状態を示すものであり、gdb でいろいろ解析ができるのでデバッグ時に重宝するのだが、サイズが結構巨大になる。それに Production な環境では不要なものなので、ディストリビューションはあの手この手で Core Dump を出力しないようにしているのが普通だ。

ググるといろんなやり方が書いてあるけれども、ディストリビューションによって手順が違うのに加えて、一般論も混じっていてかなりわかりづらい。CentOS(Red Hat系ディストリビューション) で一番簡単なのは以下だ。

これは、/etc/init.d/functions で ulimit を環境変数で毎回設定していることによる。

----

1. httpd.conf に CoreDumpDirectory を追加。

CoreDumpDirectory /tmp/

2. コアファイルの ulimit 設定を指定して Apache を再起動

DAEMON_COREFILE_LIMIT=unlimited; /etc/init.d/httpd restart

Titanium 2.x traps

これは、Titanium Mobile Advent Calendar 2012 の参加エントリです。

いやーついに Titanium 3.0 がリリースされましたね！ このエントリでは、僕が 2.x を触っていてハマった様々な罠について述べていきますが、3.0 以降ではこれらが全てfixしていることを祈っています。

今回のエントリでも、自分が iPhone, Android 両対応アプリを開発した経験に基づいていますので、皆様の環境では必ずしも再現しない場合もあると思いますが、その点は御容赦くださいませ m(__)m

1. String.format ってクロスプラットフォームで使うときはちょっと注意いりませんか？

今年の Advent Calendar でも触れられている String.format 関数。C言語でのsprintf関数の如く、文字列処理では重宝する関数なのでいやー便利ですよね皆さん！ といいたいところなんですけど、、

 String.format("input value was %d  !!!", "hogehoge");

とかいう具合で誤った使い方をすると以下のような感じだったと記憶しています。

A) iPhone ではアプリが落ちる。
B) Android ではスルーされた。。なんで通るんだ。。

そもそも文字列連結処理が面倒だという理由で この関数を自分は使っていたので、"+" 演算子を使って回避した記憶があります。

2. "iphone" というフォルダ名を [Resources|ui] ディレクトリ以下に作るとアプリが落ちる件

http://developer.appcelerator.com/question/136031/couldnt-find-module-error-on-device

android とか、 iphone という名前は root フォルダで予約されているようで、ビルドが壊れてしまいました。"Could'nt find module error on device" というエラーメッセージが出たときは要注意です。

自分はこの罠によって iPhone アプリのエミュレーターで何の前触れもなくアプリが落ちる事象に遭遇しました。3時間悩み、フォルダ名を変えて動いたときはなんのこったいと頭をかきむしった記憶があります。

3. アプリを起動したとき "application restart is required" と表示される

https://jira.appcelerator.org/browse/TIMOB-4941

これは Android 限定の現象ですが、Google Play から落としてきた配布済みのアプリを Google Play から、またはアプリのショートカットから起動すると "application restart is required" と表示されてしまうという事象がありました。

Titanium 2.0 SDK 以降でこの現象は fix されたとありますが、2.1.x でも再現しました。

Google Play にアップロードした時以降「だけ」この現象が再現するのは始末が悪かったです。回避策は、 tiapp.xml に以下のような設定を入れることです。

   <property name="ti.android.bug2373.disableDetection" type="bool">true</property>

4. UTF-8 以外のエンコーディング問題

御存知の通り Titanium Mobile では UTF-8 が使われています。ですがいろいろな理由で UTF-8 以外の文字コードを使わざるを得ない場合もあったりなかったり。。

必要な場合は Escape Codec Library を使うのがよいとは思いますが、ライセンスが不明確なので組み込みは微妙です。

http://www.vector.co.jp/soft/other/java/se342855.html

5. JSS (JavaScript StyleSheet) の扱い

もはや 3.0 以降では別の形でウィジェットの装飾方法が確立されているため、この記述は役に立たないでしょうが、一応記しておきます。
GUIの装飾をJavaScriptで行うjss (Javascript Style Sheet) はドキュメントは残っていないし、仕様と動作が[不明確|不便]なため、自分は結局いろいろ試した末使いませんでした。JSS の記述は以下にあったりしますが、2.x では使わない方がよいでしょう。

http://gihyo.jp/dev/serial/01/titanium/0015

JSSの代替となる流儀は、require してプラットフォームごとに設定を切り替える方法です。僕は以下にあった方法を使いました。

http://higelog.brassworks.jp/?p=1144


おわりに

Titanium 3.0 では Alloy という MVC フレームワークで大幅にアプリの開発が変わるでしょうが、個々のコンポーネントやアプリを公開する時にまつわるバグや罠はいろいろなところに潜んでいることでしょう。けどそれを乗り越えて皆でノウハウをシェアしつつアプリ開発を楽しめればよいなーと思います。再度書きますが、3.0 以降では変な罠を踏みたくないものですね！

次は @astronaughts さんですね！ 宜しくお願いします！

[iPhone|Android] enabled Design Tips by Titanium

これは、Titanium Mobile Advent Calendar 2012 の参加エントリです。

Titanium Mobile 3.0 RC がつい最近リリースされ、新バージョンが目前ですね。
今年の前半は 4ヵ月くらい Titanium Mobile を触りました。何もないところから流儀を身につけてそれなりのコードを書き、2ヵ月半くらいで [iPhone|Android] アプリの両方をリリースしました。

今回はその経験を踏まえて、自分なりの iPhone, Android 両対応の Titanium Mobile における設計の流儀をまとめておこうと思います。「設計の流儀」としたのは、Titanium のバージョンがそれなりにあがっても自分的に通用しうるな、と思ったものだけをまとめたものだからです。 コードを書くときも様々なトラップを踏んだ覚えがありますが、それは別途まとめてみようと思います。

自分が作った経験に基づいていますので、以下のような内容になります。念頭に置いてお読みください。

　　A)  Native 部分とスマホ向けのWebサイトを組み合わせたハイブリットアプリ向け 
　　B)  ゲームアプリではないので、3D などのTipsは含まれていません。
　　C) Titanium に限らず、スマホアプリを作るときはいつも当てはまるだろう、という事項も含まれています。


1. Android -> iPhone の順で設計する

iPhone より Android の方が出来ることが少なく、また Titaniumでの実装上の罠も 2.x 系では多い気がしました。よって、こちらをベースに先に作業した方が後々苦しまなくて済むと感じました。

UI は当然のことながら全然違うし、APIによって使える使えないが勿論存在するので、両対応を考えるなら汎用的に使えるコンポーネントで組み立てた方があとあと楽になれるかもしれません。そうした「使えそうなコンポーネント」を選ぶにあたって使えるのが御存知 「KitchenSink」です。

KitchenSink は iPhone, Android の両方で（できれば実機で）動かしてみることを強くお勧めします。それによって、それぞれのプラットフォームにおける見た目や動きが把握でき、しかもその中身がサンプルコードとして見ることができるからです。本やWebでコンポーネントの情報を把握することもよいのですが、実機での動きに勝るものはありません。

2. Titanium で出来ることと出来ないことをきちんと把握しておく

当たり前だろう、と石が飛んできそうですが、出来ることの限界が意外にわかりづらかったり、作っている途中で「これはできない」とわかったりするのが Titanium の世界だったりすると自分は思っています。。そうでもないですかね(´ー｀; )

当たり前のことですが、Titanium Mobile を使えば iPhone や Android で使える機能が全部使えるとか考えてはいけません。対応していない機能は [Objective-C|Java] でモジュールを書く必要があるため、それなりの労力が必要になってきます。

Titanium のバグで動かない API をモジュールで代替せねばならない場合もあります。自分の場合は、 Android で 音声認識機能 を Intent 経由で呼びだそうと思ったらうまくいかなかったので、モジュールを書いた経験があります。

https://github.com/mumumu/Titanium-Android-VoiceRecognition

また、出来ることと出来ないことについての限界を知る目的でも、上で述べた KitchenSink は大変役に立ちます。骨の髄までしゃぶりつくしましょう。

3. iOS 向けの対応ハードはきちんと吟味する

これは Titanium に限ったことではありませんが、iOS 向けの場合は、必要な機能によっては使えるハードが限られてしまうので、iPhone や iPod、 iPad のどの世代から使えるのか、設計および実装時にきちんと吟味しておきましょう。

iTunesConnect Developer Guide にハードごとの機能互換性が表になっています。

http://developer.apple.com/library/ios/#documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/B_DeviceCompatibilityMatrix/DeviceCompatibilityMatrix.html#//apple_ref/doc/uid/TP40011225-CH17-SW1

最近はそれぞれに世代も進んできたので、差は小さくなっているのかもしれませんが。
自分の場合はカメラのオートフォーカスが弱いことが理由で一部機能が iPod Touch や iPad で使えなかったりした経験があります。

4. Webサイトが既にあり、組込む予定がある場合は、Webサイトとアプリでやることをはじめに切り分ける

アプリから組み込みブラウザでスマホサイトを呼び出せますが、組み込みブラウザのパフォーマンスはそんなに期待できません。WebView にモバイルサイトを表示させれば全て快適に動くなんていうハッピーな世界は期待してはいけません。特に3G では通信速度の問題もありますし、一気に張れるコネクションの数がそんなに多くないからです。LTE ではまた違うかもなのですが。

ハードの機能が必要な部分のみアプリで、という思考に行きがちですが、その点は以下のような態度がよいのではないかと思いました。

スピードが必要な部分ではアプリで。それで面倒な仕組みのみ、スマホサイトに任せる方式が現実的

5. アプリから組み込みブラウザ(WebView) を用いて、Webサイトを呼び出すときの注意

上で述べた通り、組み込みブラウザのパフォーマンスはそんなによくありませんし、自分がアプリを作ったときは 3G の通信ではかなり遅く感じました。なので、以下のような流儀が役に立ちました。

　・できうる限り通信の本数は最小にする

　　１本あたりの通信がとても重いです。そのため、以下の流儀が役に立ちます。

　　　a) 小さなモバイル向けの画像については、data スキームを大いに活用しましょう。
　　　b) CSS や JS も可能な限りHTML内部に収めましょう
　　　c) jQuery Mobile はダウンロード・実行ともにとても重かったのでキャッシュが効
　　　　 かない iOS 向けではminifyした上でアプリ内部に納め、ページロード後にeval
　　　　 させるという荒業を使った経験があります。

　・テキストのコンテンツは gzip 圧縮する

　　　やむを得ず js, css などをダウンロードさせざるを得ない場合は、必ず圧縮して転
　　　送しましょう。jsonも当然対象です。

「HTML5 Web アプリケーションのつくりかた」というエントリもとても参考になります。
----

まとめ

なんだか基本的なことばっかりのような気もしますが、Titanium は Android が特に罠が多いように思います。それぞれのプラットフォームの特徴を見極めながら作るのは経験も必要だとは思いますけど、予備知識がそれなりにあれば大分違うよね、という思いでまとめてみました。何かのお役に立てれば幸いです。

では明日の担当 @h5y1m141 さんにバトンタッチします！ よろしくお願いします。

Dirty code is allowed?

http://kyuns.hatenablog.com/entry/2012/11/30/143037

汚いコードでいいから云々は基本的に「経営者の論理」なんだけど、そういう経営者の論理と折り合いをつけつつうまくエンジニアリングを引っ張っていくのがCTOの役目だと自分は思う。そういう意味で上記の筆者は非常に良心的だ。

こういうしっかりしたCTOがいる会社はまだ良くて、「経営者の論理」に抗し切れない、またはそれに抗しきれなかったコードがひとたび書かれてしまうと、それがずるずると引きずられ、メンテするエンジニアが泣くハメになる。それはいつしかその会社のエンジニアリングの文化になり、それを変えることは容易ではない環境になる。
 
だから「はじめが肝心なのだ」なんていうつもりは毛頭ない。重要なのは、そうした文化があってもチャンスを見つけてそれを少しでも突破しようと意識することだ。それには、自分が動かなければ始まらない。と自戒を込めて思う。そして、上記のエントリにも書かれている、以下の目的を見失わないようにすることが重要だなとおもいます。まる。

----
 
「よりよい実装をすることによって開発の効率化を進め、開発サイクルを早めてより素早くプロダクトをリリースし、最終的にユーザーに満足してもらうことが目的である。」

Goma-tarou And Fox-zirou

http://ja.wikipedia.org/wiki/%E3%81%97%E3%82%8D%E3%81%9F%E3%82%93

我が家には10年以上置いてあるぬいぐるみがある。いわゆるしろたん（タテゴトアザラシ) のぬいぐるみである。相方がどっかから買ってきて抱き枕として使用していたものの、結婚してからはソファーの上に鎮座している。

昔は「ごまごまん」と呼んでいたのだが、最近は「ゴマ太郎」と呼ぶようになった。見た目が素直でとてもよろしい。尚、このしろたん関連グッズが我が家には至る所にあり、枕や置物など様々な用途に活用されている。

ちゃんと調べてみて、これがオリジナルキャラだというのをはじめて知った(´ー｀；)
 
----

http://foxkeh.jp/

昨日そのゴマ太郎に加えて、Mozilla Firefox の「フォクスケ」が やってきた。Android 版 Firefox のキャンペーンがあり、それに応募して当てたものだ。うちにアザラシ以外のぬいぐるみが来ることは極めて珍しいので「フォク次郎」という名前を早速つけた。相方からも尻尾のモフモフ具合がよいと好評である。

ひょんな縁でやってきた新しいぬいぐるみ。我が家もよりにぎやかになりそうである(*´～｀)

[memo] blogger android app enhanced

常用している Blogger の Android公式アプリにちょっと不満がある。ある意味ニッチな不満なので久々にアプリを書いてみるか、と思いつつ不満に思っていることをメモ。

----

1. 投稿日時をコントロールできるようにしたい
2. あるエントリを複製して新しいエントリを起こしたい
3. ラベルを過去に投稿したものから選択できるようにしたい
4. 特定のエントリをアプリからWebViewを経由せずにオフラインで見られるようにしたい
5. 上記をラベルで絞ってみたい

Returns kindle 4th generation(2)

http://d.hatena.ne.jp/s-fridge/20101124/1290604325

以前返品した Amazon Kindle 第4世代が何の理由もなく戻ってきたよ( ;´Д⊂ヽ

日本の業者ってリチウム電池を運ぶのにいろいろとあるらしく、Amazon.comに直でメールしたらUPS経由で返すように案内されますた。

けど、配送料を調べたら普通に5k超えることがわかったので大人しく他の方にお譲りすることにしました。。上の id:s-fridge さんは 9000円したとか。よく返品する気になったなあ、、と。

----

ということで、新品の Kindle第4世代(Wifi版、広告なし)を欲しい方コメントよろですー。5000円でこうちくれると嬉しいのです(´ー｀; )

Returns kindle 4th generation

第4世代の Amazon Kindle International 版を買ったが、返品することにした。

Amazon Kindle はこのエントリを書いている現在、第4世代が発売されている。だが、よりによって明日から Kindle PaperWhite が発売されるわ、1週間前には十分電子書籍リーダーとして使えそうな Nexus 7 が発売されるわで、この時期に第4世代の Kindle を定価で買うのは明らかに負け組であることに気付いた。

よって、Kindle は返品して様子を見ることにした。Amazon.com の返品は面倒な感じがしたのだが、以下の手順を踏めば簡単だ。

[ Update October 12th 19:32 JST by m ]

... てな具合で以下には返品手順を馬鹿正直に写真付きで以前は書いていたのだが、この手順にそって郵便局から発送したところ、無言で送り返されてきてしまった。リチウム電池を日本の運送業者が扱うのはアレでソレなことが原因らしい。

よってここに載せていた手順は削除しました。ごめんなさい(´ー｀; )

HTML5, gzip deflate

皆様、スマホサイトを構成する時は、HTML5テキストそのものを gzip するのを忘れないようにしましょう。僕は忘れていました。。

CSSのリクエストを減らす代わりにHTMLに埋め込んでいる場合は尚更です。

なぜ Apache 2.2 で以下のようなトチ狂った設定をしていたのか未だに理解できない。
要するに、static なリソースで縛って満足していた、と(´ー｀; )

<Location /smartphone_static_resource>
  SetOutputFilter DEFLATE
  AddOutputFilterByType DEFLATE text/html text/css application/x-javascript
  # ...
</Location>

----

スマホアプリと連携する HTML5サイトの高速化のキモってどこもやっていることは基本同じだなーと最近思う次第。

1. data:url や ファイル統合等を駆使してリクエスト数を減らす
2. minify, gzip 等を駆使して転送量を減らす
3. キャッシュできる処理はキャッシュさせる
4. ハード側に多くをやらせない

1. の リクエスト数って大したことないじゃんって思うかもですけど、3G回線とかでは結構効いてくると思います。

4. についてはそう心配することはないのかもしれない。自分は HTML5 や JS でゲームを作ったことがないのでそこらへんノウハウがあれなんですけど、jquery-mobile を採用したサイトとかをふるーい Android 端末とかで動かすとやっぱり描画が遅いので、変に複雑な処理は書かないようにしています（んなこたーねーよって思ったらコメント希望）。

以下を読んで、ああやっぱ同じですよねー。デスヨネーってな感じでした。

「HTML5 Web Application のつくりかた」
http://ameblo.jp/ca-1pixel/entry-11009598050.html

XP-matruri 2012

http://xpjug.com/xp2012/

9月15日(※1)にXP祭り2012に行ってきた。

----

なんとか現場にTDDとか自動ビルドだけでも取り入れてほしいなーって思っていて、そこらへんのヒントを探りに行こっかなーとか、最近イベントに行ってないなーっていうのが動機になって明らかにアウェーなカンファレンスに顔を出してみた次第。

「XXというプラクティスを現場で使いたいんだけど、現状に満足している連中ばかりで何も動きません」云々という話題はアジャイル界隈では定番らしく、そういう話題が最初のラウンドテーブルでもやはり出た。薄々感じてはいたが、やっぱり『自分が動かないことには何も変わらない』、という結論は自分の状況(※2）と一致した。このイベントの中の様々な講演やLTの中でもこの話は出てきたくらい重要な話(※3)である。

動いた成果をうまく見せつける策が重要だと思う。「仲間も必要」という話も確かに同意はするけど、それだけに逃げてはダメな気がする。

----

あと、Scrum のざっくりとしたイメージをワークショップで持つことが出来たのがとても大きな収穫だった。この世界でプラクティスを自分一人でやってみることを「素振り」というらしいが、これを素振りしようと思っても、TDDや自動ビルド、CIとかと違ってチームが前提のプラクティスなのでどうかなーと思いつつ考えてやってみるかーとか思った。

----

LT では SonicGarden さんのビデオレターがとてもよろしゅうございました。マワシモノではないけれども、とても個人的には勇気をもらえたのでこちらに貼っておきますね。



----

あと、最近イベントまわりについてアウトプットできていなかったので、XP祭りのメディアスポンサーである ManasLink さんが募集していた「公式レポーター(※4)」に応募し、イベントの参加レポートを書くコミットをしてきた。dropbox には既にレポートを置いてあるのだが、掲載が遅れているらしい。今週末には多分掲載されるだろう。

[ Update September 24th 2012 18:50 JST by m ]

ManasLink さんのところにレポートが掲載されたようだ。

----

(※1) つか、ぺちこん や PyCon となんで被ってるんだYO!
(※2) この世界では「コンテキスト」というようだ
(※3) 常識ジャンとか苛めないでください
(※4) 公式レポーターの制度に意味があるのかはちょっとわからない感じ。ただ、自分の中ではアウトプットに確実にコミットできるので応募した次第

Livedoor DataHotel Patrol

https://patrol.datahotel.ne.jp/index.html

前のエントリで書いた スマホで監視 というのはあくまで簡易のお遊びなんだけど、やっぱりメール飛んできて欲しいよね的なところもある。そこで NHN傘下のデータホテルがやっている上記を登録してみた。

使い方ガイドにもある通り、少し細かいところでもWebインターフェイスから面倒見てくれる。SSLの更新切れとか、名前解決のチェックもしてくれたり。

まぁ id:shimooka さんの言うとおり、携帯じゃあ悲しいよね的な。それだけなんです、、が！ まぁ別のツールも遊んでみるつもり。

Server monitor for Android

https://play.google.com/store/apps/details?id=net.spc.app.svrmon

TCP, http, ECHO で携帯電話から簡易的なサーバ監視が出来るのが上記の Server Monitor だ。以前から監視したいなーけど別回線のためにお金出すのもなーとか思っていたら、Android アプリ作れば（使えば）いいよね、ということで上記に行き着いた。


家の自宅サーバの回線が切れたかどうかを監視する仕組みとしては、別の回線から普通にpingやプロトコルに応じたリクエストを出せばいい。

その別の回線というのが自分の場合は Air"H だったり、e-mobile だったりしたわけだが、そのリクエストを出すアプリケーションを携帯に載せるのが容易ではなかったし、自分にはその力がなかった。というか、そういうことを思いつかなかったと言った方が正しい。

今の会社に転職して nagios のアラートに追われる身となり、そういう監視ツールが身近になったことと、Android というオープンで非常に与しやすいプラットフォームが e-mobile でも手に入りやすくなったことから、そういうリクエストを出すツールも手に入りやすくなった。自分で作ろうかなと思ったが、やっぱり同じことを考える人はいるものだ。

Onsen

温泉に行ってきた。相方と過ごしながらいろいろ考えることもあったのだけど、何より結婚して以降なにも相方にしてやれなかった部分を少しは埋めることができたのであれば嬉しいな、と。

ギーク的な観点からは「おもてなし」はいらないかな、と思いました。あと、部屋に露天風呂があるとヒキコモリ度が上り過ぎて困る感じです。

まぁ、「アルゴリズムを学ぼう」や「チェンジ・マネジメント3.0」等、数冊の本をを読み進めたことが収穫だろうか。

社会復帰できるかどうかが心配だ(´ー｀; )

tibar image ovarlay patch

http://code.google.com/p/tibar/

iPhone でバーコードを読ませたいと思ったとき、いくつかライブラリはあったりするが、読み取り精度やコードの安定性とかを見たところ、ZBar SDK が一番良いと感じた。これを Titanium Mobile から使うモジュールが tibar である。

tibar のサイトや、日本語の情報を見ていると、Titanium Mobile 1.4 から 1.8 あたりまでしか動作事例がみあたらなかったのだが、最新の svn コードを試した限り、2.0.1GA2 でのビルドと動作は少なくとも確認できた。

1. 以下のコマンドで最新コードをチェックアウトする

svn checkout http://tibar.googlecode.com/svn/trunk/ tibar-read-only

2. titanium.xcconfig のバージョン指定を、使用している Titanium Mobile のバージョンに置き換える
===================================================================
--- titanium.xcconfig   (リビジョン 17)
+++ titanium.xcconfig   (作業コピー)
@@ -4,9 +4,8 @@
 // OF YOUR TITANIUM SDK YOU'RE BUILDING FOR
 //
 //
-TITANIUM_SDK_VERSION = 1.5.1
+TITANIUM_SDK_VERSION = 2.0.1.GA2

3. build.py を実行

一応上記でビルドでき、組み込んだら動いたのだが、画像を以下のようにカメラの表示にオーバーレイさせたいと思ったときに、公開されているコードだとうまくいかなかった。

patch が貼られていたりしたものを試したのだがそれもうまくいかなかったので、自分で以下のような patch を書いた。設定されるオブジェクトが ImageView であることを前提にしているので、画像以外のオーバーレイ用途にはうまくいかない。それに overlay キーが設定されていないと問答無用でエラーにしているので、その点もとても汎用的とは言えないだろう。使用は自己責任で。

RapidSSL

http://www.rapid-ssl.jp/

SSLサーバ証明書は自分で設定したいと思っていたが、以前は値段が高くてなかなか手が出せなかったものだ。ところが最近は1年で数千円とかめちゃくちゃ安く、とりあえず遊ぶ程度でも十分に手が届く。しかも審査の内容は本当にSSL証明書を申請する人が、ドメインを持っているか、という審査のみ。自前でドメインを登録している人ならお手軽だ。

そこで、お手軽SSL認証局のひとつである RapidSSL でちょっと遊んでみた。以下は Debian Squeeze で実行している。

まずは認証局への署名要求(CSR) を生成する。そのための秘密鍵(server.key)を生成する
RapidSSL は2048bit以上の秘密鍵を要求するため、最後のオプションでその値を指定している。

$ openssl genrsa -des3 -out server.key 2048

次に秘密鍵をもとに署名要求(CSR) を生成する。

$ openssl req -new -key server.key -out server.csr


















ここで注意すべきなのは、CSRを生成するにあたって入力する情報は、SSL設定を行うドメインの管理情報と基本的に一致させておかなければならないということだ。つまり、ドメインの whois 情報と一致するようにすること、ということだ。少なくとも以下の情報は一致させておく必要がある。


Country Name
State or Province Name (full name)
Locality Name (eg, city)
Organization Name (eg, company)


また、SSLを設定したい FQDN を Common Name に指定し、Email Address にはドメインの登録者 Emailアドレスを設定すればよい。Emailアドレス は他にも指定できるが、多分これが一番やりやすい。「a challenge password」や「An optional company name」は空にしておく。

whois情報を隠すサービスってのが最近はあって、レジストラの情報でwhois情報が置き換わっているドメインが存在するが、そういうサービスは外した上で正しい情報を登録した方がよい。

----

CSR を生成したら、申し込みフォームから上記で生成したCSRを貼り付けて必要事項を記入してSubmitすると、CSR生成時に指定した Emailアドレス に「【重要】 SSLサーバ証明書発行承認のお願い」というメールが送られてくる。そのURLをクリックすると、以下のようなドメイン証明画面がブラウザで開く。

ここで「承認します」ボタンを押せば、RapidSSL から サーバ証明書と中間証明書が送られてくる。これだけで手続き完了。15分くらいしかかかっていない。whois情報さえちゃんとしていればお手軽だということがわかる。

----

あとはサーバ証明書と中間証明書をサーバにインストールするだけだ。Apache + mod_ssl なら一般的な手順は以下の通りとなる。

https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&actp=CROSSLINK&id=SO6252

要するに、Apache の SSL 設定に以下を設定するだけだ。


SSLCertificateFile    -> 発行されたサーバ証明書
SSLCertificateKeyFile -> opensslコマンドで一番はじめに作った秘密鍵
SSLCertificateChainFile -> 発行された中間証明書


あとは、Debian 特有の注意点がある。デフォルトでインストールされる SSLサイトの設定ファイル /etc/apache2/sites-available/default-ssl だが、これをそのまま使うと 「Invalid method in request \x16\x03\x01」というエラーが出てSSLリクエストを受け付けてくれなかった。これについては多数の事例が報告されていて、バーチャルホストの設定が _default_:443 だとまずいらしい。自分はこの部分をIPアドレスまたはワイルドカードに置き換えるとうまくSSLリクエストを受け付けてくれるようになった。







[ Update January 17th 2013 11:09 by mumumu ]

サーバの秘密鍵(server.key)を作成したときにパスフレーズを設定するが、これを解除しておかないとサーバを再起動した時にパスフレーズを聞かれて処理が止まってしまう。パスフレーズを解除するには、以下のコマンドを使う

openssl rsa -in server.key -out server.key

複数証明書がある場合は、Apache の SSLPassPhraseDialog 設定を使うのも手かもしれない。

Blog Template changed

ちと悪趣味で見にくかった以前のブログテンプレートを、気分転換も兼ねて明るいものに変えてみた。昨日から10連休に入っており、いろいろ考えたり作業したり旅行したりな感じ。

ただ、手を動かすのはやめないでおこう、と。この更新もその一環である(*´〜｀)

Problem driven enginnering?

「少しでも楽をしたいから自動化したい。自動で信頼出来ることをしたい。そうすれば効率があがるよ」という思考は、「問題点がなければ何もしないでいいじゃん？」という問題ドリブンの考え方と対立するものだ。それは自己満足だ。コストがかかる（そりゃバランスも重要）と言われようと、問題がなければ何もしない、では進歩は望めないし、何より俺たちエンジニアは楽になれない。周囲の文化がなんであれ、『楽をするため』に向上心を持ち続けることは忘れないでいようと思う。

・・・と考えていくと「楽をしていないことが問題だ」という問題意識があると気付かされる。結局問題ドリブンに戻るわけだな。タハハ(´ー｀；)

meshi-only blog

http://mumumu-meshi.blogspot.jp/

思うところがあり、飯専用ブログを作った。
要するに太ったんでダイエットしますってことですよいわせんなよ恥ずかしい！( ;´Д⊂ヽ

Titanium Module for Voice Recognition on Android

https://github.com/mumumu/Titanium-Android-VoiceRecognition

お久しぶりです。最近 Titanium Mobile を触っていて、Android へのかゆいところへの手の届かなさにムズムズしている mumumu です。

Android は 1.5 から 音声認識の機能にアクセスできるAPIを備えていて、Intent に情報を詰めてビルトインの Activity を起動すればいとも簡単に音声認識の結果が得られる。ならば Titanium でも簡単でしょう。と思って以下のコードを書いた。


上記のコードでも、Android 2.x 系で Ti.Android.currentActivity.startActivityForResult の結果が返ってこないので困った。3.x 系では返ってくるので不思議不思議。どうせ Titanium は getStringArrayListExtra による Intent からの結果取得に対応していないので、モジュールはどうせ書かねばならない。

よって、Titanium の JavaScript から Activity を起動するのではなくて、 Java 側で 「音声認識 -> 結果取得 -> 結果を戻す」 というモジュールを書いた。それが上のリンクである。

これを使えば以下のようなそれっぽいコードで Android 2 系でも 3系でも結果が取得できた。




実装の肝は、 Android ビルトインの Activity を起動する VoiceRecognitionProxy.java である。本当は Activity#startActivityResult で ビルトインのActivityの起動と動作結果取得を同時に行うのが筋であるが、呼び出し元の Activity が Titanium 側の初期化済みアクティビィティなので onActicityResult で結果が取得できない。なので、Titanium 側のアクティビティと呼び出し側のビルトインアクティビィティは Handler を包む Messenge と それを Intent で運ぶ Messenger を使って結ぶやり方を採っている。

正直迂回コードである。気持ち悪い。Titanium の startActivityForResult がちゃんと動いてくれればこんなモジュールはいらないのだが。。(´ー｀; )

Nexus Prime = Galaxy Nexus

http://www.datacider.com/11749.php

ICS が載った Google の次期（もうcurrentだけど)Android機のリファレンス名が「Nexus Prime」
それをコンシューマー向けに製品化したのが Samusung の Galaxy Nexus。

俺の携帯って Prime なんだぜ、とのたまっているお友達がいたので何かと思ったら上記のよう
にただの Alias 関係だった。

＃個人的には Prime って数学的な意味以外では厨二っぽいなって思う。