おのたく日記 YouTubeも始めました→

■ [Eclipse] MyEclipse J2EEプラグイン

http://www.myeclipseide.com/

「よさげかなぁ」と思ったんだけど、$29.95無料じゃないのね(トライアル30日) しかも、EA1ではまだJSP/Servletだけか…

■ シリコンバレーのプログラマーは本当に凄いのか？続き

5月7日の日記「シリコンバレーのプログラマーは本当に凄いのか？」に沢山のreferと、トラックバックが有った。やっぱり、このあたりには日々感じる事が多い人が沢山いるんだと思った。

この一連を読み始めることになった日記である吉岡さんの日記でも5月1日のシリコンバレーのプログラマーは本当に凄いのか？で「refere を頂いて休日にはそれを眺めるのを楽しみにしている」って事で、いろいろ感想を書いてくれている。しかも、この中では、わんこの5月4日の日記にもリンクを頂いた。

吉岡さんも「Cagylogic blog: 単純に真似すると痛い目を見る」については、「なかなかいい感じである」とのことで、「みんな感じるところは同じなんだなぁ」と思った。

■ Cagylogic blogの続きを読めてなくて残念

ちょっと残念なのは、Cagylogic blog:必要な製品のクオリティからもトラックバックを頂いたけど、ゴールデンウィークでサーバが止まっているのか読めてない事。

■ 単価を高くするためにSEにする

スキルではなくて、年数や経歴で単価を決めてしまう業界の仕組みが、すばらしいプログラマが育たないことについて、

ネットワークやOSやデータベース周りのスキルがない技術者が高い単金を取得するためにSEとして売り込まれている現場

[サイボーグ戦士の日記:Re:シリコンバレーのプログラマは本当に凄いのか？より引用]

と現場の例をあげて「サイボーグ戦士の日記」さんから熱い同意のトラックバックを頂いた。

■ ソフトウェア製品の輸出

吉岡さんの5月2日の日記を読んで、自分がなんで、今の会社で仕事を続けているかの理由がわかった気がする。古臭いソフトウェア製品製造手法がメインだし、収入も安いのにいる理由は、

1. お客の要望によるアプリケーションプログラムではなくて、 ソフトウェア製品。

2. 北米はもとより世界中に輸出される。

この二点を持っていながら、日本で開発を行っているからだ。

望んでここに来たというわけでない。この仕事へは、たまたま流れ着いただけだし、本当は「シリコンバレーに行きたい」と思っていたる。それに、去年の前半までは、輸出はするけどオフショア開発のための製品の担当だったので、本格的に製品として輸出するソフトウェア開発にかかわることが出来たのは、去年の9月からのこと。これも、必然性があったわけではなく、たまたま輸出できる製品の担当になるチャンスがあったからなんだけれど…

20代のころは、金になる新しい仕事があれば、次々と仕事を変えていたのに30代になって変わらなくなったのは、「おれも年を取ったのか」と思っていたけど、もし次の仕事を探そうして、こんなソフトウェア開発の仕事はなさそうだから、もう少しつづけてもよいと思えるんだな。

日本では、吉岡さんも指摘するように、「輸出されているソフトウェア」一歩譲って「ソフトウェア製品」を開発できる場所って限られているからな。

■ 「日本の凄いプログラマを生かす場所を作る」という意気込み

話は変わるけど、この日の吉岡さんの日記に出てくる

日本にも凄いプログラマはいる。間違いなくいる。しかし今まではそのスキルや専門性を生かす場所がほとんどなかったのである。

であるならば、小さくとも当事者として自分がその場を作る。そーゆー意気込みである。

[はてなダイアリー - 未来のいつか/hyoshiokの日記より引用]

という、吉岡さんの意気込みには感服した。

一応、輸出できるソフトウェア製品の担当だけど、自分は、今の仕事もプログラマとしてはプロモートされない。でも、大学で国に1,000万円以上の税金を使わせて「100名以上のトップになる」教育を受けていたのだから、自分ではプログラマーでなく、プロジェクトマネージャーとしての道を進むのも合っていると思っている。

もしプログラマで生きていくような人生だったら吉岡さんのようなパイオニアが道を開いてくれる事は、絶対に必要だと思うだろう。

プログラムって楽しいし、サービスではなく「物を作り出す製造業」しかも「頭を使って、物を作り出す」ということは、資源が無い日本では大切だから、これは日本にとっても必要な道だと思う。

■ バグ分析

吉岡さんの5月2日の日記:Tバックで、バク分析についての解説が有った。

バグデータベースに記録されているオープンなバグ数、クローズしたバグ数などをマクロに見ていくことによってプロジェクトの進捗を知ることができる。またバグを一つ一つ検討することによって、どのようにしてバグを発見したか、どのようにバグを修正したかを知ることができる。バグを分析をするのは最終的にはどのようにしてバグを作ったかを知ることであるが、そのレベルまで深くバグを分析している例は少ない。

