« 2004年5月 | トップページ | 2004年7月 »

2004年6月

はきゅーんな掲示板はっけん

ペットうp板

可愛いネコ、ハムその他もろもろがテンコモリだー


追記:"はきゅーん"の使い方間違えた......_| ̄|○

| | コメント (0) | トラックバック (0)

美人フィルタなるもの

hirax.net/できるかな?:帰ってきた「美人フィルタ」で眉毛処理 編

 要するに目元の彫りを深くして、ついでに美白とかいろいろすることで写真を美人にしてしまうプログラム。

 というわけで、早速香里をフィルタに通してみる。

<元画像>
profjpg

<美人化!>
prof_bijin.jpg

 ・・・・・・む、確かに美人になった「気」がするw

| | コメント (2) | トラックバック (0)

オムツをさらけ出せ!というのならテープを何とかしてくだちい

きつねのすみか: 大人気になる?「しっぽ」がついた紙オムツ

 から、

「しっぽ」がついた紙オムツ 大王製紙が月販300万枚へ弾みというニュース。

 えー、昨今の乳児さん方は、オムツが丸見えになっていても平気なんでしょうか?ウチは気にします。なので、外出時にはオーバーパンツ。

 オムツがおしゃれになって「見せオムツ」になるのは良いんですが、相変わらずオムツの背中テープはそのままなんですな。
 アレ、子供がずりずりするとびろーんとはがれちゃうんですよねー。あのテープ無いとスゲー困るし、意外と粘着力がすごくて、一旦ぺロっとはがれかけると、割と大変なんすよ。どーにかしてください>グーンの中の人。


 それにしても、グーンって絶好調なのですね。

 この間TV見てたら、パンパースかなんかが、「オムツM、Lサイズで売上No.1!」って謳ってたんです。そのときは「へー、がんばってんなー、グーンを抜いたのかぁ」って思ってたんですが、よく考えたら、M以上になったらパンツに移行するんじゃなかろうか、Sと新生児サイズがオムツタイプの主戦場じゃなかろうか、と。

 んで、パンツタイプは、ドレミが「パンツタイプで売り上げ2位なのご存知でしたか?」という"良く考えたら消極的な"広告を打ってたのを思い出したりして、相変わらずグーン圧勝か、と。グーンはオムツ最後発のはずなのに、たいしたもんです。

 ウチもこの間、試供品を貰ったのですが、確かに生地がやわらかくて肌触りがいいです。ウチは安さで選ぶので、グーンはなかなか手が出ないのですが、いつもお世話になってるマミーポコとか、ドレミとかと比べると段違いです。すげえぜグーン。
 とはいえ、これで成長が左右されるとは思わんがね、中居くん(古)w

 以上、徒然。

| | コメント (0) | トラックバック (0)

フェラーリに勝つにはどうすればいいか

2004 USA GP Laptime Analysis

 あー、読んでて気分良いわ、コレ。
 というわけ(?)で引用。

フェラーリに勝つにはどうすればよいか

ラップタイムチャートを見れば、佐藤が多くの周でフェラーリよりも速いタイムを出していたことがわかる。むろん、フェラーリはBARとのタイム差を考慮した上での走りだったろう。だからガチンコ勝負が見たくなってくるものだ。

ただし、フェラーリはバリチェロが復調傾向である。したがって、BARも二人で戦う必要がある。これまではバトンと佐藤のどちらかしか最後まで戦えなかった。それでは戦略やチームプレーで大きく上回るフェラーリには勝てない。バトンは佐藤を意識するのではなく、フェラーリを意識して戦って欲しい。佐藤は予選で一か八かのアタックは控えるべきだ。佐藤らしさが失われるだろうか。勝つということはあらゆることを犠牲にしなければできない。攻めるときは攻め、引く時は引く。今後はそういう場面がたくさん出てくるだろう。

たとえば予選で、フェラーリの前に陣取るのが理想的だが、そうでなくても、フェラーリの間に割り込むことが重要だ。フェラーリの二人に作戦をとらせる余地を与えないことだ

| | コメント (0) | トラックバック (0)

甦れ悪魔の…

炎上しますた

 北見「今度は320km/hに耐えられるボディを作れ。1ヶ月だ。」
 高木「アキオーーーーーッ!(泣)」

| | コメント (1) | トラックバック (0)

