それにしても、ここの現場をとりまく人間共は使えないのが多い。
やる事といったら常に会議をしてるだけ。
そして自分では作れないから、それをどこに作らせようか必死に悩んでいる。

目に余るので、救いの手を差しのべる事にする。
どうせ暇だったのでちょうどいい。
聞いてみると、おそらく5人日程度で出来そうなプログラムを
作る人がいなくて困ってるらしい。

--- 作らないと始まらない ---
そんなの考えてる暇あったらさっさと作れよ。
俺が作りますよ、と声を掛けると「あ、もう開発を初めるんですか？」と戸惑う奴ら。
おいおい、仕様も大体決まってるんだからもうやる事はそれしか無いだろ？
これ以上何を詰める必要があるというんだ。

これだから設計しか出来ない輩は困る。
徹底的に製作を後延ばしにしようとする。
なぜこんな奴らが高い給料貰ってるんだ。この不条理な社会に腹が立つ。
さっさとこんな現場からは手を引きたいものである…

何か最近ひたすらキーボード打ってる気がするぞ。
昨日なんかおそらく2000行以上書いて手が疲れ気味。
まぁやる事ないよりはマシですが…

--- 現在のメイン ---
そんな中でも、Ruby Eclipse Pluginの製作は欠かせない。
まずは色付け、インデント付け、デバッガくらいは欲しいものだ。

初めに手を付けたのは色付け。
それなりのものは出来たので次。
デバッガは予想以上に大変。途中までやって投げる(笑)。
一応ブレークポイントとVariableビューへの表示くらいまでは成功。

最後に、インデント付け。
これにはコードのパース処理が必須だ。
今までそういう分野に手を出したこと無かったから大苦戦。
とりあえず何とか完成したものの…

--- 次の課題 ---
色付けが今いちなので改良を試みるが、これが意外と大変なことが判明。
もともと、EclipseはJavaベースの開発環境なので
Rubyのようなスクリプト言語の色付けには向いていない作りになっている。
今さらながら、Emacsのruby-modeが実現している完璧なまでの色付け処理に感心してしまう。

--- 12月 ---
さすがに12月ともなると色々と忙しい。
仕事の方はそうでもないけど(笑)。

来週は会社の忘年会があるらしい。しかも会社のフロア内で。
あんな狭いフロアに全員収まるのか果たして疑問だ。
もっとも、外でやろうとしたら3000円の予算じゃロクな店が無いからそれよりはマシか。
なんで六本木なんかに拠点を置くんだよ、まったく。
なるべくあんな場所には行きたくないのだ。

昨日、サッカーの東アジア選手権を見る。
日本vs韓国。今年最後の日韓戦(おそらく全スポーツを含めても)。

いつもは0-0という結果は僕にとってつまらないモノが多いけど、
昨日の試合はそうじゃなかった。内容の濃い0-0。
引き分ければ選手権優勝の韓国はあまり攻めて来なかったとはいえ、
終了まで試合を観れたという事はそれなりに良い試合だったんじゃないかな。

--- いつまで使う？ ---
が、0-0という結果はやはり不本意だ。
その決定的な理由が、前半早々に退場になった大久保。
以前から、何度もそのラフプレーを注意されてきた若者は、
この大舞台でも案の定その忠告を忘れていた。

正直、こんなんじゃ日本代表として使えない。
幸い今回は、この試合の結果が直接今後の展開を左右するような舞台じゃなかった。
でも日頃の積み重ねがあってこそ、厳しい時にその力を発揮できるもの。
いつまで経っても成長しないストライカーは、次の代表からは確実に外されるだろう。

もっとも、海外組が参加した時には元々彼の居場所は無いのだが。
高原と柳沢。が、僕は昔から柳沢の実力を信頼していない。
彼に代わる選手は誰か。やはりここは地元だし田中達也を推しておこう。

--- 真冬 ---
最近かなり寒くなってきた。
先週コートを新調したので、それが完成するまでは
コート無しで過ごそうと頑張っているのだが、正直厳しい。
まぁこれも明日までの辛抱だ。

