Web制作の最近のブログ記事

 PHPもC++も使うプログラマーにとっては凄い興味が沸きます。確かにPHPはスクリプト言語という宿命がある限り、キャッシュしようが限界がありますよね。だからといってC++で再コーディングするにも時間的なコストを考えると手段から外される事も多い。

FacebookがPHPをC++に変換し高速化する「HipHop for PHP」を公開したようです | ke-tai.org
http://ke-tai.org/blog/2010/02/05/hiphopphp/

PHPをC++に変換して高速化する「HipHop for PHP」をFacebookが公開 : candycane development blog

 PHPがウェブアプリ作る言語としてオリジナルで便利な関数が揃っている為プログラマーを教育しやすい初心者にも敷居が低いのは良く分かりますが、元々HTMLにSSIの代わりに埋め込んで使うような言語でJavaScriptとの違いはサーバーで動作させるか、クライアントで動作させるかといったものなのに、Smartyのようなテンプレートエンジンやその他多機能なフレームワークなど、折角Apacheモジュールとして高速動作させているのにパフォーマンスに対して本末転倒なライブラリを実装する開発のほうが標準的になっている事がとても嘆かわしいですね。

 そういったPHPを遅くするライブラリどもを全てエクステンションに追い出せるならサーバーコスト(特にCPU周り)の節約に貢献できそうです。あとバッチ処理とか単体で変換できるとバッチ付き抜け防止に役立ちそうですね。(そもそもPHPでバッチ組むなというのもありますがシェルプログラミングスキルがあまり無いのでほんのちょっとでも複雑になると他のスクリプト言語に逃げてしまいます。。。Perl使ってもOKならPHP選ぶ前に使ってます。)

 RubyはPerlの文字化けに苦しんでいた10年前は興味ありましたが未だに手を出してないなぁ。。。Pythonはあまり興味なし。(多分仕事で使うことがなさそうだから)。Javaはどうなんでしょう?アプレットは遊びで作ってましたが、サーブレットはコンパイル済みプログラムをシステムに反映するのにApache、tomcatを再起動なんて仕様がデバッグコストを上げる原因にもなるし、無停止サービスを目指すシステムから見れば「ナンセンス」なのでまずサービス稼動したままリロードできるようにしないと大変ですよね。


 今日は立春ですが道路は凍結してました・・・。
さて今年からかのかな?HTML5。そろそろ本気でやっておかないとJavaScriptのリッチコンテンツの時みたいに乗り遅れそうですが(もう遅い?)、サンプル集を見つけましたので見てきました。

HTML5サンプル集 - 株式会社あゆた
http://ayuta.co.jp/html5-samples/

この中でクライアント上にリレーショナルデーターベースを持てるという所に希望を感じたw。というのもウェブアプリで運営の中の人が使う管理機能等でもログ集計とか基本サーバー上で行っていることが多いじゃないですか。生ログから表示用の集計まではこれまで通りサーバー上でバッチ処理等で行えば良いのですが、『集計条件を変えて再集計』みたいな機能は本来クライアントでやった方が良いわけなんですよね。抽出条件代えるだけならサーバー上でも良いが集計条件変えるってなると絞込ではなく再集計となって管理系サーバーの負荷が気になるし(フロントにはお金掛けても管理系は節約したりしますからね)、だからといってアプリ開発すると配布管理が面倒だとか言われ、FLASHにするには開発体制が揃わないとか開発コスト上がるとかでまた難儀だったりしています。(システムに強いFLASH開発会社ってそんなに多くないからなかな?普通のウェブアプリ開発だと開発メンバーがFLASH持ってないとか、スキル不十分とか・・・)

現状、表示だけのHTMLがアプリとしての機能を持ちクライアントにDBを持てるとしたら上記のようなFLASH開発体制が整わなくても実現できそうな気がします。
 ウェブページの作成などでDreamweaverではなくてテキストエディタなどで書いているとき、色については結構勘で設定したりしますが、表示させてみてちょっと変だな~と思う事が多い気がします。だからといっていつもカラーパレット持ち歩いているわけではないのでこういったページがあると便利ですね。

カラーパレット [フルカラーセレクト]
http://web-img.com/color/full.php

カラーパレットのページは欲しいなと思うたび検索エンジンで探したりしてますが、今回見つけたのがこのサイト。作りもシンプルなので使いやすいです。
 STUDIO8を持っていてCS4アップグレードに4万円、このキャッシュバックで2万円戻ってくるとすると2万円でグレードアップできることになりますがDWはもう殆ど使わないだろうし、使うとしてもFLASHとFWだけなのでどうしようか考え中。FWに関しては動作さえすればブレードアップもする必要ないし・・・。

