スマートフォン向けはガラケー向けと違ってAndroidを含めると機種の差異を把握するのは事実上不可能なのでその辺は空気読んでそれを基準とする感じになりそうですが、特にスマートフォン向けと呼んでいる物はHTML5を使ったものやiPhoneアプリ風なインターフェースを再現したものを指すようですね。iPod touchを持っているので自分用にスマートフォン向けウェブアプリでも作ってみたいとは思っていますが、まだブクマが後で読む状態。。。
Web制作の最近のブログ記事
今年はPython+Djangoな開発をしているわけですが、それだけでなくCSS+Ajax+JSONとフロントエンドもリッチだったりするととにかくデバッグが大変！AjaxのあたりでInternal Server Errorだした時に画面でPythonのエラーが確認できないとか流石に参った。。。で、FirefoxにはLive HTTP Headersのようなツールがあるので、もしかしたらボディ部分を記録してくれるツールあるかもっと調べたら良いのを見つけました。
HttpFox :: Add-ons for Firefox
これはリダイレクトで飛んだりしてもすべて追跡してくれるしAJaxで定期チェックするようなアクセスについても全部ログを残してくれる！
これはおすすめです！
SVGなんて今更？と思われそうだけど、ウェブページ作成が目的ではなくてePubで作成する書籍内の図に使ってみようと思った。今後電子書籍が再生できる端末の解像度は上がっていくだろうから、高解像度端末で再生したときに、図だけボケボケなんて事の無いようにベクター画像で作っておいたほうが良いですね。
ただ漫画とかで紙原稿のものは大変でしょうね。将来の漫画家はPCでベクター画像描いて電子出版なんて事もあるのかな？
Inkscape 自由に描く。
この前、phplistを導入してみてどうも使い辛い感じがしたのでもう少し範囲を広げて探したらPerlで作られたエーシーメーラーを見つけました。
こちらのインターフェースは直感的にも使えて導入しやすいのと、デコメールに対応しているのが強みですね。これならおすすめできます。
acmailer│無料で使えるメール配信CGI「エーシーメーラー」
http://www.acmailer.jp/
個人的にメルマガ配信を自力でやることも無くて、サーバ構築してもMLはaliasで済ませるような程度ですが、ECサイトだと必須に近いのがメルマガ配信システム。年々スパム判定も厳しくなっていくので単純なメール送信でループさせるとスパム判定されたりする。特に携帯は制限が厳しい。
とは言っても外部サービスを使ったりパッケージ購入したりすると費用もバカにならないので、無償で使えそうなのを試してみようと思った。
pc.casey.jp » phplist - オープンソース高機能メールマガジン
http://pc.casey.jp/archives/1866 
これでスマートフォン⇔PC間で絵文字のやりとりを標準仕様で出来るようになるのかな。どちらかというと顔文字のほうを使うタイプなのであまり恩恵を受けないかもしれませんが、ますますガラケーが浮いてしまいそう。
「Unicode 6.0」が策定、絵文字が国際標準に - ケータイ Watch
http://k-tai.impress.co.jp/docs/news/20101013_399811.html?ref=rss 
詳しい経緯は公式発表で確認ですが、つまりmemcachedダウンでDB負荷急増でダウンという事ですか。そうなるとなぜmemcachedが落ちたかという事になりますが最近負荷軽減にmemcachedを使うケースが増えてきたのでとても気になりますね。HTTPでさらに動的ページ生成って環境にやさしくないよな。。。アプリにしたら無駄な通信とレンダリング消えるのにと思う日々です。
『mixi』のアクセス障害のお詫び及び復旧に関するお知らせ « 株式会社ミクシィ
データキャッシュシステム＝memcachedなのかはこちらが情報元
これはどうなのかな？今更というのもあるのですが。。。
ケータイHTML ポケットリファレンス
本棚に青マンモスがあるのでそれを見れば速いのですが、ちょっとネットでも探してみましたら直ぐにみつかりました。
phpでベーシック認証 - bnote
これは再掲な気がしますが前回より資料が増えているみたいなのでチェックします。
情報処理推進機構：情報セキュリティ：脆弱性対策：安全なウェブサイトの作り方
http://www.ipa.go.jp/security/vuln/websecurity.html
最近のEclipseってプログラミング言語別のパッケージが出ているけどプラグインとの相性問題で苦労。。。例えばPHP組むからPDTにしたらSubversionのプラグインがよくエラーを出すとか。。。今後もClassic一択にするかなぁ。。。
Togatterでこんなの見つけました
これはどこでも同じだと思う。
これは現在の悩み。全く読まないような酷い人はなかなかいませんが、自分がコーディングする部分だけの資料で理解出来てると思っている人は多い(参照しろと書いても読まない人が多い)、若しくは割り切って知らないものは知らんと言った態度の人もいる。時間とコストが少ないせいでもある。
SEが設計書まで書いてプログラマに渡す場合で仕様書に書かれているルールはわざわざ設計書までに同じことを書かない事もある。その期待に外れて仕様書を無視して設計書に書いている事だけを見てコーディングして後は知らん。というのは経験した。あと仕様が複雑になってくるとデバッグする目の数が必要になってきてそういうときに仕様書をしっかり読んでくれるプログラマは仕様に潜むレアなバグの発見に繋がったりして重宝します。
ウェブデザイナーでもRGBが理解できないとか透過GIFの原理を全く知らないとか、ウェブ上のデザインなのにメートル法で表現しピクセル単位で要望すると逆切れしたりとか。アバターの着せ替えとか2Dのゲームではドット絵師としてのセンスと合わせて必須事項だと思うのに。特化してて面倒なのはバッチ屋になってしまってる私も反省。
ゲームはともかくシステム開発でも同じような状況。業務の多様性は否定しないが毎回、創造して作らせていたらコスト削減がうまくいかない事にいい加減気付くべき。まぁ気付かれてどの会社も一斉にパッケージを使い始めて業務をパッケージに合わせるようになったら、コストメリットの無い独自開発が減るが同時に沢山のプログラマが職を失うかもねｗｗｗ
人数の多いプロジェクトや役割分担をローテーションせずに長期でやってると陥る罠。全体を見れる人が育たないのも問題だが欠員が出たときのリスクがヤバい。何とかしないと。
いきなりweb屋がゲーム作れるわけでもないのでゲーム業界の方々と協力が必要ですが、大きなゲームを一本作るというのは無くて小粒にタイトル量産、権利を受けて移植量産って感じでした。こっちは素人なんで企画さんとゲーム屋さんにお任せではあります。
Togetter - まとめ「ゲーム制作にまつわる問題点」
結構似たような事や関係してそうな事ががあるんですね。以下同じだと思った内容を抜粋
金出してる奴は金出してる以上のリターンを求める。全部いう事聞いてたら赤字になる。
昔は全部紙書けばどうにかなるだろうと思ってた。無理だった。だって、紙読まないんだぜ。かなりの開発者が。
ちゃんと仕様書を読むプログラマはものすごく重宝する。
最近のプログラマは、高速化や圧縮の小技を知らない人も多い。
確かに、こういうプログラマは任せられる範囲が限定されるのでやりにくい。でも教えてあげて次回は出来るようになってもらうしかない。
ちなみに最近の絵描きは、プログラム的知識に乏しいので、パレット（クラット）や、ファイル、ディレクトリ、なんやらかんやらの知識をぶっこむのが超大変。３Ｄツールの操作に長けるが絵が下手とか、絵は上手いけど３Ｄ苦手とか、特化してて面倒な人も多い。
日本のゲームの特徴として、毎回エンジン新造したり、ルールを根底から創造したりするところがあるので、これはなかなかツール化が大変だ。（時間とハードスペックが解決するとは思うが）
細深化もしているので、各開発者は自己パートのエキスパートにはなるんだけど、全体を見る能力が磨かれていかない。
ゲーム業界が煮え詰まってエライコトになってるところに、「一方webと携帯屋はソーシャルゲームを作った」という状況
ソーシャルゲーって簡単そうだけど、あれはコストかかるんだぜとか。アジアプログラムの流出とか
その割りに単価が安いですよね。昔はFlash制作に夢見てましたが今のFlash受注単価見てるとアニメ制作と同じ道に進んでいるような気がするのです。
テストについてはこちらの日記を見つけました
2010-06-12 - 未来のいつか/hyoshiokの日記
全く同感。
テスト書くこととテストをすることの違い
みんなテストはしますが、テストを書くというのは本当に少ないですね。
私は同じ作業をしたくないのでテストを書きますが、そのコードをプロジェクトごとに使い捨てにしてたのは反省。
テストプログラムを作ると言うことは、エクセルのシートにテストケースを書くことではない。
手作業テストだと実行可能なケース数が限られますからね。エクセルシートだけで全機能テストはコスト上不可能なのでどこか発生しにくいパターンを端折って想定外で済ますという隠蔽工作を・・・
テストがアジリティをあげる
コンパイラだってソースコードの文法テストツールとして考えることもできますからね。だからコンパイラを通さないスクリプト言語だとツマラナイ構文エラーで無駄な作業が発生するし。
さてさて、ePubで仕様書・設計書が効率よく出来ないかという課題。ePubの原稿はXHTMLなので、SGMLから始まり、ウェブ用に簡略化したHTMLが登場しそしてXHTMLとなったのでePubはSGML系マークアップ言語。それに対してPDFはLATEXやPostScriptの仲間って感じかな。
で、PDFの場合はプリントドライバさえあればどのエディタからも作成できる手軽さはあるもののAdobeのビューアは動作が重いとか、文字を読むにはXGA以上の解像度必須だとかいろいろと再生環境の条件が厳しいです。それに対してuPubは原稿がXHTMLの為、解像度の低いモバイル端末でも文字を読むのには問題ありません。但し印刷用ドキュメントのような考えで作っていると思わぬレイアウト崩れに悩む事になりそうです。
今、ネット上でePubについて書かれている内容を見るとiPadで再生できる事と、論文向きで雑誌や漫画の電子化には向かないといった記述が見られました。確かに電子書籍販売については日本国内ではePubは流行らない可能性の方が高いですね。DRM掛けたい配信元の希望にも沿わないだろうし、和書は体裁に拘る本が多いので不向きという事ですか？また文章中心の本となると縦書きというのも原因かな？強いて言えばケータイ小説や2chスレから編集した本は横書きのテキストなので相性が良いと思います。
本題の開発ドキュメントについてですが、現状としてはこれが何の生産性に寄与しているのか理解しがたいドキュメントが眼に余る状況なので移行は難しいかな？と考えています。ただ国内ITの生産性の低さの根本原因にもなってそうなのでドキュメント制作のシステム化を計りたい。システムを作っているのにドキュメントが手作業とかいつまでやっているんだという状況を改善したい。
まず始めに廃したいのはページ枠。開発ドキュメントのページ枠というのは只の枠ではなくて、タイトルは当然、そしてそのページ編集された日付とか編集者の名前とかリビジョン番号とか入っています。これが開発管理のシステムからのアウトプットそのままならそれで良いのですがワードやエクセルで手作業管理とか異常な管理状況だったりしませんか？もちろんそんな枠なんて製品に影響出る場所じゃないから修正時に更新を忘れたりして最終的に意味を持たない記述になってたりしませんか？というかそんなとこ編集する時間があったらテストに廻せよよ言いたい。大体、更新内容や日付は表紙の次のページに改版履歴作ってそこに書けば十分だろう。
さらに愚かしい事に、外注を使った開発の場合、ドキュメントを受け取った会社がその枠を再作成します。孫請けなんてあったらそのドキュメントに対し「枠編集」の人件費が３倍です。そんな事になるのなら最初から枠なしで良いのに、自己主張の為だけにコストを増やしてバカの極みです。まぁ発注側から外注に独自の書式で提出しないようにクギを刺せば済みそうですが。
次にあり得ないのはワードやエクセルまたはパワーポイントでお絵かき。企画書なら見た目重要なので仕方ありませんが開発ドキュメントは正確さが大事で偽者の絵をわざわざ時間掛けて描く意味が分からない。これは私自身失敗したことがあるのですが画面イメージを時間かけて作図したがフォントと文字数の関係から通常のHTMLでは実現が困難だったりするイメージが出来てしまい、こちらとしてはその辺は拘ってなくて表示する内容さえ正しければ良いレベルだったのが、知らない間に無理やりその資料そのままを再現しようとして外注の進捗が遅れたことがありました。で肝心の表示内容の方はバグだらけだったので一括したらチクられて外注イジメの疑いを掛けられた。そういうことがあったので画面イメージはHTMLでモックを作ってキャプチャーしたものをドキュメントに貼り付け、モックも一緒に渡す形式を採用しています。特に見た目が重要でないシステムほどこの辺りで無駄なコストを発生させない配慮は必要だなと感じています。
そして最後はエクセル。この表計算ツールは印刷に関しては本当に使いづらい上にちょっと気を抜いてプレビューチェック忘れた時等に印刷事故を起こし、紙資源を破壊する。印刷事故起こさないにしても毎回プレビュー出して印刷イメージの微調整やってるとか罰ゲームとしか思えない。但しバグシートやテスト項目書などワードよりもエクセルで作成した方が効率が良いドキュメントも存在する。エクセルを方眼紙代わりにして普通のドキュメント書くのは論外。エクセルはそういう使い方するツールじゃねーから！
現状で上記３つをクリアすればePub化はし易いと思っています。さらにウェブシステムで開発ドキュメントの内容を入力するようにして出力結果がePubなら、バグシートや枠の問題も特に問題ないと思います。フロー図とかは他のツールで描いて埋め込むしかないのがちょっと面倒かな？これもしっかり作りこめばウェブシステムで自動生成できるかもね。ウェブだと共有やバージョン管理もしやすいし印刷も減らせるかもしれません。
その他としてはWikiやブログがePub化できると便利かも。phpDocumentotのようなソースからリファレンスマニュアルを生成するツールがePubに対応してるとこれも便利かも。
iPadが発売されてEPUBフォーマットが話題になっています。XHTMLベースで軽くてオープンな形式となれば電子書籍でこれを利用しない手はないでしょう。
今まではPDFで電子化を考えていましたが、既存の本のスキャニングの場合は仕方ないとして、これから作成するドキュメントは全てEPUBに変換できるようにしようかなっと。ドキュメントは仕様書等も含みます。
前からウェブでドキュメント作成できれば効率上がるだろうなーと思いつつ結局やらずじまいですが、EPUB形式なら、プロジェクト管理とドキュメント管理全てをウェブシステムで行ってEPUB形式でエクスポートって形がいいかな。
そこまでは先の話だけど。
とりあえずはPCやタブレットでさくさくドキュメントが見れるのを実現したい。
長い間携帯サイト製作やってると独自ノウハウもできますが、PCサイト製作のノウハウを吸収できてないなっと反省。むしろ勝手サイト製作ノウハウの方が最近生きているような気がする。
Yahoo!ケータイのかんたんログイン脆弱性について詳しく解説された講演資料「ケータイ2.0が開けてしまったパンドラの箱 」 | ke-tai.org
http://ke-tai.org/blog/2010/05/25/hashpandr/ 
ソフトバンク2Gの停波に伴ってユーザエージェントによるキャリア判定のロジックを書き直してみました | ke-tai.org
http://ke-tai.org/blog/2010/04/15/uaswitch/ なるほどねぇ・・・特にニュースで聞いていないような気がしますがこっそり停波した？で、UA判断にJ-PHONEは用いなくても良いと。
それとサラっと掛かれてますがKDDIのUP.Browser端末も停波ずみ？昔の端末ってKDDIの文字が無かった頃のかな？確かにそうなればKDDIで見るほうが正しいですね。Vodafone機にUP.BrowserがあったりしてキャリアチェックするときはKDDIよりもSoftBankを先に判別しないと事故る場合がありますからね。
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/ この中でクライアント上にリレーショナルデーターベースを持てるという所に希望を感じたｗ。というのもウェブアプリで運営の中の人が使う管理機能等でもログ集計とか基本サーバー上で行っていることが多いじゃないですか。生ログから表示用の集計まではこれまで通りサーバー上でバッチ処理等で行えば良いのですが、『集計条件を変えて再集計』みたいな機能は本来クライアントでやった方が良いわけなんですよね。抽出条件代えるだけならサーバー上でも良いが集計条件変えるってなると絞込ではなく再集計となって管理系サーバーの負荷が気になるし（フロントにはお金掛けても管理系は節約したりしますからね）、だからといってアプリ開発すると配布管理が面倒だとか言われ、FLASHにするには開発体制が揃わないとか開発コスト上がるとかでまた難儀だったりしています。(システムに強いFLASH開発会社ってそんなに多くないからなかな？普通のウェブアプリ開発だと開発メンバーがFLASH持ってないとか、スキル不十分とか・・・)
現状、表示だけのHTMLがアプリとしての機能を持ちクライアントにDBを持てるとしたら上記のようなFLASH開発体制が整わなくても実現できそうな気がします。
ウェブページの作成などでDreamweaverではなくてテキストエディタなどで書いているとき、色については結構勘で設定したりしますが、表示させてみてちょっと変だな～と思う事が多い気がします。だからといっていつもカラーパレット持ち歩いているわけではないのでこういったページがあると便利ですね。
カラーパレット [フルカラーセレクト]
http://web-img.com/color/full.php カラーパレットのページは欲しいなと思うたび検索エンジンで探したりしてますが、今回見つけたのがこのサイト。作りもシンプルなので使いやすいです。
