1. 無料アクセス解析

crossroad's Blog

Javaを中心にした技術ネタなど。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告

責任感...たけしの日本教育白書

途中からしか観てないんですが、たけしの日本教育白書と言う番組で「責任感」について取り上げてました。

# いやしかし爆笑問題田中の小倉智昭への発(暴)言...スゲ(汗
# 佐々木アナとか大丈夫かいな

企業の責任感として、森永ヒ素ミルク事件や、日航ジャンボ機墜落事故なんかを
取り上げていましたが。。。

IT(ソフトウェア開発)業界はどうかなぁ。
僕が思うに、責任感を持って仕事できてる人ってあまりいないのでは。

「言われたことだけ、やっとけば良いや。
 それで問題になっても、指示した人の指示の仕方が悪いんでしょ」

「なんかヤバそうだけど、どうせ会社(あるいは上位ベンダ)が責任取るだけだし、
 俺の知ったこっちゃないね」

「失敗したら、お客の責任にして逃げれば良いし」

「ミスはアウトソーシング先の問題だ」

「発注元がヘボすぎて、こんなんじゃ仕事できない」

...こんな感覚が蔓延している気がします。

しかも、ある程度の大企業、キャリアや地位にある人ほど責任感がない気がする。
末端で、安い単価で地道にプログラム書いたり、テストしたりしてるが一番一生懸命だったり。
# いや、あくまでも僕の印象ですよ...

そりゃソフトウェア開発が失敗して死人がでることは滅多にないでしょうけど、
今やITなしの社会はありえないので、結構責任重大だと思うのですが。

恐らく、「どんだけしくっても、最終的には何とかなるだろ」と言う感覚が根底にあると思います。
(事実、良くも悪くも最終的には何とかなってしまうことが多いですし)

あとは、アウトソーシング、外注(ビジネスパートナ)依存のビジネスモデル。
上位ベンダは、外注先に仕事放り投げて任せっぱなし。
下位ベンダは、お客さんの顔が見えないので責任感が沸かない。自分達の仕事と言う意識がない。