ADOBE CREATIVE SUITE 4 キャッシュバックキャンペーン
http://www.adobe.com/jp/joc/cashback/?trackingid=FBDFB
携帯サイトで使える証明書というとどうしても高いイメージがあるのですが、RapidSSLだと年間3,000円強で取得できるみたいですね。やっぱり海外は安い。なんで証明書やドメインは原価タダみたいなものなのに国内だとボッタクリ価格なんだろう。
 今までGoogle AnalyticsはJavaScriptが必要だったため携帯サイトでは使用できませんでしたが近いうちにJavaScriptが使えない場合でも集計ができるようになるようです。AdSenseと同じと予想すると多分動的ページのサーバーサイドスクリプト内にGoogleが用意したコードを追記してサーバ間通信で送るのかもしれないですね。

Google Analyticsがとうとうケータイに対応したようです | ke-tai.org
http://ke-tai.org/blog/2009/10/21/googleanalyticsmobile/

Analytics 日本版 公式ブログ: Google Analytics 新機能公開のお知らせ
 サイトの配色は基本、自分の好きな色にしたいものですが、それを2色3色って組み合わせるときはセンスが無いとどうやってもダサくなりますよね。でもこのサイトのツールなら配色決定の力になってくれると思うんだ。

Color Scheme Designer 3
http://colorschemedesigner.com/
 最近バージョンアップされたのは気がついてましたがいつも何が更新されたか確認してないので、まさかシミュレータを有効にするホストを指定できるようになっているとは気がつかなかった。今は起動の重いFirefoxはFireMobileSimulator専用にして他はGoogleChromeだったりしますが、たまにPCサイトのデバッグを同時に行う際にはやっぱり不便でした。同一ドメインでケータイとPCが分かれている場合は無理かもしれないけどこれで9割ぐらい切り替えの面倒から開放されそうですね♪

ke-tai.org > Blog Archive > 「FireMobileSimulator1.1.9」がリリースされ、待望のホスト制限設定機能が追加されたようです
http://ke-tai.org/blog/2009/08/24/firemobile119/
 ウノウラボさんのところでウェブテストに便利なFirefoxアドオンが紹介されています。

ウノウラボ Unoh Labs: WEBアプリのテストに便利なFirefoxのアドオン
http://labs.unoh.net/2009/08/webfirefox.html

ケータイエミュレータやヘッダ解析関係は同じですがデザイン系は入れていないなぁ・・・。
ここに紹介されてないもので現在使用しているのはこれ。

Html Validator
IE Tab
LinkChecker
Mobile Barcoder

テスト補助ツールって言ったほうがいいかな。
昨日に引き続き「何それ、こわい」な情報が出てきました。あまりJavaScriptは触らないのでヘッダ情報を書き換えてアクセスできるなんて知らなかった・・・。現在iモードブラウザ2.0のJavaScript機能は停止されているとの事ですが下記URLの記事の内容からするに勝手サイトでかんたんログインを使っていたら全滅の可能性すらありますね。公式サイト制作の知識のある人だったら公式サイトも力技で突破できる。

ke-tai.org > Blog Archive > JavaScriptとかんたんログインのセキュリティについて解説した記事「携帯JavaScriptとXSSの組み合わせによるかんたんログインなりすましの可能性 」

徳丸浩の日記 - i-mode2.0セキュリティの検討 - 携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性

ここまで来ると実機から送られているIDは絶対にセッション管理に使用しないようにして、公式サイトであっても使い捨てセッションIDを発行してログイン管理しないといけなくなるな。公式サイトの実態は殆どかんたんログイン状態なのですが、別にキャリアはUID等を課金以外の目的で使う事に対して特に触れてなかったと思うし、この際キャリアからバシッと言ってもらえるとCPも従うはず。今までconfidentialで守って来たかも知れないが勝手サイトで実機にアクセスさせれば丸見えのパラメータなんてなんの機密にもならないから手遅れだと思います。

技術者も危ない危ない言っても環境は変わらないので、リスクをちゃんと見積もったうえでサイト制作のガイドラインを作って理解を求める方にシフトしたほうがいいな。つか自分がやらなきゃ・・・。orz
 iPhoneのSIMアンロックとかは面倒そうなのですが、SoftBankケータイをUSBでPCに繋いで通信するだけって・・・。ソフトフォンだと組み込んだプログラムでハックできるかもなんて予想はしていましたが、この情報が本当なら斜め上すぎますね・・・。x-jphone-uidがネットワーク上で付与されるのは契約情報以外のidもくっついてるからですね。他のキャリアでもUSB接続でネットが出来たと思いますのでパケ死しない程度で調べてみる必要がありますね。むしろユーザが面倒になってもキャリアから付与されるIDとサイトでログインする情報を分けたほうがよさそうですね。