--- 意外な盲点 ---
知らなかった。
Javaのグラフィックライブラリには境界色指定の塗り潰し命令が無い事を。
昔だったら直線や円と並んで必須命令だったはずなのに。

しかも、軽く探した限りでは有名なフリーGraphicライブラリ等も無い様子。
なんで今さら自作のペイントルーチンなんかを作らにゃあかんのだ。
幸い、Cで記述されたペイントルーチンは発見できたので
これをJavaで書き直して使うことにする。

もっとも、こんな処理を必要とするWebアプリの方がおかしいのだが。
毎回塗り潰し処理なんかしてたら無駄な負荷が掛かりすぎるぜ。

っていうか、もしかしたらJavaって全ての描画処理をCPUで行っているのか？
つまり、グラフィックボードの描画エンジンを使っていない。
だからこんなに遅いのか。
いくら機種依存を無くす為とはいえ、こんなんじゃグラフィックボード開発者が泣いてるぜ。

--- 絵に描いた餅 ---
この現場を一言で表すならば、まさにこの言葉以外思い付かない。
あやふやな仕様、あやふやなスケジュール。
全てが存在していないのに、あたかもそれがあるように開発を続けようとする。

よくこんなんで開発の仕事を受ける気になるよな。
とにかく、ここには一切のプログラマがいない。
SE(設計者)なんて誰でも出来るんだ。もっとも、そこからは腐った設計書しか出来上がらないが。

--- 構造改革 ---
いい加減、この構造(SE,PG)を改革したらどうだろう。
ちょっと前、音楽業界の構造を改革しようとしている
247ミュージックのドキュメントをやっていた。

音楽業界は、効率化を進めるあまりミュージシャンの「個性」を消してしまった。
しかし経済の面から見れば、それらの方針を取る企業だって必ずしも間違っているとは言えない。
もちろん、僕が応援するのは247ミュージックの方だが。

--- この業界 ---
この業界は、音楽業界と違って「一般人」相手の商売ではない。
一般向けアプリを作っている会社を除いて、
その大半が「企業」を相手にした商売になる。

だから、こんなどうしようもない構造でも存続できるのだ。
企業より遥かに厳しい一般人を相手にしていたら
とてもじゃないがこんな構造では確実に潰れるだろう。

つまり、よその企業から金を踏んだくっている訳だ。
これも一つの経営方針かもしれないが、この方針では決して長くは続かない。
相手企業もそこまで馬鹿じゃないはずだから
いずれこの杜撰(ずさん)工事は見捨てられるだろう。
前にも言ったかもしれないが、今この業界はバブル時期にあるという事を忘れてはならない。

バブルが弾けたときに生き抜いていく為には、
その時にも通用する実力を身に付けていかなければならない。
その為には、この構造を変えていく必要がある。
もちろん、これを変えていくには相当の力が必要なのだが。

--- 僕が考える開発現場の分け方 ---
まず、プロジェクトマネージャは必要だろう。
彼がプロジェクト全体のスケジュールを管理する。

そして、現場におけるプロジェクトリーダー。
彼は現場のプログラム全体を把握し、必要な仕事を各グループに割り振る。
現場における全ての責任は彼に押しかかる。非常に重要なポジションだ。

そして、各グループのリーダー。
その下に数人のプログラマが付く。
その他に、金銭関係を扱う営業担当も必要だね。

--- 実際の作業 ---
この中で、仕様を決定するような相手との会議に参加する人間は
プロジェクトリーダーと、各グループのリーダー(一部でも可)。
プロジェクトマネージャは必ずしも参加する必要は無いかもしれない。

プログラムを組める必要がある人間は
各グループに存在するプログラマ、そしてグループリーダー。
もちろんプロジェクトリーダー。

実際にプログラムを組む人間は、大半はプログラマだが
それを行う前に、グループリーダーが
プログラム構成や共通化のプログラム仕様を決定する事が必要だ。
そうしないと、プログラム全体の統一化、効率化が図れない。

