Hatena::ブログ(Diary)

しんさんの出張所 はてな編 このページをアンテナに追加 RSSフィード

カレンダー
2007 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2013 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 11 | 12 |
2014 | 01 | 02 | 03 | 04 | 05 | 06 | 08 | 09 | 10 | 11 | 12 |
2015 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 11 |
2016 | 05 | 08 | 10 | 11 | 12 |
2017 | 01 | 02 | 06 | 08 | 11 |
2018 | 02 |

2008-12-31

[]日本人なら年越しそばだろJK

来年はみなさんにとって(ついでにおいらも)よい年でありますように。

2008-12-30

[]この1年を振り返る その2

2008年5月

フェスタ68へGO!mkeiさんとえふおうさんに会ってパワーをいただく。

幻霧ノ塔ト剣ノ掟をゲット。いわゆるWIZとかテーブルトークRPGとか昔のRPGが好きな人ははまれる。序盤から中盤まではWIZを超える神ゲー。後半のバランス崩壊や全体魔法バグに悩まされるが中盤まででも十分元が取れるマイナーながらも当たりの作品。WIZ好きならばさわっておいたふがよい。

このあたりからTopLink以外のJPAの実装をいろいろとさわってみた。Hibernateが一番で気が悪いという面白い結果に。OpenJPAはちょっとあまくみてました。

EJB3.1などもいろいろとチェックしたのもこの時期でした。

2008年6月

テイルズオブシンフォニア ラタトスクの騎士をゲット。

SAIムックが出てたのもこの時期。買ってないけど。

Java Expert #3執筆開始。

2008年7月

Java Expert #3執筆完了。


2008年8月

ファイアーエムブレム 新・暗黒竜と光の剣がでたのもこの時期。兵種変更はキャラの個性をつぶす改悪かなぁという感じ。ただ先に進めればよいというのならばこちらのほうがゲーム性がたかそうでよいのだけれども、やはりキャラクターに思い入れがある人は受け入れられないと思う。

このあたりはJAX-RSのRI実装がわりと固まってきていて(確か0.8だったかな?)結構テストしていた。


2008年9月

たった1000円のグラディウスリバースのあまりの出来に年寄り歓喜。

GWTを試していたのもこの時期。JAX-RSとの相性がわるいというのを知ることになる。というかJAX-RSのRI実装は今のバージョンでもあんまりよいJSON形式で返してくれない(文字列以外扱えない)。正直かなりがっかり。

仕事がなくなったので都内でバイト開始。


2008年10月

この月は九十九電気の民事再生手続きでしょう。九十九電気以外の老舗のPCショップは全滅状態。比較的歴史の長いように感じるツートップとかが赤子に感じるくらいの歴史のあるお店なのです。

JSF2.0の開発ビルドもちょっと触ってみたり。

きしださんが技術ネタみんな飽きたのかなとかいったあたりもこの時期です。これをきっかけにおいらは技術ネタが増えたような気がします。あとネガティブなのも減っていったような気もします。これは間違いなくきしだパワーもらいましたね。


2008年11月

930SHゲット。カメラの出来のよさに驚く。910SHでよい画面をとるのは静かな場所であることが必要(本体の動作音で調整する必要があるため)とか本当に骨が折れるのです。それがぱっとだして910SH並み。

Java Expert #3が発売。


2008年12月

ICEfacesNetBeansでの本命くさいということでいろいろと調べちゅ。

Visual Web ICEfaces + EJB 3.1 + JPAの手軽さは異常。EJB3.1のおかげでトランザクション管理も全自動だし、実装のみに専念できる。


風邪で3日間ほどのたうちまわっていたのもこのころ。発熱と腹痛はすごかったですが、咳やくしゃみはまったくありませんでした。風邪じゃなかったのかも?

[]この1年を振り返る その1

複数回に分けて1年の間に起こったことをかいていきます。おおむねNetBeansまみれの1年だったと思います。

2007年12月

日記をはてなに変更。

片貝さんにプラネットNetBeansへ登録していただく。いつも毒ばっかりはいていてすみません。

ウルティマ 恐怖のエクソダスネタ開始。(今では途中でとまってるけど。そのうち再開したい)


2008年1月

JavaEE 5でのフルスタックの話が登場しています。後にこれを記事化するわけです。

あとはウルティマネタが多いですね。

NetBeans 6.0を実際にさわることが多くなってバグ等不具合周りで大量に毒をはいています。ここではいたものが今でも直ってないのが多いのがちょっと残念ではありますが。


2008年2月

世界樹の迷宮IIネタが多いですね。

また、Visual Web JSFEJB3.0バグ周りとか実際に業務で扱う上で悩まされたものが噴出しています。


2008年3月

この月はなんと言っても「ねこび〜ん」ですね。

今までのNetBeansカラーを用意したねこび〜んずを作成もしました。

http://d.hatena.ne.jp/shin/20080325/p1

NetBeans7.0ではメジャーバージョンが変わるとまた箱の色が変わると思いますので、ねこび〜んも色が変わるかもしれませんね。

バンガイオー魂に激しくがっかりされた月でもあります。

仕事もやっと落ち着きを取り戻したところです。一ヶ月で30画面とかつくっていたころです。

2008年4月

EJB3.1Glassfish V3などの次世代の話題が増えてきます。

ひそかにjakarta POIがバージョン3になって久々にメンテされ続け、かなり実用的に鳴っていたのに驚いたというのが一番の収穫でした。それ以前の2.xではバグ等も放置されつづけ、メンテされていませんでしたから、POIは使わないというのが常識でしたが、3.xはまじでつかえます。ちょーびっくりです。


月末にはNetBeans 6.1が登場します。超がつくほど大量にバグが修正されていました。

NetBeansは枯れたバージョンを使うより新しいバージョンを使うほうが安定していて使いやすいことが多いということが今回も証明されました。たぶん、今後もこの傾向は続くと思います。パッチで修正されるバグはわりと軽微なものばかりだからです。

2008-12-29

[][]ICEfacesでのツリーコンポーネント

JSF標準にはTreeコンポーネントはありません。ですが、ICEfacesにはあります。しかも非常に面白い。

まずvalueプロパティにバインドするプロパティを用意します。

DefaultTreeModel model;

public DefaultTreeModel getModel() {
    return model;
}

public void setModel(DefaultTreeModel model) {
    this.model = model;
}

たぶん、このへんでピンときた人も多いと思いますが、このモデルはSwingのモデルです。

初期化コードをみるとさらによくわかります。

//ルートノード
DefaultMutableTreeNode root =  new DefaultMutableTreeNode();
IceUserObject rootUO = new IceUserObject(root);
rootUO.setText("るーと");
root.setUserObject(rootUO);

//子ノード
DefaultMutableTreeNode chield1 = new DefaultMutableTreeNode();
IceUserObject chield1UO = new IceUserObject(chield1);
chield1UO.setText("ちゃいるど1");
chield1UO.setLeaf(true);
chield1.setUserObject(chield1UO);
root.add(chield1);

DefaultMutableTreeNode chield2 = new DefaultMutableTreeNode();
IceUserObject chield2UO = new IceUserObject(chield2);
chield2UO.setText("ちゃいるど2");
chield2UO.setLeaf(true);
chield2.setUserObject(chield2UO);
root.add(chield2);


model = new DefaultTreeModel(root);

これで

  • るーと
    • ちゃいるど1
    • ちゃいるど2

というようなツリー表示が出来上がります。Swing使いには簡単ですね。Swingですでにモデルが標準APIとして用意されているのだからそれを使うという思い切りのよさが素敵です。

注意しなくてはいけないのはユーザーオブジェクトはIceUserObjectを継承したものでなくてはならないというところだけです。


あとはVisual Web ICEfacesだとツリーコンポーネントを貼り付けるとクリックイベントが設定されているのでそれを削除すること。

まさかWebアプリで「DefaultMutableTreeNode」がでてくるとは夢にも思うまい。


そのままvalueをセットするとデザイン時に不具合が出ると思うので後で書く。



いつのまにかはてなスーパーpre記法ソースコードにまともにマルチバイトがつかえないようになってるくさい。しかたがないのでただのpreに。ちなみにプレビューは問題ない。最近ダイアリーバグうめこんだ?

[]コードレビューしかない

http://d.hatena.ne.jp/itoasuka/20081228/1230427187

コメント方面へのつっこみとなります。


規約にそったからコードが見やすいということは一切ないですねぇ。

規約をほとんど無視していてもしっかりしたコードならばおいらは気にしません。大概は表面上の規約ですからそれは後でリファクタリングでどうにでもなることが多いですけど、コードの質そのものは規約で底上げできませんから。

まずは規約で縛る前にコードをちゃんと書く練習しようよということです。でも、それを縛ろうとしてる人はコードかかない人種ですからそんなのはしったこっちゃないんですね。


保守時に他人のコードを見るとき規約に沿っているかどうかってのはそんなに影響しないと思います。コードの質そのもののほうがはるかに大きいかと。

個人的には

  • 規約で得られる保守性の向上が2%くらい
  • コードの質そのものが98%くらい

