ここ数日、お客様先で発生したトラブルの調査やらなんやらにかなりの時間を費やしています。

IISのログやOracleのログを追いかけてみたり、関係各所に調査を打診したり
カウンタの値を見ながら原因を推察したり。

何となく原因説明のストーリーは立てられなくもないけど、それを裏付けるには
トラブル発生時の状況を示すための資料が足りない。
足りていない部分をあれこれと推察しながら資料を作っていくことになります。

不謹慎ながら、こういう技術系の調査や原因の究明に頭を使うのって楽しいんですよね。
それは多分、原因を調べていく過程で、これまで把握していなかった知見を得ることが出来たり、
推測をデータで裏付けていくことが出来た時にすっきりするからなのかもしれません。

でも、ぶっちゃけてしまうとどれだけ考えても明確な裏付けを持たせることが難しい場合もあるし、
こうやって考えたりしている時間は短ければ短いほどいい。

なぜならば、こういうことに時間をかけていても、その時間で価値を生み出している訳ではないから。
本来は、もっと価値を生み出すことに時間を費やし、そこに楽しさを見いださなければ行けない。
そこが中途半端だったりするから楽しく感じてしまうのかもしれないな。

と言う訳で、障害からの復旧をいかに手をかけずに効率よく行えるのかをもう少し真剣に考えてみることにする。
え？障害が起きないように頑張れ？

そんな夢、見てらんないよ

表題の本を読んだ

テストから見えてくるグーグルのソフトウェア開発

posted with amazlet at 13.07.02

ジェームズ・ウィテカー ジェーソン・アーボン ジェフ・キャローロ
日経BP社
売り上げランキング: 1,971

Amazon.co.jpで詳細を見る

本書は、Googleにおけるテストの考え方やテストの実践を通して、Googleにおけるソフトウェア開発や思想を紹介しているのであって、テストの仕方を学ぶものではない。

もちろん、Googleという巨大企業がどういうテスト体制というか、ソフトウェア開発体制をしいているのかということは知ることが出来る。
そこから展開できることも多くあるのだが、考え方は参考になってもやり方はまねできるものは少ない印象を受けた。

私は開発の現場を多く知っている訳ではないので、知っている世界と言うものはたいへん狭い。
なので、どういう開発体制が一般的なのか？ということに関して語る言葉を持たない。

しかし、開発の現場によってどういうメンバーがいるのかと言うのは大きく変わっていくんだと思う。
テスターと呼ばれる専門メンバーを用意できる体制もあれば、仕様検討と設計、コーディングが完全に別れている体制もある。

何がベストかは結局の所何を開発するのかにもよるだろうし、ベストと思われる方法があったとしても、会社の経済的な理由やリソースが足りないこともよくある話だ。

結局の所、その場その場で考えて動くしか無いという結論になってしまうのかもしれない。
ただ、だからこそ、こういった様々な事例をインプットしておくのは必要なことだと思う。
実践できるかどうかは別として、中々面白く読むことが出来た。
思わずGoogleに入りたくなるくらいだ（門前払いが確定しているが）

テスターという位置づけを確保することは、ちと難しいかもしれないが、
それでも持ち回りでそういうことを意識する役割を設けてみるのも面白いかもしれない。
なんて思った。

これまで、職場では基本的にJINS PCをかけていて、家ではそれほど多くの時間をPCの前にいないので裸眼でした。
週末だけ、家にもってかえって着用するような形です。

それはそれで何とかなっているのですが、最近、少しずつ家でのPCに向き合う時間が馬鹿にならない気がしていてもう一つ欲しいと思っていました。
と言う訳で、少しお出かけした際に購入。

写真の奥においてあるのが今までのもの。
今回買ったのは、手前の「メタルスクエア」というタイプ。
見てわかるように、これまでのものよりフレームが細いです。

私のように、元々メガネをかけていない人間にはメガネをかける事自体が少しストレスです。
なので、少しでも軽くてフレームが気にならないタイプの方がいいのではないかな？と思った次第です。

1週間ほど会社で着用してみましたが、正直どれほど効果があるかは思っていた以上にわかりませんでした。
自分でも思っていた以上にメガネに慣れてしまっていたのかもしれません。