--- プログラマ ---
この中で、プログラムを組めなくていいのは唯一、営業担当だけだ。
彼らは別にプログラムを知っている必要は無い。
プログラムを知らない相手の人間と同等の立場で話すためには
むしろ知らない方がいいかもしれない。

一般的に言うSEなんかは、絶対に必要無い。
設計書を作るのは、各グループリーダーの役目だ。
もしくは、その下に付くプログラマに任せてもいい。
設計しか出来ない人間が、アプリケーションを作る上で
どれだけ役に立っていないかは、色々な現場を見れば一目瞭然なのだ。

--- 全ての基準 ---
全ての基準になるのはプログラマだ。
これが、僕の考える開発のスタイルに他ならない。
プログラマを続けていけば、必ず設計の技術も身に付いてくる。

プログラムを組む事を考えた設計は、どんな設計よりも優れている。
プログラムの事を何も考えていない設計は、とても設計書とは言えない、
まさに絵に描いた餅でしか無いのだ。

--- 早速 ---
ではここで一つ、プログラムの組めない設計者の実態をお伝えしましょう。

彼はあるグラフを生成するプログラムの設計をしているようです。
そして、プログラマである僕に
線を引くのと点を描くのとどっちが簡単ですか？みたいな事を聞いてきました。
そんな事もわからないなんて！
当然答えは「どっちも簡単」です。

そう、プログラムを組んだことが無い人というのは
こういった決定をする際の判断材料が圧倒的に不足しているのです。
だから、とんでもなく間違った設計書が出来上がってしまいます。

こういった設計書はプログラム化できません。
つまり、プログラマは自分で基本設計から見直してプログラムを組んでいく必要があるのです。
そう。こうなってしまうと先程のSEの存在価値が無くなりますね。
だから、彼らはいなくていい存在なのです。

--- 傾向と現象 ---
こんなに長文を書くということは、つまり暇だという訳です(笑)。
仕事の出来ないオッサンはどこかに出張しているらしい。
後は定時を待つだけである…

昨日はライブに行ってきました。
毎年恒例(？)LoRaNライブ。

最近はメンバーがプロデュースしてるバンドが前座に出てるのだ。
それ自体は別にいい事なんだけど、ライブ時間がかなり長くなるので正直疲れる。
前座が30分×2。そしてLoRaNが約2時間半。

まぁライブの内容は言うまでもなく。とにかく良かった。
いつもの事ながら、明日仕事あるのに遠くから来てる人達には感心しちゃうね。
夜行バスで帰ってそのまま仕事に直行だとか。
僕も負けないように今日は仕事に行くことにしました(笑)。

--- ライブモード？ ---
なんか昨日は久々のライブだったので、
急にライブ行きたいモードに突入してしまいました。
そんな訳でひたすら良さそうなライブ探しon仕事中(笑)。

アンリミは年末ワンマンは無いらしい。
敦さんもいずみさんも、ワンマンは無い様子。
ちょっと前までは学校の先生をやっていた(まだやってるのかな？)
知り合いの子がやっている[ma]というバンドも、
とにかく色々探してみるが…なんでこういう時に限って無いんだろう。

年越しライブならいくつかあるんだけど、どうも行く気がしない。
オールの雰囲気ってのはあんまり好きじゃないのだ。

とりあえず、弟がやってるバンドの知り合いバンドが
今週末にやるらしいのでそれに行くことを検討中。平日だから確定とまではいかないけど。
HPで公開してた音源が結構良かったのだ。
ちなみに、19(金)大宮HEARTSでPM21:20頃の予定なので、来れる人は来て下さい(笑)。

--- 年末モード？ ---
さぁ、いよいよ今年の仕事もあと2週間を切りました。
こうなったらもう気分は休みモードです(速っ)。
ここんとこ一段とやる事が無くて少々苦痛です。
誰か、僕にプログラミングのネタを提供して下さい(笑)。

午前中、例のオッサンから何やら定義書を渡される。
どうやら次に取りかかるシステムのものらしいが。