ですかね。そしてこの規約にがんじがらめになるとコードを書く効率が大幅に低下し、かつコードの質そのものが低下すると感じています。最大2%部分をMAXまで目指すかわりに98%部分が大幅に低下していくので総合的には大幅にひどいコードになっていくというのは実感としてあります。


ですから後から気がついた人が体裁を整えるリファクタリングをしてあげればいい、その程度にしか考えていません。

結局保守性に優れるコードってのは質の部分が大きいのでコードレビューしかないとおもいます。


コードってのは書く人によって非常に差がでるというのを認識してないんですかねぇ。SEとかわけのわからない肩書き持ってる人。工場で出来上がる製品のように均一的になるとでも?

2008-12-28

[][]ICEfacesでのテーブル

Visual Web Icefacesをもりもりと勉強中。


とりあえず今日判明したこと。

DataTableを使うと表の内部のコンポーネントで一度でも入力したものがあるとFirefox2が処理が遅い。

Firefox2は今月でサポート切れるのとFirefox使ってる人ならば3をいれてるだろうから害は少ないと思うけど。IE6はさくさくうごきます。

Firefox3だと1回目のアクションが遅いけど、2回目以降は普通に動く。まぁ問題ないかな。



あと、VisualWebでの最大の特徴である仮想フォームがない。ということはformを意識して配置するか、アクションのプロセス内で入力チェック等をする必要が出てくる。このへん通常のWindowアプリケーションみたいなバランス感覚が必要になってきそう。


いじっていて非常に面白い。NetBeansでのWebアプリ開発の本命だろう。>Visual Web ICEfaces

2008-12-27

[]DQ9の評価

AmazonDQ9の評価がすごい。

まだ発売前3ヶ月も前でぜんぜんシナリオとかゲームバランスとかもわかってないのに、DSだからかわない、10もWiiだからかわないとか工作でお金もらってそうな★1レビューが大量に。


amazonは昔から言われてることだけど、発売日前レビューってやめるべきじゃね?もしくはamazonから購入した人だけレビューかけるようにするとか。少なくともそういうレビューとはわけるべきかなと。

[]Wii 出前チャンネル

http://plusd.itmedia.co.jp/games/articles/0812/26/news078.html

電話すると聞き取れないとか絶対にあるし、いわゆるカタログがポストに届いていないと注文できないし、これは純粋にいい試み。

ピザ体型にならないことを祈るのみ。

[]年寄り歓喜エディタ

http://d.hatena.ne.jp/nowokay/20081227#1230338597

VDP好きなおっさんはぜひ!

16*16のみだけじゃなく、256*192あたりまで拡張できればゲームの1シーンを完全に再現できますね!

あとは単色スプライトあたりでMSXとしてはばっちり。ちなみに256*192はDSの解像度とまったく同じ。

本当はそういった大きい解像度でラインとかサークルとかひいてみて、「VRAMの制限によっておかしい表示になるー」一度は悩んで欲しいというか。

マニュアルとかでは「にじみ」って表現されてましたよね。デジタルな製品でにじみってどうよとか当時は何も考えてなかったですね。今みたいにひねくれてなくて純真でした。



1ピクセルごとに違う色を打ちたいよ!という欲張りな方は1ピクセルが4*4ドットになるマルチカラーモードをドゾー。スクリーン3あたりでしたっけ。

2008-12-26

[]モンスターハンターGWiiに登場

http://game.watch.impress.co.jp/docs/20081226/mhg.htm

ゲームそのものは別にたいしたことのないニュースだが、ポイントはクラシックコントローラ専用のソフトのパッケージ販売が任天堂から許可されたこと。任天堂の姿勢が柔軟になった証といえるだろうか。

ポイントはこういったゲームになれたユーザーが購入するタイトルの場合追加でハードが必要になったとしても問題は少ないということ。これがWiiスポーツみたいなハードで別途ヌンチャクが購入する必要がありますとかだったら大変なことになっていたのだが、このユーザー層ならば問題はあるまい。


これでWiiコントローラがネックだと考えていた開発会社が国内でもWiiへ一気に流れ込むだろうか。海外ではすでにWiiがラインナップも協力になっているが、国内ではどうもWiiに力を入れているサードが少なすぎる。個人的にはヌンチャクスタイルでも遊べるようにして欲しいところ。


あとカプコンモンスターハンターWiiとか外伝っぽいタイトルにしなかったところが興味深い。国内のサードは任天堂ハードにはずっと外伝っぽいタイトルばかりつけていたからね。先にコナミパワプロで正伝ナンバリングしたことといい国内でもWiiへの流れが加速していると見るべきか。

[]仕事納め

本日で今年の仕事は終了。

明日から帰省します。


帰省しているうちに体調を万全にするのはもちろん、NetBeans + Visual Web ICEfacesを真面目に勉強します。来年1月からはすぐに仕事で使えるくらいに。それくらいすごいプロダクトですから、NetBeansJavaを使ったWeb開発をしている人にとって避けて通ることの出来ないものだと思っています。JSFを知っている人も知らない人もてがるにはじめられるのはよい。

ICEfaces自体は実績も歴史もあるプロダクトなのでまず問題はないでしょう。あとはVisual Webの使い方のみ。今のところ基本コンポーネントとファイルアップロード位は試しましたが、プログレスバーが配置の際に不具合を起こす以外は問題に遭遇していません。配置のバグということでこれはNetBeans側の問題でしょう。

テーブルやレイアウト周りを中心にチェックしていきたいと思います。

2008-12-25

[]TBSにチャンネルを変えたら

なんか懐かしい曲ばかり流してた。あんまり音楽に興味がなかったのでほとんどの曲は知らないかと思ったけど、聞いたことがあるのが意外と多くてちょっとびっくりした。曲名とか歌詞とかぜんぜん知らないのに。

しかし昔の曲ってなんでこんなにパワーあるんだろう。曲の作り方や盛り上げ方がやっぱり日本人がきれいだと思うような音色なんだよね。いわゆる15年くらい前までのゲームミュージックもそうなんだけど。


あとは声がみんな特徴がある。

でも、今の本人が歌うとほぼ例外なくあんまりいい歌じゃなかったりするのがなける。ためが多すぎてダメなんだよ。あとは丁寧にうたいすぎ。みんなパワーがなくなってる。とんがってるのがない。多少粗があってもとんがってるのがいいのに。

中でも昭和50年代のパワーの強さは異常。異邦人とか、ギザギザハートの子守唄とか、言葉に出来ないとかルビーの指輪まぁ上げればきりがない。


なんだ、CDがびっくりするくらい売れないといってたけど原因ちゃんとあるじゃないか。

とはいえ、30年くらい前くらいからの名曲をひたすら流してるのと、ここ数年とくらべるのは公平ではないか。



ビデオにとって最初から見たかったかも。

2008-12-24

[]純真無垢な童心にかえってサンタさんにお願いをしよう!

実家への帰省時の土産のためにさいたま新都心をぶらついていたのだが、えらい人ごみが。ああ、そうかクリスマスか。

こうなったら童心にかえってサンタさんにお願いしてぐっすり眠るとしよう。



「サンタさん、1月から仕事ください!」



…うん、なかなか子供心あふれるお願いだったね!

12月で契約が終わることが決まったので、1月からはフリーです。


システム開発をSIerに頼んだら100万超えてびっくりしたという東京埼玉方面にすむ中小、個人企業なお方はご連絡ください。おおよそ20画面60万くらいでつくりますので実勢価格の1/5〜1/3くらいではないかとおもわれます。

個人事業をずっとしていまして来年1月1日には8期目になります。今年は専門書籍JavaExpert#3で書かせていただいたりとなにかと飛躍の年でした。


というわけでサンタさん、靴下10個くらいぶら下げてるのでよろしくです。

2008-12-23

[]正直ひどいね

デュアルコアAtom 330で遊ぶ!の連載

http://pc.watch.impress.co.jp/docs/2008/1202/nishikawa.htm

http://pc.watch.impress.co.jp/docs/2008/1209/nishikawa.htm

http://pc.watch.impress.co.jp/docs/2008/1217/nishikawa.htm

http://pc.watch.impress.co.jp/docs/2008/1224/nishikawa.htm

正直かなり無理やり感があってひどい内容だね。どこにも広告企画とは書いてないようだけど。特に第4回はもうお花畑。

シングルスレッド性能が非常に低いAtom。SMT対応&高クロックなのでコアの中でくるくると単純なループをまわすようなベンチは非常にいい値を出す。各種ベンチもまさかインオーダコアが来るとは思っていまい。

デュアルコアにすることによって大幅に性能アップしただの、Nanoよりはるかに性能が高いとか笑いを抑えるのがちょっとつらい。おなかに響く。

この理論だとPentiumDはとんでもないスペックもってることになるよね。