逞しい琢磨にペヤング形無しw

 今週のF1速報(P.55)のジョック・クリアインタビューから抜粋

 「タクは他人の意見を簡単に聞くようなヤツじゃない。自分で理解できない限り、受け入れることは無いんだ。だからカナダの予選でのミスは彼自身があの出来事から学ばなくてはいけないんだ。(中略)でも、チャレンジして当然なんだ。それくらい闘争心は剥き出しにしていなくてはいけないよ。だから、誰がなんと言おうと、タクはバリチェロとの接触を単なるレーシングアクシデントと捉えているんだ。クルサードがタクに”僕だったら、あんな無謀なことはしなかったね”って言ってきたんだ。そうしたらタクは”そうだね、君ならしないだろうね”って言い返してた。だからこそタクは挑戦するんだ。」

 ペヤング、もういいよ。君も来年も走れるんだからいいじゃないか。


 ヘレスとかw

| | コメント (0) | トラックバック (0)

ゴルァ!!( ゚Д゚) フジ!!

琢磨、早くも次へ始動 [ 2004/06/21 ]

ヘレスで新エンジンなど試す

 佐藤琢磨(BAR)は20日、3位入賞を果たした第9戦アメリカGP(20日決勝)の舞台、インディアナ州インディアナポリス・モーター・スピードウェイ(IMS)をレース後3時間ほどで後にして自宅のある英国に向かった。22日からのスペイン・ヘレスでのテストに参加するため。テストでは新しいホンダ・エンジン、ミシュランの新リア・タイヤのプログラムをこなす予定で、その成果次第では第10戦フランスGP(4日決勝)、第11戦イギリスGP(11日決勝)でも好結果につながりそうだ。

 こんなスケジュールで、どうやったら生出演できるんじゃ!
 元々無理やったんちゃうんか!

| | コメント (0) | トラックバック (0)

ど、どうやら今夜みたいですよ、琢磨さん

 すぽるとの琢磨特集はどうやら今夜やるようです。

2004年6月22日 23:55~翌0:35
佐藤琢磨14年ぶり日本人表彰台の裏側

 しかし番組の説明はトーンダウンしてるので、どうやら生出演は期待しない方がよさそうです。アメリカから日本経由でヨーロッパに戻るってのも現実的でないし。激励&報告に和光(栃木だっけ)に寄るなら別だけど。
 せめて表彰台後の本人への独自インタビューくらいは撮っていて欲しいですが。


 これで、昨日みたくお茶を濁した構成にしたら、、、したら、、、、

 、、、うーん。他に選択肢が無いのが悲しい。

追記:
 たいしたことありませんでした、、、_| ̄|●

| | コメント (0) | トラックバック (0)

琢磨,今晩の『すぽると』に緊急生出演!…しませんでした

BARの佐藤琢磨はアメリカGPで自身初となる3位表彰台を獲得したが,この快挙を記念して本日深夜のフジテレビ『すぽると』(24:10~)に緊急生出演することが決まった。今回の番組は特別に「F1祝琢磨表彰台大特集歓喜生出演」と題され,14年ぶりの日本人ドライバーの表彰台をファンに報告することになる。
F1Newsより

よっしゃー!ちぇっく!


