asatoの技術的な日常日記

「成長に最大の責任をもつ者は、本人であって組織ではない。自らと組織を成長させるためには何に集中すべきかを、自らに問わなければならない」  非営利組織の経営 - ピーター・ドラッカー

スポンサーサイト

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

Implementation Patterns/Java Persistence With Hibernate

amazon うろうろしてたら、チェックし忘れの本発見。
Implementation Patterns, by Kent Beck

Java Persistence With Hibernate, by Christian Bauer, Gavin King
スポンサーサイト

More Trouble with Programming - The second part of our interview with Bjarne Stroustrup, the inventor of C++.


 More Trouble with Programming - The second part of our interview with Bjarne Stroustrup, the inventor of C++

うーん、後で読もう。



Commercial Users of Functional Programming (CUFP)

 Commercial Users of Functional Programming (CUFP 2006)

最近、関数型な言語が流行ってるっぽいので気になるワークショップですな。スライドとかぱっとみたところ、あんまし、アピールしてるような感じじゃないっぽいきがした。

とりあえず、機会があれば、それなりのアプリケーション 作ってみて Haskell とか使ってみるかって感じ。

POPL 2006 の invited talks の「The Next Mainstream Programming Language: A Game Developer's Perspective」で Haskell がいいぜ(?)、かどうかしらないけど、ちょっと参照して書かれてたのが気になってる。

あと、GPCE 2006 の「Software Extension and Integration with Type Classes」でも Haskell いいよ、みたいなのがあったので気になる。

Eclipse Mylar 1.0 released

うーむ、Mylar のバージョン1.0がリリースされたみたいだぜ。

 Eclipse Mylar 1.0 released, to make work with large projects easier

Mylar のページによると Mylar とは:
Mylar is a task-focused UI for Eclipse that reduces information overload and makes multi-tasking easy.

むかしちょっと使ったときは、あんまし利点を感じられなかったけど、パワーアップしてるのかな。試してみよう。

リーダーシップ

 セルゲームに学ぶ「再チャレンジ支援税制」
 http://blog.livedoor.jp/insidears/archives/50972634.html

特に、「第5弾 戸愚呂面接官に学ぶ中途採用基準」が、色んな意味で笑えない。心臓が冷たく凍えるぐらいだぜ。ただでさえ、面接とかクソくらえなのに、博士進学で就職がやばい僕にとっては。


この中で戸愚呂面接官が言ってるせりふがある。

 「リーダーシップを発揮した体験をお聞かせください」

リーダーシップとは何か?

ドラッカーの「プロフェッショナルの条件:4章 仕事としてのリーダーシップ」に載ってるリーダーシップ論を紐解いてみよう。

まず、カリスマ性とかは必要ないらしい。カリスマ性を持っているかどうかは、リーダー的資質とは関係ないらしい。

そもそもリーダーシップそれ自体が、よいものでも、望ましいものでもない。それは手段である。何のためのリーダーシップかが問題である

とある。

ドラッカーは、カリスマ的なリーダーとして、スターリンヒトラー毛沢東 の三人を例に挙げている。ドラッカーの言葉で言えば彼らは「市場かつてない悪行と苦痛を人類にもたらした似非リーダー」である。

また、リーダーシップはカリスマ性に依存しないとして、そのようなカリスマ性をもっていないが、強力なリーダーだったものとして、ドワイト・アイゼンハワージョージ・マーシャルハリー・トルーマン の三名を挙げている。

では、逆に、リーダー的資質、リーダー的特性というものは存在するのか? ドラッカーによればノーらしい。6人ほどの傑出したリーダーを例としてあげ、彼らのうちの誰も、資質や特性が同じ者はいなかったとしている。


では、カリスマ性でも資質でもないとすると、リーダーとは何か。ドラッカーはリーダーであることのいくつかの要件をあげている。

第一の要件:リーダーシップを仕事としてみることである。

 効果的なリーダーシップの基礎とは、組織の使命を考え抜き、それを目に見える形で明確に定義し、確立することである。リーダーとは、目標を定め、優先順位を決め、基準を定め、それを維持するものである。もちろん妥協することもある。



 リーダーは、妥協を受け入れる前に、何が正しく、望ましいかを考え抜く。リーダーの仕事は、明快な音を出すトランペットになることである。