サーバー用途で1.8GHzという微妙なPentium4をピンポイントでもちだすあたりもようわからん。SMT対応してないけど、シングルスレッド性能はAtomよりは高い。方向が違う。そもそも低消費電力なサーバーが欲しい人はPentiumM系列(Core2まで含む)やC7系にとっくにのりかえてるし、マシンパワーが欲しい人はCore2やPhenom使ってると思うし。もし今でもサーバー用とでこのスペックをつかってるとしたら必要ないから乗り換えてないというところでしょう。

Atomデュアルコアでこれだけさわいでるということは、やっすいCeleronM/1.6GHzとかさわったらたぶんこの人ぶったまげるくらいの性能だと思うよ。ここに出てるHDBENCH結果は非常に悪いけど。

[][]人気度調査


NetBeans

http://k.hatena.ne.jp/hotblog/NetBeans

どうやらここんところのNetBeansネタ連続投下で一気にランク急上昇した模様。今後も気合入れてネタ提供するぜ!一位を狙うぜ!

JSF

http://k.hatena.ne.jp/hotblog/JSF

あんまり気合入れてネタにしてる気がしないけど、Visual Web JSF使ってるからランクが高いのか。ここも一位を狙うぜ!

Glassfish

http://k.hatena.ne.jp/hotblog/Glassfish

なぜか一位。NetBeansからのセットアップと絡めた説明しかあんまりしてない気もするけど、いいものはいい。軽いアプリケーションサーバーっていいよね。geronimoはしらないけど、それ以外と比較するとアプリケーションサーバーで最も軽いよね?

Java

http://k.hatena.ne.jp/hotblog/Java

競争相手が非常に多いが意外と健闘。TOP20をまず目指そう!

JPA

http://k.hatena.ne.jp/hotblog/JPA

がんばれば2位は狙えるかな・・・?1位はまだまだ無理くさい。



番外編 まさに化け物

http://k.hatena.ne.jp/hotblog/Seasar2

2位が足元にも及ばない。まさに別格。

[]今日は意外と

今日も仕事。病み上がりでもがんばるぜ!まだぽんぽんの調子は悪いけど!

今日は祝日なので通勤の電車がすいてるかと思ったが意外とそうでもなかった。スーツ姿を結構見かけたのでみんながんばってるんだなとおもた。おいらもがんばらないと!

帰りはすいていた。

職場は秋葉原なのでさすがに平日とは歩いてる人ががらりと変わっていておもしろかった。また、食事が出来る場所がかなり休みになっていたのにも驚いた。休日のほうが儲かるのかなと思ったが、意外とビジネスマンがもくてきなんだなぁとおもた。


Win95がでるまえまでの楽しい秋葉は毎週のように通っていたのを思い出す。ああ、遊びに行きたい^^;

2008-12-22

[]工人舎UMPC

http://pc.watch.impress.co.jp/docs/2008/1222/kohjinsha.htm

工人舎UMPCと真っ向からぶつかる価格帯とスペックを出してくるとは思わなかった。

でも、Officeつきで6万きるってのはすごい。その他のスペックもOSXPAtom/1.6GHz、HDD120GB、ワンセグモバイルカメラ、ExpressCard、無線&有線LAN、ビデオ出力、4.7時間バッテリと手を抜いていない。大手も最低限これくらい見習って欲しかった。



でもね。

工人舎に一番出して欲しいのはこれじゃない。

このスペックにプラスしてタッチパネル搭載&首がまわるやつなんだ。1万うわのせになってもいい。

[][]Visual Web ICEfacesデフォルト設定

NetBeansICEfacesを使っているとすぐにあることに気がつく。


画面遷移をしてもどってきても、初期表示にもどっていないこと。VisualWebのページビーンはリクエストスコープ。まさかセッションスコープになっているんじゃないかとセッションの中身を調べたりも下がまったくそういうことはなかった。

じゃあどこで各ページの状態を保持しているんだ?

もしかしてJSFとはちがうところ、ICEfacesが独自に管理してるってことか?そこでいろいろと調べてみる。


web.xmlにそれらしいのがみつかった。説明部分にちょっと書き加えたところが注目すべきところ。

ここをtrueにすると他の画面遷移後もどってくると初期状態になるいわゆるJSFっぽいアプリとなる。


そもそも、通常のWindowアプリケーションとかのように基本的に以前表示していた画面を保持するのはおかしいことではない。

たとえば、業務アプリ系の場合検索結果を一覧に出力することはよくあると思う。そのあと別画面に画面遷移をして戻ってきた場合、その一覧画面はどのようになっているべきだろうか。通常のWindowアプリケーションならば以前検索した結果が残されているはず。どこかに「再検索」などというボタンがあってそこではじめて一覧が更新されるというアプリは非常に多いはずだ。

ところがWebアプリは毎回検索をして、常に最新状態を表示するものが多い。毎回検索するということはDBサーバーへの負担がものすごく多いことをあらわす。Webアプリケーションでもっとも負荷が増える理由はクライアントサーバーにくらべてべらぼうに多いDBアクセス回数が原因だと思っている。何も考えずステートレスにこだわるあまりクライアントサーバー時代の数十倍のDBアクセスが起きているのは紛れもない事実だろう。

サーバーのメモリ増強が容易でなかった時代ならばセッションの使用メモリにこだわるのもわからなくもないが、いまやローエンドサーバーであるx86も64bit化し、4GBの制限から開放され、2GBのメモリがECCつきであっても平均価格で1.5万をきるなど恐ろしいほど安くなった。

仮にセッションを多用しまくって1ユーザあたり1MBも使ったとしても8GBのフリーエリアがあればおおむね8000同時アクセスには耐えることが出来る計算だ。そしてそこまでの同時アクセスが求められるアプリばかりではなく、むしろほとんどのアプリはそこまで必要としていない。


セッションを多用するのは怖くない。怖いのは各自勝手にセッションを隠れて使われることだけだ。bean単位で管理してくれるシンプルなJSFはむしろ都合が良いはず。


なんか途中から「WebアプリケーションでもWindowアプリケーションと同様の使い勝手になっていくといいなぁ」という別エントリになった気がするが(゚ε゚)キニシナイ!!

だからGWTICEfacesには今後もっともっとがんばってもらいたい。あとアプレットやWebstartも社内やB2B投資系のツール以外でも広く使われるといいなぁ。

2008-12-21

[][]Visual Web ICEfacesで気をつけるべきこと

プログレスバーコンポーネントを貼り付けてはいけない。

貼り付けるとページデザイナがおかしくなる。


いや、しかし便利だねVisual Web ICEfaces。これ使うだけにNetBeans使う意味はあるで、まじで。

[][]小ネタ千夜一夜 第5夜 Glassfish管理ツールで使われているアレ

Java使いはみんな知ってるのにid:yone098さんだけ知らないシリーズ第2弾。


Glassfish管理ツールJSFで出来ているのは常識だよね!

ソースを見てもコロン区切りのIDが見えるし、woodstock使っているのですぐにわかると思うけど一番わかりやすいのをひとつ。適当にフレームを単独で表示してみる。

URLを見れば一目瞭然ですね。JSFを触りもせずに批判する人もいるようだけれども、その人はGlassfishインストールしないようにしているのだろうか。

[][]ICEfacesはてなキーワード登録しました

たぶん、今後NetBeansユーザーならば特に頻繁に扱うであろうフレームワークなので取り急ぎキーワード登録しました。

特に読み仮名があってるかわからないのでわかる方は加筆修正お願いします。


軽く触ってみましたが、ページナビゲーションでボタンの新規作成等がwoodstockコンポーネントを生成すること、デフォルトのPage1.jspと新規に作成したページとで多少構成が違うことが気になったところかな。あとはページのタイトルが関連付けされてないのでタイトルは自分でタグをJSP似記述することになる。


なにもせずにブラウザの戻るボタンが効果をなさないので、戻るボタンに頭を悩ませる&対応が面倒な業務Webアプリには最高のフレームワークだと思う。

あとは普通にコンポーネントのリサイズも出来るし、スタイルの変更のプレビューもきくし、まじですごいと感じる。


JSFICEfacesとセットでやっと完成したといってもいいと思う。今後すべてのコンポーネントを試す予定。


久々に超大物がきたなという感じ。ここまで衝撃的なJavaフレームワークは今までなかったと思う。

2008-12-20

[][]ICEfacesNetBeans

のネタやろうとしたら先にやられてしまった…。

ICEfacesは実は非常に注目していて、これをNetBeansのVisualWebJSFがサポートしてくれたら世の中どんなにハッピーになるかと思っていただけにかなりうれしい。

現在のAJAX対応としては単純にAJAXなアクションの見極めとレスポンスだけというのが非常に多く、Webフレームワークでしっかり対応し切れていないのが多いはずです。コンポーネントツリーをサーバー側で保持しつつプロパティの変更をクライアントでシンプルにしっかり対応できるのはICEFacesASP.NET AJAXくらいしかないと思っていましたので。