追記:
 生出演したのは、右京でした。(´・ω・`)

 「F1祝琢磨表彰台大特集(右京が)歓喜生出演」

 全国ネットで釣られますた。

 しかも、右京は思い出し泣きでロクにコメントできないし、大久保はバカコメント出すしで(三宅も振るなよ)、もお、激しく萎え。口直しに、今朝トウチュウ買ってきました。一日後れの一面記事。ちょとマヌーですがw

追記の追記:
 フォロー記事です

| | コメント (1) | トラックバック (2)

ゲイツさんTOYOTAお買い上げー(?)

トヨタのスポンサーにビル・ゲイツ氏浮上 [ 2004/06/20 ] :年4000万ドルを出資

 ソフトウエア最大手マイクロソフト(MS)のビル・ゲイツ会長が年4000万ドル(約44億円)を出資し、トヨタのチーフF1スポンサーになる希望をもっていると、20日付のビルト日曜版が報じた。

 その前にCARTを助けてやれよ、とw


 というわけで、予想される来年のコメント

 R・シューマッハ
「ピットから出たら、突然エンジンが止まったんだ。無線でチームから『ちくしょう!またブルー(スクリーン)だ!』という叫びが聞こえたよ。ピット作業中にマシンのソフトウェアをアップデートするのは止めたほうがいいね」

| | コメント (0) | トラックバック (0)

ええーい!野口なんざどうでもいいんじゃ!(中日ファンw)

 トウチュウよ、琢磨を写せ、琢磨を!

 というわけで、やっと、ようやく、ついに、表彰台です。
 まだ録画を全部見てないので、早く帰って最後尾からのオーバーテイクをじっくり堪能したいと思ってます。

 いやー、ずいぶん待たされたね。

 でも、まだ3位。アクシデントが多すぎて期待のランクを下げてしまっていましたが、まだまだ諸手を挙げて喜んではいけないのです。やはり優勝です。優勝。
 コンペティティブなマシンに乗るレーサーは一度勝てば勝ち癖がついてどんどん勝てるようになるのです。
 予選3位だのフロントローだの海外GPでの表彰台だのコマい「日本人初」の冠はもう要らない。そのままガツンと優勝して、バンバン勝って下さい。


 そして、こんどこそ、俺も録画を失敗しないようにしますw

以下、トウチュウF1Express記事内の琢磨のコメント

信じられない気分です。この結果は僕にとってもチームにとっても良かったです。スタッフは本当に頑張ってきましたからね。スタートはちょっとびっくりしました。何が起こったのか分からないうちにアロンソに抜かれてポジションを落としてしまった。でも2度のセーフティーカーが入った後は、クルマは十分戦える感触があったのでポジションを戻せました。何人かといいバトルができましたし、(最後は)ヤルノ(トゥルーリ)がオイル旗にひるんだのが見えたのでチャンスと思いました。ここ数戦、辛いレースが続いたし、いろいろあったので、感慨深い気分です

| | コメント (0) | トラックバック (0)

ソニック・ザ・ヘッジホッグ?

UTADA

おまけ
グッホジッヘ
ステキ大根2より、使用させていただきました)

| | コメント (0) | トラックバック (0)

ちぇっくちぇっく

モデリングの神さまが降りてくる瞬間

ソフト開発は最初が肝心

オブジェクト指向について学びたい人におくる3冊

| | コメント (0) | トラックバック (0)

リスタンの演奏

ほのぼの。

| | コメント (0) | トラックバック (0)

新球団名提案

オリバ


オリックス+ッファローズ。


…最強っぽい?

| | コメント (0) | トラックバック (0)

宿直室を作ってみた

 Fozyさんのヤプログ! - 最強無料blog?という記事でヤプログを知ったので、ちぇっく。

 で、よさげだったので。作ってみました

 ココは、正直話題を広げすぎてて手狭に感じていたので、ちょうど良いです。livedoorより使いやすげですし。有難うFozyさん。

 宿直室では、ココよりも少し手綱を緩めた話題を書こうかと思います。

 育児を含めたほのぼの系はこっち、放言上等な社会派(w)記事はあっち。
 残したいものはこっち、残さなくてもよさげなものはあっち。
 キッヅな記事はこっち。アダルツ(w)な記事はあっち。
 ココログが軽いときはこっち。重いときはあっち(w)

 という感じで、コンゴトモヨロシク。

| | コメント (0) | トラックバック (0)

リチャーズ…(ノ∀`)

F1:BAR、佐藤の力を解き放つ

 リチャーズは土曜カナダGP予選の後1時間、“我々が最善の結果を手にするには何が必要か”について佐藤と話し合ったという。

 「彼と少し話をしたよ。彼のエンスージアズムを抑え、なだめ、そして期待を少し小さくするようにね。1コーナーでレースを優勝することはできないし、最初のレースで選手権を優勝することもできない
自分の位置、もしくは全体的なパフォーマンスが不確かなドライバーは、アグレッシブに走ろうとする傾向にある。彼はもう少し目標を楽にしていい
我々には皆プレッシャーがあるが、きちんと向き合っていくことはできる。彼のプレッシャーを我々がコントロールする方法はあるし、問題から救うことだってできる。何より、一番のプレッシャーは私にある。率直に言うと、彼は私のために走っていると言えるわけだからね…(編注:それは無いw)だから私は彼の力を最も引き出せる方法を見つけなくてはならない。」

 ストッダートやエディやペーターはこんなこと言えまい。
 理想の上司に+1ポイント。(ちょっと勘違いが入っているのはご愛嬌とw)

| | コメント (0) | トラックバック (0)

自作パソコンも全国の郵便局が回収

デジタルARENA / 自作パソコンも全国の郵便局が回収

 これで「バラして不燃ごみか、粗大ゴミ」以外の選択肢が無かった自作マシンも資源ループの中に入れてもらえそうです。

 まぁ、HDDだけは不要になっても、ループの中には入れませんけどw

| | コメント (0) | トラックバック (0)

Javaアプリ開発でなぜLinuxを使わないのか

ITmedia エンタープライズ:特集:全1回 Javaアプリ開発でなぜLinuxを使わないのか

 ちぇっく。ところで「全一回」ならわざわざ断る必要ないんでないの?

