S2JMS についてちょっと調べました。
そもそも S2JMS はどこにいるのか。
ここにいた。
s2jms: Default Project Content
OSCJ.net には Seasar Sandbox に属しているプロジェクトがホストされてるのか？
seasar: ホーム
ていうか、OSCJ.net って何？
OSCJ.net
OSCJ.netは、「使う」ソフトウェアを、インターネットを通じて広く公開するとともに、ソフトウェアを「つくる」こと或いは「改良する」プロセスも公開し、多くの人々にソフトウェアを「つくる」或いは「改良する」楽しみも提供するために設立されたグループです。
S2JMS はここにもいた。
Seasar - DI Container with AOP -
サンプルプロジェクトがダウンロードできるけど、「S2JMS-ActiveMQ-Blank-JSF-1.0.0-M1」が動かない。
↓ここで書かれているのと同じエラーが出る。
大樹の色々日記 - 2006-05-14
そもそも JMS ってどのくらい使われているんだろう。
mixi の足あとにひがやすおさんがいてびびった。
たぶん「Seasar」で検索してきたんだろうな。
mixi は細々とやってます。
mixi の jugyo
メモ:
現場が最新技術に敏感すぎるのも考えもの。
最新技術は見極めが難しい。
それとあと、できるだけ多くの人が理解できるものが望ましい。
自分だけが開発するわけじゃないから。
もういっそのこと、Seasar と Spring を一緒に使えば良いのではないか。
冗談です。
「やる気を失っている」状況は、「ドラえもん」の新刊が欲しい状態であり、「アラレちゃん」では満足できない心境と言えます。まずは「そうか、自分は『ドラえもん』の新刊が欲しいのだ！」ということに気づくことが先決なのです。
それに気づくことができれば、あとは「ドラえもん」の新刊を買いに走るだけです。
面白い表現。
注: グダグダです
「プログラミングとはどういう作業なんだろう？」と、最近ふと考えたりする。
世の中には「物を作れる人」と「物を作れない人」がいると思う。
で、「物を作れない人」はプログラマには向いていないかもしれない。
そもそも、物を作れるとか作れないとかってのはどういうことか。
「作れる」と「作れない」とではどういう違いがあるのか。
うーん、これは難しい。
例えば、絵が描ける人と描けない人の違いみたいな。
ちなみに、自慢じゃないけど僕は絵を描くのがうまい。
でも文章書くのは下手。
ま、人には向き不向きってものがある。
参考: HiroIro: NHKの歌のお姉さんが草彅画伯を超えた件について
できるだけ得意な分野を伸ばすようにしていくべき。
話それた。
どうもアプリケーションをうまく設計できない人ってのがいる。
その人が作ると、どうやってもセンスが悪い作りになってしまう。
ところで、以前呼んだ読んだこの本が面白かった。
 |
Cプログラミング診断室―さらに美しく健康的なプログラムのために 藤原 博文 技術評論社 2003-07 |
途中までしか読んでなかったな、そういえば。
この本にはセンスの悪いプログラムの例がたくさん出てきて面白い。
「アイデアとしてはすごいんだけど、ちょっと…」てな感じのがたくさん。
そう、人って「一番始めに思いついたアイデアに固執してしまう性質」を持ってる気がする。
ミーティングとかで話がそれちゃうのもそれと似たようなことが原因ぽい。
その話が本質的じゃなかったとしても、その線でどうしても考えずにはいられなくなっちゃうんだろうな。
「ここはコンボボックスにしてユーザーが選べるようにしてよ」
「え、じゃあここもコンボボックスじゃないと変じゃないですか？」
「いや、そこはコンボボックスじゃないほうがいいな。ユーザー的に」
「でも統一性という観点からするとですねぇ…」
「それを言い出すと、ここも変えないとダメだよねぇ」
「うーん、そうなりますねぇ…」
…
話それた。
物をうまく作り上げるためには、自分に何ができて何ができないのかをちゃんと知っておく必要がある。
あと、目的を見失わないこと。
 |
達人プログラマー―システム開発の職人から名匠への道 アンドリュー ハント デビッド トーマス Andrew Hunt ピアソンエデュケーション 2000-11 |
最近この本をまじめに読み始めた。
面白いし、非常に為になる。
プログラマなら読むべき。
とか軽々しく言うのはどうかと思うけど、やっぱ読むべき。（何が言いたいのか）
思ったんだけど、ブログ等で「プログラマ必読」とか言ってそれ系の本が何冊か紹介されてたりするじゃないですかぁ。
ま、それらは確かに必読だったりするんでしょうけど、プログラマが読んでおくべき本ってのは当然それ以外にもたくさんあると思うんですよね。
で、それらを全部挙げるとかなりの量になると思う。
で、で、思ったのですが、僕としては、それらをどういう順番で読むのが良いのかが知りたいんですよねぇ。
別に他人を頼りにしてるわけじゃなくて、あくまで参考にするだけ。
例えば、自分の知らない分野のことについて勉強を始める時に、その分野に関連する本としてどういうものがあって、それぞれがどういう位置づけなのかということがある程度わかれば便利じゃないですかぁ。
てういか、そういう意味でブログってすごく良い。
ブログに含まれるアマゾンのリンクを調べてゴニョゴニョやってどの本にどのブログが言及してるのかとかすぐにわかると便利かもとか思ったけど「はてな」とかそういうふうになってるよね確か。
あ、そうそう、本もいいけどソースコードもたくさん読まないとね。
知識と経験がないと、まともなアプリケーションは作れないと思う。
ちなみに、僕はソースコード読むのはあまり好きじゃない。
読むの遅いから。
でもだいぶ早く読めるようになってきた。
読む速度が上がったんじゃなくて、必要なところだけを選別して読む能力が上がった。
そう、仕事においては、学習するにしても効率が重要になってくる。
だから知ってる人に聞くとかもする。（でも時と場合による）
断片的な知識・知能をチームワークで補うというのも重要。
仕事はチームワークが重要ですね。
面白いのは、一人じゃできないことでもチームだとできたりすること。
でも数は少ない方がチームとしてはうまくいきやすいと思う。
話それた。
「達人プログラマー」はプログラマ必読です。
「プログラミグとはどういう作業なのか」とか「どのように考え、行動すればよいか」とか「どういったところに気をつけなければならないのか」ということがわかりやすく書かれています。
「まえがき」から引用
我々はすべて（あるいはほとんど）の答えを知っているとか、すべての状況にわれわれのアイディアが適用可能である、という主張を行うつもりは毛頭ありません。ただこのアプローチに従えば、飛躍的に経験を積むことができ、生産性を高め、開発プロセス全体のより良い理解が得られるようになるでしょう。そして結果的により良いソフトウェアを構築することができるようになるのです。
要は、疑似体験としてでもいろんなことを前もって経験しておくと良いよ、ってな感じかと。
