「Engineering」カテゴリーアーカイブ

エンジニアとしての生き方

エンジニアとしての生き方  IT技術者たちよ、世界へ出よう! (インプレス選書)

著名なブロガー・プログラマー中島聡氏の著作。中島氏の存在を知ったのは、たまたま会社の先輩のブログからリンクを見つけてのもの。その時のエントリーはあまり興味を引かなかったのだが、他のエントリーを見るに連れて、徐々に引きこまれていき、今では、心の師なる存在。

SIerという業界で働いていると、そもそもエンジニアという存在が異質なものなのでストレスを感じる部分も多いが、自分がそもそも信じているエンジニア像、技術に非常に長けて、企画・センスもあるというキャリアイメージを具現化してくれる存在。

学生時代に大学の学術情報センターでアルバイトした経験から言うと、大学規模のシステムでも管理者は20人弱。20人で学内の数百台のPCをの管理から、学内外のネットワーク、ファイルサーバ含めて管理していた。外注も一切なしで、(と言っても、ハードの初期セットアップは委託していたが)、事務所にはオライリーが山ほど並んでいる。ICカードからプリントするシステムが2001年時点で内製で運用していたり、ブートローダーも作ってしまう。

そんな環境を見るに、プログラマとしては到底活躍できないだろうと思い、SIerという少し業務寄りなところへ就職したつもりだったが、方やプログラミング言語を大して知らない1~2年目が動くものを書いてしまうエンタープライズな開発に愕然としたことも思い出す。それでも、それじゃいかんと思い、技術書を漁ったりもしたが、やはり、仕事上そこまで求められるケースはほぼ無く、ギャップに悩む事も多い。ただ、SIer、SEに関する以下の記述になるほどなと思わされるし、進むべき方向を暗に照らしているようにも感じる。

私の理解では、SEという職業はレストランに例えればウェイターである。それも、メニューから料理を選んでもらう通常のレストランとは異なり、「客の注文するものなら何でも作る」という個別注文レストランである。

そんなレストランであるから、客の注文もさまざまである。「豚のしょうが焼き定食」と料理を指定する客もいれば、「今が旬の魚を使った寿司」とか、「ご飯のおかずになるものなら何でもいいけど、コレステロールが気になるから野菜を多くしてね」という漠然とした注文も来る。ウェイターの役目はそれぞれのお客さんに満足してもらうには、何を作るのが一番良いのかを見極めて、キッチンに伝えることである。

難しいのは、客が必ずしも料理に詳しくはないので、真夏に「生牡蠣が食べたい」などと無理を言って来る客がいることである。そこを相手の自尊心を傷つけずに、「お客様、今は8月なのであいにく生食に適した牡蠣がございません。牡蠣フライではいかがでしょう」などと客を説得しなければならない。そういった仕事をちゃんとせずに、「生牡蠣一人前!」とキッチンに伝えてしまうと、料理人たちからは、「あのウェイターは料理のことが分かっていない」と非難されてしまう。

優秀なウェイターになると、客の好みや健康状態、季節の食材、キッチンにいる料理人の得意料理、各料理にかかる時間、食材のコスト、などが全て頭に入っているために、客にも喜んでもらえるし、キッチンからは信頼される。そんなレストランの客席はいつも満足げな客で一杯だ。

これが私の理解する「SEの役目」である。客に満足したソフトウェアを提供するという意味で、SEという職業はものすごく重要ある。ソフトウェアエンジニアとどちらが上か、などということは決してなく、それぞれに「客が何を本当に必要としているのか見つけ出す」、「受けた注文に基づいて作る」というそれぞれに重要な役割を果たすだけのことである。

会社ではやれ鉄人など、技術マニアなど、といった呼ばれ方をするが、世間を教えてくれる名著。願わくばもっと前に出会いたかった本。これも殿堂入り。

うちの部員にも読んでもらいたい。。。

prezi

きっかけは、@nahiのtwitterより。

これからJJUG Night Seminarでしゃべります。スライド:http://bit.ly/JJUGJRuby2011 / 利用サンプル:http://bit.ly/JJUGJRubySamples#jjug#jjugNight

もともと参加したいセミナーだったけど、有休だからと言い訳をして不参加。資料が見られるということで覗いてみると、見たことが無いページ。slideshareでも無いし、どうやってもるんだろうと思ったら、、、

でもびっくりした。たまげた。感動した。

プレゼンテーションそのものに対する考え方を変えさせてくれるようなぐらい、びっくり。

まだ日本のインターネットメディアでは紹介記事が内容だけれども、検索結果の上位を見ると2009年頃よりブログでの紹介が広がってきている。先日やった社内のBIG-IP勉強会で使えなかったのが残念。次回、好き勝手できるプレゼンがあったら使ってみよう。