| | コメント (0) | トラックバック (0)

バトンがたっくんの運を吸い取ってるーっ!w

 予選後、初めて"意気消沈した琢磨"を見れたのが今GPの収穫でした。というのは歪んでますか?w

 つーか、そういうことで自分をごまかさなきゃやってらんねーんだよね、実際。まぁ、すぐに次のGPがあるので一度冷静になって、浮き足立った心を落ち着けたらどうでしょうか。なぁたっくん。

 ところで、
 ウィリアムズがレース後失格、控訴しないということで、バトンの3位が確定しそうです。
 これで全戦表彰台。凄すぎです。「先に優勝するのはバトンより琢磨」とか言ったモントーヤは、ウィリアムズのモーターホームに引っ込んでなさいw


 それにしても、ミハエル強すぎ。

| | コメント (0) | トラックバック (0)

固定小数点の掟

 iアプリは浮動小数点が使えないので、下駄を履かせて固定小数にして計算します。その際の掟。

  • 整数を掛けたり割ったりする場合は、そのままでOK。
  • 小数同士を掛ける場合は、掛けた後に下駄分を割る。
  • 小数同士を割る場合は、割られる数に予め下駄分を掛けておく。
  • 下駄は2の累乗にしておくと、シフトで賄えるので速いかもしれない。

| | コメント (0) | トラックバック (0)

「+」の恐怖…

 汎用的な簡易オーバーラップウィンドウクラスを作り、その継承クラスとしてメニューリストクラスを作ろうとしていたときのこと。
 あるクラスの継承クラスのclassファイルの大きさは、スーパークラスの大きさに左右されるのかな~、とか思いながらclassファイルを覗くと、割と大きいことに気づき、大きくしている犯人をコメントアウトしながら探っていた。

 犯人は、drawString( "MenuTest"+id, 0, 0, 2, 40 ); とかいう文字列描画メソッドだったのだが、そのあまりの大きさ(300byte近い)に驚いて、色々試行錯誤。

 ふと、+id を.concat( String.valueOf(id) ) に変更すると、67byteも減りますた。

 いや、恐ろしや~、恐ろしや~。わたしがそなたで、そなたがわたし

| | コメント (0) | トラックバック (0)

ぼくとわたしの7つのルール

キッズgoo [インフォメーション] 7つのルール

 だそうです。100円ショップものの取り扱い説明書のようなこなれていないルビの振り方がナイスです(笑)
 というか、こんなにルビ振りまくりのHP初めて見ました。ま、TOPページに殆ど振られていないのはご愛嬌ってことで。

 それにしても、この7つのルールを読むと、インターネットって危ないところにしか見えませんね。いや、実際怖いですけども。
 例えば、これ

インターネットで仲良(なかよ)くなった人でも、お父(とう)さんやお母(かあ)さんがいっしょでなければ会(あ)いません。

インターネットだけでのやり取(と)りだけではなく、お友達(ともだち)とはどんどんお話(はな)をしよう!
は、少し矛盾してるし。
 これの趣旨としては「インターネットでコミュニケーション取るな、隙を見せるな。ネットの向こうは全員怖いおじさんだと思え」という事ですよね。

 これなら「インターネットをするときは、必ずお母さんかお父さんと一緒にしようね」の一言があればいいのではないかと。いや、ここまで怖いものなら一人でやらせることないでしょ。マジで。ほとんど「深夜の繁華街で遊ぶときの注意」レベルだもん。

 だからといって、この7つのルールがやりすぎかというと、全然そうは思わなくて、まさにごもっともだし、殆ど完璧だと思うしで。

 少なくとも今のインターネットの状況は子供一人に遊ばせるには危険すぎるということですね。全く、いつからこうなったんだろうねぇ…。

| | コメント (0) | トラックバック (0)

