中の人の徒然草357

美味しそうな専門書発見♪



デコンパイルJavaとは、これまた私好みな書籍です。昔Java仮想マシン仕様 (The Java series) を熱毒した私にとって凄く心躍るテーマの本です♪
リバースエンジニアリングPythonとは、これまた美味しそうな本です♪Pythonってバイナリアンが喜ぶ言語だったんだ・・・知らなかったな。
この2つの本はオライリーによると/ART/OF/REVERSINGシリーズの本だそうです。という事は、他にもディープな本があるってことだよね♪これは目が離せません！最近のオライリーは濃さが足りなかったから凄く期待しています。
エキスパートPythonは、Pythonを知りたい私にとって最適な書籍です。開発工程の全てを網羅していて好感が持てます。Python系の本は入門者向けばかりで、あまり私好みの本がなかったので、非常に期待しています。私が持っているPython本は、オライリーのPython入門 とPythonプログラミング で、これ以上濃い本が欲しかったので、この様な濃い本が出版されるのは非常にうれしいです。
これはひょっとすると、夏は豊作になるかもね♪
今ふと思ったんだけど、プログラミング言語系の本って、文法を解説したものは詳細なものが1つあれば、殆ど要らなくなるよね？言語がヴァージョンアップして文法が増えても、殆どの言語は似たような機能ばかりだから、マニュアルを読んだら済む話しになってしまいます。
これが意味するところは、入口（入門者用の本）ばかり多くて、山頂（よりディープな本）が少ないってことだと思います。
ですから私は、何言語でもいいからとにかくディープな本が欲しいです。その点、オライリーの/ART/OF/REVERSINGシリーズは期待できます。
/ART/OF/REVERSINGシリーズのようにディープな本がもっともっと出版されたらいいのになー。
ディープといえば、この本にも注目しています。この本はディープというよりもマニアックかな？



これも読みごたえがありそうな素敵な本です。人工知能ごぶさたしているし、Common Lispの実用書が見当たらないから、これはそそられます。人工知能は面白いよね♪でも、これ高いな・・・当分買えそうもありませんorz

中の人の徒然草356

みんなお久しぶり♪仕事が忙しくてブログの事を忘れていたインドリです♪
最近気候の変動が激しいですね。寒くなったり、暑くなったり、もう大変です。
昨日暑かったと思って薄着をしたら、その日は寒かったりしてもう面倒くさい。
それに、晴れていると油断したら雨が降るかもしれないから、外出する時は傘を持っていく。
それもまた面倒くさいです。折りたたみの傘にしても場所取るしね。

それはさておき、Visual F# 2010 Expressがないのが不満です。
これを使えという事かな？
仕方がないから当分これで遊ぶ事にします。
MSはもっと関数型言語をサポートしてほしいな。
一層の事新しい関数型言語も出すとか・・・
あと、論理型言語も出して欲しいです。
開発ツールは色々あった方がいいと私は思います。
まぁ、既にフリーなコンパイラが色々ありますから、それを使えばいいのかもしれませんが、やっぱりMSがサポートしてほしいです。
Windowsでのお仕事は、やはりMSの様な有名企業がサポートする開発ツールしか使えない事が多いし、豊富なライブラリも使いたいので、.NETの多言語対応なんだからもっと出して欲しいです。
そうすれば、開発効率も向上します。
なにはともあれ、多様性って大事ですよね。
知識が偏ると視野もせまくなって、開発効率は落ちるし、自分が変な言動をしても気付かない。
そうなってしまうと、アンチパターンの打ち出の小槌になってしまいます。
これは開発者として致命的な症状だから、こうならないように私はこれからもどんどん広く深く学習していきます。
打ち出の小槌状態にならないようにみんなも気をつけよう！

中の人の徒然草355

おはピヨ♪五月病に罹りそうなインドリです♪
いやー、この時期だるいですね。
それはさておき、スキルアップに悩んでいる人は多くいます。
勿論私自身も悩みつつ頑張っています。
その結果考えだした自分なりの答えを書きます。
スキルアップ関連で一番多いのが、自分が希望する部署とは違うので、自分が希望するスキルをアップさせられない事でしょう。
その気持ちは理解できます。
私の場合は、ブラック企業出身なので全ての開発工程を丸投げされて不本意でした。

どうして仕事量がこんなにあるのか？
どうして自分を指導できる先輩が居ないのか？
何故誰もが新人の私に聞いてくる状態なのか？
自分が希望するスキルをひとまずあげたい。
せめて、一つずつスキルをアップしたい。
・・・・・・・・