woodstockが安定していて高性能だったらこの発表がうれしいと思うこともなかったのでしょうが、バグは相変わらず長年放置、真っ当なターゲットとなるブラウザはFirefox2.0のみ(1.5や3.0はダメ、IEも描画が崩れやすい)なうえに、コンポーネントDojoですべて動的に配置するために、非常にクライアントの負荷が高かったのです(Pentium4/2.4GHzだとつらい。PentiumM/1.6GHzくらいは必要)。動的に生成されるからこそ、サーバーサイド側からのAJAX対応は容易になるかと思われたのですがなかなか対応せず、むしろ、後付でAjax対応しにくいなどデメリットの塊でした。

ファイルアップロード以外のwoodstockコンポーネントは基本的に使ってはいけないというのがNetBeansのVisualWebJSFでのポイントでしたが、比較的最近までこのwoodstockコンポーネントのタグには「基本」とだけ書かれていたんですね。「基本となるコンポーネントがこれだけ使えないんじゃJSFオワタ」といわれて仕方がありません。そしてJSF1.1時代の機能しかないというのもおはなしになりません。

ICEfacesってなに?という人はこちらのリンク先を参照してください。


手っ取り早くデモを見たい方はこちら


というわけで近いうちにICEfacesもネタにしていきます。デモとそれに対応するコードをみていただければJSFが今後Strutsにかわり一般的に使われる技術になる可能性が非常に高いことがわかるでしょう。

[]おもいっきり風邪引きました

水曜の夜に思いっきり風邪を引いてつい昨日まで死にそうにしていました。今はだいぶ楽になりましたが、まだ本調子ではないので、今日もずっと布団の中の予定。

家にいながら2日半ほどPCの前にほとんどすわらなかったのは久々。TVも見ていませんでした。寝室にTVがないというのもありますが。


ただ横になっていると1時間がものすごく長いんですね。おなかの調子も悪く、大量のの汗で水分補充もひんぱんにしなくてはならず、保冷剤を交換するので1時間すら眠ることもままならず。やっと今日の明け方くらいから1時間半くらいずつ眠れるようになってきました。

やっぱり長時間の通勤で体力が低下、そして大量の人と密着状態が長いというのも風邪を引きやすい原因かと思われます。自営業をしてもうすぐまる7年になるわけですが、ほとんど通勤なるものをしていませんでした。自宅で開発でしたから。このときは風邪なんて無縁すぎると正直思っていましたが、やっぱり通勤があるとそうでもないですねぇ。それに体調が少しでも悪いとすぐに仕事を中止して布団にもぐりこんだり休憩をしたりしていたのも理由かもしれません。外で仕事をするとどうしても拘束時間での商売になるのでそういうことはしにくいですしねぇ。

というわけで引越しは思ったより早くなるかも。

2008-12-18

[]掲示板を撤去しました

スパムがうざくて消すのが面倒になったため。それもどうも手動でやってるっぽいので回避は不可能くさい。

なにかあれば適当にコメントで垂れ込んでください。

2008-12-17

[][]小ネタ千夜一夜 第4夜 Glassfishは再配備時にセッション維持するんだぜ?


Java使いはみんな知っていると個人的には思っていたGlassfishアプリ再配備時のセッション維持機能。

どうもid:yone098さんは知らなかったらしい。

続きを読む

[][]数少ないまっとうなAtom搭載マシン

http://pc.watch.impress.co.jp/docs/2008/1215/fujitsu1.htm

価格はEeePCなどのマシンとは大きくかけ離れていますが、上位モデルで11万と決して高いわけではありません。それでいてタッチパネル搭載、OSVistaからXPへ変更、解像度も1280*800WXGA、FMトランスミッタ、バッテリは標準5時間、大容量10時間と抜けがありません。重量はなんと500g台ですよ!

日本のメーカーはこういうのをしっかり作って欲しいところです。最近NECにしろ東芝にしろ5万程度の安かろう悪かろうのマシン作ってますけど、EeePCの後追いならばEeePCで十分です。

これで上位モデルが10万切って経費で落ちるようになると購入する人が増える・・・気もする。

2008-12-16

[]Spring MVCStrutsの一番の違い

やっぱりアクションフォーム(SpringMVCではコマンド)関係かなぁ。

Strutsは数値型のプロパティ用意しても変換不可能なものを入力されると0という値に変換して何事もなかったように返すのが一番の問題。したがって、へんにいじられるくらいならばStringだけでいいとかになる。そして型変換全部やるのかよといった面倒なお話になるのも普通。

Spring MVCは数値型のプロパティに文字の入力を入れるとエラーになります。それはBindExceptionとして不正な入力があったパラメータ名や値がとりだせます。そしてエラーがあった場合自動で入力画面に戻され、submitのアクションは呼ばれません。

Spring MVCのほうが一見よさげに見えますが、単純にはそうはいかないのがこまったところ。なんといっても入力エラーがあった場合コマンドは生成されません。テキストフィールドに入力した不正な値も正しい値もセットしたりそれによるエラー処理とかをするとき面倒なお話になります。


というわけで一長一短ですが、SpringMVCのほうがいろいろと挟み込んだり拡張ポイントが用意されていたりして楽なのには変わりませんけど。たぶん、自作Controllerでこのへん全部面倒を見たほうが楽っぽいです。なによりStrutsはconfigの生産性の悪さに頭が痛いのでほかがすべてStrutsが優れていたとしてもかなりイマイチですけどね。

一応いっておくとこの話はSpring MVC 2.5になる前のお話です。2.5でコマンドをGETに割り当てるとどうなるかは確認していません。

ついでに言うとNetBeansは2.5未満のコントローラ作成のウィザードしか用意されていません。もうちょっとがんばってほしいところです。Springを使うならNetBeans!といえるようになるといいですね。

[]会社訪問