第二の要件:リーダーシップを、地位や特権ではなく責任と見ることである。

優れたリーダーは、常に厳しい。ことがうまくいかないとき、そして何ごともだいたいにおいてうまくいかないものだが、その失敗を人のせいにしない。


真のリーダーは、人間のエネルギーとビジョンを創造することこそが、自らの役割であること知っている。

第三の要件:信頼が得られることである。

信頼が得られないかぎり、従う者はいない。そもそもリーダーに関する唯一の定義は、つき従うものがいるということである。



以上を基に、戸愚呂面接官にどう立ち向かえばいいのか。

僕は思うに、普通に、この要件を満足してる人 or リーダーの要件とは何か、について認識している人ってほとんどいないんじゃないの? ってことだぜ・・・

Large Refactorings


Martin Lippert and Stephen Roock

Refactoring in Large Software Projects

John Wiley & Sons Inc (2006/5/28)

より、ラージリファクタリング(Large Refactoring)について。


ファウラーのコードレベルの ベーシックリファクタリング(Basic Refactoring)ではなく、アーキテクチャレベルのリファクタリングのことを、ラージ(大規模)リファクタリングと呼ばれてるっぽい。

ラージリファクタリング必要となる理由はなにか? この本では、いくつかあげられている(以下は個人的解釈であって厳密な翻訳ではない)。

  • 小さなリファクタリングのサボり:小さなリファクタリングによってデザインを継続的に改善してない。そのため、デザイン上の小さな欠点が積もり積もって、大規模な再構成が必要となってしまう。

  • アーキテクチャの不吉な匂い(architecture smells)の出現:アーキテクチャの不吉な匂いが徐々に現れる。アーキテクチャの不吉な匂とは、アーキテクチャレベルでの問題を示す匂い。アーキテクチャの不吉な匂いに対処しようとすると、小さな基本的にはリファクタリングがサポートするスコープを超える。

  • 要求変化:新しい機能(フィーチャ)の追加や要求の変化が、ラージリファクタリングを要求する。機能追加のいくつかは、簡単に追加できたり、簡単なリファクタリングにより追加できるが、場合によっては、大きな再構成が必要。


ラージリファクタリングの正確な定義は難しいらしいけど、この本では、次のような特徴を持つのがラージリファクタリングだといっている。

  • 期間:ラージリファクタリングは、一日以上に及ぶ。
  • チーム:ラージリファクタリングは、チーム全体に影響する。
  • 安全性(Unsafety):安全なベーシックリファクタリングで完全には置き換えられない。追加的な危険な安全でない修正が必要。


この特徴だと、ベーシックリファクタリングとラージリファクタリングのの正確な区別は難しい、と書かれてるけど、色々理由も書いてる。たとえば、メソッド名の変更は、大きなプロジェクトだと、一日以上かかるかもしれないし、チーム全体に影響するかもしれない。けど、単に「メソッドの変更」のリファクタリングにより実現できる。もし、開発環境がこのリファクタリングをサポートしてるのなら、数分で実現可能。


ラージリファクタリングは、普段の小さな基本的なリファクタリングを継続的にやることで解決できるか? この本によるとそうもいかないらしい。

一つは、要求に関する理由のため。新しい要求によっては、現在の構造では対処できないかもしれない。

さらには、アプリケーション領域をうまく理解できていなかったがゆえに、デザインを大幅に変える必要があるかもしれない。

tokuda さんも書いているように、デザインは、人間的な側面の理由が元で変化する。

  • 経験:経験ある従業員は、彼らのドメイン知識をベースにして、より良いデザインを作る可能性がある。
  • 新しい展望:新しいプロジェクトメンバーは、あるデザインがどう構成されるのかついて異なるアイデアを持っていることがよくある。
  • 実験:適切なデザインに達するには、異なるデザインパスを探索することが要求されるかもしれない。


そのため、ラージリファクタリングを避けることは困難、と本では言っている(本ではもうちょっと詳しく説明されているので参照)。

さらには、アーキテクチャの違反が簡単に起こってしまうことも関係する。