とりあえず読む。
ページ数ばかり多くて内容の無いこの作りにはもう慣れたけど、
変なのがその文体。
まず「ですます」口調っていうのが違和感有り有り。
普通定義書っていったら「?である」口調でしょ。

さらに変なのが、「?して下さい」…っておい。
なに定義書でお願いしてんのさ(笑)。
そんな謙(へりくだ)ってどうすんの。
他にも「?できると思います」とか、そんなんばっかり。
大人の事情か何かわからんが、こんなもの俺に見せて
一体どんな返答を待っているんだろうね。奴らは。

--- 複雑な事情 ---
この定義書、なぜか同じようなものが2種類ある。
一つはどこかの会社、もう一つはこの現場の会社が作ったものだ。
どうも、これは「定義企画書」であり、この企画書を元に
どこかに製造を依頼するという目的があるらしい。
つまり、この2つの内良い方を選んでくれという訳か。

残念ながら、この両者を比べたら
圧倒的にこの会社が作ったものの方が腐っている。
何を言いたいのかが全く伝わってこない。

おそらく午後にはオッサンが帰ってきて
「どうでした？」と聞いてくるだろう。
その時の僕の答えは…まぁ、言わずもがなです。

「誰だよ、これ作ったの」とでも言ってやっても良いのだが、
まぁここは大人の対応で交わすとしよう。

--- 無駄金 ---
巨人の清原は来年の年俸が4億5000万円だとか。
そんなに高い金払う必要がどこにあるんだ。
去年それだけの活躍をしてないだろ。年功序列か？馬鹿馬鹿しい。

もう少しうまいお金の使い方があるだろうに。
若手に使うとか、ファンに還元するとか。
巨人のファンは一体どう思ってるのか聞いてみたいね。

--- お払い箱君 ---
現場では年末の激しい仕事風景が繰り広げられている。
そう、ここは販売課。
そんな中、いつも上司に怒られてるのがいる。
そのくせ下の人間には偉そうにしてるという典型的なダメダメ君である。
来年あたり居なくなってたら笑えますな。

なんでこの部屋はこんなに寒いんだ。
どっからか冷たい風が入り込んでくる。
これが冷房だったらひどいもんだな。

--- まだまだ未定 ---
相変わらず仕様がふわふわしたままです。
さっきも、昨日確認したばかりの仕様が間違ってるだか何とか騒いでいる。
やっぱりここは駄目だ。
現場の人間もそうだが、それ以上に相手側の人間が問題らしい。

大企業の人間っていうのは、のんびりする事に慣れてしまったようだ。
一向にプロジェクトを進めようっていう気配が感じられない。
今日は何をして時間をつぶしましょうか…

--- 酒の席 ---
仕事後、現場の人の結婚祝いという事で食事会。
会場は小さめのイタリアレストランだったんだけど、
どうしてこういう店のカクテルってのはあんなにまずいんだ。
まずい酒だと酔い回るのも速いね。
この前の忘年会もそうだったし、たまには外でうまい酒を飲みたいもんである。

おっ、今日は僕の島に誰も人がいないぞ(笑)。
これで好きな事やり放題ですな。

どうも毎週金曜は全体的に人が少ないらしい。
フロア全体でも10人くらいしか居ないぞ。

--- MySQL ---
僕の推奨するアプリケーションはいくつかあるけど、
データベースでいったら迷わずこのMySQL。

まず、僕のような個人開発者にとって最高の強みなのが
GPLであるという事。
GPLライセンスでは、個人使用においては完全に無料で使用できる。
そしてもちろんオープンソースである。

商用で使用する場合にも、1ライセンスが29,800円という破格の安さ。
CPUをいくつ積んでいても「1マシン」ならライセンスは一つでいいそうだ。
さらに数種類の年間サポートも別途受けられる。

それに対し、現在多くの企業で採用されているOracleはどうだろう。
最高位のEnterprise Editionは、1CPU当たり5,000,000円。
他にも100万円以上する付属アプリが山ほど。
こんなに高い金を出したって、その機能を使いこなせる企業はごくわずかに違いない。

