移行しました。
今後はこちらを更新します。
http://momiage3dau.com/
では。
スマートフォンのセミナー行ってきた
久々のエントリ。
さて、本日は以下セミナーに行ってきた。
「スマートフォン向けサイト&アプリケーション 〜ディレクション+企画のための基礎知識〜」
http://swapskills.info/2011/02.html
現状、以前作成したPCサイトのスマートフォン対応の依頼のが増えていて、
どんなディレクションをしたら良いか、指標がブレているので、そのあたりを主題に聞きに。
iPhoneは良いにしても、Andoroidはどの程度まで対応するか。
各キャリアで販売されているAndoroid端末って、OSバージョンが 1.5, 1.6, 2.1, 2.2 と、複数あって、その中でも端末メーカーによって解像度も違う。
では、Andoroid用にサイトを最適化する場合、どのOSのバージョンで、どの端末メーカーのどの解像度まで正常表示出来るように担保するか。
そのあたりって、判断がなかなか難しい。
数をこなせばだんだんと見えてくると思うけど。
10年前は各キャリア毎にサイトを分けるのは当たり前だった。
しかし、今はキャリアに関係無く、モバイルサイトって一括りでサイトを作っているのが殆どだと思う。
この数年間は過渡期になるから、iPhone/Andoroid/ガラケー/PCと、サイトを分ける事もあるかもしれないが、いずれは、1本化されると思われる。
ガラケーは別として、iPhone/Andoroid/PCサイトは全て同じHTMLファイル。
CSSを切り替えて表示するという形。
セミナーの中でもあったけど、今後はiPhone/Andoroidアプリではなく、両方で普通に見れるWebアプリが増えていきそうだ、と。
発注側もiPhone/Andoroidアプリの2本立てで金をかけるよりは、
Webアプリ1本で両方見る事が出来た方が工数も期間もかからないし、その流れになっていくでしょう、と。
で、今日の自分の中の結論としては、
・iPhone は iOS4(iOS3も対応出来るならやる)
・Andoroid は 2.1 以降
・アプリ開発は避け、要件をなるべくWebアプリへ寄せていく
・Andoroidだからと言って、Flashがちゃんと見れると思うなよ!!
・WindowsPhoneとBlackBerryは無視
・タブレットの場合はPCサイトを見せた方が良い
と、他にも色々あるけど、大きくはこんな感じで。
でわ。
さくらインターネットの共用サーバでEC-CUBEのモバイル版を動かす
現在運用中のEC-CUBEのサイトがある。
さくらインターネットの共用サーバで動作している。
で、今まではPCサイトのみで動作していたのだが、モバイル版もカスタマイズして使えるようにして欲しいと。
専用サーバの場合、ゴリゴリとサーバ自体の設定をいじれるから問題無いのだが、さくらの共用サーバはそうもいかない。
インストールされた状態のままでもうまく動かない。
色々やって、うまく動くようになったので、備忘録。
1) SC_DbConn.phpの修正(data/class/SC_DbConn.php)
DB接続部分でなにやらエラーが出てうまく動かなかったので、コンストラクタのDB接続部分をこんな感じで修正。
// 既に接続されていないか、新規接続要望の場合は接続する。 if(!isset($objDbConn->connection) || $new) { if($dsn != "") { $objDbConn = DB::connect($dsn, $options); $this->dsn = $dsn; // ここから下3行を追加 $buf = $objDbConn->prepare('SET NAMES utf8'); $objDbConn->execute($buf); mysql_set_charset("utf8"); } else { if(defined('DEFAULT_DSN')) { $objDbConn = DB::connect(DEFAULT_DSN, $options); $this->dsn = DEFAULT_DSN; } else { return; } } }
2) php.iniをばらまく
さくらサーバの場合、html/mobile配下に設置されている.htaccessが効かないので、php.iniにして、その配下のディレクトリ全てにばらまく。
$ cd html/mobile $ mv .htaccess .htaccess.bk $ vi php.ini mbstring.language=Japanese output_handler=null mbstring.encoding_translation=Off magic_quotes_gpc=Off mbstring.internal_encoding=UTF-8 variables_order=EGPS session.auto_start=Off session.use_trans_sid=On $ cp ./php.ini ./cart/ $ cp ./php.ini ./contact/ $ cp ./php.ini ./entry/ $ cp ./php.ini ./forgot/ $ cp ./php.ini ./frontparts/bloc/ $ cp ./php.ini ./guide/ $ cp ./php.ini ./mypage/ $ cp ./php.ini ./products/ $ cp ./php.ini ./regist/ $ cp ./php.ini ./shopping/ $ cp ./php.ini ./unsupported/ $ cp ./php.ini ./user_data/
とりあえず、こんな感じでうまく動くようになりました。
でわ。
PHP(PDO)+Oracle=too large for buffer and was truncated
ハマったので。
PDO_OCIでPHPとOracleとを繋いでる環境でエラーじゃないけど、Warningが出た。
Warning: PDOStatement::fetch(): column X data was too large for buffer and was truncated to fit it in test.php on line XXX
VARCHAR2のカラムからデータを取得すると出た。
正常にデータが取得出来てるっぽかったけど、おしりの何バイトかが切れてた。
おぉ、trancateされてる。
色々調べてみたところ、全角文字が入ってるとダメだった。
さらに調べてみると、原因が分かった。
Oracle:SJIS
PHP:UTF-8
これが原因だった。
OracleはSJISなので、全角文字は2バイト。
PHPはUTF-8なので、全角文字は3バイト。
PDO_OCIの場合、テーブルのカラムの型と長さを参照してバッファを決めるようで。
全角文字が入っていた場合、そのバッファが溢れる事があるのです。
なんせ、2バイトだと思っていた全角文字が3バイトだったので。
VARCHAR2(20)のカラムに、全角文字が10文字入っていた場合、SJISならば20バイトなので、OK。
しかし、UTF-8だと30バイトになってしまうので、受け取る側のバッファが溢れてしまう、という事。
対応どうしようか・・・
と考え、
/etc/sysconfig/httpd
をちょっと編集してみた。
# cd /etc/sysconfig/
# vi httpd
export NLS_LANG=Japanese_Japan.UTF8
↓に変更
export NLS_LANG=Japanese_Japan.JA16SJIS# /etc/rc.d/init.d/httpd restart
Warnningは出なくなったけど、文字化けした。
DBから取得してる根っこの部分でSJIS→UTF-8の変換をかけようかと考えたのですが、symfony+doctorineという事もあり、断念。
だって、調べるの面倒だから・・・
テーブルのカラム長の定義を1.5倍すれば回避出来るけど、運用案件では無理なので断念。
結果、PDO_OCIのソースをちょっと直して対応する事に。
# cd /usr/local/src
# cd PDO_OCI-1.0
# vi oci_statement.c
510行目付近に有る記述
col->maxlen = data_size;
↓
col->maxlen = data_size*1.5;# ./configure
# make
# make install
PDOがOracleのテーブルのカラムの長さを取得してる部分で、その長さを1.5倍してあげれば大丈夫。
この対応方法が良いかどうかは疑問が残るが、とりあえずはこれで回避しよう。
でわ。
Skypeで過去のチャットログを見たい場合
Skypeで過去のチャットログを見たい場合、
「今回の会話」
「今日」
「今週」
「30日以内」
「初めから」
をクリックすれば、見る事が出来ます。
しかし、しばらくチャットをやっていないユーザの場合、上記表示が出てきません。
そのユーザとの過去のチャットログを見たい場合、
/htmlhistory
とメッセージを送信すると、そのユーザとの全てのチャットログがデフォルトブラウザにて表示されます。
他にも便利な隠しコマンドが色々あるようなので、気になった人は探してみてくださいな。
でわ。