と多くの疑問と不満を抱きつつ、新人時代はすごしました。
しかし悪い事だけではありませんでした。
全ての開発作業をしたおかげで、幅の広い視野とスキルを身につける事が出来ました。 その結果分かった事があります。
それは全ての情報処理技術はどこかでつながっており、どの開発工程でも自分の希望するスキルをアップさせる機会は自分で作れます。
自分から仕事を見つけて、積極的に仕事をしていきましょう。
そうすれば、自分が希望するスキルをその周辺とセットで学べます。
ただし、仕事と趣味は違いますので注意して下さい。
ある程度自分で調べておいてから、本当に仕事の効率がアップする事だけを提案をしましょう。
そうしないと、貴方の信頼性が失われ、仕事仲間に迷惑をかけることにもなります。
あくまでもメインは仕事であり、学習がメインではないのです。
その点に注意し、作業効率が上がるなどの仕事上のメリットを見つけてから、それを材料に説得するとよいでしょう。
すると大概はその要求は通ります。
コツは「少し変える」です。
人間は変化を恐れますし、組織の都合上はそう簡単に変化する事は出来ません。
少しずつ変えていけばよいのです。
ここをちょっとこうすれば作業効率がアップすると言われれば、上司も大概は納得してくれます。
ですが、焦ってはなりません。
一旦提案が却下される事なんてざらにあります。
その時は、少しだけ変えて実践し、作業効率のアップを体験してもらうのです。
そうすれば、作業効率を下げたがる上司はいませんので、自然と自分の要求が通る事になります。
この少しずつを実践していけば信頼性は高まり、逆に自分に対して聞いてくる状態になります。
そうなれば、自分のしたい仕事は手に入ります。
これを繰り返していけば、自分が望むスキルをアップさせる事が出来ます。
それでも限界はあります。
限界に達した時、貴方は転職が頭に浮かぶかもしれません。
しかしながら、この不景気に転職するのは危険な行為なので、なるべく自分の職場を変化させ、それでも駄目ならば時期を待った方がいいでしょう。

中の人の徒然草354

おはピヨ♪常に情熱大陸しているインドリです♪
私は職業柄「どうすれば技術力がアップすのか」とよく聞かれますので、それについて書きます。
私の持論は、技術力をアップせさせるには、ラヴ＆パッションを持つというのが持論ですが、やはりそれだけでは納得してくれない人もいます。
そこでそういった人には、私のラヴ＆パッションが具現化して行った事を教える事にしています。
それは、「何でも自分で作ってみる」です。
CPUを知りたかったらプログラムで再現してみましょう。
TCP/IPを知りたかったらそれをプログラムで再現してみましょう。
プログラム言語の本質が知りたかったらコンパイラを作ってみよう。
デバッグ能力を高めたければデバッガを作ってみよう。
データベースについて知りたければRDBMSを作ってみよう。
コンピュータの動作原理を知りたければ、OSを作ってみましょう。
・・・・・・・
作ってみれば多くの事が分かります。
こういえば、多くの人がそれは難しすぎるといいます。
しかし、その様な事はありません。
初めから完璧さを求めなければ、決して出来ない事ではありません。
逆に失敗を含める事により多くを学ぶ事が出来るのです。
失敗しない学習なんて、得られるものはたかが知れています。
実際私は仮想CPUを作った時、軽い気持ちでインテルCPUのマニュアルと、はじめて読む486―32ビットコンピュータをやさしく語るを読んだら普通に作れました。
我々は普段から日本語の文章をプログラムで具現化する事に慣れています。
ですから、対象となるものが日本語で説明できるのであれば、作れない理由なんてありません。
仕事で仕様書などに書かれている文章を読んで、それを実現する為にプログラミングするのと同じ感覚です。
コツはリラックスるする事です。
公私混同して仕事と遊びの境目がなく、失敗をやたら恐れる人もいますがそれは危険な思想です。
趣味では逆に失敗する方がいいのです。
予め失敗しておけば、その原理が分かるので仕事で失敗する確率が減ります。
最後に注意しておきますが、これはあくまでも私の鍛練法なので、自分のラヴ＆パッションから導き出される事をしましょう♪
自分の事は自分が一番よく知っています。
心の声に耳を傾け、積極的に行動すると自然と技術力がアップします。

中の人の徒然草353

こんピヨ。もう梅雨ですね。
雨が嫌いな人も多いかと思います。
そんな人は、雨の良さを探すといいと思います。
雨の良さ探しは楽しいですよ♪