個人的には責任感持って仕事しないと良い意味での緊張感もないし、
モチベーションもあがらないし、仕事が面白くないんですよね。
「これミスったらヤバイなぁ」みたいなある種のスリルが欲しいと言うか(^^;
# 以前、長期間アサインしていた現場で鍛えられたなぁ
# 真剣にヤバイときはそんな悠長なこと言ってられませんが

それに、仕事の面白さや、やりがい、仕事への評価、そして報酬。
これらは全て責任を負って仕事をするからこそ付いてくるものだと思っていて、
これらはトレードオフなんですよね。
責任から逃げておいて、やりがりのある仕事がしたい、高い給料くれ、なんてのはあり得ん話なわけで。


そういう意味では、フリーランスはおいしいと言えます。

普通のサラリーマンに比べれば、自由で高収入。
しかも、業務請負契約..自分で責任を持って仕事をやり遂げます...と言っておきながら、
責任は所属した会社が取ってくれる。
# もちろん、本当に自分で仕事を請けてやってるフリーエンジニアの方もいます。

最近はフリーランスへの風当たりも強くなってきていますし、
本来、こんな責任と報酬のバランスの取れてない職業はあり得ないわけで...
本当に自分で仕事をしているエンジニア以外は、いずれ淘汰されるような気がします。

ってことで、自分も危機感アリアリ。
頑張るとこは頑張って、自分の道筋を考えないと。


と、話がそれましたが、自分(達)の仕事に責任を持っている現場で仕事がしたいものですし、
自分もそういう雰囲気を作れるように振舞いたいと思いました。

スポンサーサイト
  1. 2007/10/27(土) 23:57:08|
  2. フリーランス
  3. | トラックバック:0
  4. | コメント:0

au 秋冬モデル

先日、auの秋冬モデルが発表されました。

夏モデルが(僕的には)不発だったので、期待していたのですが。。。

一番気に入ったのは、W55T
待っていた超薄型ケータイですね。ワンセグなんていらねー。
超重要ポイントのポケベル文字入力も東芝製なら搭載している可能性大。
ディスプレイは2.4インチでneonと一緒。もうちょっと大きければよかったんですけども。

あとは、INFOBAR2。。。
でも人気機種だろうし、いかにもすぎてちょっと敬遠。

W56Tも悪くはないけど。。。重そう。

あとは候補外。


今使っているneonも古いし、ここらでいっちょ機種変するか。
  1. 2007/10/25(木) 22:58:43|
  2. 日記
  3. | トラックバック:0
  4. | コメント:0

Maven2のjavadoc生成でコンパイルエラー

Maven2 でJavaDocを生成(mvn javadoc:javadoc)すると、
コンパイルエラーが発生しました。


例えば、JUnitのTestCaseを継承して、独自のTestCaseを作成し、JavaDocを生成しようとすると。。。


-----------------------------------------
> mvn javadoc:javadoc
  :
パッケージ foo.bar.test のソースファイルを読み込んでいます...
Javadoc 情報を構築しています...
標準 Doclet バージョン 1.5.0_11
全パッケージとクラスの階層ツリーを作成しています...
警告 3 個
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------

C:¥eclipse¥workspace¥foo¥src¥main
¥java¥foo¥bar¥test¥FooTestCase.javaa:23: シンボルを見つけられません。
シンボル: クラス TestCase
public abstract class FooTestCase extends TestCase {
                     ^

java.lang.NullPointerException
at com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:65)
-----------------------------------------



JavaDoc生成以外では、Maven2からでも、Eclipse上でもコンパイルが通っているのに、
なぜかJavaDoc生成時にJUnitのTestCaseクラスが見つからず、コンパイルエラーになってしまいます。


原因は、pom.xmlの依存関係のスコープで、
--- pom.xml(抜粋) ---
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
-------------------
のようにJUnitライブラリを追加していたことでした。

JUnitなので、テスト時にしか使わないだろうと言うことでスコープをtestにしていました。
# testスコープのライブラリは、ユニットテストのコンパイルと実行にしか使用されません。(参考

ところが、JUnitを拡張して作成したクラスFooTestCaseは、
¥src¥test¥java下ではなく、¥src¥main¥java下に配置
していた...
つまり、ユニットテストではないので、testスコープの範囲外と言うことで、
JavaDoc生成時にJUnitライブラリがクラスパスに設定されないようです。


対応としては、pom.xmlで、JUnitのスコープを修正すれば良いのですが、
compileスコープにしてしまうと、実行モジュールにJUnitがバンドルされてしまう
(*.warの/WEB-INF/libに入ってしまう等)ので、

--- pom.xml(抜粋) ---
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>provided</scope>
</dependency>
-------------------
のように、providedにしました。

これならコンパイルも通るようになるし、実行モジュールにJUnitが入ってしまうこともありません。




  1. 2007/10/22(月) 23:11:59|
  2. ソフトウェア開発 Maven
  3. | トラックバック:0
  4. | コメント:0

情報処理試験(AE)受験してきました


秋期情報処理試験(アプリケーションエンジニア)を受験してきました。

結局、過去問題集をザッと読んだだけでチャレンジ(^^;
# 本当はちゃんと勉強するつもりだったんですけど、出張やらなんやらで忙しくて..
# いや、まぁ昔程学習意欲がなくなったってのが本当のとこですけど。

で、結果は。。。微妙。。。

午後Ⅰは自身アリ。
まぁ普通にSEやってれば普段の業務と変わらない設問です。
UMLが普通に使われていて、もはやUMLは必須知識になったんだなぁと実感。

午後Ⅱの小論文は。。。ちょっと失敗。
前回受験したとき、時間が足りなかったのでとにかく急いで字数
(少なくとも2000字くらいは書かないといけない)を稼ごうとしたのですが、
いきあたりばったりになってしまって、いまいちまとまりのない論文に。。。
書き始める前に5~10分でも時間取って、章立てを考えればよかった。

午前は一番自信ナシ。
一通り解答して、4分の1はさっぱりわからない状態。
と言うか、こんなの実業務では全く関係ねーよ、って問題も結構ある。
あと、計算問題が結構多くてゲンナリ。(基本、計算問題は捨てている)
とりあえず常識的に考えて。。。で解答したけど、合格ラインはギリギリかなぁ。

まぁ、運が良ければ合格してるかも。
合格発表を楽しみに待つとしよう。

テーマ:情報処理技術者試験 - ジャンル:コンピュータ

  1. 2007/10/21(日) 21:13:17|
  2. ソフトウェア開発 一般
  3. | トラックバック:0
  4. | コメント:0

Eclipse + Maven2 + Tomcat + Seasar2 の開発環境ベスト!?プラクティス

昨今、良くある(僕自身も好みの)組み合わせで、
 ・IDE・・・Eclipse
 ・ビルドツール・・・Maven2 及び Eclipse m2eclipseプラグイン
 ・コンテナ・・・Tomcat 及び Tomcatプラグイン
 ・フレームワーク・・・Seasar2 及び S2ファミリー
と言うのがあります。

しかし、開発環境構築は結構難問です。
Eclipse、Maven2、m2eclipse、Tomcatプラグイン...
それぞれ「個別の問題」にフォーカスしたツールを組み合わせようとすると、
細かいところでギャップがあって、各ツールの長所を活かしつつ、うまく連携させるには試行錯誤が必要です。


そこで、以下のような各ツールの長所を活かせる開発環境を作ってみる。

 1.Eclipse
  ・修正したソースのインクリメンタルコンパイル
  ・その他もろもろ...

 2.Maven2
  ・pom.xmlによるプロジェクトメタ情報の定義、一元管理
  ・ビルドの標準化

 3.m2eclipseプラグイン
  ・pom.xmlの依存ライブラリを修正するだけで、
   ライブラリのダウンロード、Eclipseビルドパスを自動更新

   (依存ライブラリを修正するたびに mvn eclipse:eclipse しなくて良い!)

 4.Tomcatプラグイン
  ・Eclipse上でTomcatの起動/停止。
  ・デバッグが簡単。(リモートデバッグしなくて良い!)
  ・DevLoaderを使えば、Warモジュールを作成することなく、
   修正したソースをTomcatに即反映可能


 5.Seasar2 2.4.xのSMART Deploy
  ・HOT deployで、Tomcat(のコンテキスト)を再起動することなく
   修正したソースをTomcatに反映可能

   Seasar2 2.4.x以上が必須になります。

つまり、
必要なライブラリは自動設定されて、修正したソースはTomcatに即反映されて、
Tomcat上でデバッグもできて、Mavenで一貫したビルドもでき、
しかも開発者ひとりひとりの手間を極力省くことができる、環境なのです!!(のはず)


では作り方。
ちなみに、この作業はアーキテクトだけが行う初期作業です。

 1.Eclipse
  特に特別な手順はありません。

 2.Maven2
  ①pom.xmlを書きます。
   maven-eclipse-pluginの設定で、downloadSourcesとdownloadJavadocsをtrueにしておきます。

  ②Eclipseのプロジェクト作成ウィザードを使うのが面倒なので、
   初回だけ「mvn eclipse:eclipse」でEclipseプロジェクトを作成し、Eclipseにインポートします。
   この時点では、クラスパス変数M2_REPOが未定義なので、ビルドエラーになります

  ③プロジェクトのプロパティ、Javaビルドパスから「M2_REPO/~」を
   全て削除します。当然、ビルドエラーになりますが、ここでは無視します。

 3.m2eclipseプラグイン
  ①m2eclipseをインストール。

  ②Eclipseの設定のMaven2で、ソースのダウンロードと、JavaDocのダウンロード
   を有効(チェックON)
にしておきます。

  ③プロジェクトを右クリック→Maven2 で、Maven2特性を有効にします。
   Maven2 Dependenciesと言うクラスパスコンテナが作成されます。
   この時点でビルドが通るはずです。

   これ以降は、pom.xmlを修正すればライブラリのダウンロード~ビルドパス設定が
   自動的に行われます。
   mvn eclipse:eclipse でビルドパスを更新する必要はありません

 4.Tomcatプラグイン
  ①Tomcatプラグインをインストールし、基本設定。
   
  ②dragon3さんが公開している改変版DevLoaderを入手し、
   Tomcatにセットアップ。

   TomcatプラグインにバンドルされているオリジナルのDevLoaderを使うと、
   pom.xmlにservlet-api-xxx.jarへの依存性が含まれていると実行時にClassCastExceptionが発生
します。
   逆に言えば、Servlet API を使わなければ、オリジナルのDevLoaderでも構いませんが、
   Servlet APIを使わないということは少ないのかなと思います。

  ③プロジェクトのプロパティ、Tomcatで以下の通り設定。
   ・Tomcatプロジェクト・・・ON。
   ・コンテキスト名・・・任意の名前を入力。
   ・コンテキスト定義の更新を可能にする・・・ON。
   ・このコンテキストを再読込可能にする・・・OFF
    (ONにすると、ソースを修正するたびにコンテキストが再起動してしまいます)
   ・Webアプリケーション・ルートとするサブディレクトリ・・・main/src/webapp
   ・開発用クラスローダを有効にする・・・ON
    /PROJECT_NAME/target/classes
    org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER をチェックON。
    (個々のライブラリをチェックONにしてしまうと、.tomcatpluginに絶対パスが書かれてしまい、再配布できません)

 5.Seasar2
  env.txt で、開発時はHOT Deployが有効になるようにしておきます。
  こうすることで、コンテキストを再起動することなく、修正したソースをTomcatに即反映できます。

 6.配布
  pom.xml.classpath.project.tomcatplugin を含めて、プロジェクトを配布(CVSやSVNにコミット)します。
  (通常はpom.xmlだけで、.classpath等は含めないことが多いと思いますが)

  なお、これらのファイルに特定の環境に依存する値(絶対パスなど)が書かれていないのが、再配布可能にするミソです。

  各開発者は、配布されたプロジェクトをEclipseにインポートするだけで、
  特別な設定をしなくても開発できる
はずです。


以上で、快適な開発環境ができる...と思います。

一応、ざっくりと動作確認していますが、うまくいかなかった場合はご容赦をm(_ _)m


テーマ:プログラミング - ジャンル:コンピュータ

  1. 2007/10/16(火) 00:18:07|
  2. ソフトウェア開発 Java
  3. | トラックバック:1
  4. | コメント:0

(続)Maven2のブラックリストに載ってしまったリポジトリを復活させるには

以前の記事「Maven2のブラックリストに載ってしまったリポジトリを復活させるには」で、
Maven2のブラックリストについて書きましたが、その後、色々とわかりました。

1.ブラックリストは、アーティファクト単位に管理される
 当初、ブラックリストはリポジトリ単位で管理されている...例えば、
  ・centralリポジトリ はOK
  ・mirrorリポジトリ はブラックリスト(注:mirrorリポジトリと言うのは単なる例で実在しません)
 のように...と思っていたのですが、そうではなく、
 アーティファクト単位で管理されているようです。

 つまり、
  ・アーティファクトmaven-surefire-pluginは、centralリポジトリからダウンロードOK
  ・アーティファクトmaven-surefire-pluginは、mirrorリポジトリからダウンロードNG(ブラックリスト)
 のような感じになっているようです。

2.ブラックリストに載るのはプラグインだけ
 ブラックリストが管理されるアーティファクトは、プラグインだけで、
 一般のライブラリは関係ない
ようです。

 つまり、例えばリポジトリのダウンやネットワーク障害でアーティファクトの
 ダウンロードに失敗した場合...
  ・プラグイン
   ブラックリストに載る
   リポジトリやネットワークが復旧しても、ブラックリストをクリア(後述)しない限り
   ダウンロードされない

  ・ライブラリ
   ブラックリストに載らない
   リポジトリやネットワークが復旧すれば、自動的にダウンロードされる。
 と言うことになります。

3.ブラックリストの実体
 ブラックリストの実体は、ブラックリスト用のファイルが存在するのではなく、
 ローカルリポジトリのプラグインディレクトリの中にある「maven-metadata-リポジトリID.xml」
 と言うファイル
で、その内容によってブラックリストか否かを判断するようです。

 たとえば、M2_REPO/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata-central.xml を見ると...

 ・通常(ダウンロード成功)時
  ----------------------------------
  <?xml version="1.0" encoding="UTF-8"?>
  <metadata>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-plugin</artifactId>
   <version>2.1.3</version>
   <versioning>
    <latest>2.3</latest>
    <release>2.3</release>
    <versions>
     <version>2.0-beta-1</version>
        :
     <version>2.3</version>
    </versions>
    <lastUpdated>20070301014816</lastUpdated>
   </versioning>
  </metadata>
  ----------------------------------


 ・ブラックリスト時
  ----------------------------------
  <?xml version="1.0" encoding="UTF-8"?>
  <metadata>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-plugin</artifactId>
  </metadata>
  ----------------------------------

 のような違いがあります。

4.ブラックリストのクリア
 上述のように、ブラックリストの実体は「maven-metadata-リポジトリID.xml」なので、
 ブラックリストをクリアするには、このファイルをバサッと消してやれば良いです。

 問題は、ローカルリポジトリ内にたくさんある同ファイルの、どれを削除すれば良いか?です。
 いちいちファイルを開いて中身を確認していられません。

 これに対する鍵は、Maven実行時のログです。
 ブラックリスト化されたプラグインが原因でMavenの実行に失敗すれば、

  [INFO] Repository 'central' will be blacklisted
  [INFO] ------------------------------------------------------------------------
  [ERROR] BUILD ERROR
  [INFO] ------------------------------------------------------------------------
  [INFO] The plugin 'org.apache.maven.plugins:maven-surefire-plugin' does not exist or no valid version could be found

 のようなログが出力されるはずなので、この表示を手掛かりにブラックリスト化されている
 プラグインを特定し、ローカルリポジトリの下を探せば良いわけです。


と、こんなところです。
いまいち、なぜこのような仕組みが導入されたのか良くわかりませんが...

テーマ:プログラミング - ジャンル:コンピュータ

  1. 2007/10/11(木) 23:11:08|
  2. ソフトウェア開発 Maven
  3. | トラックバック:0
  4. | コメント:0

宇宙旅行に行きたいなぁ

TVでやってましたが、2015年には宇宙旅行が500万円くらいになる(のではないかと予測されている)らしいです。

500万なら、がんばれば手が届きそうな金額です。
もちろん、庶民には簡単に出せる金額ではないですが、
人間として生まれたなら、一度は宇宙を見てみたいなぁとか思いました。


小学生の頃。。。
秋山さんと言うTBSのジャーナリスト(?)が、日本人として初めて宇宙に飛び立ち、
特番が連日放送されていました。

 # 一般的には、毛利さんが日本人初の"宇宙飛行士"として有名ですが、
 # 初めて宇宙に出た日本人は、秋山さんなのです。

その番組が大好きで、必死になって観ていたのを懐かしく思い出します。
宇宙飛行士と言えば、男の子であれば誰しも一度はあこがれますが。。。
僕は、当時から近眼だったので「近眼じゃ無理だな」と思ったりしてました。


2015年だと、僕はもう40才近いですが、もしも可能なら宇宙旅行、行きたいですね。
(たぶん、99.9%行かないと思いますが)


ちなみに、現在でも30億程出せば行けるそうです。
(宇宙遊泳オプションは13億円だそうな)

5分間の無重力体験ツアーなら、2500万程度で行けるとか。


  1. 2007/10/08(月) 01:57:07|
  2. 日記
  3. | トラックバック:0
  4. | コメント:4

プロフィール

Author:crossroad
関西在住。男。
フリーランスのソフトウェアエンジニア。
エレキベース(Rock&Roll)とお酒が好物でございます。

カテゴリー

タグリスト

Java F1 フリーランス ベーシスト HARRY TheStreetSliders iPhone FX お酒 Seasar Maven eclipse Wicket マイホーム 野球 プロジェクトファシリテーション Rails Ruby UML お店 ソフトウェア Tomcat S2Flex2 jsf Teeda Eclipse タグライブラリ ajax タスク europa mylyn trac 

ブログ内検索

最近の記事

最近のコメント

最近のトラックバック

カレンダー

09 | 2007/10 | 11
- 1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31 - - -

月別アーカイブ

全ての記事を表示する

全ての記事を表示する

Twitter


RSSフィード

リンク

このブログをリンクに追加する

アクセスカウンタ

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。