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 さんにバトンタッチします！ よろしくお願いします。

[memo] Livedoor Technical Seminar #5

http://blog.livedoor.jp/techblog/archives/65434269.html

昨日ライブドア主催の技術セミナーに行ってきた。遅刻してしまったので途中からではあるが以下にSummaryのメモを置いておく。自分のための超適当メモなんで、詳細はのちに公開されるであろう動画をちゃんと見てくださいね（はぁと

ソーシャルアプリは参入障壁が低いなりにちゃんと考えて作らないといけないんだなということと、スピード感と新技術の採用という部分のバランスが重要なんだなと勝手に思いました。まる。

****

- HTML5 でFlash Playerを作ってみた(途中から）

- SVG
-- 描画速度が遅いのが問題
-- 最適化することがプログラムから指示しずらい
-- 2fps -> 8fps だったが断念 (iPhone 3GSの環境)

-- canvas をキャッシュ
--- ラビン／カーブ検索 で描画した配列の一致した部分のみをキャッシュする
--- 15 fps

****

- 新進気鋭のSAPに聞いたソーシャルアプリ現場事情

1. 登壇者について

- 株式会社オルトプラス 石井さん
(ブラウザ三国志の製作を指揮。現在はダービーズキングの伝説というゲームをグリーでリリース)

2. ダービーズキングの伝説 について

- ダービーズキングの伝説は登録者数100万人突破、アクティブユーザーが10万人
-- オンラインゲーム登録者数　-> 10000〜15000が相場
-- ソーシャルゲームの登録者数、アクティブユーザー数は右肩上がりののち、下がる一方なのが普通だが、ダービーズキングの伝説は右肩上がりを維持している
-- 小さく産んで大きく育てる
--- やめられないようにするためには、比較的課金を早いタイミングでやって、タイトルを覚えてもらうこと。これはゲームタイトルがどんどん出てくるので、スイッチングコストが低いから。
--- PC市場に比べてモバイル（ガラケー)は課金障壁が非常に低い
--- 一方でPCに比べて伝えられる情報が非常に少ない。検索してたどり着くよりはバイラルで広まることが前提になる。友達が始めたから始めた、的なやり方が多い。10万〜20万くらいの人数があればバイラルが聞くが、そこまでいけるかどうかが成功するまでの一つの壁

3. 開発コストについて

