早めに帰って寝たらかなり回復。
やはり人間寝ないとだめですね。
やはり人間寝ないとだめですね。
ここ数週間とりくんできた難題「在庫問題」おそろしく難産でしたが、
やっと動きそうな感じ。今までひたすらつらかったけど、ようやく楽しくなってきました。
やっと動きそうな感じ。今までひたすらつらかったけど、ようやく楽しくなってきました。
数週間にわたり継続して取り組んでいる難問「在庫問題」、
その最終段階で、RMIを導入する必要が出てきました。
もう5年くらいRMIは触ってなかったので、全てを完全に忘れていて、一から勉強し直しています。
以下は、今しらべた、役にたちそうなものども。
Maven RMI Compiler Plugin
Eclipse RMI Plugin
その最終段階で、RMIを導入する必要が出てきました。
もう5年くらいRMIは触ってなかったので、全てを完全に忘れていて、一から勉強し直しています。
以下は、今しらべた、役にたちそうなものども。
Maven RMI Compiler Plugin
Eclipse RMI Plugin
なぜプログラミングが楽しくなくなったのかにて、浜口さん曰く、
ともかく、プログラマーのレベル認定をきちんとしそれに対応する処遇を行うこと、そしてプログラマーが創造的な能力を発揮できるよう、仕様をきちんと決めるということの重要性を世の中全体で認識し、ソフトウエア開発の仕事の割合をふやしていくことが必要なのだ
浜口さんの中では仕様を決めるという仕事とプログラミングという仕事は別のものという認識のようです。つまり、プログラマの能力とは、決められた仕様をどれだけ早く、正確に、ソースコードに落とせるかで決まってくる、と。
私はそうは思いません。プログラマの仕事には、仕様を決める作業も含まれるべきであると思います。なぜなら、ソフトウェアの動作はソースコードによって決まるからです。さらに、最近のプログラム言語は抽象度が高いので、仕様と切り離せる純粋に技術的な問題はプログラマにあまり残されていないという事情もあります。
このような理由から、私は明確な「ソースコードが仕様だ」派なのです。
仕様を決める作業と、コーディングの作業を別のものと考えたときに、仕様を決めるという作業に取り組む態度としては、以下の２通りの考え方があります。
1. ざっくり決める
2. こまかく決める
もし、プログラマに仕様を決めることを求めないのであれば、
1. の態度をとった時、仕様に書かれていない部分のソフトウェアの動作は不定となります。2. の態度をとったとき、実質的にはコーディングとほぼ同じ作業を仕様を決める作業の中で行わなければならない。しかも、仕様書はソースコードと違ってコンパイルもテストも出来ないので、仕様書のバグを検出できる可能性は、ソースコードのバグを検出できる可能性よりずっと低くなります。
どちらにしても、顧客が得をする作業分担ではなさそうです。
プログラムがかけないSEも、仕様に思いを馳せないプログラマも、顧客にとってのソフトウェアの価値を高めるということに関しては、等しく無能なのです。
だから私は、
「プログラマの仕事とは顧客の求めるものを作ることであり、仕様書どおりのものを作ることではない」
というのです。
優秀な人でも意外に基本的な知識が欠落していることはあるし、パフォーマンスが環境に左右される部分も多いので、単純なレベル認定でプログラマの能力をはかることは困難ですが、
それでも、自分以外の誰かのためにプログラムを書きたいという思いをもち、そのためにどれだけ真摯な努力を積み重ねているかが一つの判断基準になるとは考えています。
面接とかでそこを見抜くのがまた難しいのですが。。
ともかく、プログラマーのレベル認定をきちんとしそれに対応する処遇を行うこと、そしてプログラマーが創造的な能力を発揮できるよう、仕様をきちんと決めるということの重要性を世の中全体で認識し、ソフトウエア開発の仕事の割合をふやしていくことが必要なのだ
浜口さんの中では仕様を決めるという仕事とプログラミングという仕事は別のものという認識のようです。つまり、プログラマの能力とは、決められた仕様をどれだけ早く、正確に、ソースコードに落とせるかで決まってくる、と。
私はそうは思いません。プログラマの仕事には、仕様を決める作業も含まれるべきであると思います。なぜなら、ソフトウェアの動作はソースコードによって決まるからです。さらに、最近のプログラム言語は抽象度が高いので、仕様と切り離せる純粋に技術的な問題はプログラマにあまり残されていないという事情もあります。
このような理由から、私は明確な「ソースコードが仕様だ」派なのです。
仕様を決める作業と、コーディングの作業を別のものと考えたときに、仕様を決めるという作業に取り組む態度としては、以下の２通りの考え方があります。
1. ざっくり決める
2. こまかく決める
もし、プログラマに仕様を決めることを求めないのであれば、
1. の態度をとった時、仕様に書かれていない部分のソフトウェアの動作は不定となります。2. の態度をとったとき、実質的にはコーディングとほぼ同じ作業を仕様を決める作業の中で行わなければならない。しかも、仕様書はソースコードと違ってコンパイルもテストも出来ないので、仕様書のバグを検出できる可能性は、ソースコードのバグを検出できる可能性よりずっと低くなります。
どちらにしても、顧客が得をする作業分担ではなさそうです。
プログラムがかけないSEも、仕様に思いを馳せないプログラマも、顧客にとってのソフトウェアの価値を高めるということに関しては、等しく無能なのです。
だから私は、
「プログラマの仕事とは顧客の求めるものを作ることであり、仕様書どおりのものを作ることではない」
というのです。
優秀な人でも意外に基本的な知識が欠落していることはあるし、パフォーマンスが環境に左右される部分も多いので、単純なレベル認定でプログラマの能力をはかることは困難ですが、
それでも、自分以外の誰かのためにプログラムを書きたいという思いをもち、そのためにどれだけ真摯な努力を積み重ねているかが一つの判断基準になるとは考えています。
面接とかでそこを見抜くのがまた難しいのですが。。
NexusはMavenリポジトリの管理ツールだそうで、1.0-beta1が公開されています。
まだ触れてないですが、ドキュメントを見る限りは、
複数のリモートリポジトリをまとめあげて、一つの論理的なMavenリポジトリとして見せるプロキシとなるほか、リポジトリの全文検索とかもできるようです。
組織に一つたてておいて、セントラルリポジトリからとってきたアーティファクトと自社で作ったアーティファクトを一元管理するような用途に使う事を想定していると思われます。かなり凝った設定も可能なようです。
それより、フレームワークとしてRestletを採用しているのも気になります。
Restletは1年半位前から気になっていたフレームワークなのですが、さっきサイトを見てみたらちょっとみないうちにまた雰囲気が変わってました。
Restlet、本格的に調べてみようかな。
まだ触れてないですが、ドキュメントを見る限りは、
複数のリモートリポジトリをまとめあげて、一つの論理的なMavenリポジトリとして見せるプロキシとなるほか、リポジトリの全文検索とかもできるようです。
組織に一つたてておいて、セントラルリポジトリからとってきたアーティファクトと自社で作ったアーティファクトを一元管理するような用途に使う事を想定していると思われます。かなり凝った設定も可能なようです。
それより、フレームワークとしてRestletを採用しているのも気になります。
Restletは1年半位前から気になっていたフレームワークなのですが、さっきサイトを見てみたらちょっとみないうちにまた雰囲気が変わってました。
Restlet、本格的に調べてみようかな。
新入社員が入ってきましたね。春って感じがします。
私が新人に期待する事は、出来るだけ生意気で異端であることです。
長く会社にいると、外からみるとおかしいことも、当たり前のことと感じてしまいがちです。新人なので、もちろん生意気な発言の9割は間違ってるとは思いますが、残りの1割が先輩に何かの気付きをもたらしてくれれば良いと思います。
そうはいいつつも、新人にもそれぞれの個性があるので、まずはリラックスして、のびのびと頑張ってくれればOK。
できれば、何か嫌々やらされるのではなく、主体的に打ち込める好きな仕事を見つけてくれればいう事なしです。
私が新人に期待する事は、出来るだけ生意気で異端であることです。
長く会社にいると、外からみるとおかしいことも、当たり前のことと感じてしまいがちです。新人なので、もちろん生意気な発言の9割は間違ってるとは思いますが、残りの1割が先輩に何かの気付きをもたらしてくれれば良いと思います。
そうはいいつつも、新人にもそれぞれの個性があるので、まずはリラックスして、のびのびと頑張ってくれればOK。
できれば、何か嫌々やらされるのではなく、主体的に打ち込める好きな仕事を見つけてくれればいう事なしです。