ke-tai.org > Blog Archive > ソフトバンクの携帯用GatewayをPCで通る方法があるようです
http://ke-tai.org/blog/2009/08/04/softbankgwpc/

SoftBank Mobileの携帯用GatewayをPCで通る方法のメモ - Perlとかmemoとか日記とか。

他にke-tai.orgさんではかんたんログインのサンプルが公開されていました。一応DB保存時にはMD5をかけて有るので漏洩してもUIDはばれないですね。(但しちゃんと塩は自分で作ること)。それでもPCから接続可能は成りすましされやすくなるので怖すぎる。

ke-tai.org > Blog Archive > 実際に動いてすぐ使える「PHPによるかんたんログインサンプル」を作ってみました

 こんなアドオンが有るなんて知らなかったFireMobileSimulatorでブラウザテストしたあとに実機でテストする際に毎回QRコードを生成するアプリを使っていましたがこれなら一発読み込みだけで手間が省けますね。

Mobile Barcoder :: Firefox Add-ons
 経験は時間と密度で蓄積され、長く生きてれば偉いってわけじゃないけどそうそう減るもんじゃないと思う。でも技能は常に訓練してないと落ちてしまうんだなぁと再認識。

 ここ4年くらいケータイサイト制作ばかりなのでJavaScriptやFLASHは触らなくなって時代について行ってないなぁというのは分かっていましたが、余りにも遅いPHP/MySQLのバッチに痺れを切らしてバッチをC++で組みだしたらいろいろ忘れていてコンパイル通らなくなりさらに落ち込みました。どうせ納品するコードじゃないしアルゴリズムを検討しなおしてC言語で書いたらPHP/MySQLで3日掛かってたバッチが1分以内で終了・・・。多分プログラム以外の部分で無駄な処理をしていたのかな?結局C++で作ろうとしたものはそのまま投げ出してしまいました・・・。(一応自分ルールとしてC++で組むときはC言語のライブラリを使わないように努力してます・・・今回は無理でしたが)

 さらに30歳過ぎるとコーディングしている時間が減る一方、ミーティングが増え何故か同じ事を何度も説明するハメになってストレスが溜まる。35歳定年説って体力の問題じゃなくて年功序列による役割変更の弊害じゃない?と思ったりもする。このまま行くと本当に35歳になったときコーディングに関して無能になってそうで不安だなぁ、知識だけが増えて技能が無くなるなんて・・・何とかしないと。

 それにコンピュータと向き合って仕事したくてプログラマーになったつもりが気が付いたらコーディングしてなくて人と向き合って仕様会議。さらにコミュニケーションの手間でイライラ。

 やりたいのにやれてないことがここ7年分どっさり溜まっている・・・そろそろ諦めと絞込みしないと身が持たないんじゃないかな。(DTMまで入れると約20年分くらいか?)

 スキルは貯めて仕事で消費するものだなというのは前から思ってましたが、まさか自分自身に現象として出るとは思わなかった。全ての時間を仕事につぎ込むと新しい情報は入ってこないし現業以外の事は忘れてしまう。少しだけ余裕が欲しい。みんな不景気が悪(ry

 このご時世はまたブラック企業が増えて将来の有る若者を消費して国力が削がれるんだろうな・・・氷河期ニートの再生産が起きないようにしっかり支援してほしいな。

 でもベーシックインカムがあるなら一生ニートプログラマーとして過ごしたいwww
 
「緊急人材育成支援事業」が29日から開始、生活給付金受給も - 不景気.com | ハローワーク, 給付金, 失業, 就職, 政策,
 今日はMySQLに対し数千万件のデータ生成バッチを組んでましたが、重複禁止のデータの為主キーにしていたら200万件超えた辺りから見る見るデータ挿入が遅くなる。これは挿入のたびに重複検査するから遅くなるのかとうっかりしてました。それでINDEXなら大丈夫だろうとキーの種類変えて再実行したら主キーのときに比べれば若干マシなのですがそれでも500万件超えると極端に遅くなる・・・。何でだろうとちょっとSELECTしてみたらINDEXのフィールドはソートされるのか!今までメモリにキャッシュしてるだけかと思ってた。こんなのDBエンジニアやシステム開発者では常識なんだろうな。。。結果、INDEXを全く付けないテーブルだと最も速い(挿入以外の処理をしない)事になりますが当然検索や集計には向かないので記録用テーブルと集計用のクローンテーブルって必要なんだな・・・。並べ替え不要な条件だったら速いのならログ関係はタイムスタンプのみINDEX貼って、集計クローンテーブルは集計期間で拾って作成すると効率よさそう。(やってみないと差が分かりませんが)

これはMySQL5.1のパーティショニングを使ったときはどのような挙動するだろうか?INDEXなしは余りパフォーマンスが変わらなくて、INDEX付きが結構速くなり、主キーだとちょっと速くなりって感じかな?

HTML5関連

| コメント(0) | トラックバック(0) このエントリーを含むはてなブックマーク
 動画コーデックが白紙になったりXHTMLと統合されたりと具体的に仕様が収束してきましたね・・・。こういうときってブラウザ対応がどうなるのか、普及するのかも含めて不安です。ここ10年くらい大きな変化が無かったというのもあるからかな?

HTML 5の仕様が一覧できるクィックリファレンス | コリス
http://coliss.com/articles/build-websites/operation/work/freebies-cheat-sheet-html-5.html

fladdict » HTML 5の仕様からオーディオ・ビデオコーデックに関する要件白紙に

オープンソースの動画コーデック「Theora」、HTML 5での仕様策定が挫折 - インターネット - ZDNet Japan

W3C,マークアップ言語「XHTML 2」を「HTML 5」に統合へ:ITpro
Perlでシステムを組まなくなってそろそろ3年以上になるかな、その間に結構定番のコーディングが変わってきていますね。比較してみるとへぇ~と思うのばかり。明らかに私はoldtype...最初はoldtypeのものさえ使ってなかったかなPerl4だったし。

Perl 5 今昔 - Perl-users.jp
http://perl-users.jp/nowpast.html
 不具合が発生から修正対応するのはしかたない事ですが何故UAを変えた!この件で機種判別が必要な着うた・ゲーム系携帯サイトは機種マスターデータの更新作業をするハメになりました。別に2機種だし更新なんてすぐなんていってもサイトの数だけ更新しなきゃいけないから「チリも積もれば」って状態です。

ドコモ、ソフトで自動修正 一時販売停止の携帯 モバイル-最新ニュース:IT-PLUS
http://it.nikkei.co.jp/mobile/news/index.aspx?n=AS1D2808K%2028052009

NTTドコモ、販売停止中の「N-06A」「P-07A」に更新ソフトウェアを用意 : CNETニュース : ニュース : ネット&デジタル : YOMIURI ONLINE(読売新聞)
 JavaScript,Cookie対応の情報を見て、まずその前に外部CSSはどうなの?と思ったら外部CSSも対応になってました。これは大変ありがたい。でもJavaScript対応ってことは携帯サイト開発はもう一段階進んでgoogle mapみたいなリッチコンテンツも作れるということですね。時代遅れにならないようにかんばらないと・・・。

ke-tai.org > Blog Archive > ドコモ端末がついに外部CSSに対応したようです
http://ke-tai.org/blog/2009/05/20/docomocssrenew/

iモードがJavaScriptやCookie対応、Flash動画も
 ちょっとCSSの仕様で(?)なところがあったので調べていたらこんなクールなページを見つけました。今までHTML/CSSはリファレンスばかり見ていて環境依存の理由は特に調べなかったからね・・・。どうして仕様通りに動かないって質問されて・・・それは・・・と、こそこそ調べてました><。

W3G - World Wide Web Guide
http://w3g.jp/

上記リンクは英語サイトっぽい雰囲気ですがしっかり日本語サイトです。
 簡単ログインについて触れられているエントリーがありましたので、私なりの意見も。

高木浩光@自宅の日記 - 無責任なキャリア様に群がるIDクレクレ乞食 ―― 退化してゆく日本のWeb開発者
http://takagi-hiromitsu.jp/diary/20080727.html

契約者固有IDだけで認証するのは危ないというのは同感で、ケータイサイト作っている人なら実機よりも高速でデバッグしやすいエミュレータでガンガン作っていると思います。(それだけお手軽という意味)

この契約者固有IDは実機と特定する情報として公式サイトでは課金情報に利用されますが、ケータイサイト側ではユニークIDとして会員情報のキーとして使っているのは事実です。しかもケータイでログインIDとパスワード入力は極めて面倒な作業なので契約者固有IDだけで認証しているサイトが殆どです。

ただケータイサイト側に送られてくる契約者固有IDはHTTPヘッダです。これは簡単に偽装可能だから契約者固有IDだけで個人情報を提供するには大きなリスクがあります。

例えばdocomoの場合、公式サイトではuidを使いますがケータイ⇔キャリア間では固定文字で内容は分かりません。但しキャリアで公式サイトのドメインと判断されたら、キャリアからケータイサイトまでは平文で送られます。その設定場所はGET引数かPOST変数です。つまり公式サイトのサーバーでなくても途中経路ではuidバレバレです。SSLで暗号化すると今度はキャリアがリクエスト先ドメインを判定できなくてuidを提供できなくなります。guidについても同じ。GETやPOSTだとPCのブラウザを全く改造する必要が無いので簡単に偽装ログインできます。というかGETだった場合、実機だけで偽装できちゃいます。本当に本当にとても頭悪い仕様です。いい加減この仕様は廃止して欲しい。

次にauやsoftbankの場合、HTTPヘッダによって契約者固有IDが送られます。但しこれもFirefoxならFireMobileSimulatorを使えば一発で突破可能です。まだauにはキャリア認証があるので実機以外をブロックすることは可能ですがパフォーマンスが悪くよく認証がダウンするので限定的にしか使用できません。公表はできませんが認証ループしないように認証結果を受け取る仕様があるのですがそれを知っていると認証回避を簡単にできます。

契約者固有IDが簡単に偽装されるならIPフィルタが次の手になります。但し3キャリア共に公開情報が信用できないのは注意書きにも現れています。多分公表と実態のタイムラグが大きいのではないかと思ってしまいます。

IPフィルタで管理が大変なら逆引きで判別するという方法もいくつかのサーバーで見かけましたが、この方法も信用できないのは、キャリアのドメインは実機のみに割り当てているかどうかが全く信用できないという事です。つまりPCとケータイをケーブルに繋いでインターネットしたときにIPアドレスは変わってもドメインが同じならこの方法もアウトになります。ここまではキャリアも情報公開してなさそうだし、3キャリとも実際に試してはないので何とも言えません。これはソフトフォンからの接続では警戒したほうがいいかも知れません。

仕事なので仕方ないにしろ、トップページで自動的に会員認証してポイントやらニックネームやら表示するのはセキュリティ的に危険なだけでなくサーバーに対する負荷も大きいのであまりオススメしないです。(要は非会員分までサーバーリソース食うのはもったいない、非会員にはトップページと入会ページしか見せない完全会員サイトならありかも)

対策としては
  • 契約者固有IDをチェックする際に他のHTTPヘッダが全て実機によるものかを検証する。(殆どのエミュはこれで弾けるがやり過ぎは機種データの対応負担と相談)
  • IPフィルタと逆引きの検証をする(HTTPヘッダ偽装をある程度弾く)
  • DL課金のみのサイトの場合、契約者固有IDはキャリアでの課金以外に流用しない。
    (再ダウンロード補償期間をサイト側で処理する義務があると無理)
  • 契約者固有IDのみでセッション管理しない。Cookieが使えない端末向けには別途工夫が必要。
  • 月額会員サイトはキャリア側の認証かパスワード認証を設置する。リマインダーの設置も必要となるが必ず実機宛てのメアドに制限する。メアド変更のサポートを受付けているならメアド認証しても良い。メアド認証で失敗したら合言葉か一旦退会?
  • ユーザに不必要な情報登録を要求しない。(メルマガ配信や通知をしないのにメアド登録等)
  • 月額課金サイトで退会者の固有情報は次回課金日までに削除する。また差異の補正で会員→非会員となる場合も同様。SoftBankは月末締めでは無いことに注意。これは電話番号が同じ場合に契約者固有IDが重複するためで、ケータイ解約に伴う退会の場合は全く無関係の新規契約者が以前の契約者の情報を知りえてしまう危険があるため。勝手サイトしか作って無い人はこの辺の事情を知らないことがあるので十分注意。ちなみにドコモはある程度対策済み。
  • 検索クローラーを許可するなら、専用ダミーサイトを作って転送しろ。
とりあえずすぐに思いつくのでこんなトコかな。仕事上ではケータイサイトビジネスの常識(?)に負けて正直守れてませんが・・・orz。自前のケータイサイトを作るときにはひとつひとつ実践して行こうとおもいます。

最後に高木浩光さんのエントリーにあるタイトルで「退化してゆく日本のWeb開発者」が気になりますが本当に最近のWeb開発者はHTTPを知らない人が増えてきています。一切ライブラリを使用せずPerlでWebアプリ組んだ経験を持つ人が激減しているのが大きな原因と思います。PHPはGET/POSTが簡単に取得できるとPHPの実装ばかり自慢してその仕様を理解しようとしない後輩を見たとき、Webプログラマーの将来が危ないって感じましたが、本当にそうなってきているのかな・・・。他方Javaの世界でもフレームワークバカが増えて大変だという事を耳にします。

アーカイブ