年別アーカイブ: 2010年

4Gbpsを超えるWebサービス構築術

タイトルは随分と前から気になっていたし、数少ない基盤系本という事で、たまプラーザに行ったときに駐車場代金が足りなかったので、ということで購入。普段、最大でも40Mbpsに行ける私としては興味が高かったのですが、、、やっぱり魔法は無いなと言うのが率直な感想。また、読者層もかなり若手に絞られている印象。表面的な話やインストール手順などもあり、8年目の基盤やってる人間は読者層として概ね不適当。あと、4Gbpsのポイントもあまり感じ取れない。

サーバ系ははてな本とも内容の重複が多いし。

Chapter2~４のキューイング、DBキャッシング、HTMLキャッシングはどこでも良く書かれている話。Chapter6-7の入出力パフォーマンス、分散ストレージはそこそこ楽しめるし、今の時代に分散ストレージを作るという選択に至る状況が書かれている点は楽しめるが、この本を読むよりはHadoopやMapReduceを読んだ方が役に立つと思う。Chapter8 ここはインターネットビジネスをやっている人にとっては新人でも読んでおくべき内容。

9章の回線以外はあまり楽しめず。。。

ただ、それでも、Chapter9の「ネットワークを取り巻く技術」は、普段縁がない世界だけに面白かった。

黒いワールドカップ

帯は強烈だった。

ドイツ、イタリア、フランス、スペイン、ロシア・・・。世界各言語で翻訳されているインターナショナルベストセラー　待望の日本版。八百長サッカーの実態を追い求めるジャーナリストが世界各地を駆け巡った衝撃のノンフィクション

前書きもなかなか良かった。

特にオリンピックの日本代表チームが関係する試合で八百長をしようとしたことについて、フィクサー自身が語っているからだ

でも山場はそこで終わってしまった。

外人のノンフィクションだからなのだろうか。。。リズムがとかく咬み合わない。読みたいリズムと全く合わない。ニュースになったように八百長問題がヨーロッパで盛り上がったことをしってるけれども、本を読むには盛り上がらない。

結局全部読むことなくお蔵入り。マジック・ジョンソンのマイライフ以来のがっかり作。。。

嫌われ者

PRIDEで活躍後、消えてしまった格闘家の記録。

プロレス・格闘技の裏本は最近大量に出ていて、そこそこに面白いんですが、総合格闘技のは読んだことが無いのでそこそこ新鮮。ただ、やはりつまるところ興業だけに。。。PRIDE自体は自殺があったり、終焉がショッキングだっただけに色々と黒さはあったのだが・・・。

ただ、Wikipediaを紐解いて見ていくと出てくる情報も多いので、買ってはみたもののBookOff行き確定。

自演乙のように、興業とは、プロとは、が分かっている人間はやはり強いなぁ。多分何をやってもそれなりに。

逆にスポーツ・アマチュア意識が強いと成功は難しい。（スポーツでは無いから）

面白いけど、様々な黒さにエネルギーを奪われてしまうという点でオススメはあまりできない。正直かなりやる気がでなくなりました（苦笑。

しがみつかない生き方

しがみつかない生き方―「ふつうの幸せ」を手に入れる10のルール (幻冬舎新書)</a>

この半年で恐ろしく疲れてしまったので購入。体調不良を挙げてみても欝じゃないかとドキっとさせられるし（汗。

とにもかくにも、肩の力を抜いてくれる内容、そして肩の力が恐ろしく抜けている文体。香山リカというか、この手の医者って上から目線で嫌なイメージもあったけど、本人も影を抱えているようなエピソードもあり、素直に読める。

勝間和代と香山リカ。どっちも好きだし、激しい舌戦を（意図的？革新的？）にやってる気もするけど、その時の気分・状況で読み分けたい。

AxisでのTCP Connection Timeout（2）

前回からの続き。

結局Axisの実装の問題だった。結局タイムアウトを利用しているSocketの生成、HTTP通信の場合は

