Joel on Software
Joel on Software
業務都合によりあまり時間が取れませんでしたが、私もレビュワーとして協力させていただきました。
この本、本当にいい本です。
第一線でプロとしてソフトウェア開発を行う全員に読んでほしい。 強くそう思います。
超オススメです。 文句なく、自身が読んだ中での今年のNo.1書籍といえますね。
Joel on Software
業務都合によりあまり時間が取れませんでしたが、私もレビュワーとして協力させていただきました。
この本、本当にいい本です。
第一線でプロとしてソフトウェア開発を行う全員に読んでほしい。 強くそう思います。
超オススメです。 文句なく、自身が読んだ中での今年のNo.1書籍といえますね。
koichikさんのコメント : Csus4.net - Just example. ≫ Blog Archive ≫ PoEAA 4th により書名を教えてたいただき、早速購入したのですが・・・・・
む、むずいっす・・・・。 付録AのOSAの形式的定義の構成を抜粋します・・・。
A.1 ORMから第一階述語と規則への写像
A.1.1 述語 A.1.2 規則
A.2 第一階言語から数学的モデルへの写像 A.3 OSAメタモデル
A.3.1 図A.4における最初の制約の変換 A.3.2 図A.4における二つ目の制約の変換 A.3.3 図A.4における三つ目の制約の変換 A.3.4 図A.4における四つ目の制約の変換
なかなか手ごわそうです・・・オブジェクト指向システム開発―分析・設計・プログラミングへの実践的アプローチ
伝説のプログラマ、カトラー氏はなお健在だった - So what is IT? [ITmedia オルタナティブ・ブログ]
私:「私はその昔、デビット・カトラーさんにインタビューしたことがあるんです」 K氏:「へぇ、そうでしたか」 私:「13年も前の話です。カトラーさんはもうMicrosoftにはいらっしゃいませんよね?」 K氏:「とんでもない。今でも現役のプログラマとして、64bit Windowsのコアをゴリゴリと開発していますよ」
すごすぎる。まぁ、私の隣の席の人も、負けずに一生コードを書いてそうな勢いだが・・・。
PofEAA’s Wiki - PofEAA読書会第4回
行ってきた&発表してきた。
PofEAA Chap5. Concurrency
ogijunさんのサマリをベースに。
ひがさんとkoichikさんによる(豪華な!)レクチャー風景を見物できて、こっそり満足(笑)。 見た目的に面白く感じたので、携帯のカメラで撮影してしまった。(笑)。
話題に上った分離レベルの話について、詳細に知りたければ 別の書籍にあたるのが良いと思う。分離レベル程度ならば、いくらでも良い解説は読める。 もう少し具体的なレベルで知りたいならば、RDBMS固有の振る舞いに振れた書籍にあたるのが良い。
SQL Serverの場合は、.NETエンタープライズWebアプリケーション開発技術大全 (Vol.5)”がなかなかよい。
そして、Oracleの場合は、
がわかりやすいのでオススメ。(これ以外の書籍がNGというわけではサラサラ無いです。自分が所有している書籍の中では。という意味)
自分の発表: 複雑なトランザクション 1/2
自分の発表のネタは、
の第3部の複雑なトランザクションをサマリ化したもの。これの内容をベースにいろいろ議論した。
時間の関係もあり全部はプレゼン&議論できなかった。 今回扱うことができたのは・・・
8章. 対話型トランザクション処理の設計方法
対話型トランザクション処理とは 業務排他制御による対話型トランザクション処理の設計方法 楽観同時実行制御による対話型トランザクション処理の設計方法
9章. 複雑なトランザクション制御
複雑なトランザクション制御とは ネットワーク障害時のメッセージロスト対策
まで。
記憶している範囲で・・・
論点となったのは
ロックの方式
楽観的同時実行制御における「残念!」は、ユーザーに嫌がられる可能性アリ 在庫引き当ての場合など厳密なモノの管理が求められるケースだと、ここで提示した方法+αが求められるだろう。
会員限定とか、在庫をクラス分けするとかもあり。
楽観的同時実行制御の実現方式であるtimestamp方式は、サーバ時刻ズレなどの問題をはらむ。versionNoが一番ツブシが効く。
二重submit防止とロギング
ビューに対するモデルを、永続化しておき、過去の画面(=ビュー)を再現できることを求められたケースアリ (類似例として?) モデルをXML化しておいたが、予想以上にサイズが大きくなりいろいろ苦労した。 (WebObjects屋的には) ブラウザ戻る対策が主目的であるが、pageCacheとしてメモリ上にレンダリング後の画面データを持つ仕組みが存在している
来月もやります。
PofEAA’s Wiki - PofEAA読書会第5回
残りは・・・
9章. 複雑なトランザクション制御
オンライン型長時間バッチ処理 トランザクションマネージャと連携できないリソースマネージャを含む短時間トランザクション キュー型トランザクション
です。
ここらへんのテーマが気になる人は、第5回PoEAAに参加するか・・・・
をボチっとやっちゃってください。イイ本ですよ。これ。
2005/06/28: 追記
「ネットワーク障害時のメッセージロスト対策」のどこが複雑なトランザクションなの?
という問いに対してイマイチな回答をしてしまったので補足。 HTTPなどのメッセージ転送機構がReliableでなく、Tx配下で動作するRM的に動作できないためです。あの本では、機能を実現する全ての構成要素がReliableでないと「複雑なトランザクション」である。という定義なんです。
あと、2相ロックに関する、私とkoichikさんのやり取りで混乱されていた方いたら、ごめんなさい。 (当然といえば当然ですが)koichikさんの主張が正しいです。 私は(直列可能性を実現するロック方法である)2相ロックと、デッドロックしないロック方法(ロックを徐々に取るのではなく、一気にとる!)をごっちゃにしてました。スンマセン。
最後にkoichikさんにお願い。 クラス正規系(?)に触れているベージュの表紙の本の名称などを教えてください!という思いをこめて「お願いトラバ」!
ん?行かないな・・・。あれれ?
超オススメできる。
あとで書くかも。いや、(ビジネス的な視点に興味がある人なら)買いなさい。とりあえず。
職場のやりとりの中で、オブジェクト指向を知らない上司にオブジェクト指向を説明する羽目になった。
たとえ話で説明したのだけど、なかなかうまくいったように思う。上司にも「わかりやすい!」と感謝してもらえ、かつマイmixi限定でやりとりを公開したら結構好評で、わたくしカナリゴキゲン(←アホ)なので、ここにもやり取りを残しておくことにする。うほ。
やりとり
上司「なんで継承構造が複雑だと問題なの?」
自分「(継承を駆使した(※))オブジェクト指向設計のメリットは2つです。1つは、実作業者をある種のカタにはめられること。もう1つは、機能を共有できることです。」 (※: テンプレートメソッド的なイメージを持っていただければ。)
自分「たとえると、ビジネスフォームみたいなものです。たとえば、契約書とかで、本文には「甲が乙に・・・の義務を負う」みたいなヤツありますよね? 甲の部分を変えれば別の契約書になりますし、逆に言えば、ソコしか変えることが出来ないので、いわゆるカタにはめる格好になります。そして肝心の契約本文は共有できるので、契約を起こすたびに文面を考える必要はありません。継承を多用したオブジェクト指向設計っていうのは、こんな感じなんです。」
上司「ふーん、いいじゃない。」
自分「ですけど、問題点もあるんです。」
上司「何?」
自分「たいていの開発の場合、契約書テンプレートを作る人と、テンプレートを埋める人は別の人なんです。そして、継続してメンテナンスしないといけない。しかも、契約書の場合と異なり、両者は常に整合性をもっていないとイケないんです。 たとえば、法律の改正があって、契約書を修正しないといけないとしましょう。契約書の場合だと、テンプレートを修正して終わりですけど、ソフトウェア開発の場合だと、そうはいきません。現実の契約書テンプレートとは異なり、契約書テンプレートを修正すると、この契約書テンプレートを元にして作った契約書も全部修正されちゃうことになるんです。去年作った契約書も全部です。」
上司「あー」
自分「しかも、この(イケてない)協力会社がつくったソースの構造は複雑で、契約書にたとえると、契約書の本文に、「~の詳細については、・・・を参照」みたに契約書の構成が複雑で全貌を容易につかめないような感じなわけです。 これを将来的にメンテナンスしていくのは大変ですよ。」
上司「なるほどねー」
てな具合。
うーむ。 解答を計算用紙にメモしなかったのは痛恨。 メモし忘れたことに試験終了時に気づいたので、 さりげなくキーとなる数値をメモ。 大原の模範解答と照らし合わせると、数値自体はあっているので、たぶん大丈夫かと。(思います・・・・・)
にしても、ケアレスミスの多さに我ながら困ったもんだと思ってしまう。事前勉強の中で問題を説く際にやらかしたミスのオンパレード。なにも本番でもやらかさなくても・・・と自己嫌悪。
0と6の見誤り 借方/貸方 転記ミス 繰越分を計算に入れてしまい、貸借があわねー!と焦る。
逆に言えば、チェックを可能とする仕組みが存在しているということである。簿記すばらし。
帰りに
啓文堂書店でストレス解消。
7つの習慣がらみとあっては。
問題発見型財務会計勉強方の流れで。
そろそろ真面目に勉強しようかと。
最近、異職能、異業種の仕事のやり方に興味があります。
面白い。自分のような皮肉屋にはもってこい。
1,500円の価値があるかといわれると・・・、好き嫌いが分かれそうなので一概には言えない。 ただ、単なる皮肉だけではないので、この本のストライクゾーンは結構広いのでは?と思っている。
Doblog - Joe’s Labo -
人事制度を作る時、従業員に対して“将来のビジョン”が描けるかどうかが非常に重要 な鍵となる。十年後自分がどうなっているか、あるいは自分の希望する業務に携われる かどうか。平たく言えば「その会社で夢がかなうか」ということだ。
一見古臭そうだけど、実は大きなパワーをもつ日本企業の施策については、この本が詳しい。しかも面白い。オススメできる。
via Day by day(2005-05-31)
from Data Crunching: Everyday Help (Books)
Data Crunching covers areas of most interest to working programmers:
Using plain text files > Learning how to use Regular Expressions > Parsing XML using SAX, DOM, and XSLT > Encoding data in binary files > Handling relational databases using SQL >
ふむ。面白そう。
「プログラマの最大の武器は、プログラムを書けることである」とは、わいの親方の言葉であり、とても共感する言葉であるけれども、世間一般的な「SE」と呼ばれる立場の人間が日常の業務において「プログラムを書く」機会は少ない。残念ながら。 テキストエディタを相手にする時間よりも、打ち合わせをする時間、Word/Excelに向かう時間、ミドルウェア・OS等のマニュアルを読む時間のほうが圧倒的に多いのが現実。
ただ、「いざ!」というときはやってくる。 たいていの場合、緊急性が求められ、ミスが許されない状況下である場合が多い。
そう、素振り必要。
心の中で思っていても、考えても、「やる環境」を作るところまでやらないと意味がない。 この本がその助けになれば。