- 開発コストの点でいくと、十数人の人数が6ヶ月動いた＞ブラウザ三国志。
- ダービーズキングの伝説は4名で1ヶ月-> 開発コストはかなり安い ファミコン時代に似た感じ。当たれば大きい。- コンソールゲーム(ゲーム機用に製作されたゲーム）は桁がひとつか二つくらい開発費が上になる

4. なぜ競馬ゲームなのか？

- なぜ競馬ゲームかというと、外国等で既にあるものを日本に持ってくるのはやめようと考えたから。日本のよさが出せるものを。

5. ガラケーとスマートフォンの違いは？

- ガラケー -> flash lite 1.1 -> 枯れている
- Android -> ユーザに若い男性が比較的多い
--作って見ないと判らない部分がある
-- 端末依存が大きい
-- 移植に手間がかかることがある
- iOS (ダービーズキングの伝説はまだ未対応）
-- 一度覚えれば作法が一つなので一度覚えてしまえばやりやすい。-> ユーザに若い女性が比較的多い
-- iOS については、4割がユーザに占めていて、lostしている状況 -> 是非人を採用したい

*****

- GREEのスマートフォンアプリ開発の現在（伊藤直也さん）

1. スマートフォンビジネスのトレンド

- 今年の年末はスマフォ向けでもクアッドコアで2GHz超え -> 性能がどんどんあがっていく
- 1億スマートフォン (9200万PCを超えた)
- PC利用時間は -20%
- 世界的にスマフォの普及スピードは凄く早い
-- 日本国内では2年後には6000万台を契約ベースで超える予想がある。その2年後にはiOSでなくてAndroidがその半分以上を占める予想もある
- スマフォ需要により3年ぶりに出荷台数がプラス
-- スマフォによりデータARPUが上昇するから
- 女性向けへのマーケも活発

2. スマートフォンアクティビィティの実際

- すべての時間のうち、電話、Webサーフィンが半分
- 残りはアプリ、ゲーム -> アプリ開発者には有利な状況
- コンソールゲーム市場は後退している
- ソーシャルゲームの売上は右肩上がり -> シリコンバレーでもソーシャルゲームバトル
- Facebook Mobile -> 現在アクティブユーザ2億人(2年間で4倍に増加)
- Twitter -> アクティブユーザの半分がモバイルアクセス、新規ユーザーの16%がモバイルから
- アプリ内課金が本格化(android, iphoneともに)
-- 急成長。50%が In App. 有料DLからIn-App課金へ
-- Android が 既に iPhoneを超え始めている Android 2.1, 2.2 が支配的

3. NFC(Near Field Communication)

- Android 2.3で対応。iPhone 5, iPad 2にも搭載か
-- taglet というサービス -> Android 2.3 +NFCによる情報共有サービス。taglet で mixiチェックイン

4. GREEのスマートフォン開発

- HTML5 and CSS3 and Javascript
-- Webkit ベースブラウザ、新技術を積極的に採用できる
-- ローカルセキュリティの関係で、カメラ等に直接アクセスできない
-- HTML5 + css + javascript だけでできないことをネイティブが補うというアーキテクチャ
-- UIの拡張の方もアプリで

- アーキテクチャ比較
-- HTML5
-- ネイティブ
-- JSミドルウェア(Titanium等) =>　動的更新の点で難あり
-- ハイブリッド -> HTML5 and CSS3 + javascript + ネイティブ

※ Javascript で アニメーション GIFを再生するのに悩む -> dataスキームでgifデータを連続して送り、settimeoutで再生していくライブラリを作った

5. クロスモバイルプラットフォーム開発のトレンド

- 急発展の最中
- まだデファクトは決まらず
- 長期的には HTML5へ。短期的にはネイティブアプリ

- ミドルウェア

-- Titanium mobile, 開発例：MogSnap
--- JSで書いたものがネイティブアプリになる
--- iPhoneはよくできているが、Android向けはまだまだ発展途上

-- PhoneGap
--- ハイブリッドモデル(HTML5 + native)のアプリを作るためのフレームワーク
--- 中身がWebViewでよければこれ

-- Unreal Engine -> 3Dゲーム開発ミドルウェアの大御所
--- C, C++, Android はこれから

-- Corona SDK
--- Lua で 2D開発。ActionScriptライクに開発

-- Airplay SDK
--- C/C++ で write once -> Android, iPhone, コンソールゲーム機もサポート

-- Unity : Game Development Tool
--- JavaScript, C#, Lua etc で 3D可いつ。ActionScript用に。
--- これが本命？ スマフォの世界で台頭してくると思われる
--- True Multiple Development

- HTML5 Webアプリフレームワーク
-- jQuery Mobile
-- Sencha Touch
-- JQTouch

6. まとめ

スマートフォン&Androidはじまったな
-> GREEもフィーチャーフォンからスマートフォンへ
Mobile = Global

海外では3Gの回線普及率がまだまだなので、回線がつながっている前提で
作るとおかしなことになる。-> Nativeアプリ中心。通信が必要になったときだけ通信する
--> 速い回線が整えばHTML5で作っていくモデルがはやっていくのではないか

mod_rewrite and MultiViews

http://www.fya.jp/blog/2007/09/14/mod_rewritemultiviews/
http://httpd.apache.org/docs/2.2/content-negotiation.html

Apache には mod_rewrite というリクエストを内部で自在に書き換えるための黒魔術が備わっており、それをWebアプリケーションフレームワークでREST風なURLを解釈させるために以下のように使うのは、割とPHPな世界では普通に行われていることである。

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]

これはファイルが存在してサイズが0以上のリクエストに対してはそのままリクエストを実行。そうでなければ index.php を頭につけるようにURLを書き換えている。

こうしたやり方に対して、Options MultiViews は相性が悪い場合がある。特に 同じプレフィックスのファイルが複数存在した場合がタチが悪い。

MultiViews 機能は、拡張子が表記されていないリクエストがあった場合に、それが仮に存在しない場合は拡張子ありの同じファイルを自動的に探してくれる機能である。たとえば http://example.com/hoge がリクエストされた場合に、MultiViews がドキュメントルートで有効だと hoge.txt や hoge.html 等から適当に選んでレスポンスを返してくれる。

----

ちょっと複雑だが、ここで俺がハマった mod_rewrite と MultiViews の相性でハマった例を記す。

A) ドキュメントルートで MultiViews が有効
B) 上記のような RewriteRule を設定している
C) index.php と index.html がドキュメントルートに存在する
D) この状態で、/index/search をリクエストした場合

