予定では二日間でしたが、急遽一日追加して三日間。
北海道へ出張してきました。
幸い出張中は天候がよく、冬の北海道の割に準備したホッカイロも使う事なく
純粋に仕事に集中する事が出来ました。
ええ、観光なんてする暇が全くないくらいに。
残念ながら。。。。
今回、久しぶりのお客様先への出張だった訳ですが、
やはり実際の現場に出ると色々勉強になりますね。
開発者となると、今は基本的に会社でPCとにらめっこしている事が多いですが、
こうやって外に出る事で開発者以外の人の動きと言うものが見えてきて勉強になります。
開発が出来ない技術者と言うのは困り者ですが、実際の製品は開発者以外の人も関わっている訳で、そういった人やお客様の現場を知る機会は大切にしていきたいところ。
もちろん、今回赴いた目的はトラブルの収束だったので、そんな機会は増やしたくはないですが、
自分に足りないところを気づかされる機会と言うのはいいものですね。
多少胃がキリキリする思いでしたが。
参っちゃうよね、まだまだ成長出来ちゃうじゃん
mongoUnivで出されている課題があって、言語としてはpythonを使っている訳なのですが、
結構煮詰まってました。
感覚的には通りそうなコードで、ネットで見てみても行けそうな気はするけれど
うまく実行出来ない。
うわー。うわー。
mongoDBでつまづくならまだしも、pythonでかーと思って何度となく見返してみたら。。。。
単純にif文に”:”がついてなかっただけという悲しいオチが。
IDEを使っていれば、もう少しエラーの原因を早くつかむ事が出来たんでしょうけど、
この辺りでつまづくあたりがちょっと情けなくも、手になじんでいない感が強いですね。
精進せねば。
ドットインストールの話題を先日エントリーしたが、それとは別にMongoDBを勉強している。
今は、その製品名がそのまま会社の名前になっているが、10genが手がけているオンライン学習サイトがあるのだ
https://education.mongodb.com/
本家が手がけているだけあって、体系だって学ぶことが出来る。
さらに、ビデオは日本語訳をつけてみることも可能だ。
実はこのMongoDB University は比較的最近始まったばかりで、まだこれからと言うところもある。
それでもいくつかのコースを始めることが出来る。
それほど難しいわけではないのだが、序盤は少し放置してしまって、取り戻すのに時間がかかってしまった。
何とか今は授業に追いついているので、最後（10/28）までなんとか続けて行きたい。
先に紹介したドットインストールと違って、こういうオンライン学習は開始と終了の日程がはっきりいしている。
Coursera や edX と同じですね。
これらのようなMOOC（Massive open online course）は少し敷居が高い。
両方とも登録してはいるのですが、長続きしていないです。
でも、色々な選択肢を私たちに提供してくれる。
問題は･・・1時間以上のビデオを家で見るとなると眠くなってしまうんだよなぁ･･･。
これも大学の講義と同じですね。
最近、通勤時間も延びたことなのであき時間を利用して何か始められないかな～と、
ここを物色している
ドットインストール
http://dotinstall.com
一つの動画が3分程度なので、ちょっとした空き時間に見ることが出来る。
基本的には見るだけなので、深い勉強にはつながらないけど、さわりを学ぶにはちょうどいい感じだ。
これまで、そういう役目は書籍が担ってきていた。
そう、たとえばWeb+DB Press とかそういう類だ。
定期的に、自分の視界範囲外の話題を手に入れるのは面白く、
これまでは時々これらの本を購入してきた。
ただ、興味を持ったとしてもあくまでその先に進むにはこれらの本ではぜんぜん足りず、
掲載されているサンプルを動かす以上のことをしようとするには難しい。
対象の技術に関してネットを探せばそれなりに記事は見つかるけど、体系的に学ぶのには
紙面の関係上足りない。
ドットインストールのようなオンライン学習が全てをカバーするなんて寝ぼけたことを言うわけではないけど、動画で見る分なのか、教え方がいいからなのか、わかりやすく感じる。
紙面上の制約を考える必要がないので、分量も申し分ない。
新着やコースの人気度をみれば、今の話題性がなんとなくわかる。
何より、他のリソースに対してのリンクを張りやすいので色々と幅が広がるように感じる。
見ていると、どうしてもキーボードでコードを打ちたくなってしまうが、主に通勤中に見ているので
それが出来ないのがちょっと現在は悩みどころ。
ノートPCを新調して移動中に使えるようにしたいような、、、、
うーん、Surfaceは電車のような場所で使うのは難しそうだからちょっと悩んじゃうな
世間ではお盆だそうです。
お盆ってなんでしたっけ。
あぁ、通勤電車が不思議と空いていて快適に会社に行けるラッキーな期間の事ですよね！
確か５月にも似たような期間があった気がしますが。
まぁそれはさておき、Facebookのタイムライン見ていたら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のログを追いかけてみたり、関係各所に調査を打診したり
カウンタの値を見ながら原因を推察したり。
何となく原因説明のストーリーは立てられなくもないけど、それを裏付けるには
トラブル発生時の状況を示すための資料が足りない。
足りていない部分をあれこれと推察しながら資料を作っていくことになります。
不謹慎ながら、こういう技術系の調査や原因の究明に頭を使うのって楽しいんですよね。
それは多分、原因を調べていく過程で、これまで把握していなかった知見を得ることが出来たり、
推測をデータで裏付けていくことが出来た時にすっきりするからなのかもしれません。
でも、ぶっちゃけてしまうとどれだけ考えても明確な裏付けを持たせることが難しい場合もあるし、
こうやって考えたりしている時間は短ければ短いほどいい。
なぜならば、こういうことに時間をかけていても、その時間で価値を生み出している訳ではないから。
本来は、もっと価値を生み出すことに時間を費やし、そこに楽しさを見いださなければ行けない。
そこが中途半端だったりするから楽しく感じてしまうのかもしれないな。
と言う訳で、障害からの復旧をいかに手をかけずに効率よく行えるのかをもう少し真剣に考えてみることにする。
え？障害が起きないように頑張れ？
そんな夢、見てらんないよ
表題の本を読んだ
本書は、Googleにおけるテストの考え方やテストの実践を通して、Googleにおけるソフトウェア開発や思想を紹介しているのであって、テストの仕方を学ぶものではない。
もちろん、Googleという巨大企業がどういうテスト体制というか、ソフトウェア開発体制をしいているのかということは知ることが出来る。
そこから展開できることも多くあるのだが、考え方は参考になってもやり方はまねできるものは少ない印象を受けた。
私は開発の現場を多く知っている訳ではないので、知っている世界と言うものはたいへん狭い。
なので、どういう開発体制が一般的なのか？ということに関して語る言葉を持たない。
しかし、開発の現場によってどういうメンバーがいるのかと言うのは大きく変わっていくんだと思う。
テスターと呼ばれる専門メンバーを用意できる体制もあれば、仕様検討と設計、コーディングが完全に別れている体制もある。
何がベストかは結局の所何を開発するのかにもよるだろうし、ベストと思われる方法があったとしても、会社の経済的な理由やリソースが足りないこともよくある話だ。
結局の所、その場その場で考えて動くしか無いという結論になってしまうのかもしれない。
ただ、だからこそ、こういった様々な事例をインプットしておくのは必要なことだと思う。
実践できるかどうかは別として、中々面白く読むことが出来た。
思わずGoogleに入りたくなるくらいだ（門前払いが確定しているが）
テスターという位置づけを確保することは、ちと難しいかもしれないが、
それでも持ち回りでそういうことを意識する役割を設けてみるのも面白いかもしれない。
なんて思った。
これまで、職場では基本的にJINS PCをかけていて、家ではそれほど多くの時間をPCの前にいないので裸眼でした。
週末だけ、家にもってかえって着用するような形です。
それはそれで何とかなっているのですが、最近、少しずつ家でのPCに向き合う時間が馬鹿にならない気がしていてもう一つ欲しいと思っていました。
と言う訳で、少しお出かけした際に購入。
写真の奥においてあるのが今までのもの。
今回買ったのは、手前の「メタルスクエア」というタイプ。
見てわかるように、これまでのものよりフレームが細いです。
私のように、元々メガネをかけていない人間にはメガネをかける事自体が少しストレスです。
なので、少しでも軽くてフレームが気にならないタイプの方がいいのではないかな？と思った次第です。
1週間ほど会社で着用してみましたが、正直どれほど効果があるかは思っていた以上にわかりませんでした。
自分でも思っていた以上にメガネに慣れてしまっていたのかもしれません。
それよりも困ったのはメガネケース。
以前購入した際は、プラスチックのケースが付属されていたのですが、今は布で出来たソフトケースだけのようです。
これは持ち運びにはとても怖くて使えません。
と言う訳で、以前購入した際についていたケースを会社用に。
家で使う用にソフトケースを、と言う形で入れ替えて使うことにしました。
体感することの無いJINS PCの効果ですが、体感してからでは遅いってのもあるとは思うので、暫くはつき合ってみようと思っています。
お客さん先で、不可解な現象が発生していてその調査をしています。
実際問題、アプリケーションの問題と言うよりはインフラ。
特にネットワークの問題である可能性が高いのですが、
そこまで完全に決めつけるには一貫性ある説明が出来ない苦しい状況。
さてはて。困ったな。
今回に限った話ではないけれど、トラブルの原因がネットワークや
それに類する機材にあった場合の原因の切り分けは骨が折れる。
よく、ネットワークモニター等を利用してパケットの流れは確認し、
問題が起きている事はわかる。
ただ、それがどこで起きているのか。
何が原因で発生しているのかを突き止めるのは地道な作業になる。
ロジックとして説明出来る事もあれば、機器の故障で本当に不可解な現象が発生して、
機器を交換して初めて「この機材が原因だ」とわかる事もある。
もちろん、ネットワークに対する知識が足りずにそういう判断しか出来ないという話もあるのだが、
この分野だけはどれだけ勉強しても”詳しい”と言えないような気がするなぁ
少し前にオルタナティブブログにてこんな記事を見かけた
実際にあった怖いバグ票（バグレポート）
http://blogs.itmedia.co.jp/morisaki/2012/08/post-a506.html?ref=rssall
見ながら、「あ〜、あるある」と思った節が何度となくあった。
指摘している内容や、考えている方向性だったりするものはしっかりとしていて、
それ自体は本当は評価されるべき内容なのにも関わらず、
最後に余計な一言が書いてあるせいで読み手にものすごい不快感を与えている。
それでいて、その人にとってはその一言こそが言いたい事だと考えている。
そこがまた一際厄介なんですよね。
言っている事がわからなくはない。
背景を教育しなければ、今回の問題はクリアされてもまた別の形で現れるかもしれない。
ただ、それはバグ票という媒体の役目かというとちょっと違う気もする。
その辺りの交通整理を、プログラマ以外の人に対してもわかる形で行えるようにならなければダメだと思う反面、
自分自身がそういう動きをとっていないかを気をつける必要がある。
なんだかんだ言って、私がメインでプログラムを書く機会というのは減って来ている。
どちらかというとチェックする側に立っているわけで、文句を付けたい衝動に駆られる機会も多い。
ううむ、少し自信無くなって来たぞ