多くの企業にとって、Oracleを使う理由はただ一つしか無い。
「一番有名だから」
そんな事だけでアプリケーションを判断するのは非常に危険だ。

--- Webサイト ---
ほんと、企業のWebサイトには使えないものが多い。
Webサイトにとって一番重要なことは、
「いかに目的の情報に簡単にたどり着けるか」だ。

これには使っているユーザからの声を反映させるのが重要だと思うが、
これをやっている企業は少ない。
だからこれ程までに使えないサイトが氾濫しているんだ。

今日も、りそな銀行の年末年始の営業日を知りかったのに
結局その情報が見つからない。
駄目な企業っていうのは、全てにおいて駄目なんだって事か。

--- 再びライブ ---
先週に続いて今日もライブ。
平日に仕事終わりでライブ行くことなんて滅多に無いんだけど。
弟がやってるバンドの知り合いバンドのhamlet hamlet。
HPで音源が公開されてたのでそれを聴いたのがキッカケかな。

基本的に女性ボーカルはあまり聴かない僕だけど、
彼女の声には魅かれるものがあったので良かった。
「4つのライブハウス代表アーティストが激突するバトルイベント」という事で
結構人が入ってた。
来週も渋谷のDeSeOであるらしい。時間が合えば行ってみようかな。

むむむ…またminidns.netが停止している。
ここが止まってるとうちのサイトは完全にダウン状態だ。
そろそろ自宅のDNSサーバを使おうかな。

--- firebird ---
こんなものがあったとは。
Mozillaが開発する次世代ブラウザ。

今までIE以外はスタイルシートの対応が遅れてたので
仕方無くIEを使ってた部分もあるんだけど、
このfirebirdはその部分もほぼ完璧。
FLASHも使える。まだSVGは使えないみたいだけど、今後の対応に期待しよう。
何よりオープンソースっていうのがいいね。

しかも、Windows / Linux / Mac 全てに対応している。
ようやく全プラットフォーム共通のブラウザが誕生したわけだ。
もうこれで、ブラウザによる動作の違いに悩まなくていい。
作る方としてはこれほどありがたい事は無い。

--- 会議 ---
この席はいつもは静かなんだけど、
後ろが会議スペースなのでこれが始まるとうるさくて困る。
…ふぅ、どうやら今日はすぐ終わったようだ。

--- ここも ---
djbdns.qmail.jpにも繋がらない。
なんか今日は世界的にDNSが調子悪いらしい(笑)。
それとも、単にこの現場のDNSサーバが壊れてるだけか？

…ふぅ。午後2時、ようやくminidns.net復帰。
俺が確認できただけでも4時間以上止まってたことになる。
やぱり無料サーバに頼るのは良くない発想かも。
他に独自ドメインのDyncmic DNSサービスを無料でやってる所は無いようなので
月額500円程度の有料サーバに頼むか、それとも自宅でDNSサーバを公開するか。
悩むところである。

--- 席外し ---
これって一般用語なんだろうか？
「○○さんは？」
「あ、いま"席外し"」
のように使うらしい。この現場でたまに耳にするのだ。
なんかの技(ex. 間接外し)かと思ったぞ…俺だけか。

--- 稼働率急上昇 ---
午前中はのんびりしてたのに、午後になって
ちょっと時間の掛かる作業が入る。
なんとか定時前に終わらせたものの、今日は結構疲れました。

--- 携帯対応 ---
今まで、僕のページはほとんど携帯から見れないものが多かった。
しかし、これからの事を考えたらそれではまずい。
弟のバンドHPを作ることになったのがキッカケ。
弟は携帯からしかネットに繋げないので、携帯版とPC版を分けることにした。

が、現在僕が作成してるBBSと日記は携帯から使えない。
そこで、泣く泣く(？)レンタルを薦めることにしたのだが、やはり少し納得がいかない。
全部自分で提供するのが自宅サーバを運営する人間に課せられた使命だ(マジかよ)。