以下は上の本の話を基に感想。

結局のところ、システムの再構築、つまり、デザイン構造の変化が避けられない、あるいは、健全に保つのが難しいのは、二つがあるきがする。あるいは、この問題を考えるに当たって、前提としなければならないのは、以下のことだと思う。

  1. 要求変化の不可避:要求変化は避けられない。要求は変化する。

  2. 完全なデザインは実現困難:

    1. 困難なのは、一つは、要求が変化し、そのの変化は完全には予測できないため。したがって、今ある要求 に対しては、良いデザインを生み出すことはできたとしても、要求変化によって、良いデザインの 向きが変わる

    2. もう一つは、そもそも今ある要求に対してさえ、良いデザインを生み出すのは困難。これは、アプリケーションドメインの理解不足に伴う理由などによる。



これに関係する話は、じゃあ、モジュール化の技術やテクニックは、この文脈でどんな役割を担っているのか、ということ。

新しいモジュール化の技術(たとえばアスペクト指向プログラミング)の基では、従来の良いデザイン(たとえばデザインパターン)は、必ずしもよいデザイン or 局所的に最適なデザインとは限らなくなる。むしろ、コードの不吉な匂いとして捉えることができるかもしれない。実際、オブジェクト指向によるデザインパターンの実装を、アスペクト指向や他のモジュール化技術が提供する言語機構を用いてで書き直す(リファクタリング)ということが行われている。

つまるところ、現在のモジュール化技術は、不十分だともいえる。では、全体的に、モジュール化技術の進歩は、何を意味しているのか。

モジュール化の技術の進歩によって、ラージリファクタリングが必要な場合は減少するのか。

ラージリファクタリングは、アーキテクチャレベルでの問題をなんとかするためのテクニック。言語として、アーキテクチャレベルの抽象化の方法を提供する言語もある。たとえば、ArchJava など。このような言語を使えば、ラージリファクタリングが必要なケースは、少なくなって、ベーシックなリファクタリングを継続的に繰り返すだけでシステムを進化させていけるのか。

1st Workshop on Assessment of Contemporary Modularization Techniques (ACoM.07)

ワークショップ。

 1st Workshop on Assessment of Contemporary Modularization Techniques (ACoM.07)
 http://www.comp.lancs.ac.uk/computing/ACoM.07/index.htm

引用。太字は僕。

A number of new modularization techniques are emerging to cope with the challenges of contemporary software engineering, such as aspect-oriented software development, feature-oriented programming, object-oriented design patterns, and the like. The effective assessment of such emerging modularization technologies plays a pivotal role on:

-A better understanding of their real benefits and drawbacks when compared to conventional development techniques

-Their effective transfer to mainstream software development

However, there is no standard approach or even any 'rules of thumb' for assessing such new software development approaches. This means that the evaluation of a technique is relatively arbitrarily chosen and made in an idiosyncratic manner.

The 1st Workshop on Assessment of Contemporary Modularization Techniques (ACoM.07) is the first initiative to put together researchers and practitioners with different backgrounds in order to discuss the multi-faceted issues that emerge in the assessment and/or comparison of new modularization techniques.


僕の答えは、ベンチマーキング を行うこと。

実際、二年くらいこの目標に向けて研究してたし。下のはほとんど書きかけに等しい、論文とは呼べない代物だけど、ヒントにはなるはず!

 http://www.ncfreak.com/asato/bench-final.pdf
 http://www.ncfreak.com/asato/survey.pdf


原則の種類

ドラッカーの「明日を支配するもの」では、組織が守るべき原則として5つがあげられている。

  • 組織は透明でなければならない
  • 組織には最終的な決定権をもつ者がいなければならない
  • 権限には責任が伴わなければならない
  • 誰にとっても上司は一人でなければならない
  • 階層の数は少なくしなければならない

ドラッカーによれば、これらの原則は、何をなすべきか については教えなくて、何をなすべきでないか を教えるだけとのこと。つまり、うまくいきそうにもないことを教えるだけらしい。例えるなら、建築家にとっての建築基準とのこと。どんな建物を建てるべきかは教えない。教えるのは、制約条件だけである、とのこと。

