dolem0.8.0のリリース
Read More
ふうはあ。
やっとこさdolemのVer.0.8.0のリリースができた。
以下のリンクから最新版のVer.0.8.0がDLできる。
http://dolem.jp/?m=download
そういえば0.6.0と0.7.0のリリースの告知ができてなかったなあ。
ついでにここでそれらの変更の概要をざっくり書いておこう。
Ver.0.7.0は今回のVerUPのための布石のようなところがある。
Ver.0.6.0に至ってはシステム内の書式の統一とか定数のネーミングとかそんな感じ。
まあ今回のVer.0.8.0のリリースの方がよっぽど重い。
今回のリリースのうち、主な機能としてはモバイルとスマホの切替機能が実装されたこと。
boot.php内には以前からPC、モバイル、スマホの切替処理が書かれていたが、モバイルは404ページが強制的に表示されるようになってたし、スマホはPCと同じページしか表示できないようになってたと思う。
まあ実を言うと以前のVerででもスマホ用の独立した処理を書くことは可能だった。
当然ちゃんとスマホ用ページを表示させることもできた。
しかしながら以前リリースしたものはスマホ用の処理の書き方がわかるようなものをきちんと用意できなかった。
当たり前だが使い方もさっぱりだっただろう。
今回はそれをようやくパッケージに内包することができた。
まあこんな書き方をするとさぞすごいように聞こえるかも知れないが、実のところcore直下のcontrolフォルダ内を見てもらえばわかるようにPC用のcontrol.phpとスマホ用のcontrol.phpにはほとんど差がない。
せいぜいコードの最下部のincludeのパスが変わっているくらいだ。
そしてそれはモバイルに関しても同じことが言える。
要はcontrolフォルダ、modelフォルダ、viewフォルダのそれぞれの配下にモバイル用の_mobileフォルダというのを作ってあるだけ。
スマホの場合も同様でこちらの名前は_smartphoneフォルダとすればよい。
PC、モバイル、スマホの動的な切替自体はboot.phpで行われるのでそれぞれの最適化したページがまだきちんと用意できない場合は該当するcontrol.phpを削除すれば良い。
コントローラがなければその処理は呼び出しされないので404ページが表示されるはず。
或いはboot.phpの切替処理の部分を修正してやってもいい。
ま、このあたりはboot.phpを目で追えば一発だと思うのでここでごちゃごちゃ言うのはやめよう。
--
さて、このVer.0.8.0。
もっと早いタイミングでリリースを行えれば良かったのだが、モバイルのセッション管理の部分で意外と時間がかかってしまった。
旧フレームワークで実装していたものをdolemでそのままリリースするのにどうしても抵抗があったのだ。
というのも旧フレームワークではモバイルのセッション管理に個体識別番号というものを利用した作りにしていたからだ。
どういうことか簡単にいうと、個体識別番号をもっているものでしかセッションを利用することができないので、つまり必然的にdocomoとau、SoftBankのみしかサポートすることができなかったのだ。
しかもSSL通信時の処理にセッションの引継ぎのためにどうしてもURLにセッションIDを付与せざるを得ないパターンがあった。
これが一番ネックだった。
とにかくURLにセッションIDを付与するのだけはホントになんとかしたかった。
そしてあれこれ試行錯誤した結果、ついに、モバイルのセッション管理にはcookieのみを使うという結論に達した。
そう、cookieを使えない古い機種は切り捨てる！のだ。
まあそうすることで色々と恩恵があるんだ。
例えばdocomo、au、SoftBank以外のキャリアもサポートできるようになったりだとか、先ほど少し問題視したSSL通信時の件もグダグダ考えなくてよくなるし、URLにセッションIDの付与する手間だとか抜けだとか絶対パスだとか外部リンクだとか、RefererでセッションIDが見える問題とかGoogleにセッションID付きURLがIndexされる問題とか。
そういうったものから一気に開放される。
近年発表されているモバイルはcookieがデフォで使えるものしかない。
もはやcookieが使えなかったモバイルは過去のものとなりつつある。
なによりスマホの利用率が上がりつつある昨今、それに比例してモバイルの利用率は着実に下がっている。
ちょっと想像してみて欲しい。今日日高校生や大学生、若いねーちゃんなんかがフィーチャーフォンをわざわざ買うだろうか。
いいやスマホを買うだろう(思い込み)。
そう、スマートフォンの流れが強いのでフィーチャーフォンの利用者は今後も減る一方だ。
つまりモバイルページ自体の価値が下がってきているわけだ。
時間が経てば経つほどに。
これはつまりどういうことかというとモバイルに充てれる開発費用が十分にとれないということを現す。
「モバイルの開発費がとれない」ことと「cookieが使える使えない」ことは通ずるところがある。
逆説的な言い方になるが、cookieが使える機種を前提としたのだからcookieが使えないことによって発生する問題がなくなるのだ。
つまりキャリアごとに存在するcookieに関する問題を解決する必要がなくなる。
開発時点で気が付かなかったような隠れた問題、つまり保守管理にかかるコストをも軽減できるというわけだ。
そしてcookieが使えないような古い機種向けのページデザインをしなくてよくなる。
つまり1ページあたりの利用できるバイト数の問題だったり利用できるHTMLタグの問題が若干緩和されるわけだ。
これは見た目のデザインも古い機種を切り捨てるので俄然よくなる。
そもそも想像してみて欲しい。
古いフィーチャーフォンの機種を使い続けるような人間がはたしてショッピングサイトとかをモバイルから利用するだろうか？
いやいや、未だにcookieすら使えないような機種を使ってる人間はそんなページ最初から利用しやしないよ。
ショッピングサイトにしろなんにしろ、それらを使うような人間は新しいモバイルやスマホを利用するような人間だ。
つまり古い機種のためにあれこれ色々考えることは仕事的にははっきりいって労力の無駄遣いだ。
だからcookieが使えない機種を思い切って切り捨てる。
それだけでモバイル開発のコストがかなり抑えられるというわけだ。
ごちゃごちゃ書いてしまったがこのような理由からdolemでは全てのデバイスにおいてセッション管理はcookieのみを利用することにさせた。
--
ふー、この結論に達するまでぐるぐる同じところを何週もした。
半年は悩んだなこれ。
せめてdocomoでiモードIDがSSLの時も使えたらまた少しは話が違ったんだけどなあ。
utnは気軽に利用できないしなあ。
それでもモバイルのセッション管理にcookieだけを使うってのはきっと賛否両論あるだろうなあ。
まあ俺がたまたまそういう結論に達しただけであって、フィーチャーフォンの時代はもう一度来る！とか、古い機種も全部動作させたい！とか思う人はそうすればいいだけだし。
あとはクライアントへの言い方かな。
「発売から二年以内の機種が動作対象です。ただしメーカー独自のバグであったり新たな仕様が発見され、それに対応させる場合などは別途ご相談させて頂きます。それ以前の機種に関しては基本的に動作対象外とさせて頂きます。」
とかだったら大抵大丈夫なんじゃない？
万が一、一部の機種がうまく動かないものがあるようならその機種のみセッションIDを渡すようにしてやるか、或いは個体識別番号を使うようにしてやればいいだけの話だ。
各キャリアから出た機種の発売日はきっちりリストとして抑えておく必要はあるな。
なんにせよこれで次のステップへやっと進める。
やっとこさdolemのVer.0.8.0のリリースができた。
以下のリンクから最新版のVer.0.8.0がDLできる。
http://dolem.jp/?m=download
そういえば0.6.0と0.7.0のリリースの告知ができてなかったなあ。
ついでにここでそれらの変更の概要をざっくり書いておこう。
Ver.0.7.0は今回のVerUPのための布石のようなところがある。
Ver.0.6.0に至ってはシステム内の書式の統一とか定数のネーミングとかそんな感じ。
まあ今回のVer.0.8.0のリリースの方がよっぽど重い。
今回のリリースのうち、主な機能としてはモバイルとスマホの切替機能が実装されたこと。
boot.php内には以前からPC、モバイル、スマホの切替処理が書かれていたが、モバイルは404ページが強制的に表示されるようになってたし、スマホはPCと同じページしか表示できないようになってたと思う。
まあ実を言うと以前のVerででもスマホ用の独立した処理を書くことは可能だった。
当然ちゃんとスマホ用ページを表示させることもできた。
しかしながら以前リリースしたものはスマホ用の処理の書き方がわかるようなものをきちんと用意できなかった。
当たり前だが使い方もさっぱりだっただろう。
今回はそれをようやくパッケージに内包することができた。
まあこんな書き方をするとさぞすごいように聞こえるかも知れないが、実のところcore直下のcontrolフォルダ内を見てもらえばわかるようにPC用のcontrol.phpとスマホ用のcontrol.phpにはほとんど差がない。
せいぜいコードの最下部のincludeのパスが変わっているくらいだ。
そしてそれはモバイルに関しても同じことが言える。
要はcontrolフォルダ、modelフォルダ、viewフォルダのそれぞれの配下にモバイル用の_mobileフォルダというのを作ってあるだけ。
スマホの場合も同様でこちらの名前は_smartphoneフォルダとすればよい。
PC、モバイル、スマホの動的な切替自体はboot.phpで行われるのでそれぞれの最適化したページがまだきちんと用意できない場合は該当するcontrol.phpを削除すれば良い。
コントローラがなければその処理は呼び出しされないので404ページが表示されるはず。
或いはboot.phpの切替処理の部分を修正してやってもいい。
ま、このあたりはboot.phpを目で追えば一発だと思うのでここでごちゃごちゃ言うのはやめよう。
--
さて、このVer.0.8.0。
もっと早いタイミングでリリースを行えれば良かったのだが、モバイルのセッション管理の部分で意外と時間がかかってしまった。
旧フレームワークで実装していたものをdolemでそのままリリースするのにどうしても抵抗があったのだ。
というのも旧フレームワークではモバイルのセッション管理に個体識別番号というものを利用した作りにしていたからだ。
どういうことか簡単にいうと、個体識別番号をもっているものでしかセッションを利用することができないので、つまり必然的にdocomoとau、SoftBankのみしかサポートすることができなかったのだ。
しかもSSL通信時の処理にセッションの引継ぎのためにどうしてもURLにセッションIDを付与せざるを得ないパターンがあった。
これが一番ネックだった。
とにかくURLにセッションIDを付与するのだけはホントになんとかしたかった。
そしてあれこれ試行錯誤した結果、ついに、モバイルのセッション管理にはcookieのみを使うという結論に達した。
そう、cookieを使えない古い機種は切り捨てる！のだ。
まあそうすることで色々と恩恵があるんだ。
例えばdocomo、au、SoftBank以外のキャリアもサポートできるようになったりだとか、先ほど少し問題視したSSL通信時の件もグダグダ考えなくてよくなるし、URLにセッションIDの付与する手間だとか抜けだとか絶対パスだとか外部リンクだとか、RefererでセッションIDが見える問題とかGoogleにセッションID付きURLがIndexされる問題とか。
そういうったものから一気に開放される。
近年発表されているモバイルはcookieがデフォで使えるものしかない。
もはやcookieが使えなかったモバイルは過去のものとなりつつある。
なによりスマホの利用率が上がりつつある昨今、それに比例してモバイルの利用率は着実に下がっている。
ちょっと想像してみて欲しい。今日日高校生や大学生、若いねーちゃんなんかがフィーチャーフォンをわざわざ買うだろうか。
いいやスマホを買うだろう(思い込み)。
そう、スマートフォンの流れが強いのでフィーチャーフォンの利用者は今後も減る一方だ。
つまりモバイルページ自体の価値が下がってきているわけだ。
時間が経てば経つほどに。
これはつまりどういうことかというとモバイルに充てれる開発費用が十分にとれないということを現す。
「モバイルの開発費がとれない」ことと「cookieが使える使えない」ことは通ずるところがある。
逆説的な言い方になるが、cookieが使える機種を前提としたのだからcookieが使えないことによって発生する問題がなくなるのだ。
つまりキャリアごとに存在するcookieに関する問題を解決する必要がなくなる。
開発時点で気が付かなかったような隠れた問題、つまり保守管理にかかるコストをも軽減できるというわけだ。
そしてcookieが使えないような古い機種向けのページデザインをしなくてよくなる。
つまり1ページあたりの利用できるバイト数の問題だったり利用できるHTMLタグの問題が若干緩和されるわけだ。
これは見た目のデザインも古い機種を切り捨てるので俄然よくなる。
そもそも想像してみて欲しい。
古いフィーチャーフォンの機種を使い続けるような人間がはたしてショッピングサイトとかをモバイルから利用するだろうか？
いやいや、未だにcookieすら使えないような機種を使ってる人間はそんなページ最初から利用しやしないよ。
ショッピングサイトにしろなんにしろ、それらを使うような人間は新しいモバイルやスマホを利用するような人間だ。
つまり古い機種のためにあれこれ色々考えることは仕事的にははっきりいって労力の無駄遣いだ。
だからcookieが使えない機種を思い切って切り捨てる。
それだけでモバイル開発のコストがかなり抑えられるというわけだ。
ごちゃごちゃ書いてしまったがこのような理由からdolemでは全てのデバイスにおいてセッション管理はcookieのみを利用することにさせた。
--
ふー、この結論に達するまでぐるぐる同じところを何週もした。
半年は悩んだなこれ。
せめてdocomoでiモードIDがSSLの時も使えたらまた少しは話が違ったんだけどなあ。
utnは気軽に利用できないしなあ。
それでもモバイルのセッション管理にcookieだけを使うってのはきっと賛否両論あるだろうなあ。
まあ俺がたまたまそういう結論に達しただけであって、フィーチャーフォンの時代はもう一度来る！とか、古い機種も全部動作させたい！とか思う人はそうすればいいだけだし。
あとはクライアントへの言い方かな。
「発売から二年以内の機種が動作対象です。ただしメーカー独自のバグであったり新たな仕様が発見され、それに対応させる場合などは別途ご相談させて頂きます。それ以前の機種に関しては基本的に動作対象外とさせて頂きます。」
とかだったら大抵大丈夫なんじゃない？
万が一、一部の機種がうまく動かないものがあるようならその機種のみセッションIDを渡すようにしてやるか、或いは個体識別番号を使うようにしてやればいいだけの話だ。
各キャリアから出た機種の発売日はきっちりリストとして抑えておく必要はあるな。
なんにせよこれで次のステップへやっと進める。