とりあえず今日からここは「しんさんの転職日記」となります。(大嘘

みなさん、ハローワークは毎日眺めてますか?もちろんですよね?常識ですよね?



とりあえず先日会社訪問をしまして、シャッチョサンのイメージとかけ離れたまじめさにちょっと驚きを感じたりしています。



現在、定期で都内に出るのに毎月2万円かかっているわけですが、よくよく考えると、これ都内に住んでいると5000円くらいですんじゃうんですよねぇ。

つまり、1.5万くらい家賃が高くなってもなんにも問題がない。

実際のところ1.5万程度の値上げじゃすまないわけですけど、現在のあまりの体力と精神力の消費を考えるとやはり都内、もしくは近くに引越しをしないといけないなぁと思いました。毎日往復で1時間半のあき時間の差がつくと考えると一ヶ月20日換算で30時間にもなってしまいます。

やっと都内でアホみたいに高い家賃を払ってでもそこに済む理由がなんとなくわかった気がします。でも、おいらみたいな田舎もんには家賃が5万こえてるだけでかなり裕福な暮らしをしていると感じるんですよねぇ。


http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/shin/20081112/p1

にある

Youchan 都内に住めない人は都内で働くメリットはあまりない気がする

に今頃納得もしたりして。まぁ交通費がでる現場だとだいぶ変わってくるとは思いますけどね。せめて大宮以南かなぁと。電車の数が違いすぎますし。


というわけでハローワークと賃貸情報は毎日みようぜ!

2008-12-15

[]Java対応レンタルサーバーの価格の安さと機能に衝撃をうける

いまでもしんさんの出張所でレンタルサーバーを利用していますが、これかなり昔に契約したのが続いています。当時としては安いほうでしたが、今調べてみると大容量かつ低価格なのが多くてちょっと驚きました。



特にJava対応のレンタルサーバーが普通にいろいろとあるんですね。特に気になったのが下記の場所。

http://java.1strentalserver.com/index.html

Java対応はちょっと前までは海外製ばっかりだったと思います。

ここはJavaのバージョン5や6対応、Tomcat5.5/6/JBOSS/glassfishなどが対応してこの価格は衝撃的でした。しかもほとんどの場所にあるMySQLはいいとして、PostgreSQLが対応してるというのも非常に珍しい。価格的にも個人で十分つかえますね。

ほかの場所ではJavaは1.3や1.4などが多く、DBMySQLのみばかりでした。JBOSSGlassfish対応してるところなんてまずありません。

Javaのプラン以外にもWindowsのプランもあって、ASP.NET等も同様の価格帯で扱えるっぽいですね。


今の場所だと容量が少なくて大きいサイズの写真とかなかなかアップロードができません。いまじゃGB単位が普通に存在しますし、ほんと安いですねぇ…。

1年後あたりをめどにいろいろと検討してみようかな。でもメールアドレスを含めて引越しは面倒なんですよねぇ。

[]GWT標準にならないかなぁ

http://itpro.nikkeibp.co.jp/article/NEWS/20081212/321336/

GWTってJava標準になると面白いんだけどなぁ。JavaVMの上で動くアプリじゃないからたぶん無理なんだろうなぁ。

WebBeansと連携してGWTから簡単に会話スコープでごにょごにょというのができるとたぶん、開発はすごく楽になると思う。

問題はWebBeansが簡単に扱えそうな代物ではなさそうだということ。JPAのときのようにseamをベースにシンプルに作るものだと勝手に思い込んでいたらかなり複雑なまま持ち込まれた感じ。正直ひどい。

これだとJSFEJB 3.1との統合目的にですら使う人は誰もいなくなりそうで怖い。特にEJBが3.1であれだけ手軽になったから。

JSFに会話スコープを追加し、JSF以外のアプリからも手軽に管理Beanを触れるように汎用的なPOJOが作れればそれでいいと思う。

[]30代のおっさんにはたまらない

なんというおっさんホイホイ

http://alfalfa.livedoor.biz/archives/51405327.html

元々の>>1の内容と以後の内容がまったく関係なくなって懐かしいおもちゃ大集合になってる。だがそれがいい

2008-12-14

[]クライアントサイドは縛られないのが大事

JavaScriptラッパを使うべきか、JavaScriptフレームワークを使うべきか

過去に何度か書いているとおり個人的にはサーバーサイドにビジネスロジックDBをもってクライアントとの通信にはJSONXMLをつかういわゆる3層式のRPC形式が一番だと思ってます。


そうなるとクライアントの形態は客の状況にあわせて自由に作るだけでよいということになります。重要視するのは予算なのか、開発スピードなのか、ランタイムを入れても良いのかなどを最初に決めるべきです(これは現状のWebアプリ開発のプロジェクトでもいえることだと思いますが、このへんはこの数年特に無視され続けてますね)。

クライアントサーバー側よりもどうしても流行りとかに影響されやすいので状況に合わせて適切に選択できれば良いというwけです。

例えば、クライアントは社内LANだけということならばWin32ネイティブアプリとかでもいいのです。この場合開発効率や操作性の高いのを選ぶのが良いことが多いと思います。無理して開発効率が悪く、UIもわるいjavascriptベースで考える必要はまずないでしょう。これが一般的に公開されるアプリだとまた変わってきますし、BtoBとか社内の拠点間でのアクセスとなるとWebstartやappletノータッチデプロイメントといったバージョン管理ができてなおかつUIがリッチなものが重要になってくるでしょう。


サーバー側はJAX-RSのように1つのサービスに対してJSONXMLを自動で作り出すのがいいですね。JSONだけとかXMLだけとかじゃなくどちらも対応できるやつで。


したがって、参照記事に対する回答は「案件しだい」となります。どちらに転んでもいいように両者とも勉強しておくのが良いと思う。社内用やBtoB用ならば、はるかにリッチなUIで開発効率も何倍も高いGWTを選択するのがいいと思うし、オープンなコンテンツならばデザイナと共同でjQueryを使うのがいいでしょう。

今後は狭く深い知識が必要なのは非常に減ってくるかもしれません。同じアプリをさまざまなクライアント環境で用意できる力があるかがポイントになるような気もします。

ただ、アプレットやWebStartにしてもそうですけど、オープンなコンテンツ以外で大量に使われていても

一般的なユーザーの目に留まらないので技術的なアピールが弱いような気がします。そこが逆にjQueryの強みかもしれないですね。逆に自分の得意分野が食われないことがわかっているからこそMSjQueryをサポートしたとも考えられます。

[]はてなに移住してから早一年

去年の12月15日にかき始めたのでちょうど今日で1年だったりします。

プロフィールを見ると

ユーザー登録から本日までに日記をつけた日数:357日

となっているので366日のうち11日も休んでしまったことになります。

日記もまともにかけないダメ人間ですね、すいません。



ページビューは同一IPをはじくアクセスカウンタに比べて大幅に増えやすいので単純には比較できないのですが、それでも23万5000は1年目にしてはわるくはないほうでしょう。

現存する日記を見る限り99年の7月にスタートしたしんさんの出張所。来年の夏にはいよいよ10周年となります。


この当時に使用していたマシンはX68030です。メールもメールコマンドで送受信していましたし、WebはLynxでした。Windowsマシンとのデータのやり取りにFTPを使っていたのが思い出されます。すぐ隣にマシンがあるのに転送できないという。このときメールではテキストしかおくれませんから、テキストにエンコードする必要があります。たしかuuencodeやISHを使っていたと記憶しています。この日記を見てる奇特高貴なお方なら説明不要ですね!


しょぼいネタしか提供できていませんが、今後もよろしくお願いいたします。

[]T2Framework 0.4.1SNAPSHOTをもう少し触る + Cubbyの古いやつをGlassfishV3preludeで起動



前回思うように動かなかった(正確には、一応動くけどログの吐き出しやデプロイ時間等がダメ)のは0.4.0のサンプルにT2のjarファイル2つを差し替えたもの。

今回は

http://d.hatena.ne.jp/shot6/20081210#1228901357

のwarファイルからプロジェクトを作成し、2つのjarファイルを差し替えることにした。

でも、ソースファイルが同梱されてないようなのでここだけは0.4.0からもってくる。

実行!

ん、エラーがでとる。

続きを読む

2008-12-13

[][]X68000を手軽に扱えるようになる

ぴぴblogより

http://av.watch.impress.co.jp/docs/20081212/micom.htm


X68の出力が可能になったらしいです。液晶全盛時代になってから大変な状況に陥っているX68ですが、これでお手軽に扱えるようになるでしょうか。

記事がPC-watchではなくAV-watchにある時点でちょっと悲しい。ゲーム機の情報がPC−Watchに出てるくらいだからPCに関係のあるファームウェア更新ならPC-Watchにだしてもよかろう。



…すでに4万出して出力しようとしている時点でお手軽ではないとかいわない。

[]知っ得納得Webフレームワーク 第2回の資料公開


T2FrameworkとSpring MVCということで、非常に興味のある内容だったのですが、あの時間帯にいけるはずもなく…。

http://d.hatena.ne.jp/c9katayama/20081212/1229087742

http://d.hatena.ne.jp/shot6/20081212#1229011881

http://d.hatena.ne.jp/yone098/20081212/1229090811


とりあえずSpring MVCセッション周り使っちゃいけないという考え方は同じですね。1年位前に2.5さわったときまっさきに思いました。Spring MVCは2.5になっても1.xのときと同じようにシングルトンで作られる事が前提になっているためにあんなへんな仕組みになっているのだと思います(プロトタイプとかでも一応動くけど)。

とはいえ、2.0までとは別次元の快適さです。SpringMVCを使いこなそうとするとカスタムタグがStrutsと同様に必要になってくるのですが、標準APIであるJSTL+ELだけでそれなりに大丈夫だとは思います。

少なくともStrutsよりはシンプルで何倍もいいです。Strutsはフォーム周りの仕組みがひどすぎるのがなんとか改善されれば多少ましになると思うんですがねぇ。型変換な仕組みがあるのにStringしか事実上使い物にならないとかおわっとる。

SpringMVCの上にラッパを作るのもありですが、コンテナ依存もありますし、それくらいならばT2の上にかぶせるタイプのほうがいいのでしょう。T2がどこまで拡張できるポイントを用意してくれているかはわかりませんが、メソッド呼び出しの前後に処理をはさめるタイミングがあれば大丈夫なはずです。これ、引数が固定化されてないために、AOPでは対応できませんからね。

2008-12-12

[]データベースバグは直ってなかった

昨日のエントリで直ったといったが、直っていなかった。どうやらデータの種類によるらしい。



原因はどうやら文字列型の型の取得に不備がある模様。

postgresqlは8.3からはインストーラに付属のpgadminIIIでvarchar型が作成できず、text型のみとなっています。そしてこのtext型は速度的な面で推奨されていますが(実際は囲い込みの面ででしょうが)NetBeans 6.5ではvarchar(0)という型と認識しているようです。

ですから、1文字以上入れた時点でアウト。varchar型で作成して文字数を入れた場合のみ動くようです。varchar型で作成しても文字数を0のままだとエラーが出てしまいます。

ResultSetMetaDataの説明をみると

列サイズが適用できないデータ型の場合は、0 が返されます。

となっているので0ってのはサイズが0ではなく、無制限の場合等に使われる動きに対応できないとだめなはず。

ぜんぜんだめですなぁ。

[]SSDの時代

http://d.hatena.ne.jp/nowokay/20081211#1228983243

数年前に「フラッシュメモリは書き換え回数があるのでスワップがあるPCだと厳しいが、そのうち書き換え回数は多少は改善されて普及するはず。特にノートPCでは低消費電力、軽量化、耐衝撃といいこと尽くめ」といっていたが、本当にここまで一般的になるとは。

正確にはPCに搭載という意味ではまだ一般的ではないけど、単語として一般的になったかなと。少なくとも夢のデバイスとして特集がよくくまれたりしています。


で、外部記憶が高速化するのはいいけど、外部記憶以前にCPUコアとメモリの速度の剥離が激しすぎて、結局従来のメインメモリが現在の2ndキャッシュの位置づけになったりして。メインメモリは所詮バッファキャッシュで、SSDの書き込み耐久性の調整に使われるのみとか。

メモリは1TSRAMのようなものが普及するとよかったんですけどねぇ。通常タイプに比べて容量がすこし減ることになりますけど、4GBが3GBになったところでほとんどの用途に問題なく使えそうな気がしますが。複数のコアからのアクセスはランダム的になると思いますので低レイテンシなものが必要だと思うんですけどね。転送速度だけならHDDSSDに比べて負けているわけではありませんし、それと同じようなことかと。



しかしまさかEEPROMを外部記憶装置として使うなんて誰が想像してたでしょうか。ROMですよ、ROM。それを頻繁に書き換えるとか10年以上前だったら頭おかしいとかいわれてそう。

[]T2Framework 0.4.1SNAPSHOTでGlassfish V3 prelude対応

http://d.hatena.ne.jp/shot6/20081211#1228981195

したらしいのだが、試してみたら結果は一緒だった。うーむ。



以前とログもまったく一緒。

http://d.hatena.ne.jp/shin/20081201/p1

0.4のサンプルに0.4.1SNAPSHOTのT2本体とLucyのjarをさしかえただけだけど、このほかのファイルも更新しないとだめなのかな?

後で調べる。

2008-12-11

[]NetBeans 6.5 update1登場

とりあえずわかる範囲で。

以前指摘したPostgreSQLのデータをいじる場合の不具合修正されました。されてませんでした。


これ、データの修正をする場合pgadmin等を起動しなくて良いので非常にらくちんなのでありがたいです。pgadminIIIはデータの種類によってはつらい場合がありましたからね。


どう便利なのかは以前のエントリを参考にしてください。

http://d.hatena.ne.jp/shin/20080827/p2


データを見ればわかりますが、実はこれはJava Expert #3にかいた記事用のテーブルそのままだったりします。記事自体は7月中旬にはおわっていました。

[]気温の高さが異常

関東の気温の高さが異常。

まじで12月ですかい。

コートいらんよ。

2008-12-10

[]DQ10Wii

DQ9DSDQ10Wiiと連続した流れは久々に任天堂ハードですかね。

Wiiでまともに開発するサードが増えることを臨む。

[]930SHの写真でわかるトライ・アミューズメント・タワー新館

ゲームはプレイしてないけど、どういうのがあるか気になったので昼休みに確認しに言ってきた。。入り口はこの前写真に撮ったエレベータではなく、奥のほう。手前のやつは途中までしかいけないので注意だ!いや、アレ普通の人いき方わからんて。

その1

その2

その3

その4

その5

その6

その7

その8

その9

君はいくつわかるか!



・・・いや、タイトルとかインストとかもろにうつってるのも多いけど。

いったことがある人はわかると思うし、ライトの反射でわかると思うけど、中はびっくりするほど暗いです。これだけ暗いとまともに写ってないんじゃないかと心配したが、意外とくっきり写っていてちょっとびびった。

2008-12-09

[][]ゲーム開発の入門

おっさんがよろこびそうなネタですね。

http://d.hatena.ne.jp/bleis-tift/20081207/1228662563

JavaではVolatileImage(つまりVRAM)使える1.4から大きく変わりましたね。アクセラレーションが聞くようになったのは1.4.1からだったと記憶しています。

でもピクセルフォーマットが容易に取得できないのにあわせないといけないとかBufferedImageから普通に使うと非常に遅いとか考えないといけなかったので実はかなり使いこなすのが大変でした。

その後JavaSE6で単純なblit等アクセラレーションが何も考えてなくてもかなりの部分がかかるようになりました。でも、拡大縮小とかぜんぜんだめだったんですよね。そのへんはupdate10で大丈夫になりました。以下のエントリを参照するといいです。

http://d.hatena.ne.jp/shin/searchdiary?word=Java2D%a4%ce%c2%e7%c9%fd%a4%ca%b9%e2%c2%ae%b2%bd

のこるはAPI的に不備があるアルファブレンディングです。これはVMの速度以前にAPIが整備されないとはじまりません。現時点では通常合成以外はあきらめましょう。ぶっちゃけ加算合成がくわわればJOGLをやめてもいいくらいなのにもったいない。

ここを解決するためにはJOGL使ってOpenGLでやるのがいいでしょう。



でも、元の質問者のレベルからいっておそらく目的がそんなところにあるとは到底思えません。どうしてもゲーム開発がパソコンの用途のほぼすべてをしめる時代に育ったおっさんは、すぐ垂直帰線割り込みで同期を取って60fpsで動かすことなどを考えてしまいますが、最初に作ったゲームはそんなのは関係ありませんでしたよね。テキストキャラクタが動くだけで十分楽しかったはずです。

まずは何の言語でもいいから言語になれてキャラを手軽に動かしたり音楽を鳴らしたりしていくのがいいと思います。その環境に我慢ができないくらい成長したら乗り換えればいいだけです。

われわれおっさんはBASICで育ちました。そして速度や制限等から逃れるために開発効率の非常に悪いマシン語に手を出しました。マシン語は早いけど見通しの悪さはどうにもなりませんでした。なんせテキストエディタがないのがわりと普通の時代です。

そこでBASICのようにかける高級言語はないものか。そして見つけました。C言語です。おそらくC言語があっという間に普及した環境はX68だったかと思われます。XBASICがC言語に非常に近い構造だったというのもあります。おいらもバイトで7,8万かせいでやっと買えました。

XBASICはこんな感じです。記憶があやふやですから参考程度に。

int i
dim int dt(6)={1,5,3,6,2,4}
str s

for i=0 to 6
  s = "すうじは" + dt(i)
  hoge(s)
next
end

func hoge(s;str)
  print s+"だぜ!"
endfunc

こんなのがMSXとPC88全盛の80年代にBASICとしてあったのですから、X68がどれだけすさまじかったのかがわかるでしょうか。すごさがわからない人はおそらく若い人ですかね。GOTOなしでwhileで無限ループとか衝撃ありすぎ。あと、BASICですが、小文字なのが特徴なんですよ。



えーっと。気がついたら昔話のほうにそれてしまった^^;

今現在画像を描画して音楽も効果音も容易にだせるオールインワンな環境はおそらくJavaと.NETでしょう。描画がすぐに手軽にできないと面白くないですし、音楽や効果音がないのもさみしいものです。


  ●/ < ハンカク ヒラガナ ト トランプマーク ガ アル MSX サイコウ!
<■
/  >

なんか変なのが現れましたが、気にせずに続けると、とりあえず今の時代にLLとして存在してもいいくらいの完成度だと思います。入門用としてはすばらしいの一言。

mkeiさん、XBASIC移植お願いしますね(^-^b

[]NetBeans 6.5の今まで気がつかなかった新機能

階層呼び出しが右クリックのメニューに追加されてる。

念のため6.1を起動したらやっぱりなかった。ショートカットがついてないのが気になるが、やっぱり便利だな、この機能。

2008-12-08

[]月曜日だってのに

すでに疲労がなんかやばい。

2008-12-07

[]930SHカメラ画質以外でのお話をいくつか


バッテリ

バッテリは%表記できるようになっているのだが、どうもこれは購入直後はかなり少ない表示になりやすいようだ。最初の4,5日程度は1時間で2%減っていった。これでは2日ももたないじゃないか!と思ったものだ。

その後1時間で1.5%、1%と減っている表記となった。

現在では金曜の朝9時時点で96%だったのがその後補充せずに日曜の夜9時時点で56%。60時間で40%減という値になった。とりあえず5日くらいは持つ模様。今後もっと数値が伸びる可能性もある。

ただ、分表示がなんかおかしい。最大まで充電されていても400分ちょっとしか表示されない。これって1日も持たない計算になってしまう。これは待機時間ではなく、通話時間ってこと?

とりあえずカメラはかなり電池消耗しやすいので注意。

背面ディスプレイ

最悪。いままでみたなかでももっとも視認性が悪い。こんな有機ELディスプレイいらない。そもそも背景色が銀色で文字の色が白という時点でおかしすぎる。屋外で曇り空でも見えないのは異常。

メインディスプレイ

910SHとの比較になるが、非常に視野角が広い。910SHのときも903SHとくらべて解像度が上がってかなりよくなったと思ったものだが、930SHは視野角や色の濃さが別次元。175度くらいから覗き込んでもはっきりと見える。

それよりディスプレイの大きさ・・・というか長さになれると910SHにはもどれない。


モーションコントロール

カメラとワンセグで有効にしているが、これの横画面はかなりいまいち。というのは左側に倒した場合のみ横が面になるから。右に倒しても反応はない。あとカメラを使うときには下に向ける可能性もあるが、こうなると縦横の調節はもはやきかないと思ってよい。一応左に倒してからそのまま下に向ければいいのだが、ちょっとでもいじっているうちに縦方向と判断すると変わってしまう。

ワンセグ

越境視聴のことは考慮されていない。地方では使いにくいだろう。これWiiでもいえることなんだけどね。地域の文化や生活圏って県となんの関係もないのに、県単位で設定することのおろかさはなんとかならないのかなぁ。

重量

まじで軽い。


サイズ

8Mピクセルワンセグフェリカがついてまじで薄い。でもGPSはあってもよかったかも。


総評

背面ディスプレイくらいかな。あからさまにがっかりなのは。あとはおおむね良好。

[]考えてない

http://d.hatena.ne.jp/bleis-tift/20081206/1228492885

「考え方の違い」というか、「考えてない」のが正しいのでは。


ツールに関しては自分でツールを作らない人がすごく多いのを感じています。

例えば単純に既存のツールで使えない置換が必要だった場合、置換プログラムをすぐに作るのが標準的ななプログラマだと思います。

例えばJavaならばIDEは目の前にあってJDKなど開発環境は整っているのですから、すぐにSwingGUIツール作って実行して動作確認できますよね?結果を確認したらすぐに消します。ツールの作成から実行、削除まではものにもよりますが、通常5分程度ですよね。なぜか目で確認する作業を数時間かけて直していきます。もちろんミスが増えていくことになります。

他人の仕事を自動化(つまりシステム開発のこと)させるくせに自分の仕事は自動化させないんですね。


このエントリで一番注目するところは最後のほうにちょろっと書いてある部分だったりします。

「何らかのアクション※8に対する何らかのアウトプット※9」のテストが最小の粒度のテストって時点で何かがおかしい。

※8:アプリケーションを起動する、だとか、ボタンを押す、だとか

※9:DBにこういうデータが挿入される、だとかどこどこのセルにこういう値が表示される、だとか

あるあるある・・・ありすぎて泣ける。単体テストじゃないんですよね。常に結合テストバグがあった場合アクションにミスがあるのか、サービスに問題があるのかデータアクセスロジックに問題があるのかの判断が不可能。

一応表面上テストするだけかなりましと思うのもありかもしれません。コンパイルエラーがなくてそれなりに動いている(修正した箇所がちゃんと動いているかの確認をしない)状態を「完成した」という人種もそれなりにいますので・・・。

[]結構いじるもんだなぁ

http://blog.livedoor.jp/dqnplus/archives/1198552.html

肌を白くしてしわ取るくらいかと思ったら。もう世の中の写真すべてうがった見方しかできないわ。

[]久々の公園

この数年の日課として公園めぐりで風景画を取りまくっていたのだが、忙しくてしばらくいけてなかった。

たぶん、このとき以来だからもう9ヶ月くらい前かー。とおもったけど、アップはしてないけど、7月くらいに久喜菖蒲公園に取った画像が出てきたから5ヶ月前かー。

近くに公園があったのを思い出したので夕方にいってみる。



残念なことにすでに紅葉のシーズンはすぎており、特にとるべきところがなかった。残念。

いずれも930SHで縮小以外無加工。910SHのときと比べると西日がこれだけきついにもかかわらずきれいに取れるのがわかると思う。画質の違いはこのVGAサイズでもはっきりとわかるね。


できるだけ今後も公園回りを続けたい。2年前はほぼ毎日和光樹林公園と大泉中央公園を走っていたことを考えると、今の体重の増加や疲労度急上昇具合がすごくうなずける。4年前なんて荒川サイクリングロード(上流コースが自然が多く非常に気分よく走れる。ヤジマはまだ健在かな?)をほぼ毎日走っていたし、体力の衰えを感じて当たり前なのかもしれない。

木々に触れることによるストレス解消効果もかならずあるはず。やっぱり自然が多いところは落ち着くよね。だからこそ都心に近いところに済むのは躊躇するんだよね。

2008-12-06

[][]きしださんのスレッドの記事が修正されました

http://d.hatena.ne.jp/nowokay/20081206#1228542137

スプリアスウェイクアップが記述され以前指摘した部分が修正されました。

これからは安心してきしださんのスレッド講座を受け続けられますね!^^



あとは個人的に注意していただきたいのは、コンポーネントへのアクセス時にイベントキューで動かす場合、単純にスレッドからアクセスしていた部分の置き換えで対処をするのならば「invokeLater」ではなく「invokeAndWait」を使うべきということ。イベントキューでの待ち時間や動作中に起動元のスレッドからの共有される変数等にアクセスが入る場合のアクセス順序が重要な場合がありますからね。それに例外をキャッチすることが「invokeAndWait」のほうは容易に可能です。

「invokeLater」は投げっぱなしで問題がないとわかりきっている場合だけ使うようにしましょう。

キモイおっさんとの約束だよ!

[][]脅威の耳!

http://pc.watch.impress.co.jp/docs/2008/1202/mobile434.htm

ロスレスと非圧縮をも聴き分けられる

なん・・・だと?



違いが1ビットでもあればそれはロスレスじゃねー。

2008-12-05

[][]T2Frameworkの注目すべきところが公開された

http://d.hatena.ne.jp/shot6/20081205#1228453079

Seasar2との連携用アダプタである、S2Adapter 0.2.0-gaをリリースしました.

そう。DIコンテナに依存しないというのがT2の売り。では実際にどのようになっているか・・・のぞいてみる。


…ドキュメントが一切ない。どのメソッドがどのように使われるかの1行コメントでもいいので欲しい。

拡張のさせ方さえしっかりわかれば誰でも自分でGuice Adapterとかすきなアダプタ書くだけのことだし、T2はそういう方面がしっかりのびていって欲しい。

えーっと実際のところこれだけしっかり実装すればいいのかな?

<T> T getComponent(Class<? super T> clazz) ;

これは型による解決のみで、名前ベースによる解決がないということかな?


今の資料の状況だと何もかもがわからない。

[]前者はないんじゃね?

http://d.hatena.ne.jp/masayang/20081204/1228458032

予算達成重視 vs Agile

  • 「1年間1.2億円」で見積もったプロジェクトがあったとしよう。
  • 下記筋書きのどちらが嬉しい?
    • 開始後一ヶ月で中止に追い込まれ、お客さんからは月割りで1000万円だけしか回収できなかった。ただし、デスマーチにはならなかった。チームは次の仕事に向けて鋭気を維持できた。
    • 1年間開発を続けたが完了せず、要因追加&デスマーチで2ヶ月超過。お客さんからは1.2億円もらったが、超過分の原価で赤字になった。チームの半分以上は病気になった。

上のほうがどう考えても良いように見えて実は上の選択肢はありえない。

中止したら回収はないのが普通。1000万をお返しした上で損害賠償を払う。一か月分の給与で赤字、さらに損害賠償で-1000万とか。

たが、技術者デスマほどは疲弊してないので(中止しなくてはいけない時点で現実的には結構疲弊はしてると思う)次につながるのも確か。でも、みんな次の仕事は1年後の予定にしていたから仕事がない。あわてて探すというのは非現実的。と考えると技術者を遊ばせる時間分さらに赤字を垂れ流す。

個人的には適度に遊ぶ時間があって、その間に新しい技術を身につける時間が容易できるのが望ましいけど。技術が必要な職なのにそれを磨く機械がなくて、次から次へ仕事を入れるのはおかしいかと。OJTだけじゃ無理なんだよ。

[]契約プログラミングか防衛プログラミング

http://d.hatena.ne.jp/nowokay/20081204#1228409639

本質的な問題を抱えたまま、自分の担当分で例外が出なければ例外を握りつぶしてもかまわないという考え方をするかどうか、というお話ですな。瑕疵期間中に問題が出なければいいのかどうか。

個人的にはこの問題はJavaSE7がさっさとでてJSR 308が実装され、@NonNullが使えるようになって契約プログラミングが普及するというのが一番おいしいです。

   / ̄\
  |  ^o^ | < @NonNull おいしいです
   \_[]⊂/)
   _| |/ |
  |    /
         / ̄\
        |     | < それは Java2SE 1.4 です
         \_/
         _| |_
        |

[]JavaSE6はサポート期間が長い可能性あり

http://journal.mycom.co.jp/articles/2008/12/03/javasfather/index.html

この予想通りに進んだとするとJavaSE7は大幅に遅れていて来年には出そうにないくさい。プロパティ構文だけでも実装して6.5とか言う名前でいいのででてくれるといいんだけれども。リスナー書くのは面倒だし、プロパティ名をフレームワーク側で使えるとクライテリアが真に使い物になるから。

クロージャは今のままだと微妙かなぁ。ジェネリクスのようにメリットだけが出てくるわけではないし、たぶんスパゲッティも加速する可能性あり。クラス指向な言語との相性はあんまり良くない気もするんだよなぁ。実装するインターフェースのメソッドがひとつの場合のみならともかくいくつか例外が出たりするのがよろしくない。

あ、finalにしなくてもインナークラスからアクセスできる変数にするアノテーションクロージャ専用ではなく、普通に用意して欲しい。


で、この内容のとおり再来年に7がでたとして、そこから少したって6のEOL移行期間が始まったとしよう。通常1年半以上前に告知をすることから考えるとJavaSE6は現時点で2年たっているため、サポート期間は6年ちかくはいくはず。これは1.4.2の5年ちょいよりはるかに長い。ちなみにJ2SE5.0も5年の無料サポート期間なのでそんなに短いわけではない。


あれ?5.0が来年サポートが切れて7が出てない状態だと6のみが正式なサポートされるバージョンとなる期間が出来てしまう。サポートされるバージョンが1つだけって今までなかったような。1.4.2も6が登場してからEOL移行期間がスタートしたわけだし。

[][]トライ・アミューズメント・タワーが看板を下ろしているようだった

10年前は東京都内でもっとも輝きの強いゲーセンのひとつだったわけだが、その後パチスロとか音ゲーとかそんなのばかりになりレトロゲーフロアは縮小。ついにここまでか…

続きを読む

2008-12-04

[]データベースバグ

NetBeans 6.5の新機能である、テーブルのデータの修正であるが、なんと


PostgreSQLでまともに動かない

という致命的なバグがあるようだ。文字列の項目を修正しようとするとエラーのウインドウが出て(いわゆる例外のウインドウではない)変更不可能。



それに発行するSQLを見てると数値のカラムにシングルクォーテーションつけてInsertとかSetしようとしてるっぽい。8.1だと動くけど、8.2や8.3だと動かない可能性も高そう。


なんじゃこりゃー

[]タツノコVSカプコン

http://game.watch.impress.co.jp/docs/20081204/tatsum06.htm

やべぇ。面白そう。このムービー見てると往年のVSシリーズっぽいというか。エリアル見てると春麗は3段ジャンプくさい。

でもこれたぶん4ボタンだよね?

6ボタンに体が慣れきってるので4ボタンきついんだよなぁ。おかげでマーヴル VS カプコン 2がなんかいまいちに感じた。実際出来自体もたぶん1作目にかなわないのだろうけど。

[]Wii VC 12月ラインナップ

12月分わすれてた。

http://www.nintendo.co.jp/wii/vc/lineup.html


過去で最も配信数が少ないですなぁ。

でもFC沙羅曼蛇がはいっています。これは間違いなく名作です。ACとはもちろんかなり違うのですが、MSX版ほどはなれてもいなく、FCのスペックをこの時期ではかなり引き出しています。この作品でレーザーの再現方法を開発し、グラディウスIIへと受け継がれていきます。

チップをアピールするためにスケルトンカセットでしたね。また、この作品のおかげでACグラディウスIIのフォースフィールドが完成したといっても過言ではありません。


しかし、MSXのやる気のなさがひどい。

[]人生オワタ

Sun Tech Days 2008 in Tokyo

http://blogs.sun.com/katakai/entry/sun_tech_days_2008_in1

http://blogs.sun.com/katakai/entry/sun_tech_days_2008_in2

こういう楽しそうなものがありながらまったく参加できない俺オワタ\(^o^)/



注目は2日目の写真にある女性の絵が人生オワタ\(^o^)/に見える件。特にこの1枚はいい。

http://blogs.sun.com/katakai/resource/2008/std2008_day2-12.JPG

みんな笑ってないし、とくにヨシオリさんが下を向いてうなだれてるように見えるのがいい感じ。

現地にいけない人は妄想して遊ぶしかないぜ!



一方おいらはJ2SE1.5から1.4への移行(?)プログラムを書いていた。

思った以上に・・・大変です。/(^o^)\ナンテコッタイ

[]味とボリュウムの写真


永久保存版


930SHで8Mピクセルでとったので、秋葉通なら好きなように加工して壁紙にするがよろし。

混んでることが多くてなかなかいけないけどなー。

[][]小ネタ千夜一夜 第3夜 見せかけ

今日もスレッドの話。

というか、今日もきしださんのネタにのっかる。

http://d.hatena.ne.jp/nowokay/20081202#1228188819

http://d.hatena.ne.jp/nowokay/20081203#1228274321


実はこのサンプルプログラムはちゃんと動くかどうかわからないというもの。あくまでも概念を理解するサンプルという位置づけ。この書き方で納品してはいけない。

続きを読む

2008-12-03

[]JavaSE 6 update11リリース

http://java.sun.com/javase/ja/6/download.html

日本人には大問題だったIMEの問題が解決しています。ぜひ入れましょう。

[]ツクモEXが開いていた

あ、タイトルだけで終わっちゃった。(^-^;

T/Oとか今の人に通じるのかな。オサーンにしか通じないか。パソコン通信時代はよくあったよね。

[]930SHで撮る日常

通勤時と昼休み、帰りとそれぞれ違う時間でとっただけだが。

原寸


原寸


原寸

すべてデフォルト設定のオートによる撮影なのでISO感度シャッタースピード等が参考になるだろうか。Exifを見てみよう。

しかしマイクロSDやすいなぁ。2枚目と3枚目の場所がわかる人は秋葉通だ!

2008-12-02

[][]小ネタ千夜一夜 第2夜 Swingスレッドセーフ

あぶないあぶない。千夜どころか1夜でおわるところだった。


Swingスレッドセーフな扱いはかなり厄介なのは皆さんご存知。

http://d.hatena.ne.jp/nowokay/20081202#1228188819

きしださんのこのエントリは一見初心者用に見えて意外とそう単純にはいかなかったりする。

たぶん、初心者はどこにテクニックを使っているかすら気がついてない。


さりげなく使っているJTextComponent#setText()はSwingでは非常に珍しいスレッドセーフなメソッドなのだ!



うん、小ネタならこのくらいで十分だな。

[]930SHと910SHの比較

気合でSIM交換した。気合が必要な時点でまちがっとる。910SHはバッテリが不安なのでつねに有線で。


どちらもオート。

910SH930SH
910SH元画像930SH元画像

縮小画像からでも色合いの違いがわかるはず。このあとISO100で撮り比べてみたが910SHはさらに白とびしてしまう。それでいて暗いところは相変わらずだめなまま。

910SHはこの状態だと自動でフラッシュをたこうとするのでOFFで。もちろんフラッシュなんてたいてしまうとよけいに真っ白になってしまい最悪な結果になる。


もし903SHでも撮っていたら色が910SHより淡いのでさらにひどく見えるかもしれない。でも、レンズは903SHのほうが明るいので実はいい勝負かも。

時間がないので取り急ぎ報告まで。もう寝るっ。

[]930SH大量に撮り溜め中

2年前の903のときのように910SHと比較はしたいのだが、こいつのSIMカードの抜きにくさは異常のせいでなかなかできない。というか今後もできそうにない。そのため930SHのみで大量に撮り溜め中。


なんせいまだにSIMを指のみで取り出せたことが一度もないのだ。摩擦を増やすためにティッシュを使ったりテープを使ったりしないとまず無理というのはどう考えても異常。


910SHはSIMのセットやとりはずしの容易さがすばらしい。でも機種偏するときに気がついたのだが電池パックが異常に膨らんでいた。おかげで電圧不安定でカメラ起動するだけで電池が切れるといいながら終了処理に入るわけだ・・・。

まず、屋外での比較画像は出せないくさい。まじで交換するのに10分とか平気でかかってしまう。SIMのとりはずしが容易な910SHは電池パックの盛り上がりでふたを閉めるのが大変だしそもそも、バッテリのせいでカメラが動作不安定だし。

そういや、いくつか撮っていて気になった点としては930SHは液晶の下側が暗い場所だと赤いもやもやがでてるっぽいところ。



あー、逆に903SHはたしか捨ててないと思うので比較が出来るかもしれない。引越ししたときにどこかにいってしまって探すのが大変たが、こいつはたしか電池パックも大丈夫だったはず。

あとで探す。

2008-12-01

[]勉強することが報われる世の中になればいいなぁ

http://d.hatena.ne.jp/miyohide/20081130/1228051121

トランザクションフレームワークに頼っているならそれはありだと思いますよ。自前でやらないといけない状態に自ら持っていってそれが機能していないから問題なのであって。

一番の問題はプロジェクトが火を噴かないなど解決する方法があることを知りつつそれを選択できないことだと思います。

自社内で使うユーザー数も1人くらいのアプリや落ちてもほとんど影響のない自社プロダクト等でなんの冒険も出来ていないところがちょっと苦しいのです。そういう小さいところからこつこつ勉強していくと、いざ受注したとき「こういう方法がありますよ」、「これなら開発コストが抑えることが出来ますよ」、「品質上がりますよ」、という差別化の方向があると思うんですよね。

ですから残業込みの安請負とか、真っ当に見積もると金額が高くなったりするわけで、不利だと思うんですけどね。


勉強することが報われる世の中になればいいなぁ。

[]あー12月だ

気がつけばもう今年も残り一ヶ月。がんばろう。

[]T2Framework 0.4ついに登場…しかし?

0.4からやっと本格的なフレームワークになるだろうと思い0.3のときは動作確認だけで放置してた^^;

ぱっと見た感じ「geronimo-servlet_2.5_spec-1.1」を添付する意味が謎。Tomcat6、Glassfish V2/V3PreludeともにJavaEE5のサーブレットAPIはもってるから。実際削除してみたけど、うまくいくようだ。


また、JavaEE5ではJSTLが標準APIとなっているのでGlassfish V2/V3preludeなどいわゆるアプリケーションサーバーならばこれらのファイルも削除可能だ。デプロイサイズを小さくすることが出来る。

Tomcatのような単なるサーブレットエンジンだけではどうしようもありませんけど。


だが話はそう単純ではなかった。

続きを読む