Javadoc の書き方 - イトウ アスカ blog
みなさん、Javadoc 書いてますか？ Javadoc は「API ドキュメント」と言われることが多いように、主にライブラリ的なプログラムで書いてこそのものだと思っている方もいるかもしれません。しかしながら、仕様書を Word や Excel（笑）で別途作ると、プログラムと仕様書の同期がとれてないというはめに陥り易くなりますので、Javadoc はどんなときも活用したいというのが私の考え方です。 まず、overview.html を書け Javadoc コメントをいくらか書くような人でも、overview.html を書く人は意外と少ないのではないでしょうか。リファクタリングが何度となく行われるアジャイル開発の現場では、クラスの構成がよくかわりますので、いちいち詳しいコメントを書いていられないということはあるかもしれませんが、overview.html はそれほど何度も手をつけるようなも
Wicket でこんな風にプロジェクトをすすめました - イトウ アスカ blog
ちょっとした成功体験を紹介します。 どんなプロジェクトだったか オフコン系の社内業務支援システムをWebベースに作り変えるプロジェクトでした。まだ全部終わってませんので過去形でいうのは適当ではありませんが。 コンポーネントの登録を省力化した とにかくこの手のシステムは1画面あたりの項目数が多い。なので、コンポーネントの生成と登録をちんたら手組しているとラチがあきません。そこで私がとった方法は、Excelシートに項目名とコンポーネントの種類、Wicket ID、必須か否かや値の範囲などの簡単なバリデーション情報を書いて、それを POI で読み込んでソースを生成することでした。 はじめはコンポーネントの種類はまさしくクラス名で指定していたのですが、何度かバージョンアップを繰り替えして今では和名で指定しています。実際のクラス名とは別区XMLファイルで結びつけています。たとえば「テキストフィールド
Whyも書け - イトウ アスカ blog
重要なことなので何度だって言いますよ。 コンピュータシステムの仕様書を書くとき、以下の項目が文章として残されていますか？ What - 何を（入力の形式） Where,Who - どこの誰が（どのコンピュータが） When - いつ（処理のタイミング。オンデマンド／バッチ。さらにはこのシステムが作られた日） How - どのようにするのか そして Why - なぜこのシステムが必要なのか。システムの狙いは？
すべてのものにはトリガー（引き金）がある - イトウ アスカ blog
今、私が出入りしている会社で何やら新人研修的なものをやっているようなんです。Seasar2 を用いて何かのシステムを作っているようですが、トレーナーの語調からすると上手く行ってないようです。 それで、トレーナーの方が切々とトレーニーになにやら説明しています。 仕事の進め方はそこそこの会社で違うでしょうから、私のような外の人間がとやかく言うようなものではないでしょう。でも、ちょっと気になるのが人情。私にもしゃべらせろと思ってみたり（笑）。とは言え、そんなことはおくびにも出さずに自分の仕事を淡々としていますがね。 ということで、私がその時言いたかったかったことをここで言わせていただきたいと思います。 それは、新人には「すべてのものにはトリガー（引き金）がある」ということを強く教えなければならないということです。 クラス図書いてみろと言って、上手くできない。なぜできないのか？ みんなきっと学歴で
ビギナー Web プログラマに一皮むけるためにやってほしい5つのこと - イトウ アスカ blog
1. Web サーバの設定方法を覚えてほしい そんなに深くじゃなくてもいいんです。Apache でも IIS でも、なんだったら AN HTTPD だっていい（というか AN HTTPD って学習用にはかなりおすすめです）。それでどこにファイルを置くと外部からアクセスできちゃうのかということを知ってほしい。直リンクで様々なファイルを叩いてほしい。 「どんなところで稼働するのか」ということをほとんど学ばずに Web アプリケーションを書いている人って意外と多くて、そういう人が顧客情報がぎっしりつまったデータファイルを平気で外部からアクセス可能なところに置いたりするんですよね。 2. HTTP クライアントを作ってみてほしい とにかく Web プログラム自身が吐き出した HTML を善意に解釈するブラウザ（IE や Firefox）からのみアクセスされるものだと思い込んでいる Web プログラ
Wicket + Databinder + ActiveObjects が熱い - イトウ アスカ blog
すごくいい。とってもいい。何がいいって、まず ActiveObjects から褒めてみますね。 使えるようになるまでがあっというま（設定やコード量的に）。DI コンテナとかいらない。設定ファイルももちろんいらない。 エンティティに合わせて CREATE TABLE を発行してくれる。すでにテーブルが存在したら、現在のエンティティに合わせて ALTER TABLE も発行してくれる。リファクタリングをよくする人にはうってつけ。 Commons DBCP や C3P0 がクラスパス内にあったら、それを自動的に認識してコネクションプーリングに使ってくれる。ちなみに C3P0 はクラスパス内に Log4J があったら Log4J でロギングしてくれる。log4j-over-slf4j を入れとけば SLF4J でログをはくから Wicket とのログの親和性も問題なし。 パフォーマンスはどれぐらい
こんな Java プログラマとはいっしょに仕事をしたくない - イトウ アスカ blog
自社の社員だったら、教育すればいいだけなんだけど、他社の人だったらきっついわーって人。大規模プロジェクトでかき集められた人員がこんなんだったらげんなりします。 javac でコンパイルできない IDE に頼りすぎ。いざというときに使い物にならない。こういう人は「そもそも論」がなってないことが多い。 IDE を知らない 上の逆。テキストエディタでこつこつ作る。そのほうがいいものができると確信してやってるわけでもないやつが多い。そういうやつはもちろん生産性が低い。 Entity クラスでもないのに public フィールドを使う カプセル化がわかってないことが多い。Entity クラスだけに限定して public フィールドを使ってたりするのは確信犯（？）だったりするので、別にいいけど。 static メソッドと static フィールドがやたら多い そもそも OOP がわかってないことが多い
危険なプロジェクト - イトウ アスカ blog
傍目から見て「ああ、こりゃ炎上するな」と思うプロジェクト。思いつくままに書いたので視点があっちこっちだけど。 ベンダー・ロックインしたいのかどうか知らないが誰も知らないような（シェアのかなり少ない）ツールを使おうとしている。 なので「Java 要員が欲しい」とか言いながら本当に欲しいのはそのツールの要員。 いるわけないので人員不足にあえぐ。 困ったとき Google 先生に聞いても答えてもらえない。 そのくせ開発元に問い合わせない／問い合わせても有用な回答が得られない。 結局ツールの「選定」がおろそか。 おろそかどころか選定すらしていない。 脊髄反射的に関係ベンダーの製品を使う。 脊髄反射的に過去のプロジェクトで使った製品を使う。 しかもそのプロジェクトも炎上しており、その製品を使用したことも原因のひとつだったことを忘れている。 「セキュリティのため」の一点張りでインターネットすらまともに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CentOS 5 における SELinux 関連のメモ - イトウ アスカ blog