「原則」についてあまり考えたことがなかったけど、原則の種類ってあるんだろうか。上の組織の原則は「何をなすべきでないか」あるいは「制約条件」についての原則。

Bertrand Meyer の「Object-Oriented Software Construction」では、ソフトウェア構築における5つの原理・原則が述べられている。

  • The Linguistic Modular Units principle
  • The Self-Documentation principle
  • The Uniform Access principle
  • The Open-Closed principle
  • The Single Chhoice principle


石井さんがまとめられた「オブジェクト指向の法則集」も参照。


ここまで調べて力尽きたのでまた今度。






Design Theory and Computer Science/Expertise in Design


Concerned about separation

Hafedh Mili, Houari Sahraoui, Hakim Lounis, Hamid Mcheick, Amel Elkharraz

European Joint Conferences on Theory and Practice of Software, Fundamental Approaches to Software Engineering, (FASE/ETAPS), 2006.

DL: http://www.iro.umontreal.ca/~sahraouh/publications.html

の参考文献に載ってた本(=´ω`)ノ

 Design Theory and Computer Science: Processes and Methodology of Computer Systems Design

ついでに、デザイン関係のシンポジウムも発見。

 Expertise in Design - Design Thinking Research Symposium 6

Groovy RC 1

むむ、Groovy の release candidate がリリースされたみたい。

 Groovy RC 1 released
 http://www.theserverside.com/news/thread.tss?thread_id=43375

メタオブジェクトプロトコルが気になるぜ。

Groovy 最近全然触ってないけど。

問題解決 or 意思決定

問題解決の実学」の「はじめに」の部分より(太線は僕による):
まず序章では、問題解決の考え方を理解します。人間の悪いところは、すぐにテクニックや方程式に走ることです。自分の頭を使わず、「型」に当てはめて物事を解決しようとします。そうではなく、問題決決の考え方とはどういうことかを知り、自分の頭を使うクセをつけることが大事です。

一方、ドラッカーの「経営者の条件」の「6章 意思決定とは何か:意思決定のプロセスはいかにあるべきか」によれば(太線は僕による):
 まず初めに、「これは一般的な問題か例外的な問題か」「何度も起こることか、個別に対処すべき特殊な問題か」を問わなければならない。
 一般的な問題は、常に方針や手続きを通じて解決しなければならない。これに対して、真に例外的な問題は、個別の問題として、個別の状況に従って解決しなければならない。厳密にいえば、あらゆる問題が、二つではなく四つの種類に分類できる。

とある。

四つの種類とは、
-個々の問題それの単なる兆候にすぎないところの、真に一般的な問題

-その組織にとっては特殊な問題でありながら、実際には一般的な問題であるという問題

-真に例外的な問題、特殊な問題

-そのような何か新しい一般的な問題の最初の現れとしての問題。ここで「そのような」とは、実際には真に特殊な問題というのは少ないため、それらしきものにであったとしても、「真に例外的なことか、それとも、まだわからない何か新しいことの最初の現れか」を問わなければならないため、ということから。

さらにドラッカーによれば:

 したがって、真に特殊な一部の問題(第3の問題)を除き、あらゆる問題が、一般的な解決策を必要とする。すなわち、原則、方針、政索による解決を必要とする。一度正しい方針を得るならば、同じ一般的な状況から発する問題は、すべて事務的に処理できる。すなわち、問題の具体的な状況に応じて原則を適用することで処理できる


さらにさらにドラッカーによれば

 成果をあげるエグゼクティブは、原則や方針によって一般的な状況を解決していく。そのため彼は、ほとんどの問題を単なるケースの一つとして、すなわち単なる原則の適用の問題として解決していくことができる
 「法律の多い国は無能な法律家の国である」という古い諺がある。そのような国は、あらゆる問題を法の一般原則のもとにおける個々の問題としてではなく、すべて特殊な問題として解決しようとする。



問題解決の実学」の 序章をまだ読んでない ので、この本における問題が、ドラッカーのいうところの4つの問題のどれのことを言っているのかわからないけど、もし、3つ目の以外の問題も含めて議論しようとしているなら、ドラッカーの議論とはかみ合わないと思う。

問題解決の実学」では、「テクニック」や「方程式」という問題解決の道具について述べていると思うけど、ドラッカーは「原則」「方針」「手続き」「政索」といった観点から、問題解決を述べている。

この点は、単なる言葉の言い換えだとすると、議論として残るのはこの部分:
自分の頭を使わず、「型」に当てはめて物事を解決しようとします。

特に前半部分じゃないかと思う。自分の頭を使って問題が何かを理解して、その後「型」に当てはめて物事を解決しようとするのは、一般的な方法であるはず。そうでないと、「法律の多い国は無能な法律家の国である」の諺になってしまう。


ただ、途中で述べたように、僕は「問題解決の実学」の 序章をまだ読んでない ということに注意。

Concerned about separation (Part 1)

Radium Software Development」みたいに、論文解説とかしてみよう。

ただし、ちゃんと解説するつもりはないので注意。むしろ、書きながらのほうが理解が深まりそうな気がするので、それが目的。

まずは、以下の論文について。


Concerned about separation

Hafedh Mili, Houari Sahraoui, Hakim Lounis, Hamid Mcheick, Amel Elkharraz

European Joint Conferences on Theory and Practice of Software, Fundamental Approaches to Software Engineering, (FASE/ETAPS), 2006.

DL: http://www.iro.umontreal.ca/~sahraouh/publications.html


おそらく、コンサーンの分離(Separation of Concerns or SoC)についての論文。

ソフトウェア工学の分野では、SoC は昔からある話だと思うけど、僕としては、AOP (Aspect-Oriented Programming)の文脈で知ったという感じ。

SoC とは何か? この論文によれば、イディオム。どんな、何のためのイディオム? 問題解決のための一般的なイディオム。あるいは、論文のアブストラクトによれば、SoC は概念的なツール。このツールにより、ソフトウェアシステムの開発などの複雑性に対処しようという感じ。

どんなイディオムかっていうと、複雑な問題をより小さな問題(サブ問題 or 部分問題)に分解して、それら小さな問題を個別に解決していこうぜ、っていう感じ。

論文では、単にそれだけでなく、「ゆるく結合されている(loosely coupled)小さな問題」と書いている。

図で書いてみた。
problem


論文によれば、SoC の基礎にあるのは二つ。
-サブ問題は、解くのが容易
-分解前の元々の問題を解決するために、サブ問題の解決策は、比較的よういに合成されることができる。

話はとんで、というか、よくわからんのでとばして、著者の人たちは、変換のビューを基にした概念的なフレームワークを提案するらしい。

で、ソフトウェアの要求は、変換への入力らしい。

また、この論文では、essential separability と inseparability を、accidental separability と inseparability から区別しているらしい。

essential の方は、要求を特徴付けし、accidental の方は、要求の実現を特徴付けするらしい。

accidental な inseparability は、プログラミング言語の設計によって、対処していくことが可能らしい。

図で書くとこんな感じか(間違ってるかも)。
)。soc



色々飛ばしまくったが、イントロダクションからの内容でした。


SoC と、モジュール化は、僕の関心のあるところ。特に、ソフトウェア進化の文脈で SoC とモジュール化をどう捉えるのかに興味ある。というか、研究してる。というか、研究の方向はそっち。

この論文でも書いてあるように、AOSD の研究は、解領域に焦点を当てる傾向があると思う。でもやっぱり、問題領域についても同時に考える必要があるきがする。

この傾向は、ソフトウェア進化の研究でも同じだと思う。プロダクトとしてのソフトウェアのソースコードの変化を調査することは、解が適用された後の結果を見ていくことであり、その解にいたる事になった問題や、設計者が行った設計のデシジョンなどは、ほとんど無視している。もちろん、難しいからだと思うけど。


続きはまた今度(あるかどうかは知らないが)。

@Newz


 @Newz(アットニューズ) 無料 ソーシャルニュースサイト レンタルサービス
 http://atnewz.com/

ってサービスができたみたい。@Wiki はお世話になってる(なりそう)なんだが、@Newz はどうだろう。

とりあえず登録はしてみたが、使い道をどうするかだな。

FC2Ad

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