世間ではお盆だそうです。
お盆ってなんでしたっけ。
あぁ、通勤電車が不思議と空いていて快適に会社に行けるラッキーな期間の事ですよね！
確か５月にも似たような期間があった気がしますが。

まぁそれはさておき、Facebookのタイムライン見ていたらLeap Motionの記事がシェアされていた。

Leap Motion

以前、何かの記事で軽くは見た事はあったんだけど、今読み返してみるとかなり面白そう。

Leap Motion
https://www.leapmotion.com/

初めてのLeap Motion開発
http://www.buildinsider.net/small/leapmotioncpp/01

簡易版のKinectみたいな感じだけど、普通のPC操作においてKinectのように全体をとらえる必要性ってそれほどなくて、Leap Motion くらいがちょうどいいように思う。

以前、Kinectを医療現場で使っているような動画があったけど、タッチすらし辛い環境と言うものはやっぱりあって、色々と使える場面はありそうな気がする

ただ、ジェスチャーでモノを動かすと言うのは結構難しいはず。
それほど人間の動きは安定しては無いので、思ったように動かなかったり誤作動したりする
懸念はありそう。
ただ、この辺りはやってみないと分かんないと言えば分かんない。

ちなみに、本家から購入すると10,500円かかる。
Amazonで見てみると15,980円。
随分と高い手間賃だなぁ

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

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 で詳細を見る