この状態で /index/search のレスポンスが 404 だったのでびっくらこいた。本当は、index.php/search となって、フレームワーク側で PATH_INFO を解釈してほしいのに。

起こっていたことは以下のとおりである。

1. MultiViews によって、/index/search を index.html/search とApacheがみなす
2. index.html/search に RewriteRule が適用される
3. index.html が存在するので、Pass Through され、そのまま index.html/search へのリクエストとみなされる
4. index.html/search は存在しないので 404 になる

何のことだかわからないかもしれないが、要するに、Options MultiViews は意味もわからず有効にしない。そして、mod_rewrite と混ぜる場合は注意、ということである。

search via google on Konvi

https://bugs.kde.org/show_bug.cgi?id=229589

I want this feature to be added, anyone working on this?

----

この機能は Limechat にはまさに搭載されている。誰もやってなかったらこれは是非俺がやりたいところだ。

[ Update October 7th 18:56 JST by m ]

「That's already implemented in the development version and will be available for the next release: http://bit.ly/dvDMjj 」とのこと。流石 Hein。仕事が早いべ（わら

[memo] make is NOT always GNU make

http://www.freebsd.org/cgi/man.cgi?query=make&sektion=1

当たり前のことではあるが、makeコマンドで実行される make が必ず GNU Make とは限らない。FreeBSD における make は BSD make であり、GNU make は gmake コマンドである。

Linux, Mac OS X においては、make は GNU make と見て差し支えない。Mac OS X での BSD make は bsdmake である。くれぐれも GNU脳にならないように＞自分

Solaris とかだとどうなるんだろうね。

----

※GNU脳になってしまっていてよくひっかかる別のコマンドとしては、tar コマンドや cp コマンドが挙げられる。特に後者は Mac OS X の cp に -a オプションがないことに驚愕した苦い思い出がある。

git(2) - from sourceforge.jp SVN

http://iteman.jp/blog/2009/02/subversiongit-stagehand-testru.html
http://ml.ethna.jp/pipermail/users/2009-June/001138.html

Ethna のソースコードリポジトリを subversion から git に移行した。subversion から git への移行は git-svn を使うのが定番のようになっているが、以下のコマンドを使っても git-svn は指定されたディレクトリ以下のディレクトリ名をブランチにするだけで、tag をうまく扱ってくれなかった

$ git svn clone -T trunk -t tags -b branches svn+ssh://...

このコマンドの実行結果は以下のようになる。タグもブランチとして扱われている

$ git branch -r
* master
  ETHNA_2_1_1
  ETHNA_2_3
  ETHNA_DBLAYER_UNITE_BRANCH
  ....
  tags/ETHNA_2_1_0
  tags/ETHNA_2_3_0

----

これでは話にならないので、svn2git を使った。はじめ gem でインストールしても svn2git が command not found になったので焦ったが、/var/lib/gems/1.8/bin 以下に見つかったので、それを直接実行したところうまくいった

$ gem sources -a http://gems.github.com
$ gem install nirvdrum-svn2git
$ /var/lib/gems/1.8/bin/svn2git http://svn.sourceforge.jp/svnroot/ethna/ethna/ \
--verbose --trunk trunk --branches branches --tags tags

実行中の出力は git-svn と変化ないように見えるが、結果の違いは歴然としている

$ cd ethna
$ git tag -l
 ETHNA_2_1_0
 ETHNA_2_3_0
 ETHNA_2_3_2
  ....
$ git branch -r
 ETHNA_2_1_1
 ETHNA_2_3
 ETHNA_LEGACY_EUCJP_BRANCH

ここまで出来れば、remote を登録してすべてを移行するだけである。

$ git remote add origin USERNAME@git.sourceforge.jp:/gitroot/ethna/ethna.git
$ git push --all
$ git push --tags

----

なお、最初のリンクにも示しているが、本エントリはitemanさんが書いたものをほぼそのまま実行しただけである。元エントリを書いたitemanさんには深く感謝申し上げる次第である。