JSPを使ってれば、携帯に対応させるのはそんなに大変なことじゃないので
やってみることにした。
とりあえず、BBSは新規に作成してほぼ完成。
日記は今までのものに携帯版を追加するという方式で現在作成中。
しばらくはこれで暇をつぶせそうだ。

いきなり重いタイトルですな。
だけど、これを書かずにはいられない。

「金儲けを優先するとプログラムがお粗末になる」
こんな現実がある。
少々バグのあるプログラムの方が、それを修正する度に
ユーザから金を取れるというのが奴らの考え方だ。

こんな事があっていいのか。
それは、優秀なプログラマを根底から否定している事になる。
それを実践しているのが、WindowsとBIND(DNSサーバ)だ。
確かにWindowsは無料でUpdateを行っているかもしれないが、その度に
Microsoftにアクセスしているという事を忘れてはならない。

この日記の仕様を少々変更する予定です。
変更内容は、「閲覧パスの有無を日付毎に設定できるようにする」事です。
なぜこんな事をしようと思ったかというと。
なるべくなら一般の人に公開した方が良いと考えたからです。

かつてこの日記に閲覧パスを付けるキッカケとなったのは
「一般の人に見たれたらまずい内容を書けるようにする」為です。
一応仕事には「守秘義務」というやつがあるから
実名をバンバン出してると少々(かなり？)まずい訳です。

--- デメリット ---
ただ、実際にはほとんどの日記は閲覧パスを付ける必要は無いことも事実です。
そういった日記も含めて全てを閲覧不可にしてしまっていては
あまりに周りを遮断し過ぎているという印象を持たれる可能性もあります。
仮にもインターネットという土壌で公開している訳ですから、
一般の人が見れる日記というのも必要です。

--- 変更内容 ---
そんなわけで、日付単位で日記の閲覧有無を指定できるようにします。
おそらく今週末には完成する予定です。

--- 新記録 ---
おぉ、なんか昨日のアクセス数はすげーぞ。
ログから推測するに、どうもこの前やった「自宅サーバー管理人に100の質問」
が要因らしい。

この質問を提供している「Dream-Seed」という所のBBSで
質問に答えたことをチョロっと書いただけでこの反響。
やっぱり人気のあるサイトの影響力は大きいね。
まっ、当然今日からはまた普通のアクセス数に戻るだろうから
ご心配無く(笑)。

--- 手直し中… ---
という訳で、過去の日記を校正中。
うむ、閲覧パス付ける前から実名が結構出てるぞ(笑)。
修正の結果、閲覧パスワードを全面的に解除することにする。
やっぱり皆に読んでもらった方がいいよね。
あ、僕の日記だけだよ。閲覧パスワードを解除したのは。

新BBSを作りました。
今回の最大の目玉は、携帯からも使えるものにする事。
で、これから携帯対応サイトを作る人にいくつかアドバイスを。

まず、携帯版のページはPC版と分けましょう。
もちろんシンプルなページならPC版のものをそのまま携帯で表示することも出来ますが
あまりお薦めできません。
「そんな面倒くさい事できるか」という方は、携帯対応はまた今度にしましょう(笑)。

--- 機種による違い ---
ここでも、各携帯メーカーによって様々な規格の違いが存在します。
現在、i-mode / vodafone / ez-web という3種の規格があります。
しかし、メーカーによって画面を作り替えたりするのはさすがに面倒です。
共通の作りにする事は比較的簡単なので、そうする事をお薦めします。

以下、そのときの注意点です。

--- 文字コードはShiftJISにする ---
これが意外とやっかいです。
普段からShiftJISにしてる人なら良いのですが。
ちなみに、EUC-JPに対応してるのは今のところVodafoneだけのようです。
そして、METAタグも必ず入れ文字コードを特定させます。

--- タグ等 ---
基本的なタグは大体使えます。
あまり気にしなくていいはずです。

が、スタイルシートやJavaScriptは一切使えません。
特にJavaScriptが使えないというのは結構痛いですが我慢しましょう。