それよりも困ったのはメガネケース。
以前購入した際は、プラスチックのケースが付属されていたのですが、今は布で出来たソフトケースだけのようです。
これは持ち運びにはとても怖くて使えません。

と言う訳で、以前購入した際についていたケースを会社用に。
家で使う用にソフトケースを、と言う形で入れ替えて使うことにしました。

体感することの無いJINS PCの効果ですが、体感してからでは遅いってのもあるとは思うので、暫くはつき合ってみようと思っています。

お客さん先で、不可解な現象が発生していてその調査をしています。

実際問題、アプリケーションの問題と言うよりはインフラ。
特にネットワークの問題である可能性が高いのですが、
そこまで完全に決めつけるには一貫性ある説明が出来ない苦しい状況。
さてはて。困ったな。

今回に限った話ではないけれど、トラブルの原因がネットワークや
それに類する機材にあった場合の原因の切り分けは骨が折れる。

よく、ネットワークモニター等を利用してパケットの流れは確認し、
問題が起きている事はわかる。

ただ、それがどこで起きているのか。
何が原因で発生しているのかを突き止めるのは地道な作業になる。

ロジックとして説明出来る事もあれば、機器の故障で本当に不可解な現象が発生して、
機器を交換して初めて「この機材が原因だ」とわかる事もある。

もちろん、ネットワークに対する知識が足りずにそういう判断しか出来ないという話もあるのだが、
この分野だけはどれだけ勉強しても”詳しい”と言えないような気がするなぁ

少し前にオルタナティブブログにてこんな記事を見かけた

実際にあった怖いバグ票（バグレポート）
http://blogs.itmedia.co.jp/morisaki/2012/08/post-a506.html?ref=rssall

見ながら、「あ〜、あるある」と思った節が何度となくあった。

指摘している内容や、考えている方向性だったりするものはしっかりとしていて、
それ自体は本当は評価されるべき内容なのにも関わらず、
最後に余計な一言が書いてあるせいで読み手にものすごい不快感を与えている。

それでいて、その人にとってはその一言こそが言いたい事だと考えている。
そこがまた一際厄介なんですよね。

言っている事がわからなくはない。
背景を教育しなければ、今回の問題はクリアされてもまた別の形で現れるかもしれない。

ただ、それはバグ票という媒体の役目かというとちょっと違う気もする。
その辺りの交通整理を、プログラマ以外の人に対してもわかる形で行えるようにならなければダメだと思う反面、
自分自身がそういう動きをとっていないかを気をつける必要がある。

なんだかんだ言って、私がメインでプログラムを書く機会というのは減って来ている。
どちらかというとチェックする側に立っているわけで、文句を付けたい衝動に駆られる機会も多い。
ううむ、少し自信無くなって来たぞ

今日は一日、東京ビックサイトで行われた展示会イベントに行って来ました。
毎年行われているこのイベント。
時々見学に行く事はあったのですが、今回の目的は自社ブースへの接客要員としての参加です。

私自身、これまでこういう接客業務をやった経験を多く持っている訳ではないので、
実際には営業部メンバーのサポートに類する行動が主なものになります。
しかし、直接お客様（候補）とお話をする機会というのは、通常業務ではまず無く、
非常に貴重な経験になると考えて営業部に申し入れた訳です。

始まる前までは、何とかなると結構楽観的に考えていたものの、
実際に立ってみると、やはりなかなかうまく喋れないもの。
喋れないのはわかっていて、いかに相手から話を聞き出すか？だとはわかっていても出来ない。
本当は、開発している立場からお客様がどういうところを気にしているのかなど聞きたい事はあるのだが、
そこまで話を持って行く前段階でつまづいている。
そりゃ、通常の営業メンバーが行うようなデモの流れに関して何かしらレクチャーされた訳でもないのだから、後から考えてみると当然と言えば当然。
準備を怠った訳だ。

出来ないながらも、色々と考えなきゃ行けない収穫はあったと思う。
自社のブースが空いていて、他社のブースが混雑していればやっぱり悲しくなる。
どういう方向性を気にしてお客様は足を止めるのか。

想定ではない実際のお客様が気にしている内容にもっともっと耳を傾ける活動をして行かなければいけないですね。

リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす

posted with amazlet at 12.06.21

エリック・リース
日経BP社
売り上げランキング: 204

Amazon.co.jp で詳細を見る

昨日は久しぶりに、自宅に着いたら日付が変わっているという状態になってしまった。
原因はセットアップしているPCに入れた、アプリケーションがRuntime Errorを吐き出したためだ。

アプリケーションが出力する通常のエラーメッセージとは異なり、Runtime Errorが出力されるのは結構致命的。
今回は、自社で開発したアプリケーションではないとは言え、これまでも何度となく使った事のあるアプリケーション
だったので、プログラム的なバグというよりは環境周りに原因があるんでは・・・と考えたのだがわからない。

そもそも、環境周りも何も、モジュールをコピーしてしまえば動いてしまうくらい簡単な作りのようなので、
いざこういうエラーが出た時に疑う場所自体があまり思いつかないという状態で時間を浪費してしまっていました。

結局、原因としては設定ファイルのフォーマットが正しくなかったようだった。
実は完全な解決を待たずして、メドだけつけて終電の関係で一足先に帰ってしまったのだが。。。

それにしても、設定のミスとは言えRuntime Errorはないよな〜ってのが正直なところ。
一方で、自社製品に対しても必ずしも設定周りのエラーメッセージは優しい作りになっているとは言えない気がしている。
設定が誤っているのであれば、誤りを正してもらうのが本来の 方向性であり、いたずらにエラーを突きつけるだけでは意味が無い。

何のためにエラー処理なりを入れるのかを再度考えるいい機会なのかもしれない。

そう思ったが、そもそもこのアプリはエラー処理が何も入っていないから最終的にRuntime Errorなんて
引き起こしてしまったんだよな・・・
って思ったら、ちょっと悲しくなって来たけど見なかった事にする。

今日も、僕は元気です。

今年もWWDCが行われ、いくつかの発表が出ていました。
毎回の事ですが、ライブにはつき合わずに朝起きてから内容を確認するというのんびりスタイルです。

既にいくつかのサイトで、今回の発表内容には紹介されているのですが、
それほどインパクトのある発表でも無かったように感じました。

正直、OSに他社のサービスであるTwitterやらFacebookやらが統合されて行くのは
どうなんだろう？という気がしないでもないですし。

iPhoneやiPadで一躍有名になったRetinaディスプレイ。
それを搭載したMacBookProもリリースされました。
正直、ノートPCがRetinaである事に関してはそれほど魅力的には感じていないのですが、
iPhoneやiPadに搭載された当初もそう感じ、手にしたときは凄いと思ったのでまた新たな発見があるかもしれません。
そういう意味では手にしてみないとわからないですね。

最近、家に帰ってからパソコンに向かう時間がなかなかとれません。
そこで、往復の通勤時間中にノートパソコンを広げていじれないかな〜と、
何となく思っています。

そうなると、重要なのはパフォーマンス的なものよりは重量的なもの。
そういう面で見て行くと、MacBook ProよりはMacBook Airの方がいいのではないかと思っています。

Apple MacBook Air 1.6GHz Core i5/11.6/4G/128G/802.11n/BT/Thunderbolt MC969J/A

posted with amazlet at 12.06.13

アップル (2011-07-21)
売り上げランキング: 9836

Amazon.co.jp で詳細を見る

よく、”軽い！薄い！”と評判のMacBook Air。実際に手に取ってみた事は無いのですが、カタログ上のスペックを見ると重量は約1キロ。
軽いですね。

ちなみに、今現在私が持っているノートは東芝製のDynabook SS RX1という機種。

dynabook ss RX1
http://dynabook.com/pc/catalog/ss_c/070605rx/

よくよく見てみると、これの重量も約１キロだ。

んー。
こいつをもう少し有効利用しないと行けないってことかな？
iPadを購入してからと言うものの、普段使いとしては見向きもされなくなってしまった状態なので、
何かしらの利用価値をちゃんとつけてあげる事にしよう。

家のデスクトップとしてはiMacを使っていて、仮想環境としてはVirtualBoxを利用しています。
VMWare Fusionも考えてみたものの、家でシェアウェアを利用してまで仮想環境が必要になるかの
判断がつかなかったので、まずはVirtualBoxを使う事にしたのです。