予期しない例外を丸ごと端末に送る

 アプリに例外が発生した場合、エミュだとコンソールに例外情報が送られますが、実機だとそのままでは送られません。ので、送るようにする方法。
 まず、準備として、以下のことをします。これで最低限端末に例外情報が送られます。


  • ADFのappTraceに"on"と書く(リリース時に外す)
  • 例外時、Exception#toString()を標準出力に出す(System.out.println()等)。printStackTrace()では端末に送られない

 さて、端末でデバッグするときは、全ての”予期せぬ”例外を端末に送って欲しいわけです。なぜなら端末の機種依存で落ちることもあるからです。その瞬間の例外をキャッチできなければ、真実は闇の中です。
 全ての例外を余すことなくcatchするため、独立して動くメソッド(イベントとか)やメインループのメソッドは丸ごとtry/catchで囲みましょう。これでそのメソッドから呼ばれるメソッドで起こる例外は全部catchできるはずです。その後エラー画面を出してあげると親切かもしれません(エラー画面の中でトレース情報を表示できれば、appTraceはいらないかもしれません)。
 次に、try/catch節で囲まなければならない処理を持つメソッドはcatch節の最後でthrowしてしまいましょう。このとき、そのメソッドの宣言にthrowsをつけるのを忘れずに。catchで例外処理をしないのであれば、throws宣言をすれば、try/catchは要りません。
 try/catch節が特に必要ないメソッドはそのままでOKです。例外が発生したら、呼び元に自動的に例外を投げてくれます。

| | コメント (0) | トラックバック (0)

笑っちゃうくらい厚手の衣

VAIO pocketレビュー(小寺信良の週刊「Electric Zooma!」)

 これでもかっつーくらい「衣を着せまくった」文章に思わず笑ってしまいました。
「今のままじゃVAIOpocketダメダメ」と一言いえばいいじゃんw 文章からあふれ出てますがな。というか誉めてないし。もうギリギリという感じ。「残念」という言葉は多分本当なんだろうけど、ホントは「出直してこい!」とか言いたいんだろーなーと邪推してみました。

 ところで、この部分。

ただしこのソフトにも難点があって、一度に数GB分のデータを変換できない。じゃあ1GB弱に減らせばいいのか、と思ったのだが、それもなんとなくいやがる(笑)。まあOKを押せば転送してくれるのだが。

 どう嫌がるのかは、本文の写真を見ればわかりますが、これには大笑い。

 とっても人間味あふれるダイアログボックスですね。

| | コメント (0) | トラックバック (0)

はてなも?

ACCSとoffice氏が和解~掲示板の監視義務を課す仮処分申請で

 ここんとこ。

なお、チェック対象は、2ちゃんねる、2ちゃんねるプロバイダー、はてなダイアリー。

 「はてな」もですか?
 「はてな」ってそんなもんが出回る余地が無い印象があったのですが、2chと同じくらい殺伐としてるん? それともほかに理由が?

| | コメント (0) | トラックバック (0)

当てにならない備忘録

  • drawImage()より、copyArea()の方が1.7倍速い。
  • 1回の240x240のdrawImage()より、100回の24x24のdrawImage()の方が軽い。
  • 汎用ライブラリを作る場合、メソッドにもフィールド変数にもstaticをつけること。サイズが減る。スコープは影響しないのでお好みで。
  • unlock()が呼ばれたとき、画面に変更があるとpaint()が呼ばれる。
  • 定数定義は#defineを使ったほうが、final staticを使うよりメモリの節約になる。

| | コメント (0) | トラックバック (0)

はみがきにはパペットが効く

 んですよ、おかあさん!
 ウチのカミさんが発見しました。

 歯磨き機関車はもうダメです(オイ)。即飽きです。時代はパペットです。パペットに歯ブラシを持たせて、シャコシャコやると喜んで磨かせてくれます!やったぜパペット、頼りになるぜ!

 お勧めは「うーたんのパペット」です。こいつはシャコシャコするたびに頭のマラカスがりゃんりゃん鳴るので、とても嬉しそうです。

 一度お試しあれ。

 記事の絡みでこんなところを見つけたので、対香里PC弄り用にちぇっく。

| | コメント (2) | トラックバック (0)

湾岸とny

湾岸スレより、DL板からのコピペ

291 :[名無し]さん(bin+cue).rar :04/06/06 02:54 ID:2WCVUhIP
金子さん
なんで何も言わずに捕まったんですか・・?
どうしてオレを利用しなかったんですか・・
オレのコト仲間だと思っていたんでしょ
ねぇ金子さん
オレ、Winnyというソフト選んで良かったですヨ
ないですヨ、こんなソフト 世界中ドコにも
Nyに明けくれたこの3年
後悔するわけにはいかないですよ
よく言ってましたよね
大事なコトは誰も教えてくれないって
それは自分でわかっていかなきゃならないって
DL速度300Kbps
そんなバカげた世界は終わりですか
みんなかしこくなってつまんないですヨ
こんなソフトがここにあるのに

笑いますた。

| | コメント (0) | トラックバック (0)

現実としての過去

少年犯罪データベース

 親として、目を背けることはできません。現実を直視する意味でちぇっく。


 ところで、この中にこういうのがありました。