私は昨日、情報処理技術について考えていました。
goto文有害論が叫ばれ、ただのジャンプ命令がfor文やif文が考えだされました。
それは一種の抽象化であり、大きな進歩だと思います。
しかしそれは同時に、でアセンブラが持つ柔軟さが制限される事も意味しています。
私はこの事柄を情報処理技術の本質に迫る事だと考えております。
これに似た事例は数多く見受けられます。
フレームワークもそうです。
フレームワークを使用すれば生産性は上がります。
しかし、柔軟さが失われ、状況によっては不適切な場合もあります。
すなわち銀の弾丸は存在せず、全ての物事に長所と短所が存在するわけです。
これは情報処理技術の永遠のテーマだと私は思います。
きっとこれらから先も銀の弾丸は発明されないでしょう。
テーマは違えど、如何なる時代も技術者が考える事は本質的に同じです。
技術を通じ、時代を超えて人が結びつくのは、非常に浪漫がある事だと私は感じます。
これだから情報処理技術は止められない。
雨が降ろうと、雪が降ろうと、情報処理技術さえあれば私は幸せです。

中の人の徒然草352

おはピヨ♪ゴールデンウィーク明けで疲れているインドリです。
数日休んだ後で仕事をするのはきついよね。
それはさておき、やはりあの者たちはあやしい宗教の信者たちでした。
結局、id:busaikuroは誹謗中傷したんだろ？
このやり取りを読めば分かりますが、彼らの基本方針は「思っているもん」です。
何時も苦しくなれば、こうやって逃げているから会話になりません。
AlexAndRiteさんお疲れ様です。
私も彼らと会話した時同じ気持ちになります。
ようするに不毛なのです。
彼らは誹謗中傷したいから信じていると繰り返すだけなので、宗教集団だとしかいいようがないのです。
彼らは始めから会話する気なんてないのです。
彼らの教義は、「間違った（と思ったら）とことん誹謗中傷する。だけど、自分たちは間違っていないと思っているもん」です。
全くお話しにならない。議論なんて始めから成立しないのです。
理論のかけらすらない。子供の理屈としか思えません。私は大人と思う事自体間違っていると気付きました。
まず基本教義が酷いものです。
彼らの教義は「事実があれば悪口を言ってもいい」ですが、その事実とは彼らが信じている事です。
それは事実とは言いません。これが宗教と呼ぶしかない所以です。
普通の社会人は事実だと断定できない事に対しては悪口を言いません。
いや、そもそも軽々しく悪口なんて言いません。
やはり彼らは大人になれなかった人達というのが妥当でしょう。
この調子で、自称・技術論を展開するのでから目が当てられない酷いありさまになるのです。
「思っていたもん」が信条の彼らに技術論なんて大人な事は出来ません。
何時も彼らは間違っていると思っていたもんといいますので、議論自体が成立しません。
思っていたもんで通るのであれば、会話すら意味がありません。
双方が思っていたもんで終わるからです。
彼らは信じていれば真実なんて関係がないと主張しているのですから、双方が真実と思っていればいいという事になり、会話する目的がなくなります。
要するに悪口を言いたいだけなのです。主婦の井戸端会議の矮小版と言えるでしょう。
さて、彼らはおかしな発言を連発しております。
例えば、「インドリに妹が居ないと思ったから悪口を言う」です。
事実かどうか大事だと言っておきながら、こういう検証できない個人情報を断定して行動するのですから、その稚拙さが分かるでしょう。
これらの事実を鑑みれば、大人になれずに人とコミュニケーションがとれない人の集まりだと言えるでしょう。
彼らに贈る言葉は「少しは考えてから発言しろよ。な！」です。
検証もしないで、思っていたもんで全てを済ます彼らに誰かを非難する資格なんてありません。
むかし彼らは@ITでの新人の質問（名前が新人とか初心者の人の質問）を嘲笑っていましたが、少なくともその新人は思っていたもんで終わらすつもりはないと思います。それに会話をしようと試みているだけでも大きな違いです。
会話をする気もなく、他人の悪口を言いたいだけの子供達に言われる筋合いはありません。
この人たちを見れば、コミュニケーションが如何に大事なのか分かります。
そういった反面教師としてはよい集団なのかもしれませんね。

中の人の徒然草351