Ethna 2.5.0 preview4, 2.3.7 announced

http://ml.ethna.jp/pipermail/users/2009-June/001130.html

昨夜メールをひょっと見るとセキュリティバグの報告があがっていて正直寝耳に水であった。ちょっくらテストしてみると見事に開発版、安定版ともに再現してしまった。PHPの配列のキーが入力になっていたことに皆気付いてなかったということで、完全にヤラレタとしかいいようがない。

セキュリティリリースは本来秘密裏に修正し、リリースするまでその内容はバージョン管理システムにさえ一切公にしないというのが通常だろうが、そのための窓口が Ethnaプロジェクト にはなかった。結果として full-disclosure の形になってしまい、リリースを急ぐことになった。リリース作業は意外に面倒な部分が多いのだが、今回は普段の4倍疲れた。俺自分に乙。

----

とはいえ、今週末には 開発版の次のリリースが控えている。もうひと踏ん張りである。

undefined reference(3)

もうこのネタやめにしたいんだけど、一応メモしておく。なんでクラス名忘れるかね。これはひどいとしか言いようがない。原因がわかるまでにかかった時間は2分くらい。

---- test.h ----
#ifndef __TEST_H__
#define __TEST_H__

class A {
public:
    static void hoge();
};

#endif  // end of __TEST_H__

---- test.cpp ----

#include "test.h"

void hoge() {
    return;
}

---- main.cpp ----

#include "test.h"

int main(int argc, char* argv[])
{
    A::hoge();
    return 0;
} 

以下の実行結果は最早おなじみである。

$ g++ main.cpp test.cpp
/tmp/ccSUS3Oq.o: In function `main':
main.cpp:(.text+0x12): undefined reference to `A::hoge()'
collect2: ld はステータス 1 で終了しました

undefined reference(2)

前のエントリで書き忘れていたので追記しておく。メソッドの実装忘れも俺的にはよくある。たとえば以下のようなコードである。宣言して満足しちゃった、的なアレである。

--- test.cpp ---

#include <iostream>

class A {

public:
   //    default constructor.
   //    not implemented.
   A();

   void helloworld()
   {
       std::cout << "Hello World!" << std::endl;
   }
};

int main(int argc, char *argv[])
{
    A a;
    a.helloworld();
}

上記をコンパイルすると、下記のようになる。実装がないので、リンカから見えない。以下の結果は当然の帰結である。

$ g++ test.cpp
/tmp/ccIVHTVA.o: In function `main':
a.cpp:(.text+0x74): undefined reference to `A::A()'
collect2: ld はステータス 1 で終了しました

C++ namespace -> undefined reference to 'main'

C++ の namespace は重要なキーワードであるが、うっかり main 関数のようなグローバルな関数をそれで囲んでしまうと大変なことになる。マングリングによってラベルが変化し、自分が意図した通りにリンカから見えなくなるからである。

namespace はスコープを変えるんだというごく当たり前のことがことがわかっていればこんなことは多分普通やらないんだと思います。多分。ただ、そういう理屈もわかっていない初心者とか、以下のような多段 namespace のマクロを全ファイルに適用するのが癖になっている人とかは要注意である。

--- test.h ---

#ifndef __TEST_H__

#define __MUMUMU_NAMESPACE_NAME__ mumumu
#define __AHO_NAMESPACE_NAME__ aho