org.apache.axis.components.net.DefaultSocketFactory#create

でやっているが、ここの呼び出している、

org.apache.axis.components.net.SocketFactoryFactory

がクラス名の通りで、シングルトンなので、複数の通信先と通信を行う場合に、一番最初に通信を行った先のタイムアウト設定が、ほかの通信でも効いてしまう、というオチ。

通信先によってタイムアウトを変える、なんて消極的な考え方ではく、自分が動くためには一律のタイムアウトで良い！という考え方なんだろう。

当面は使うことも無くなってしまったので調査は見切り。

課長のノート

三井物産出身の著者のノート。物産で部長代理までのぼりつめた後、異動やら転職やらされているので、ワンランク上の課長、から更に上がどの程度あるのかは非常に未知数です。

現状、部下が気づけば8名のオイラにとっては、組織のマネージメント面で課題が出てきているだけに、またこの手のノウハウってなかなか伝承されるものでも無いだけに、ヒントを求めつつも気分転換に購入。

延べ114に渡る「気づきメモ」でエッセンスはあるものの文量は非常に少ないので気軽に読めます。

頭に響いたのは以下。

課長の表情が職場の士気を左右する

確かにそうですね。。。上司がしんどい顔してると確かにそうだわ。いい表情で仕事できていないであろう自分に反省

能力のない上司が口にする３つのフレーズ。「忙しい」「難しい」「○○のはず」

「 ○○のはず」は最近多用気味。。。

EJB例外

職場で議論があったので整理してメモ。。。

本を見ると

チェック例外

Exception拡張。トランザクションを原則ロールバックしない。させたい場合は、setRollbackOnlyでマーキングが必要。

非チェック例外

RuntimeException拡張。ローカルEJB呼び出しの場合はEjbExceptionを、リモートEJB呼び出しの場合は、RemoteExceptionにてラップして応答を返す

とある。Oracleのページでは

チェック済み例外

対象となる EJB のメソッドがチェック済み例外 (RuntimeException を拡張しない例外) を送出する場合は、その例外を try-catch ブロックで捕捉する必要があります。一般的には、EJB メソッド内で発生する (EJB メソッドが使用する別のメソッドによって送出される) 例外を捕捉し、その例外を克服するか、それができない場合は、その障害の原因がシステムレベルのエラーまたはビジネスロジックのエラーのいずれであるか、あるいはトランザクションによって自動的にロールバックされるべきかどうかに応じて、これらの例外をアプリケーション例外または EJBException のいずれかとして再送出することがベストプラクティスであると考えられています。

アプリケーション例外は、Bean の開発者によって定義された、RemoteException を拡張しないチェック済み例外であるか、または javax.ejb パッケージ (CreateException、DuplicateKeyException、FinderException、ObjectNotFoundException、または RemoveException) であらかじめ定義されているチェック済み例外です。EJB のメソッドでは、throws 文でアプリケーション例外が明示的に定義されます。

実行時例外

EJBException などの、java.lang.RuntimeException とそのサブタイプは、対応する EJB コントロールを介して EJB メソッドで送出できます。これらの例外はコード内で明示的に捕捉する必要はありませんが、通常は EJB のローカルインタフェースを使用する EJB コントロールを呼び出すクライアントアプリケーション内でこれらの例外を捕捉することをお勧めします (リモートインタフェースの場合は、EJBException が RemoteException として EJB コンテナによって再送出されます)。

最後、JavaDocを見ると

RemoteException は、リモートメソッド呼び出しの実行中に発生する多くの通信関連の例外で使用する共通のスーパークラスです。java.rmi.Remote を拡張するインタフェースであるリモートインタフェースの各メソッドは、その throws 節に RemoteException を記載する必要があります。

リリース 1.4 では、この例外は汎用目的の例外チェーン機構に準拠するように改良されています。「ラップされたリモート例外」は、例外を構築するときに指定し、publicdetail フィールドを介して取得していました。この例外は、リリース 1.4 では「原因」と呼ばれるようになり、前述のフィールドだけでなく、Throwable.getCause() メソッドを介して取得できます。