みんな、ゴールデンウィークを満喫しているかい？私は満喫しています。
読書と音楽鑑賞をして、のんびりまったりと時間を過ごしています。
今日はコミュニケーションについて書きます。
前に技術者に対して求められているコミュニケーション力はたいしたものではないと書きました。
その根拠は、クライアントに聞いたからです。
技術者は生真面目な人が多いから、コミュニケーション力といえば、ばりばりの営業マンが思い浮かぶと思います。 実は私はそう思っていました。 しかし、実際にクライアントに聞いてみると、それ程の話術を期待していないそうです。
先方も技術者といえば職人ですから、それ程話術が上手いとは初めから考えていないし、逆に口がうまければ騙されないか心配になるとの事です。
ではどういったコミュニケーション力が問われているのかといいますと、クライアントの要望を聞きだし、それをどのようにしてシステム化するのかを正確に伝える能力です。
クライアントにしてみれば、営業トークは既に耳にタコが出来るほど聞いています。ですからクライアントが気にするのは、どのようにそのシステムが役に立つのかなのです。
ざっくばらんにいいますと、「そのシステムのコストと利益を分かるように言ってくれ」です。 クライアントは技術者に営業トークを望んでいません。それは営業マンに任せればいいのです。
これは、我々技術者にとって大変ありがたい事です。我々が作るシステムを説明するだけなので、営業マンレベルの話術からしてみればたいしたレベルではありません。
営業マンと一緒に仕事をしてみれば分かりますが、彼らの話術は凄いものです。営業マンを軽視する技術者もいますが、彼らに対する感謝の気持ちを忘れてはなりません。システムは売れてなんぼなのですから、営業マンも立派なプロジェクトメンバーです。
ですから、我々技術者はコストと利益を正直にいえばいいのです。クライアントも鬼ではありませんので、我々技術者が想像するよりかは寛容なのです。
一生懸命正確にわかりやすく言う姿勢さえ伝われば、あまりクライアントから怒られません。
コミュニケーション力については、変に身構えずにリラックスして、誠意を持ち一生懸命に相手に伝えるだけでいいのです。相手に対する敬意を持っていれば、それが自然と伝わり、トラブルが発生する確率を下げられます。
実際私は未だに口下手かつ不器用ですが、それでも何とかやっています。
皆様も身構えずに、もっとコミュニケーションしましょう。
そうすれば、我々を見る世間の目も変わるかもしれません。
全員が努力をすれば、我々技術者が世間から尊敬の眼差しを受ける日が来るかもしれません。

書籍をつつく140ーユースケース実践ガイド。究極のユースケース本。

今日は趣向を変えて、上流工程においてバイブルとされている本を紹介するピヨ♪



この本は知る人ぞ知るユースケースの聖書ピヨ♪


【目次】

第0章　ユースケースの概要
0.1　ユースケースとは
0.2　ユースケース図
第 1章　イントロダクション
1.1　ユースケースとは何か
1.2　ユースケースは状況によって異なる
1.3 　要求とユースケース
1.4　ユースケースの真価が発揮される場所
1.5　労力を管理する
1.6 　利用ナレーティブで準備運動をする
1.7　練習

第1 部　ユースケースの本体部分

第2章　振る舞いの契約としてのユースケース
2.1 　目的を持ったアクター間の相互作用
2.2　利益に関わる利害関係者間の契約
2.3　図で表したモデル
第 3章　スコープ
3.1　機能スコープ
3.2　設計スコープ
3.3　一番外側のユースケース
3.4　スコープを定義するための作業成果物を使用する
3.6　練習
第4章　利害関係者とアクター
4.1　利害関係者
4.2　主アクター
4.3　支援アクター
4.4 　議論の対象になるシステム
4.5　内部アクターとホワイトボックスユースケース
4.6　練習
第 5章　名前の付いた3つの目的レベル
5.1　ユーザー目的（青、海面）
5.2　要約レベル（白、雲/凧）
5.3 　サブ機能（藍/黒、水中/貝）
5.4　絵のアイコンを使って目的レベルを強調する
5.5　適切なレベルを見つける
5.6 　長めの記述例：複数レベルの「請求を処理する」
5.7　練習
第6章　事前条件、トリガー、保証
6.1 　事前条件
6.2　最低保証
6.3　成功時保証
6.4　トリガー
6.5　練習
第 7章　シナリオ、ステップ
7.1　主成功シナリオ
7.2　アクションステップ
7.3　練習
第8章　拡張
8.1　拡張の基本
8.2　拡張条件
8.3　拡張処理
8.4　練習
第9章　技術およびデータのバリエーション
第10章　ユースケース間のリンク
10.1　サブユースケース
10.2　拡張ユースケース
10.3 　練習
第11章　ユースケースの書式
11.1　書式の選択
11.2　ユースケースの記述スタイルに影響する事柄
11.3　5つのプロジェクトにおける標準
11.4　結論
11.5 　練習

