反面教師から始めよう
昨日からIβMで研修を受けていまして。その中で思ったことをメモ。
私は基本的にIT系の研修って大して価値はないと思っています。｢習うより慣れよ｣の世界だし、研修ではノウハウまで教えてくれないからです。知識の整理レベル以上は期待したことが無い。私が新人の頃に受けたプログラミングの研修も、それはそれはﾌｫ――(▼∀▼)――ｯ!!!
閑話休題。
プログラミングの研修ではほとんど文法の話が多いです。確かにイディオムがわからないとプログラミングは出来ませんが、問題はそこから先にあると思います。コンストラクタのオーバーロードを知ったからといって、良いコードがかける理由はどこにもありません。
プログラミングの研修で一番叩き込んでおかないといけないのは、｢アンチパターン｣ではないでしょうか？プログラミングだけじゃなくインフラでも何でも一緒だと思います。｢XXということはやってはいけないよ。｣という悪い事例をまず叩き込む。
かくあるべきみたいな話よりも、まずは反面教師の提示をする。反面教師を提示することで、本来プログラムを書くことで達成したいソフトウェア要件を、より高いレベルの解決法で実施する心構えを持たせる。ファウラー氏の言葉を借りれば、｢技術的負債｣にまず目を向けさせる。そうけしかけないと、技術力は決してあがらない。
実現したいことは１つだとしても、解決方法はピンキリなのがシステムというものです。なぜこの解決策ではマズいのかを考えさせるような研修カリキュラムにしないとなぁ。IβMも弊社の研修も。
Hibernateを使ってみた
正直、コレ敷居高いんじゃね？
ここ2日間ほどHibernateしてみた率直な感想です。
以下ポイントや感じたことをメモ。
①. 設定ファイル群の読みこなしが大変
設定ファイルが何を表しているか読まないとhqlをうまく書くことが出来なかったし、設定されているプロパティのせいで意図したとおりの結果が返ってこなかったりした。
②ファイルのメンテが大変
カラムの増減、テーブルの変更などに伴ってHibernateで使うエンティティとマッピングで使うXMLの更新をしなくてはならないことに気が付いてしまった。Middlegen + Antで自動生成はできるんですが、上書きして欲しくないファイルまで上書きしちゃったりするし。
｢現場で使えるHibernate」 が大変参考なりました。
③ SQL何発投げてんの？？
Hibernateでshow_sqlというプロパティがある。それをtrueにすると投げられているSQLが吐き出されるんだけど、よくみると3発SQL投げていたりする。結局SQLにもHibernateにもわかってないと、安心して使えない気がしてならなかった。
④ 実はJOINが楽
テーブルのJOIN構造もマッピングしてくれていて、しかもそれがBeanとして取れるのが非常にいい。
例えばAテーブルのカラム４つと、Aと1対多の関係にあるBテーブルのカラム３つを画面に返す場合、SQLだと結構処理が煩雑になる。HibernateだとBeanUtilsを使ってサクッとDTOにプロパティをセットできるのがいい。
つまり、
while(iterator.hasNext()) {
Order oder = (Order)itertator.next();
DTO dto = new DTO();
BeanUtils.copyProperties(dto.order);
BeanUtils.copyProperties(dto.order,getCustomer());
}
って感じ。入ってるプロパティにのみ値が入る。
また、hqlでselectするカラムを指定するとListの中身がObject[]になってしまった。こうなるとBeanのコピーができないのでO/Rマッピングの意味が無いと感じた。
⑤ SQLレスって楽。間違いなく。
SELECT時に特定のカラムを指定しなくてよいのは非常に楽。JOINもWhere句だけでいいし。全部オブジェクトとして表現されるため、ちょいちょいとBeanUtilsを使えばすっげぇ楽にINSERTやUPDATEが可能。
ActionFormとエンティティをBeanUtilsでコピーしてsession#saveorupdateで実装完了。5分で実装できる。
あとDB側の関数は使えるのか気になる。(current timestampとかrow_over()とか)
安心して使うためには勉強がいるけど、使いこなせるようになれば相当便利です。間違いない。
それでもお前はプロなのか
トラブル案件に突っ込まれてる同僚と話をする機会がありました。その中で相当ひどい設計に基づいたコードが書いてあったようです。
トランザクションが開始された後にエラーがあった場合、なんとその後続のトランザクションを実行してしまい、尚且つ後続のトランザクションが正常に成功した場合は、そのトランザクションは正しく実行されると見做す設計らしいのです。
これを聴いた瞬間は「いくらなんでもそれは無いだろう」と思いました。ロールバックが考慮されていないシステムなんてあり得ないよねって。ネタでしょみたいな。でも、やっぱりガチらしいんです。そういうコードが散在してるため、おっそろしい勢いで障害出ている、と。
そしてすぐに、猛烈な殺意がこみ上げてきました。木刀で頭カチ割るぞぐらいの勢いで。システムを作るということをナメてますよ。プロ意識のカケラもありません。怒りを通り越して悲しくなりますね。
こういった愚かな設計によってシステムが構造的な欠陥を抱えてしまうその恐ろしさが、なぜわからないのか。
その欠陥によって実装されるコードの品質により、どれだけの人間が苦しみ、どれだけの人間がこの業界に疲弊して消えて行き、会社にどれだけの赤字がでると思っているのか。
ひとつの愚かなソースコードによって、億単位の赤字に直結するという意識を何故もてないのか。
このブログを読んでくださっているSE志望の学生さんや、新人SEの方。プログラミングには苦しいことも過多あります。だけど全ての基本はプログラミングです。技術力をつけろという真意は、システム上に構造的な欠陥を作り出すんじゃないぞという意味です。是非覚えて置いてください。
位がヒトを作る
｢努力すればスキルが向上して上に昇れる」というのは幻想 より。
こちらのブログを書かれている方は恐らく左上の方だと思います。中二病と謙遜されてますが、論旨の質は高いです。勉強になります。ただ文章から出るオーラが私とは全く合い知れないものなので、読むのに気合が要ります。
ポジションが人を育てるというのは私も同感だし、紛うこと無き真実だと思います。下記引用。
[引用]
------
現実には、平社員としての基本スキルがある程度身についたら、地道な努力なんかしてる場合じゃなくって、さっさと自分のなりたいポジションを強奪する狡猾な作戦をたてて、実行しなきゃならない。
戦国大名のように、確信犯的に、計画的に、プロジェクトの乗っ取りをがんがんしかけて行くべきなんですよ。泥仕事を地道にやっていれば、おいしい仕事が回ってくるなんてウソは、絶対に信じちゃいけません。
------
[/引用]
平屋しか立てることが出来ない人間には、高層ビルの建築がまわってくるはずがありません。｢低いポジションで求められる地道なスキルアップ」がランクアップにつながるワケがないんですね。これはスキルとレベルを混同していることが原因です。
｢自分がどんなスキルをつけたいか」ではなく、｢なりたいポジションにつくにはどうするか？｣という姿勢で仕事しないとレベルが上がらない。私はちょうど１年ぐらい前の夏にそれに気が付くことが出来ました。情報収集の賜物です。ブロガーやっててよかったなぁと思える瞬間でもありました。
追うべきはスキルじゃなくてレベルであって、スキルはレベルに付随して付いてくるものです。
スキルとレベルについては別エントリで詳しく書こうかなと思っています。
Calendarインスタンスの取得コストはDateの10倍高いらしい
izu＠SanFranciscoの下記エントリより。
Calendarオブジェクトを100000個作るよりも、Dataオブジェクトを100000個作る方が10倍から30倍は早かった。
これを解決するライブラリがあるよってのが上記エントリの趣旨です。
でもって、実際のソースの流れはこうなっているらしい。
出典元：The cost of Calendar object creation
-------------------
◆Calendar c = Calendar.getInstance();
* createCalendar(TimeZone.getDefault(), Locale.getDefault());
* new GregorianCalendar(zone, aLocale)
* super(zone, aLocale);
* setTimeInMillis(System.currentTimeMillis());
* computeFields();
* computeFieldsImpl()
* timeToFields
* internalSet x 6
* internalSet x 8
◆Date d = new Date();
* this(System.currentTimeMillis());
* long fastTime = date;
-------------------
どう見ても高コストです。本当にありがとうございました。
Ant！Ant！Ant！
今回の案件ではAntを使ってWebSphere用のEARを生成することが推奨されているため、今更ながらApache Ant を使って様々なタスクを書いています。Antのあまりに広大な守備範囲の広さに、最近驚かされてばっかりです。様々なタスクを連続して行うことができるので、組み合わせは自由自在であります。正直、不勉強だった。心より恥じる。
とりあえず今使っている段階で、｢Antのココがナイス！｣っていう点をメモ。
① やっぱりコンパイルするのが便利
ファイルセットの指定が楽なのが相当アツい。｢**/*.jar｣って感じであるディレクトリの下のJarファイルを再帰的にクラスパスを通してくれる。１年半前PMにEclipseに依存しないようにコンパイルバッチ作れとか言われて、バッチで-classpath与えていたのがバカらしい。今思うとAnt入れちまえばよかった。
② 設定ファイルのバリデーション
XMLの設定ファイル群がちゃんと正しいXMLであるかどうかのバリデーションをビルド時にかけてくれます。xmlValidateというオプションタスクがあって、DTDに即しているかとかのチェックをやってくれます。Java開発ではXMLは切っても切れない昨今なので、こいつは重宝します。
③ CVSとの連携
CVSと組み合わせることでCVSからチェックアウトしたらビルドして、誰のソースがやらかしたかってことが視覚化できます。Antでビルドできなかったら負けだという状況を作ることができます。VSSじゃビルドはできないからなぁ。
④ checkstyle→Javadocの生成
checkstyleのバリデーションを実行してエラーがない状態で今回のアプリ固有のAPIドキュメントを作成することができます。これも品質向上に一役買っているナイスガイだと思っています。
個人的に面白いと思うのがconfig系のXMLにXSLTかけてHTMLにしちゃって設計書的に使うとか。ひがさんがS2のapp.diconにXSLTかましてHTMLに変換すればそれで内部設計書になるんじゃないか、という旨の発言をブログでされていたのがヒント。
まぁ今の時代ならAntでなくMaven勉強しなさいという話でもあるんですが、もうちょいAnｔと戯れることにします。
マスメディアよりブログメディア
最近良く思うのがマスメディアの情報の質と、ブログなどによる個人ベースの情報の質がえらく違うことです。マスメディアの情報の質が非常に低いと感じることが多いのです。
たとえばあるニュースが報道されます。殆どのマスコミは、｢ニュースのエポックメイキングな断面だけに焦点を当てて、そこに虫眼鏡を当てて、あたかもそれが全てであるように」報道します。つまり良いニュースは良い所だけが、悪いニュースは悪いニュースだけが際立つという特性があります。
ライブドア問題にしても、問題にすべきは粉飾決算を横行した経営幹部の企業倫理だけでよいはずです。それなのにライブドアの全てが悪であるような報道を行うことは相当に間違ってるし、そういった捏造じみたニュースに気がついているヒトもたくさ～んいると思います。
ブログという誰でも簡単にネット上で情報配信できるWEBフレームワークが、個人メディアの力を益々強くしています。IT系の技術情報は事欠かないし、テレビの低レベルで偏った報道に比べると、情報の深さと確かな解釈があります。ニュースを鵜呑みにせず、個々人のナレッジというフィルターを通して得られる情報の確かなクオリティ。そこに素晴しい価値がある、そう思います。
このブログも８割がた自分の為に書いているブログですが、２割ぐらいは他人様のお役に立てればいいなと思っています。
社員1.0と社員2.0
SunMicroSystemsの方のブログ にこんなものが。
相当インスパイアされた。これおもしれぇ。自社製品への傾倒ぶりが多少気になるがサイコ－。
実際弊社でRSS100本以上登録してちょっとでもShain2.0になろうとしている方はどれぐらいいるのか激しく気になる。｢ブログって何？｣と言っている同期もいるんだよね。痛い、痛すぎる…。とりあえず、Jyoshi1.0とJyoshi2.0で脳内ブレストしてみることにします。SI1.0とSI2.0でも相当面白いな。できたらUPします。
４つのコミュニケーションスタイル
ここ最近コミュニケーションスキル関連の研修を２本受けてきました。正直研修にはあまりよいイメージは無かったんですが、業務を離れてコミュニケーションスキルを考える機会に恵まれてよかったです。講師の方のレベルも相当高かった。
人材育成関連、モチベーション関連の事業をされている会社で必ず出てくるのが｢DISC Model｣という概念です。DISCとは、以下の行動特性の頭文字を取ったもので、それにあわせてある人間のパーソナリティ及びコミュニケーションスタイルを４つの軸で分類するというモデルです。
D - Describes how a person will respond and react to problems.
I - Explains how a person will interact with people.
S - Indicates a person's preferred work pace.
C - Shows how a person will comply with work rules and procedures.
これらの行動特性をある４つの軸で分類していくんです。この軸は言葉は違えど概念は同じコトを言っていることが多いです。恐らく人材をビジネスにしている会社さんのバイブル的モデルなんでしょう。
実際に英語サイトを探したんですが、タダでDISCモデルに即したセルフチェックを行えるサイトはありませんでした。しかし、灯台下暗し。日本語のサイトで無料チェックができるサイトがありましたのでご紹介。
# 無料版のため分析レポートが結構はしょり気味なのが残念。
◆Type分け for Coaching
http://www.test.ne.jp/inventory/type_exp.html
ここでは、「コントローラー・タイプ」、｢プロモーター・タイプ」、「アナライザー・タイプ」、「サポーター・タイプ」とあります。非常に相性の悪い組み合わせだけ補足しておきます。
｢コントローラー･タイプ｣⇔｢サポーター･タイプ｣
｢プロモーター・タイプ」⇔「アナライザー・タイプ」
この組み合わせです。
評価軸や行動特性が逆のため、非常にお互いの欠点が際立って見えてしまうコミュニケーションの罠に陥る可能性があると研修の先生に教えて頂きました。特に上司とこの関係だったら相当きつい気がします。が、これほど味方につけると強い相手もいません。補完関係が成り立ちますからね。
自分と相手がどう違うのかをDiscにより体系立てて知ることで、自分がどういったコミュニケーションスタイルを取っていけばよいか、目星をつけることができる。
このことを知りえただけでも実りあるモデルだなと思います。
プロマネに必要な三要素
｢プロマネの鍵、貸します」 からTB。非常に興味深いエントリだったので是非みなさんもご一読を。
上記エントリの中で｢プロマネに必要な三要素｣について触れてあります。プロマネに必要な三要素は、
◆経験から得たリスク感覚
◆固有技術への理解
◆管理技術
であると述べられています。私も全く同感です。
そして、これらの要素は１つでもある一定の基準を下回ったらダメです。リスク感覚は優れているが固有技術の見解はゼロだ、なんてPMはいません。技術は非常に強いが要員管理ができないのもダメ。全てが密接にかかわりあって三角形を作るから意味があるスキルモデルです。
リスク感覚をつけるには目線の位置を上にすること以外ないと思います。自分がPMだったら、自分がリーダーだったら、とシミュレーションして仮説立てて起こった結果と照らし合わせてノウハウを作っていく。このサイクルの速さがリスク感覚のセンスだろうなぁ。
固有技術を理解するには、何でもいいからある１つの技術を深く学ぶことが重要だなと思います。重要なのはある程度深く学ぶことです。浅く広くも重要ですが、IT技術はある程度のラインを超えるまでは色々な技術に手を出すべきではないと思う。中途半端で結局何もわからないひとになってしまいそう。
IT技術はある程度の深さまでモノにできれば、新たな技術を取得するセンスが身につきます。大事なことは技術の入り口が変わっても不変だということです。
管理技術もかなり大事だと思う。ガントチャート眺めたところで、それが本当にタスク完了になっているかの保証には全くならない。今までのやり方を単純に踏襲して失敗する案件も多いし。スケジュール観狂ってるプロジェクト多い気がするなぁ。
管理すると言うことは、｢自分以外の他者の仕事内容・成果物を正確に把握すること｣に他ならないと思っています。可視化する技術が管理技術だと思います。
昔の現場で｢それは○○チームがやってくれているはずです。信じましょう！｣とのたまった方がいました。私が｢信じてモノが出来ていなかったら責任とるのあなたですけど、いいんですか？｣とカウンター食らわせたら逆キレされた。おいおい、オレ委任契約だし。キレられても困るんだけどみたいな。今、その現場億単位で赤字出してるそうだ…。想定の範囲内だが、ご愁傷様です。
こう書いてみると、プロマネってほんとスーパーマンに見えてきた。敷居高いわコレ。多分ほんとに｢プロだな！｣ってPMは一握りなんだろうな。