チェック例外を投げるような実装は、あんまり見てない事を思い出した。多分、どっかで細工をしてるんだろう。

明日見てみよう。

もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら

ベストセラー本。発売当初から名前は気になっていたのだけれども、ようやく購入。直前読んでた、難しい本とは違って読みやすく、会社３往復で完了。

内容はもちろん良いですし、言うこと無いんだけれども、しょーじき、程高野球部と全く同じような状況な部活をやっていただけに、当時に読んでいたら、違う自分があったのではと思う。今年のトップ３に入ることは確定。

内容自体は、『マネジメント』のエッセンスを抜粋しているし、その抜粋されている数も消して多く無いんだけれども、その少ないながらの抜粋だけでも、いかに奥の深い洞察が行われているのか、というのが伝わってくる。疲れてるのか、作品が秀逸なのか、そもそもドラマとか映画をろくに見ないので涙腺が緩いのか、ストーリーに感動するような局面もあり、そして『マネジメント』が今の自分が欲しい内容が書かれていることも容易に教えてくれる。

読破に時間がかかりそうな、手付かずになっている本も多くあるなか、気分転換にとして浮気する感覚で買って、読んで良かった。

万人にオススメできそうです。

PS：『マネジメント』は速攻購入。

明解J2EE+アプリケーションサーバ実践プログラミング

以前書いた行方不明の本。会社で後輩に聞かれて、再度amazonで探してみたところ、見つかったので購入予定。

中古で100円で出てるし。

２００５年当時では最も簡単だったJ2EE本。JSP/Servletは１０日でできるシリーズで触り始めたものの、EJBに関しては適当な本がなく探しまわって見つけた本。

これを見て、JMSのフレームワークを作った思い出が蘇ります。J2EEも当時からはバージョンも上がっていて、JPAやJSFやWebサービスやら、新しいテクノロジーも多くなったけど、それでも古典的なEJBを知るには良い本です。

経験知に欠けた勉強会

WebLogic勉強会も、スピーカーが自分の知る限りの知識を披露しただけの会の印象は拭えず。

WebLogicに明るい若手が説明するというお題目もあるのは、設定方法メイン。アプリ開発者に設定方法教える必要があるの？という疑問をそのままに、、、

Javaでは接続プールを使うことでゴニョゴニョ。。。

接続プールでは同時接続数とかを設定してます。

とりあえず、インスタンスごとに別の接続プール使ってるみたいです。。。

虚無僧で接続プールの利用状況は分かって、ここがこーなってると危険ぽいです。。。

ん～。本人は必要なエッセンスだと思ってるんだろうが、全般的に話が表面的でかつ、言葉の端々からその点を臭わせてしまっているようにも感じる。（ハッタリ不足。

また、誤解も多く本なりWebなりでバックボーンは作れてないのは良く分かる。

接続プールってそもそも何ですか？という設問が無いまま新人始め若手に説明して効果があるんだろうか。。。

どの程度成長したかな？とも思って若手向け勉強会と呼ばれる会に参加したものの、悪い意味で想定通り。

＃自分が同じ年次だった時の事はさておき

ただ、エキスパートが１年目に教えるよりも２年目が１年目に教えたほうが効率良いことも多いので、そこに期待してます。。。ついで、WebLogicの研修に何人か行かせるようだけれども、J2EEなり、行かせるメンバーを選ぶなりした方が良いのでは？という不満も。

つまるところ、勉強会にしろ研修にしろ、然るべきプロセスを経て決まったと印象を、与えられる出来事に対して、自分が持ってる知識や問題認識、経験知がチームと大きくずれている（と思ってしまう）点が、非常にストレスの種。

開発機会が無いとはいえ、フレームワークやJ2EEの仕組み、といった点も、ミドルウェアの設定や研修を受けることと同じくらい重要という事に大半の人が気がついていないのか、重要と思っていないのかが・・・。

さて。