Windows8のReleasePreviewがリリースされたので早速入れているのですが、
VirtualBoxが用意している解像度にはMetroで推奨しているようなワイドスクリーンが選択肢にありません

そのため、Metroアプリを使っている時、ワイドスクリーンであれば右端に続きが表示されるはずのアプリでも
特に何も出てこず、続きがあるのかどうかがわかりません。
もっと言うならば、縦にスクロールするのか横にスクロールするのかがわからないのです。

これは、縦スクロールに慣れている人にとっては実際に動かしてみると横に動いて行くので
ものすごい違和感を感じる事になると思います。

VirtualBoxは無料だからしょうがないかな〜と思っていたのですが、調べてみると
解像度はデフォルトで用意されているもの意外でもコマンドで自由に追加する事が出来るみたいです

Custom Resolutions in VirtualBox
https://mknowles.com.au/wordpress/2009/05/07/custom-resolutions-in-virtualbox/

さっそく、ターミナルを起動してコマンドを実行します。
まずは、Windows8で最低限として推奨されている1366×800を追加してみる事にします。

vboxmanage setextradata “名前” CustomVideoMode1 1366x768x32

“名前”には仮想PC名を大文字小文字を意識して入力する事になります。
また、仮想PCを起動している時にコマンドを実行した場合には一度シャットダウンして起動し直す必要がありました。

起動し直すと、確かに解像度の選択肢が追加されています。

ニュースアプリもちゃんと続きが出て、横方向への誘導が出来ている事がわかります。

解像度が自由に追加出来るのであれば、遊ぼうぜ！って事でWindowsPhone 8を意識して480×800の解像度を追加してみたのですが、
コマンドは正常に動作したもののWindows8上の解像度一覧には出てきませんでした。

Windows8はやはりARM版じゃないとそのままこの解像度に載っける事は出来ないのかな？それともVirtualBox側の問題だろうか？

最近、いくつかの開発者向けPodcastを聞き始めています
きっかけになったのは@kmizuさんのツイート

ちなみに、Scala TypesのPodcast は scalatypes.com からダウンロードできます。インタビュー対象の人もScalaのあのライブラリの作者とかTypesafeの中の人(cont) tl.gd/hille3

— Kota Mizushimaさん (@kmizu) 5月 26, 2012

実際に調べてみると、結構多くのPodcastがあるんですよね。
いや、ある事自体は何となく知っていたのですが、探そうとしていませんでした。

思い立ったが吉日と言うことで、早速いくつかを購読してみています。
現在の購読対象としては

This Developer Life
http://thisdeveloperslife.com/

 The Basement Coders
http://basementcoders.com/

The Scala Types
http://scalatypes.com/

選んだ基準というのは特になく、ほぼ何となくです。
はっきり言って、英語力はさっぱりな状態なんですが、耳をこらしているとそれなりに知っている単語がチラホラ出てきます。
言ってしまえばその程度なので、あまり本文の内容が理解出来ておらず、これらのPodcastをお勧め出来るものかと言うことに関しては
正直わからないというのがあります。

欲を言えば、Podcastの中身がテキストに起こされていれば、技術の勉強としては役に立つのですが、
残念ながらそんなモノは期待出来ません。

それでも聞いて意味があると思うのは

• 技術系の言葉なら何となくわかるんじゃないか？
• 何となくわかれば、話題によってはよりわかろうとしてしっかり聞くのでは
• 英語と技術が勉強出来てスバラシー
• 技術用語で、本当のところなんて発音されているのかわからないのがわかる

と言うことがあげられます。
この最後の発音。いやいや、なかなかバカに出来ないですよ。
Scalaの話題を出した時に、自信満々に「それはスカラじゃなくてスケイラって読むんですよ！（ドヤ」とされた事ありますし。
実際、発音だけじゃなくてイントネーションを含めると結構和製英語のような状態になっている事が多いです。
知っている人からすれば、ちょっと恥ずかしいかも。

もちろん、内容がよければよいにこした事が無いと思うので、何かしらお勧めのPodcastがあれば ご紹介ください。