[はてなダイアリー - 未来のいつか/hyoshiokの日記より引用]

いままでは、ソース管理についての話が出てきていたけど、今度はバクデータベース。

ソース管理はCVS, Subversion, ClearCaseだけど、バクデータベースは、どんなものがよいのか、いまの仕事でも、使っているのは素晴らしいけど、特別製のアプリケーションで、一般的なものでないので、世界的にはどんなものが良いのか気になった。

やっぱりJavaのBugパレードや、SourceForgeのBrowse Bugsみたいなものが、今のトレンドなのかなぁ。これらで気になるのは、バグとソースコードの連携が出ない事「このバグは、ソースのココとココで直したぜ」と出ないとプログラマとしては困るし…

バグ分析については、旧来のソフトウェア開発手法であっても、最終的にテストを行いバグをみつけているのだから、旧来からの手法で分析ができるはず。先達に教わる事も多いだろうから、自分自身も、まだまだ勉強が必要な範囲だと思った。

吉岡さんの日記では、最後に「続く」となっているので期待。

■ テストエンジニアの育て方

また、この吉岡さん日記からリンクされているblogで

更に別なテスト方法を考えられるようなテストエンジニア養成に必要な事。

今、自分はバグの調査目的のプログラムを作成する事もあるんです。それって結局テストパターンの作成なんで、こういうところから仕事以外で何かやれないかなって思っています。

[はてなダイアリー - tmpfile::dialyより引用]

というのが有った。

ソフトウェア製品のサポートをやっていると、障害調査のなかで、再現という作業があるけど、ここで、うまくリグレッションテストのテストパターンを見つけたり、ここでテストエンジニアを育てていけないものだろうか。

■ プロかノンプロか

tmpfile::diary「"プロかノンプロか" ですか．」からのリンクの「この道はいつか来た道... REBOOTED: プロかノンプロか」

で「プロなんだろしっかりやれよ」という、熱い話が載っているのを知った。

「あーレビューの目的は、技術の試合じゃなくてゴールは、お客さんの満足するものを作ること、プロジェクトの成功なのになぁ。折角すばらしい腕を持っているのに」と思った。

■ [CoCoon] コクーンのHDD換装に利用したHDDについて

5月9日の日記のコクーンのHDD換装で入れ替えたHDDは、おうちサーバ用に買っておいたHitachi Global Storage Technologiesの「Deskstar　HDS722516VLAT20」です。

160GBは、今回CoCoon用に使ってしまったので、おうちサーバのHDD増量はおあずけになってしまったけど、いつのころからか忘れたけど、おうちサーバのHDDは、1台 10,000円を切るようになる毎に買い換えをしていて、3GB(1998)→27GB→60GB→160GB(2004)と増量しているが、おうちサーバ用には「音が静かで壊れにくい」という噂を耳にしたことがあるので、27GBのHDD以降はIBM(今はHitachi)のHDDを利用している。

参考: HDD主要製品の最安値推移

今回の160GBは、以下のような物です。

ハイライト

最大250GBの大容量

最大96.5Mb/mm2（62.3Gb/inch2）の面記録密度

最大8MBのデーターバッファーサイズ

流体軸受モーター採用による静音設計

ヘッドロード・アンロード機構

スマート機能/温度センサー搭載

ATA-6準拠、Ultra ATA 100（パラレルATA）

7200rpmのディスク回転速度

[Deskstar 7K250 シリーズより引用]