//
//  namespace macro
//
#define __HOGE_NAMESPACE_START__ \
    namespace __MUMUMU_NAMESPACE_NAME__ { \
        namespace __AHO_NAMESPACE_NAME__ {
#define __HOGE_NAMESPACE_END__ } }

#endif // end of __TEST_H__

--- test.cpp ---

#include "test.h"

__HOGE_NAMESPACE_START__

int main(int argc, char *argv[]) {
    return 0;
}

__HOGE_NAMESPACE_END__

上記の test.cpp をコンパイルすると、以下のようになる。

$ g++ test.cpp
/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crt1.o: In function `_start':
/build/buildd/glibc-2.9/csu/../sysdeps/i386/elf/start.S:115: undefined reference 
to `main'
collect2: ld はステータス 1 で終了しました

test.cpp を コンパイルし、main の text セクションのみをダンプすると以下のようになる。namespace の情報がラベルに付加されていることがわかる。

$ g++ -c test.cpp
$ objdump -x test.o | grep main
00000000 g     F .text  0000000a _ZN6mumumu3aho4mainEiPPc

PEAR_PackageProjector 0.2.0

http://openpear.org/repository/PEAR_PackageProjector/trunk/release

先程のエントリの patch を取り込み、それに伴う細かい変更を行った 0.2.0 を置いておきました。変更点は要するに PEAR 1.8.0 以降に対応しましたよ、ということです。

0.2.0 以降は、PEAR の requirement は 1.8.0 になります。

＃あとは sakamoto さんにリリースしてもらえばいいんだな。

----

[0.2.0]
- fixed bug getcwd() routine could not get current directory.
- followed PEAR 1.8.0 API changes.
-- PEAR_PackageFileManager2::exportCompatiblePackageFile1 was deleted.
- replaced Dependency PEAR_PackageFileManager with PEAR_PackageFileManager2.

[ Update 20th May 2009 22:24 JST by m ]

正式にリリースされました。id:magiwo さんありがとう！

[PATCH] PEAR_PackageProjector does not work with PEAR 1.8.0 or higher

http://www.mumumu.org/~mumumu/tmp/pear_packageprojector_over1_8_0.patch

現在は openpear で公開されている PEAR_PackageProjector 0.1.3 は、PEAR 1.8.0 以降では動かない。PEAR Package バージョン1 向けのメソッドが削除されたためなのだが、作者でありメンテナでもある sakamoto さんと直で連絡をとる方法が openpear 上にもないようなので、この日記を書いた時点での最新のtrunk に対する patch を晒しておく。ダウンロードは上記リンクからどうぞ。


diff -ur /home/mumumu/ppp/src/PEAR/PackageProjector/Derictory.php /usr/local/php5/lib/php/PEAR/PackageProjector/Derictory.php


--- /home/mumumu/ppp/src/PEAR/PackageProjector/Derictory.php 2009-05-16 05:46:37.000000000 +0900
+++ /usr/local/php5/lib/php/PEAR/PackageProjector/Derictory.php 2009-05-16 06:04:22.000000000 +0900
@@ -307,7 +307,7 @@
  if (self::isAbsolutePath($path)) {
      return $path;
  }
-  $tmp = (OS_WINDOWS) ? getcwd() :$_ENV['PWD'];
+  $tmp = (OS_WINDOWS) ? getcwd() : getenv('PWD');
  return $tmp .DIRECTORY_SEPARATOR.$path;
}

diff -ur /home/mumumu/ppp/src/PEAR/PackageProjector/Package.php /usr/local/php5/lib/php/PEAR/PackageProjector/Package.php
--- /home/mumumu/ppp/src/PEAR/PackageProjector/Package.php 2009-05-16 05:46:37.000000000 +0900
+++ /usr/local/php5/lib/php/PEAR/PackageProjector/Package.php 2009-05-16 06:08:01.000000000 +0900
@@ -44,6 +44,7 @@
  $this->pkg     = new PEAR_PackageFileManager2();
  $this->options = array();
  $this->options['filelistgenerator'] = 'file';
+  $this->options['packagefile'] = 'package2.xml';
  $this->options['simpleoutput']      = true;
  $this->postInstall = null;
  $this->Installgroups = array();
@@ -155,9 +156,7 @@
      $this->pkg->addReplacement($installer, 'pear-config', '@bin_dir@', 'bin_dir');
      $this->pkg->addReplacement($installer, 'pear-config', '@php_dir@', 'php_dir');
  }
-  //
-  $this->pkg->exportCompatiblePackageFile1();
-  //$this->pkg->addRelease();
+  $this->pkg->addRelease();

  $this->pkg->generateContents();
  $result = $this->pkg->writePackageFile();

[ Update May 17th 2:27 JST by m ]

この patch を取り込んで openpear に新しいバージョンを置いておきました。

dead download link

http://groups.google.com/group/smarty-discussion/browse_thread/thread/a4f0f13f56d9538d

XX がリリースされたよ！ とアナウンスするのはいいんだけど、ダウンロードのリンクが404とかエラーとかだと物凄く萎えるす。メンテナは自らダウンロードとリグレッションテストくらいはしましょうね。自戒を込めて。