--- 画像について ---
これが厄介です。
というのも、共通して使えるフォーマットが無いからです。
i-modeはgifのみ、Vodafoneはpngとjpeg、ez-webはgifとjpegです。

知ってる人も多いと思いますが、現在gifはフリーではありません。
何らかの有料アプリケーションを使わないでgifを使うことは違法になってしまいます。
ですから、僕も含めてそういう人はi-modeで画像を扱うことができません。

という訳で、僕個人的には携帯ページで画像は使っていません。

--- 画面サイズ ---
これは機種によって様々ですが、
とりあえず横幅20(全角10文字)で作っておけば大体の機種には対応できそうです。
縦幅は8?10くらいが一般的でしょう。

--- ファイルサイズ ---
一番気を付けなければいけないのがこれです。
メーカーによっても違うし、同じメーカーでも複数の規格があったりします。
とりあえず現在使われている携帯ならば、
i-modeで5K、Vodafoneで6K、ez-webで9Kが主流のようです。

ですから、5Kに収めとけばほぼ全ての携帯で見ることができます。
これは、画像サイズ等を含めた1ページの総サイズ数です。
サイズを縮める手法については、また機会があればそのときに紹介します。
掲示板などの動的ページでは、これを制限するのに様々な工夫が必要になります。

--- フォームについて ---
携帯ページではもちろんフォームを使うことが出来ますが、
気を付けなればいけない点がいくつかあります。

--- 文字サイズ ---
INPUTタグにはsizeとmaxlengthという2つの属性を設定できます。
前者は表示上の大きさ、後者は入力できる最大文字数(半角単位)です。
特に、最大文字数は制限しておいた方が無難です。

--- アクセスキー ---
携帯は画面が狭いので、画面内の特定位置にジャンプするために
アクセスキーというものを使います。
例えば、「1」を押したら入力欄にジャンプする、といった事が可能になります。
以前はメーカーによって違いがありましたが、現在はACCESSKEYという属性が
全ての規格で使えるようです。
INPUTとAタグの属性として使えます。

--- 入力モードの設定 ---
通常、入力欄では日本語入力ができるようになっています。
しかし、実際にはメールアドレスやURLの入力欄では半角英数字しか使いません。
このような場合、初めから半角英数字モードになっていた方が便利ですよね。

これは機種により若干の違いがあります。
i-modeとez-webでは、istyle属性が使えます。
vodafoneでは、一部の機種を除いてistyle属性は使えません。
代わりに、mode属性を使います。

詳しく書くと長くなるので割愛しますが、よく使う例として
半角英数字の入力欄にはistyle=3もしくはmode=alphabetを使います。
どちらも書いておけば全機種に対応できるのでそうしましょう。

--- 絵文字 ---
絵文字の使い方です。
詳しくは各携帯サイトのページに譲りますが、
各メーカーとも記述方法や絵文字の種類も違うので
これに関してはメーカー毎の対応が必要になります。

なるべくならこれらの分岐処理は
表示コードに埋め込むのではなくロジックを分離させましょう。
例えば、JSPを使っているのならばこの処理をサーブレット側に任せて
JSP側には分岐処理(if文etc.)を持ち込まないようにします。

--- ビューアについて ---
当然、携帯ページを作ったらそれを確認しなければなりません。
しかし、わざわざ携帯から確認していたらお金も掛かるし大変です。
そこで、各携帯サイトではビューアを用意しています。

i-modeなら「iモードHTMLシミュレータ」、
ez-webなら「Openwave SDK」、
vodafoneなら「J-SKY Viewer」。

が、ここで問題があります。
i-mode以外のビューアは、HTTPからの読み込みに対応していません。
つまり、掲示板などの動的なページを確認できません。

そして、J-SKY Viewerは公開を打ち切ってしまいました。
もしどうしても欲しいという方がいれば連絡をくれればお渡しします。
特に配布条件を記述した文章も無いようなので大丈夫だと思います。

--- 最後に ---
う?む、長々と書いてしまったな。
こういうのは日記ではなくコンテンツとして作るべきだよね。
もう少しノウハウが溜まったら考えてみようかな。