流体軸受けということで、たしかに、元からCoCoonに入っていたHDDより音は静か。(元のHDDは壊れかけているから、うるさいのかもしれないけど…

良くHDDの比較で用いられるスペックでいうと　

models Capacity (GB) RPM Data buffer Interface

HDS722516VLAT20 160 7200 2 MB Parallel-ATA

[Deskstar 7K250 hard disk drives specificationsより引用]

バッファーは2MBだけど7200RPMで、元の5200RPMよりは早いのでCoCoonのBootは少し早くなったような気がする。

容量的には、CoCoonに元から入っていた163GBに対して164GBなので、ちょっとだけ録画容量が増えて、いままでより録画時間が減ると言うことがないので、一応は満足している。

一度CoCoonのHDD換装に成功してしまうと、次は「3万円の400GB HDDを買ってきて録画時間250時間だ!」とか夢は膨らむ…

■ [JDeveloper] Debian amd64 etchにJDeveloper10g Release3(10.1.3)をインストールする

JDKは、Sunからダウンロードしてきて

% fakeroot make-jpkg jdk-1_5_0_06-linux-amd64.bin

として、sun-j2sdk1.5_1.5.0+update06_amd64.debを作ってインストールした。

参照: 10月31日の日記

結果は、

java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_06-b05, mixed mode

てなかんじ。JDeveloperのインストールは、JDeveloper 10g/10gR3インストールのように展開してパーミッション変えてインストール完了。

はまったのは、hotspotを使おうとするけど、amd64用のJVMには無いようなので

#T SetJavaVM hotspot

SetJavaVM server

[/usr/local/JDeveloper/jdev/bin/jdev.confより引用]

のようにSetJavaHomeだけではなくてVMオプションも変えた事。

■ [JDeveloper] Debian amd64 etchのJavaで日本語フォントが出ない

11月1の日記「Javaで日本語フォントが出ない」というのが有ったけれど、ここに書いたJAVA_HOME/jre/lib/fontconfig.propertiesを編集する方法では、うまく行かなかった。

ttf-sazanami-gothicパッケージをDebianにはインストールしてあるけどxfontselでsazamaniフォントって出ないし、sinonomeフォントなら出るので変えてみたけどダメ

Java(JRE) インストール先にある lib/fonts ディレクトリに fallback というディレクトリを作成し、フォントファイルへのリンクを張ります。

こうすることでそのフォントを Java が認識し、使用する事ができるようになります。

[Linux に Java(JRE 1.5) をインストールする方法 - Java のフォント設定より引用]

にある。JAVA_HOME/jre/lib/font/fallbackを~/.fonts(osakaフォントとか入っている)にシンボリックリンクしてみた。

/usr/lib/j2sdk1.5-sun/jre/lib/fonts# ln -s ~/.fonts fallbac

うまく漢字がでるようになった。

■ [Debian]iSCSI target

「貧乏人のためのboot-from-SAN (1) 導入編」で、LinuxでiSCSIがつかえそうなことを知ったので、早速やってみる。

まずは、iscsitargetパッケージをインストールしてみたけど、iscsi_tgrというkernelモジュールが無いとietdデーモンが起動できない。

どうやら、それはiscsitarget-modulesパッケージに入っているらしいけど、amd64用にはまだないので、iscsitarget-sourceパッケージを利用して作り出す。

# module-assistantで、iscsitargetモジュールをSELECTして、Build&Installする。

# /etc/init.d/iscsitarget start
Starting iSCSI enterprise target service: succeeded.

てな感じてiSCSI targetが動き出した。

LUN割り当ては、

# ietadm --op new --tid=100 --params Name=iSCSI-name
# ietadm --op new --tid=100 --lun=0 --params Path=/dev/sdb5

でな感じで出来るらしいけど、LVMに割り当てられるDISKが無かったりして今日はそこまで出来なかった。

Windows Vistaならば、iSCSIイニシエータがついているので、iSCSI DISKを使えるようになるはず!

■ [Linux][ext4]ファイルシステムをext4にする

Ubuntu 9.10などを入れるとdefaultでファイルシステムがext4になっている。Debianのおうちサーバは、ext2でインストールしたあとfsckの長さにヘキヘキとしてジャーナルが使えるext3してから、そのまま使っていた。

最近、なんかファイルシステムの読み書きI/O待ちでマシンの性能が落ちているような気がするし新しいもの好きなのでext4に変えてみた。まずは、おうちのext3とext4を比べてみた。

Ubuntuのファイルシステムをtune2fs -l $DEVで調べてみると

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

となっている needs_recoveryはマウント中というマーク。 huge_fileとlarge_fileの料へ方があるけどhuge_fileさえ有れば良いような気がする…

Debianのext2から移行したext3は

sda1:
Filesystem features:      has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
sda3:
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent sparse_super large_file uninit_bg
sda4:
Filesystem features:      has_journal resize_inode dir_index filetype extent sparse_super large_file uninit_bg

ということで、flex_bg huge_file dir_nlink extra_isize　が不足している。

Webで調べてみると

flex_bg ブロックグループのinodeとbitmapの配置位置が自由になる。これにより仮想的な大きなブロックグループを使ってinodeの割り当てをする。速度向上やフラグメンテーション軽減。→採用

huge_file ファイルシステム16TB→1EB ファイル2TB→16TB　→　将来検討

dir_nlink 最大サブディレクトリ数が32000から無制限に　→　将来検討

？ extra_isize　ナノ秒まで保持するように　→　アプリは対応していないのにいるのか?

ということなので、レスキューCDでマシンを立ち上げて

# tune2fs -O flex_bg,extents,uninit_bg,dir_index $DEV &&
tune2fs -I 256 $DEV &&
e2fsck -yfDC0 $DEV

としてext3からext4に移行した。ただし、ルートパテーションは、flex_bgは怖いので、まだ使っていない。