昭和54年(1979).10.11〔小4女子が友達を13階から突き落として殺害〕

 これをもって、例の小6女児の事件が必ずしもネットや映画の所為ではないと言うわけではないのですが、なにか適当なものをスケープゴートにして、事件を風化させないようになってくれれば良いと思います。自分も含めて。

| | コメント (0) | トラックバック (0)

もっと言って!

F1:佐藤、バトンとは異なるエンジンを使用?

 前半はどうでもよくて、後半。

 また佐藤琢磨については、“荒くせっかちだ”としているものの、かつてのボスであったエンツォ・フェラーリを思い出させるとのことである。

 「エンツォは、“胸に闘志を秘めているドライバーのみが好きだ”と話してい  た。また彼は、若手ドライバーがおかしなミスをしないというのは、特にそれが成長段階のときは、そのドライバーは必死に頑張ろうとしていないだけだとも話していた。」

 ・゜・(ノ∀`)・゜・.
 あのジョン・サーティースに励まされるなんて、やるじゃん琢磨。
 A・デビッドソンもBARのレギュラーシートは狙ってないみたいだし、今年はガンガン行っちゃえー!

| | コメント (0) | トラックバック (0)

ぷりぷろぷりぷら

 Javaのクセに機種依存があるiアプリでは、プリプロセッサが欠かせませんが、Javaには標準のプリプロセッサがありません。ナゼ?という感じですが、無いものは仕方ないので、こっちで用意することになります。

 Java用のプリプロセッサで、特にiアプリ開発において有名なものにPPPがあります。
 こいつは、Javaにはないenumキーワードを解釈してくれるおまけ付きで、非常に重宝するのですが、"enum定義に定数定義ができない"、"if 0外しができない"、"#includeが本当にインクルードしてくれるわけではないので、インクルードするファイルにソースを書くことが出来ない"という理由で、惜しまれつつも引退してもらうことになりました。

 enumを使うことが出来ないということを承知すれば(元々無いしね)、C用のプリプロセッサが使えます。BCCでもいいし、VC++でもいいですね。もちろんgccを使ってもOKです。これで、汎用的に使うコードをメソッドとして別ファイルに置くことができます。VC++のclだと、コメントを残したままプリプロセスを行ってくれるので、javadocを通すこともでき、便利です。
 ちなみに、docomoのエミュレータ/ビルド環境を使って、プリプロセスを通すバッチはこんな感じ。

@echo off
REM src2の下にソースを書くと、srcの下にjavac可能なソースができる(VC++版)
cd src2
for %%f in (*.java) do cl /P /EP /C /X %%f
cd ..
del src\*.java
for %%f in (src2\*.i) do move src2\%%~nf.i src\%%~nf.java

 ああ、これでまた一歩、Javaから離れた! ・・・・w

| | コメント (0) | トラックバック (0)

サイズ削減計画の掟

いろんなところを漁って調べたiアプリの主にサイズ削減のための掟をリストしてみる。

  • クラスはIApplicationとCanvasの2つだけ
  • メソッドの数は極力抑える
  • フィールド変数の数を抑える
  • paint()を使わない(Graphicsを取得してlock()/unlock()で)
  • Threadを使わない(start()を呼ぶスレッドのみを使う)
  • Vector/Hashtableを使わない(可変長配列はVectorの方がいい)
  • Timerは使わず、System#currentTimeMillisを使う
  • switchは使わず、if elseを使う(case一個で10byte)。その際、条件が満たされる可能性が高いものから並べると、処理が早くなる。
  • 比較は0と行う。ループはダウンカウントにする
  • Obfuscator必須(あとjargとか)
  • 短いタイミング(描画更新等)でSystem#gcをする
  • Display#setCurrentは起動の一回だけ
  • Stringの"+"は使わない
  • packageは使わない
  • Srting#getBytesを2回以上使う場合、一旦配列に落とすとサイズを食う。しかし、そのまま使うと処理を食うw
  • 変数宣言時にnullを代入しない
  • 文字列の連結は、3回以下ならStringで、それ以上ならStringBufferで
  • Stringを初期化付きで宣言するときは、new String("abc")よりも"abc"で
  • 定数は、-1~5(1) / 8bit整数(2) / 16bit整数(3) / それ以上(7) でサイズが変わる。 long型は0,1以外はサイズが変わらない。
  • フィールド定数(クラススコープの定数)は、インスタンスから導くよりクラスから導くと最適化される。
  • ファイル名は短く。拡張子は無くても構わない。
  • クラスにfinalをつける。
  • インスタンス生成は(メイン)ループの外で行う
  • メソッドのパラメータは先頭3つまでが高速。
  • byte,short型はサイズ縮小の為に使っても意味が無い(配列定数は別?)

参照サイト

| | コメント (0) | トラックバック (0)

アセンブラ気分

 iアプリを作るべく、いろいろなサイトや本を漁り、どうやら敵は「サイズ」であることが判明。503iを無視すればコードサイズ(jar)は30KB以下でなければならない。30KBつったらあーた、240Kbitでっせ。ファミコンのゼビウスも載りません(256KbitROM)。ちなみに1MbitROMは128KBなので、900iでギリギリ足りないサイズ(100KB)。DQ1がやっと載るくらい。もちろんスクラッチパッドという拡張RAMがあるんですが、その代わりJavaなのでどっちもどっちですな。

 で、Javaで(速度ではなく)サイズを気にするなんてのは普通ならしなくていいので、jarサイズを縮めるテクニックなんてのは、常套手段がないわけですが、幾つか見つけまして、とりあえずまとめてみました。

 まず、諸悪の根源はクラスです。クラスを1つ作るとclassファイルが1つ出来、そのサイズが馬鹿にならない(200B程度)ので、クラスは極力減らすことが重要です。クラスの中にクラスを作ったってclassファイルは(innerClass@とかいうプレフィクスのおまけつきで)できてしまうので、無駄なあがきです。
 というわけなので、構造体(としてのクラス)はあきらめましょう。カラーRGBを構造体で纏めるなんてもってのほか(w)です。
 クラスは1つが望ましいのですが、画面描画につかうCanvasと、アプリ起動に使うIApplicationの二つが必要なので、どうしても最低二つにならざるを得ません(画面描画用にPanelを使うのなら別)。
 結論として、iアプリは、IApplicationを継承したアプリ起動クラスとCanvasを継承した画面描画クラスの二つだけで作ることが望ましいです。

 クラスが二つだけということで、すでにオブジェクト指向などというものは役に立たなくなってるわけですが(w)、せっかく二つあるんだから再利用性やクラスの独立性も考えて、二つのクラスにそれぞれふさわしい役割分担をさせたいと思うのがプログラマの人情というものでしょう。
 すぐに考え付くのが、描画周りはCanvas継承クラスで、内部処理やライブラリその他はIApplication継承クラスでメソッドを書くというやり方です。美しいですね。
 しかし、それはお勧めできません。
 別クラスのメソッドを呼び出したり、フィールド変数にアクセスするよりも、自クラスのそれにアクセスした方がサイズ的に有利だからです。
 クラスを増やさないというのはiアプリ鉄の掟ですが、メソッドを増やさないのもまたiアプリの掟です。単なるフィールド変数のアクセサを書くなんてもったいないことをしてはいけないのです。
 そうなると別クラスではpublic宣言をする必要があります。自クラスであればpublicにする必要はありません。
 また、二つのクラスを同じようにメソッドを増やして太らせるよりも、思い切って1つのクラスで全てを行ってしまった方が後々メモリの調整もしやすくて有利です。
 それに片方のクラスを汎用機能を纏め、ライブラリ化してしまうとサイズが固定化/肥大化しがちですし、「動くものは弄るな」の法則が働いてしまいます。

 そうなると、答えは決まってきます。IApplication継承クラスは、Canvas継承クラスのインスタンスを作って、カレントに割り当てるだけで後は何もしない。全ての処理はCanvas継承クラスで行います。アプリケーションの終了でさえ、IApplicationクラスに戻る必要はありません。
 再利用性は、ソースコードのコピペで実現しましょう。どうせiアプリなんて、そう何回もメンテしませんし、Dojaのバージョンが変われば手をつけなければなりません。機種ごとのカスタマイズだってあります。したがってライブラリ化で楽をしようと思わないことが肝要ですw。

 スレッドやイベントは極力使わないようにしましょう。
 paintメソッドは使う必要はありません。Canvas#getGraphicsでGraphicsのインスタンスは取得できます。repaint()で描画指示を出すよりも、lock()/unlock()を使ったほうが制御しやすいし、処理も速いし、機種依存もありません。
 processEventメソッドは使わざるを得ませんが、そこでダラダラキーの処理を行っているとメインループに影響を与えることになるので、typeとparamだけ取得してどっかにコピーして終わらせちゃった方がラクでしょう。
 つまり最低限必要なメソッドは、アプリ起動のIApplication#startとCanvas継承クラスのメインループ(例えばexe())とキー取得イベントをキャッチするCanvas#processEventの3つだけ、ということになります。簡単なアプリなら本当にこれだけでOKです。


 ということで、すでにJavaの体裁を成していない異形のプログラム構造になってしまいましたw。先人たちの業績や今のトレンドをぶちこわしにするプログラミングスタイルですが、どこかなつかしさを感じます。
 これって「昔のゲーム機でアセンブリ言語」で書くときと同じですよね。あるいは8bitPCでBASICプログラミングもそうです。
 スコープなし、構造体なし、オブジェクト指向なし。SFCはそうでした。それでもシムシティが作れてしまうわけです。ウィンドウシステムもお手の物です。別にJavaの機能を駆使しなければ作れないものではないのです。めんどくさいかもしれませんけど、一人で作るくらいのスケールなら、これもアリでしょう。昔とった杵柄気分ですね。

 ただ、ソースファイルまでひとつになってしまうのが難点です。まあプリプロセッサを使えばいいわけですが、そうなると益々Javaではなくなってしまいますな、わははw

| | コメント (0) | トラックバック (0)

Robの嘆き、そしてハッパ

システムソフトウェア研究は見当違いのほうを向いている(和訳)

 尊敬するRob Pike(ココとかココとか)の論文。

 どこを切り取っても至言だらけで、エ○ック・レイ○ンドなんぞより、よっぽど含蓄あふれている。ちぇっく。

| | コメント (0) | トラックバック (0)

謎が解けた! つか常識ですか?

 仕事でJavaを弄り始めた関係でJavaに興味を持ち始めた私。
 Javaそのものについては、大分前から知っていたし、概要的な知識も持っていた。しかし、今ひとつ不思議だったのが、どうしてこんなにもブームなのか、ということだった。

 巷にはJavaの本や雑誌があふれ、IT技術者系のサイトにはJavaが主要言語という扱い。でも、Javaは遅い。とよく言われ、"Write Once, Run Anywhere"という利点も、JVMの上で走るバイトコードと呼ばれる中間言語で実現されてて、ネイティブコンパイラは無い。それって、インタプリタじゃん?スクリプト言語みたいなもんでしょ?
 Windowsアプリケーションは、Javaベースのものなんて無いし、組み込み系はCが主流。ネットワークかWEBアプリケーションくらいしかJavaの使い道なんて無いよ。それだって、PerlやPHP、Javascriptの方が使われてるんじゃないの?

 と、思っていたら、今日これを読んで謎が解けました。
 UNIXの世界では、Javaがスタンダードなんだね。Cはカーネルに近い部分以外はもう使われていないんだね。10年近くUnix弄ってないから知りませんでした。
 考えてみたらUNIXの世界だと、"Write Once, Run Anywhere"は重要だよね。ネイティブだと、いちいちリコンパイルしないといけないし、C/C++はあまりにも実装依存が大きいもんね。スクリプト言語では、スケールに不安があるしね。

 そう考えると、C++が最もこなれているのが、WindowsとVisual C++の世界だってのも良くわかります。ネイティブが走る環境でオブジェクト指向の言語というと、C++だけだもんな。その流れでC#を作ったのも良くわかる(Javaをそのまま採用するか、VisualBasicを拡張した方が合理的な気もするけど、そこはMSだからということもあるんだろう)。
 MacがObjectiveCなのは、よくわからんけど。

 てなわけで、Javaを学ぶかC#を学ぶか、今まで迷ってたけど、Javaにしようかなーと思いました。WindowsはManaged C++で十分かなー、と。Longhornが出たらわからんけどね。

追記:
 ごめん。超間違ってる。もうちょっと勉強しまふ

| | コメント (4) | トラックバック (0)

Javaとiアプリと私

 iアプリのお仕事をすることになったので、新規カテゴリ設置。

 恥ずかしながら今の今までJava弄ったことないです。そのくせCは16年くらいどっぷりなもんで、ついついC的思考でJavaを見てしまいます。しかも、iアプリ。JavaはJavaでも組み込みJavaなので、「クラスの数は極力抑えて、ひとつのクラスを万能化させようね」な世界です。オブジェクト指向って何?Javaにする意味あるん?

 てな感じで、中途半端なJavaプログラマになりそうな予感バリバリですが、Javaに関する役に立たないアレコレを書き殴っていこうかなと思います。

 ブログなので、Javaとかiアプリとかのキーワードで検索に引っかかる可能性大ですが、来ても役に立たないどころか、バリバリJavaプログラマの方には「うっきー!」となるかも知れません。予め謝っておきます。すまん。
 

| | コメント (0) | トラックバック (0)

« 2004年5月 | トップページ | 2004年7月 »