第2部　よくある議論

第 12章　いつ終えるのか
第13章　ユースケースの数が膨大になったら
第14章　 CRUDとパラメタライズドユースケース
14.1　CRUDユースケース
14.2　パラメタライスドユースケース
第15章　ビジネスプロセスモデリング
15.1　モデリングVS.設計
15.2 　ビジネスユースケースとシステムユースケースを結びつける
第16章　欠けている要求
16.1　データ要求の精度
16.2　ユースケースからほかの情報へのクロスリンク
第17章　プロセス全体の中でのユースケース
17.1　プロジェクトの組織化におけるユースケース
17.2　ユースケースからタスクまたは機能一覧へ
17.3　ユースケースから設計へ
17.4　ユースケースからUI設計へ
17.5　ユースケースからテストケースへ
17.6　実際の記述
第18章　ユースケース概要とエクストリームプログラミング
第 19章　問題点の修正
19.1　システムが書かれていない
19.2　主アクターが書かれていない
19.3 　ユーザーインターフェイスについて詳細に書きすぎている
19.4　目的レベルが低すぎる
19.5　目的と内容が合ってない
19.6　ユーザーインターフェイスについて詳細に書きすぎている長い例

第3部　忙しい人のためのメモ

第20章　個別のユースケースについてのメモ
第21章　ユースケース全体についてのメモ
第22種　ユースケースの作業に関するメモ

付録

付録A　UMLにおけるユースケース
付録B　練習の解答（一部）
付録C　用語集
付録D　参考文献

どう？目次を見てもこの本がただものじゃないって事が分かると思う。そう、この本はユースケースを実践的に使う事を専門としている珍しい本ピヨ♪ユースケースはUMLでおなじみだと思う。だけど、みんなはユースケースがテキスト形式で書かれる事をを知っているかな？
UMLの仲間入りをしているユースケースだけど、必ずしも図とは限らないピヨ。ユースケースに於いて、ユースケース図は全てではなく、逆にテキストで書いた方がいい時もあるピヨ。この本を読めばその事が詳しく書いているピヨ♪
それに、ユースケースは非常に役に立つ開発ツールとなるピヨ。UMLでの印象が強い人は、ユースケースなんてあんまり役に立たないと感じていると思う。ボクもこの本を読むまでは、ユースケースがそれ程役に立つとは思わなかったピヨ。だけど、この本を読んだら、ユースケースを書かないプロジェクトなんてありえないと考えを改めたピヨ。
だから、この本は上流工程にかかわる全ての人が読むべき本だとボクは思う。この本んを読んでいない人はもぐりでしょうと言えるぐらいピヨッ！
ユースケースをもっと生かしたい人、上流工程の技術力をアップしたい人、上手くプロジェクトを進めたい人などは是非読もう！読まないと損をするピヨ♪


【お得情報】
もっともっと本が欲しいという本好きは書籍レビュー目次と書籍レビューを見ると良いピヨ♪

中の人の徒然草350

こんピヨ♪ゴールデンウィークを楽しんでいるインドリです。
突然ですが最近は並行処理の資料が増えてきたようですね。
マルチコア時代を感じます。
＠ITでも並行処理の記事があります。
Visual C++でマルチスレッド・プログラミング
やはりcoutはそのまま使用するべきではありませんね。
I/O処理をそのまま並行的に実行してはならないという事は並行処理の常識です。
この記事はこの本の抜粋らしいです。
気になる人もいると思いますので、Amazonへのリンクを貼っておきます。



こういった入門書で並行処理について触れられているのが時代を感じますね。
これからは並行処理は常識化していくのでしょう。
しかし、分析・設計は未だに並行処理に対応しきれていないと私は感じます。
マルチスレッドプログラミングが出来ても、それをシステム化するのは別次元の問題です。
今のところ、逐次処理的に分析・設計し、後で並行処理に対応するのがベストだと言われていますが、それは余計な作業を増やすだけであり、デスマーチを増やしてしまわないかと心配です。
日本のIT業界は一体この先どうなるのだろうか・・・
上流と下流と人が分けられて知識が分断化している状態で、並行処理システムの開発は非常に困難です。
上流だとか下流だとかは関係ありません。特に並行処理はそうです。
そこをどうするのか、組織がどうやって技術を活かすのかは非常に大きな課題です。
情報処理技術は進化が早いといわれていますが、それを活かす組織論が発展していないのがネックです。
その辺のソフトウェア工学の発展が望まれます。
情報処理技術は趣味の学問ではないのですから、どうやって管理するのかよく考えなくてはなりません。