----

お陰で一瞬だけ smarty-discussion group を購読するハメになった上、dup post までしてしまった件。google group って Web にすぐ投稿が反映されないとはいえ、俺ってスーパーお馬鹿だよね。ざっと見たら意外に流量が多くてビックリした。

POSS Japanese Edition will be published on June 2009

http://producingoss.com/ja/producingoss.jp.foreword.html

やっと最後の原稿を脱稿した。上記がそれである。

俺と高木さんが全文の翻訳を手掛けた Producing Open Source Software(邦題：オープンソースソフトウェアの育て方）は、来月中に日本語版が出版される予定となった。ボランタリーで翻訳をはじめたときはまさか出版されるなんて思っても見なかったわけだが、ここまで来れたことを今は素直に喜びたい。これで今年の目標の一つは達成できることになる。

上記のリンクを見ても分かる通り、この本はオンライン版として全文がオープンソースで公開されている。オープンソースソフトウェアの開発者は勿論のこと、ソフトウェア開発者であればきっと面白く読めるだろう。オンラインで読んでみてもし気に入ったら、手に取って頂ければ嬉しく思う次第だ。

----

原著が2005年に出版されたもので若干古いので、内容については原著者の Karl Fogel とも協力しつつ、URLやツールについての記述は極力最新のものに追随したり、注釈を施すなどした。原著の出版時から動きがあった部分（ライセンス等）についても Karl によってアップデートが行われている。オレンジニュースなどでは記述に若干古い部分があるとの指摘があったが、現状公開されているものについてはその指摘はもはや当たらないだろう。

この本を通じて、オープンソースの世界が少しでも人々に伝わることを願っている。

git

http://git-scm.com/

git を最近よく使っている。とは言っても、本格的に使っているわけではなくて、git-svn を通して使ってるわけなんだけれども。

とはいえ、ローカルにコミットを貯めておけるだけでも分散VCSを使う価値がある。最近乗り換えた e-mobile はどこでも高速であるわけではないので、いつでもリモートにコミットできる状況にあるとは限らないからだ。ローカルで編集し、ローカルでテストし、ローカルにコミットする。一通り纏まったところで git svn dcommit。いい感じである。

また、今の Ethna プロジェクトのブランチの使い方はまさしく git のような使い方である。次のバージョンを出して落ち着いたら git に移行する作業をするつもりだ。あと半月あまり。時間がないが、着実に、ね（*´～｀)

Geocoding de Android

Google Maps API には 住所やキーワードを緯度経度に変換する Geocoding の機能が備わっているが、勿論使用するにはGoogle Maps API key が必要だ。

http://code.google.com/intl/ja/apis/maps/documentation/services.html#Geocoding_Direct

Google Maps API key 取得のページ に行くと、結びつける特定のURLの入力を求められ、特定のウェブサイトをブラウザから使うのが前提であるかのように読めるが、Android にはそんなWebサイトなんてあるわけがない。

じゃあ Android からは Geocoding できないの？ と一瞬青くなったが、Android Maps API Key のページから取得したAPI Key で普通にGeocodingできた。ホッ。

----

そもそもだな、Java からあれだけAPI叩かせといて Geocoding 「できない」と思い込む俺の頭の構造がおかしいという話でした。まる。

New Machine - Dell Inprison 531s

http://www1.jp.dell.com/content/products/productdetails.aspx/inspndt_531s?c=jp&cid=21538

MX のマシンが吹っ飛んで以来、空きのマシンがなくなってしまっていた。そこに来て www のディスクまで吹っ飛んだので、ハードウェアの予備がないことに危機感を抱いた次第である。

www と同じくらいの予備機、かつ普段は Windows の開発用として新しくマシンを新調した。それが上記の Dell Inprison 531s である。もともとが AMD64なデュアルコア。メモリを4Gにした上で特急配送を付加しても4万円台。まあ今時ってこんなもんだよね。GWの後半には手元に届く予定である (*´〜｀)

普段プライベートでは Windows は一切使わないと公言している俺だが、Visual Studio が必要な場面も少なくない。Windows Mobile の開発環境には必須であるし、Windows でしか動かないテクノロジを用いたソフトウェアをハックしたくなったときに手元に置いておきたいという意図が強く働いている。