印刷もPDF化することで対応可能なようだし、社内で使う分には大丈夫でしょう。

lyはリビアと小悪魔女子大生

bit.lyをtwitterで見るたびに、lyってどこだろうと、普段見ないから怪しくも感じていたけど、リビアらしい。

でもって、書こうと思った内容も、

リビアのインターネットとbit.ly

http://www.geekpage.jp/blog/?id=2011/2/22/1

に書かれてしまっていたので、終了。

DNSついでのおまけ。

小悪魔女子大生のサーバエンジニア日記 ――インターネットやサーバのしくみが楽しくわかる

http://co-akuma.directorz.jp/blog/category/dns%E3%81%A3%E3%81%A6%E4%BD%95%EF%BC%9F/

渋谷のブックファーストに平積みされていて、立ち読み。どうしても字体に慣れなかったので、購入には至らなかったけど、(失礼千万だが)、女子大生でもこれだけまとめられてしまうのだから、インターネットのシステムをメシの種にして、高いお金を頂いてる自分たちの強み、しっかりと意識しないといけないなと、刺激をもらいました。

いや本当、テクノロジーが苦手な若手にオススメしたい。

PS:というか、これだけノートにまとめてくれる後輩がいたら、どれだけ教える気になることか。楽しいことか。中身以上に彼女の姿勢に感服です。

小悪魔女子大生のサーバエンジニア日記

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

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

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

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

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

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

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

AxisでのTCP Connection Timeout(2)

前回からの続き。

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

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

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

org.apache.axis.components.net.SocketFactoryFactory

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

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

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

 

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() メソッドを介して取得できます。

 

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

明日見てみよう。

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

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

中古で100円で出てるし。

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

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

「経験知」を伝える技術 ディープスマートの本質

後輩を育てろと言われて久しい中、経験知を伝えるシリーズの完結編。

完結編に辿り着く前に読んだ書籍は別途備忘録レビューします^^

アメリカの学者がリサーチを重ねた結果、たどり着いた結論は、古典的な時間をかけてのOJTが重要と、述べている点は興味深い。とはいえ、そこにたどり着くための要素・分析は非常に細かく驚かされるものも多くありました。

個人的にも引継ぎをしようとすると、言葉では表現できない点や、あたりまえ・常識ではないけれども今更教えること、というような経験があっただけに、考え込む事もありましたが、この本を読んでみると引継ぎ時に悩んでいた局面が全て出てきたようにも感じます。

ということで、殿堂入り(w。

ただ、それにしてもワインバーグもそうだけど、この手、時間とエネルギーをかけずにサクサク読めるようになりたいものです。

特に気に入ったフレーズを抜粋。

無意識的学習により獲得した知識は大雑把に言えば、知識の所有者の表現能力を常に上回る。

無意識の推論に基づく選択や判断の理由を説明しろと言われると、人間は実際の行動と明らかに関係の無いことを口にする

 

 「経験知」を伝える技術 ディープスマートの本質

AxisでのTCP Connection Timeout(1)

参考にした実装がイケてなくて、TCPコネクションタイムアウトが実装されていなかったorz

CONNECTIONTIMEOUTPROPERTY トランスポートセンダーが利用するタイムアウト(ミリ秒) Integer

という記述があるので、できそうだ。

もとあった実装は、Stubのタイムアウト設定のみ。せっかくなのでGlassFishで動かしてみることにする。

インストールと思ったけど、すでにインストール済みだった(w。

http://localhost:4848/ が管理画面。

インストーラでポートバッティング起こして気がついた。

C:\glassfishv3\glassfish\bin\startserv.bat を実行したら起動。

この辺は勘だけで何とかなるあたり、捨てたもんじゃない(w。

Axisのライブラリのサンプルに含まれる、webapps/axisをデプロイして、http://localhost:8080/axis/にアクセスしたところ

HTTP Status 500 –


type Exception report

message

descriptionThe server encountered an internal error () that prevented it from fulfilling this request.

exception

org.apache.jasper.JasperException: java.util.MissingResourceException:

Can’t find bundle for base name i18n, locale ja

root cause

java.util.MissingResourceException: Can’t find bundle for base name i18n,

locale ja

note The full stack traces of the exception and its root causes are available in the GlassFish v3 logs.

 

どうも、サンプルのライブラリには本来は、/web-apps/axis/WEB-INF/classes/配下に

 

という2つのファイルがあるはずなのだが、どういう訳か俺の環境には無かった。

配置して再デプロイで表示を確認。

本当は、Webサービスクライアントを作って、タイムアウトが効くところまで試したかったけど時間切れ。

に、してもこの手の作業が一番楽しい。

スケジュール書いたり、進捗報告したり、ミーティングしたりする事に比べて、どれほどわくわくする事か。。。

続きは(2)として書こう。