ソフトウェア開発」カテゴリーアーカイブ

Kindle のニューモデル!

Kindle のニューモデルが発表され、現在予約受付中です。

Kindle Paperwhite(ニューモデル)
Amazon (2013-10-22)
売り上げランキング: 2

ずっと見合わせていましたが、ついに購入する事にして予約しました!
Kindle が日本で発売される以前から欲しいと思っていたものの、電子書籍への対応状況が
余りに微妙すぎて購入をためらっていました。

今回、購入に踏み切ったのはいい加減に欲しくなってきたのもありますが、こんなサービスが始まるのが決め手になりました。

Kindleオーナー ライブラリー
http://www.amazon.co.jp/gp/feature.html/ref=sa_menu_kds?ie=UTF8&docId=3077704816
Amazonプライムにご加入で、Kindle端末をお持ちのお客様は、ベストセラーやコミックを含む数千冊の対象タイトルの中からお好きな本を、一か月に1冊 無料でお読みいただけます。

私はそれほど読書スピードが早い訳ではなく、往復の通勤時間がメインの読書時間となります。
それらを考えると、月一冊貸し出し可能であれば、結構十分な気がします。
プライムサービスへの加入が条件になりますが、年会費3900円なので突き当たり325円。
325円以上の本を借りれば十分元が取れるので問題ないでしょう。

技術書になると、後で読み返したくもなるとは思うのでこの利用方法からは外れそうですが、
それ以外の新書などを借りる事になりそうです。

発売予定日は10月の22日と、まだ一ヶ月以上先なのでちょっと気持ちが先行してしまっています。
楽しみだ〜

Leap Motion で遊べるWebアプリ(ゲーム)

Leap Motionからのメールで紹介されていたゲームが中々凄かった

Hello Run
http://hellorun.helloenjoy.com/?utm_source=Leap+Motion+Newsletter&utm_campaign=496b6c2a71-Consumer_Newsletter_12&utm_medium=email&utm_term=0_f0a6fbd89e-496b6c2a71-60371365

ゲームの内容そのものは、最初さっぱり意味が分からなかったけど、
簡単に言えば障害物競走のようなもので、手を上下させて障害物をどこまで
よける事が出来るのか?という単純なもの。

音楽がなかなかかっこいい

Flashとかではなく、純粋にHtml, JavaScript でここまでのゲームを作れると言うのもいいし、
思った以上にLeap MotionをWebアプリに組み込んでも軽快に動いている。

軽快に動いていると言っても、Leap Motion で行っているのは上下の動きだけで、
ジェスチャーやその他諸々の動きを処理していたらこうは行かなかったのではないだろうかとも思う。
とはいえ、クライアントのスペックにもよるが、やはりMotion Capture は面白い。

そして中々うまく行かない。
以下に人間の動きが安定しないのかがよくわかる。
また、空中で何も持たずに静止させると言うのは疲れるものだ。

3Dのホログラムでもあればもう少し感覚が違うのだろうか。
そういう意味ではGoogle Glass なんかとの組み合わせが出来れば
ARと合わせて世界が変わるかもしれないなぁ

Visual Studio 2013 Preview でハブアプリを触ってみた

先日行われたMicrosoft Technical Days で、幾つかストアアプリを見ていて
少し作ってみたくなったので、Virtual Box のWindows 8.1 環境にVS2013 Preview を入れてみた

 

これまでのストアアプリ作成用テンプレートに、ハブアプリが加えられている。

 

イメージしているアプリの形はハブアプリなので、迷わずこれを選択。
ちなみに私のC#知識量は0と言っても過言ではないが気にしない!!!!

とりあえず、何も考えずにビルドして実行してみる。
以前、同じように2012の Preview を触った時はテンプレートに
サンプルのデータがふくまれていてそれっぽく見えていたので、
まずはそちらを確認しようと思ったからだ。

ところがどっこい、いきなりエラーでつまづく。

まだ特に何もいじってないにもかかわらず、このいきなりのエラーっぷりが
いかにもβ版という雰囲気を醸し出し、知識量0の私を多いに幻滅させる。

正直、エラーメッセージが何を言ってんだか分からん。

とりあえず、何となくXAML上の記述がおかしくてParseがこけたんだろうと思い、
XAMLを開いてみるとあからさまに「XAMLが無効です」と書かれている場所が。

はっきり言って、何が問題なのかは読んでもよくわからないので、探索的手法をとる。
エラーとなっている箇所を絞り込むために、あれこれやっているとどうやら”x:Uid”に関する
記述が問題なように見える。

x:Uid ディレクティブ(WPF)
http://msdn.microsoft.com/ja-jp/library/vstudio/bb613571.aspx

自動生成された “x:Uid” ディレクティブが、重複しているモノがあるのが原因かと思い、
重複を排除してみたが結果は変わらず。

実は、”x:Uid” は関係ないのではないだろうか?と思い、今度は HubSection を削ったりしてみたら、最終的にはやはり “x:Uid” に原因がある事が分かった。

とりあえず、すべての x:Uid ディレクティブを削除してしまう事でハブアプリを動かす事が出来た。

よくよく x:Uid ディレクティブを見てみると、参照したWPFのXAMLの説明と次に示すストアアプリの説明とでは異なっていた

http://msdn.microsoft.com/ja-jp/library/windows/apps/hh758297.aspx
Windows ランタイム XAML での x:Uid の一意性の規則は、以前使われていた XAML を利用したテクノロジと比べると、いくらか異なります。Windows ランタイム XAML では、複数の XAML 要素上で同一の x:Uid ID 値がディレクティブとして存在することは正当とされています。

となっていて、重複そのものは問題が無くなっているように見える。
まぁ、そもそも重複と言うよりは、一つでもあるとうまく動かなかったわけなので、どちら下というと x:Uid ディレクティブの機能がそもそも有効になっていないという風に考えるのが正しい気がする。

気になって、グリッドアプリケーションのテンプレートを見てみたが、こちらにはそもそも x:Uid ディレクティブがついていない。
このディレクティブが、ローカライズを目的とした記述であるならばアプリケーションのスタイルによって要・不要が変わるものでもないように思えるのだが。
比較的新しい概念なんだろうか?

うーん、先は長そうだ

Leap Motion User Experience Guidlines の訳

Web上のページでは見つける事が出来なかったのだが、SDKには User Experience Guidlines がついてくる。
Leap Motion の障壁としては、やはりどれだけ操作を楽に行う事が出来るのか。
そのために開発者が何を考えるべき(知っておくべき)なのかが書かれている。

英語に関してはからっきし自信は無いが、適当に日本語訳してみる。

Keep in mind that symbology can be difficult to learn and memorize.
Avoid forcing users to learn complex hand gestures to interact with your application.

記号と言うものは学習したり覚えたりするのが難しいと言うことを覚えておきなさい。
あなたのアプリケーションで、ユーザーに厳密なジェスチャーを矯正するのは避けなさい

Instead, draw inspiration from physical interaction and real-world behaviors.
The more physically inspired interactions are, the less training a person needs and the more intuitive and natural your application feels.

その代わり、自然な操作や、現実世界の振る舞いから着想しなさい。
本当に自然な操作と言うものは、トレーニングを必要とせず、より直感的に、より自然に感じられるものでしょう

Don’t feel constrained by the limitations or inconveniences of the real-world — this is your world.
Interaction doesn’t have to be the way it has always been. It can be any way we imagine it to be. Why force the user to reach all the way out and grab an object? Why not have the object reach back? — Give them “the force”!

現実世界の制限や不便さを持ち込む必要はありません。これはあなたの世界なのですから。
操作は決められたものである必要はありません。それは、私たちがイメージしたように出来るのです。なぜユーザーにブジェクトをつかみ取る事を強制するのですか?なぜオブジェクトを引き寄せないのですか?力を与えてあげてください

The user should feel as if their intent is amplified rather than subdued or masked.
For example, users often like their movements to be amplified when using a mouse (i.e. they don’t need 10 inches of mouse movement to move 10 inches on screen). For gestural interactions, amplifying or exaggerating responses can have an even more positive result. Keep in mind that some people are more sensitive than others, so link this exaggeration to a sensitivity setting for users to modify this effect to their preference.

ユーザーは、彼らの意図が増幅されていると言うよりむしろ地味に、またはマスクされているように感じるでしょう。
例えば、ユーザーはマウスを使っている時に、意図が増幅されている事が好きです(10インチモニタ上を動かす時に10インチマウスを動かす必要が無いように)。ジェスチャー操作の場合、増幅または誇張されたレスポンスは、ポジティブな結果を産みます。何人かの人たちは、他の人々よりもとても敏感だと覚えておいてください。なので、これらの効果は、彼らに合わせた形へ設定変更出来るようリンクを貼りましょう。

Concentrate on giving the user dynamic feedback to their actions. The more feedback they have, the more precisely they can interact with your software.
For example, the user will need to know when they are “pushing” a button, but can be more effective if they can see when they are hovering over a button, or how much they are pressing it.

ユーザーの行動からフィードバックを得る事に集中しましょう。多くのフィードバックによってあなたのソフトウェアで彼らは正確な操作を得る事が出来ます
例えば、ユーザーは自分たちがいつボタンを押したのかを知る必要がありますが、もし、ボタン上をホバーしているのが見えたり、どれくらい押しているのかが見えたりすればより効果が上がります。

On screen visuals (such as representations of hands, tools, or digital feedback) should be simple, functional, and non-intrusive.
The user should not be distracted from the task by their tools or environment. Decoration should not distract from your purpose.

画面上の見た目(手やツール、デジタルフィードバックに代表されるような)はシンプルで機能的で、そして邪魔にならないようなものであるべきです。
ツールや環境によって、彼らの作業が邪魔されないようにするべきです。あなたの趣旨によって装飾するべきではありません。

Require more deliberate action for destructive or non-reversible acts than for harmless ones.
Subtle gestures should be reserved for subtle actions. Conversely, an act such as closing an application or deleting a file can be a non-reversible event requiring a more deliberate action. Double check with the user when unsure, such as a prompt for confirmation.

無害なものよりも、破壊的もしくは不可逆な行動と言うものによりゆっくりとした動作を求めるべきです。
目立たないジェスチャーは目立たない動作へ割り当てるべきです。逆に、アプリケーションの終了やファイルの削除のように不可逆なイベントにはより確証がなかったりする場合は、確認プロンプトを出すなどして2重のチェックを行うべきです

Provide a clear delineation and specific sense of modality between acts of navigation and interaction, unless both are simple or one is handled automatically (or with assistance). Mixing the two in a complex situation can lead to confusion or disorientation.
For example, moving an object while having the user simultaneously position their viewing angle inside a 3D environment is inherently difficult. However, if the viewing angle moves automatically in response to the user’s movement, then working with the object is easier. Likewise, when navigating a large data set the user will want the view to move easily, but when highlighting a portion of the data the view should remain still.

ナビゲーションや操作がシンプルだったり自動的だったりしない限り、明確な線引きを提供出来るだろう。複雑な2つの状況が重なりは、混乱や方向感の喪失へと繋がります。
例えば、ユーザーは3D環境で、同時にアングルと位置決めを行う事は本質的に困難です。しかしながら、アングルが動作によって自動的に変わってくれれば、オブジェクトを動かす事は容易になります。同様に、大きなデータを扱う場合、ユーザーは容易にビューが動いてくれる事を望みますが、データの一部を強調させたい場合には、ビューは固定されるべきです。

Overall, imagine that your user is faced with no instructions or tutorials on how to use your application.
Strive at all costs to make their first intuitive guesses the right ones. Where appropriate, create more than one proper way to do something.

あなたのアプリケーションを使うとき、ユーザーが操作に対するチュートリアルや説明が無い場面に出くわす事を想像してみてください。
ユーザーによる直感的な推測が正しいものとなるように力を尽くしなさい。場合によっては、成し遂げるためのよりよい方法を作り出しましょう。

(LeapSDK/docs/GetStarted/Leap_UX_Guidelines.html)

 

いやー。英語力の無さになんだかがっかりしてしまうがしょうがない。
相当、怪しい訳になってしまったので突っ込みどころ満載だと思うので指摘をお願いします。

ほんと、訳をやってる人は凄いわ。
私も修行つまないといけませんね。

Leap Motion コントローラーの置き場

SDK付属のサンプルアプリケーション「Touch Emulation」をとりあえず作ってみた

Airspaceに最初からついてくるOrientationアプリケーションでも分かる事なのだが、実際にどういう風に認識されるのか。
ジェスチャー毎にサンプルで見てみると検出がうまく行っていなかったりする事がよくわかる。

とりわけ、Google Earthで苦労した、「手のひらを飛行機に見立てて動かす」と言うことがうまく行っていないのが分かる気がした。
気を抜くとすぐに指の位置がばらついてしまったり傾いてしまったりするのだ。

アプリケーションでどういう操作をするのかで置き場を変える

なんで水平に手がならないのかを考えてみればすぐに分かった。

もちろん、単純に水平にする事が難しいと言うのもあるんだろうけど、私の場合はLeap Motion のコントローラーを体の中心線上に。
つまり、左右の手の真ん中においているからなのだ。

その状態で、片手を真ん中に持ってきて水平をしようとすれば無理が出る。
マウスをどちらの手で使うかは別にしても、使う手の方にマウスは置く。
であれば、Leap Motion のセンサーも使う手の真下に来る形に配置してあげればいいわけだ。

Leap Motion の場合、アプリケーションによっては片手ではなく両手を使って操作をすることもあるので、アプリケーションで必要とするジェスチャーによって、センサーの位置を調整するほうがいいように感じる。

というか、そういう調整によって操作性が著しく変わるのであれば、アプリケーション側でそういうナビゲーションをした方がいいのかな?
でも、一々マウスの配置を指定するようなアプリケーションは邪魔臭いだろうし。

うまく認識しない時の、ヘルプというかアドバイス機能と言った所だろうか。

色々と使ってみると、ちょっとした発見があって面白いですね

Leap Motion アプリあれこれ

妻に「これすごいでしょー!」って見せたんだけど、
「何に使うの?家でプレゼンでもするの?」
って、そそくさとPCの前を去られました。

悔しいので Leap Motion でいくつかのアプリを動かしてみたので備忘録代わりに書いておく

LeapMotionのアプリケーションは、専用のランチャーであるAirspaceにまとめられる。

アプリケーションはAirspace Storeで取得する事が出来る

MacとWindowsの対応状況を確認して入手することになります。

ゲームや地図アプリケーション

Google Earth では手のひらを飛行機のように見立てて3D空間の中を移動する事が出来る。これは体験としてはとても面白いもの。
これに慣れてしまうとマウス操作での3Dマップ移動はとてももどかしく感じてしまうのではないかと思えてしまう位楽しい。

ただ、現状では操作に少し熟練を要する。

やってみると分かるのだが、思ったように移動が出来ずにクルクルと回ってしまったりする。手のひらを見ながらであれば、ある程度水平に保つ事が出来るが画面を見ながらだとこれが意外と難しい。

Boom Ball では指差しによるブロック崩しを楽しむ事が出来るが、これも思ったように動かす事が出来ない。
ゲームで息抜きするはずが、逆にストレスをためてしまいそうだ

Boom Ball に関しては、下方向からだけのセンサーで扱うには少し厳しいのではないかと思ってしまった。Google Earth は慣れればそれなりに動かす事が出来る。

ただ、何れにしてもずっとアプリケーションを動かしていると意外と手が疲れる。
この辺りは、もう少し体験に慣れて気持ちが落ち着けば、疲れの感じ方も変わるのかもしれないけれど。

プレゼンテーション

タッチと異なり、奥行きの操作が出来るので、やはりLeap Motion で3Dは外せないだろう。
そう考えると、ゲームやマップの移動以外では、3D模型のプレゼンテーションに使える

Cyber Science – Motion 

や、Molecules 

は、まさにそういうアプリケーションだ。
拡大や縮小。方向転換を容易に行う事が出来るので、平面の教科書で勉強するのとはだいぶ違ってくる。

こういう使い方であれば、常にLeap Motionを操作し続けるわけでもないだろうし、それほど操作が複雑にはならないので受入れやすそうに感じる。

3D以外

奥行きがあるのでどうしても3Dアプリケーションに意味を求めてしまいたくなるが、単純にジェスチャーによる操作が出来ると考えてしまえば通常のアプリケーションへも適用できる

 

これはNYTimesのニュースアプリ。
同じように、Facebook のPhotoアプリもある

私はFacebookにろくに写真をアップロードしないので何も面白くなかったけれど、まぁ、誰かと話をしながら見る分には面白く使えるのかもしれないな

何のジェスチャーにどの操作を割り当てるのかは結構考えどころだ。
それに関しては、また今度に。

Leap Motionがやってきた

水曜日に発注したLeap Motionがようやく到着しました!

パッケージや梱包は、なんだかAppleを思い起こさせるような外観ですね。
妻が「またよくわからないものを・・・」と怪訝そうな顔で見てきましたが、
気にせずに行きます

 

本体をUSB接続したところ。
真ん中と両脇でセンサーが光っているのが分かりますね。

 

早速いくつかアプリケーションを試してみました。
写真はGoogle Earthを手のひらで動かしている所。

まだ、触り始めたばかりなので何とも言えない所ですが、
センサーがあくまで下から出ているので、水平方向の認識はそれなりにするけど、
垂直方向に少し傾けてしまうと思ったように認識してくれなかったり、難しく感じる場面が多いです。

この辺り、他のアプリケーションを動かしてみながらもう少しまとめられればと思います。

 

Leap Motionが楽しそう

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

まぁそれはさておき、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のログを追いかけてみたり、関係各所に調査を打診したり
カウンタの値を見ながら原因を推察したり。

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

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

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

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

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

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

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

表題の本を読んだ

テストから見えてくるグーグルのソフトウェア開発
ジェームズ・ウィテカー ジェーソン・アーボン ジェフ・キャローロ
日経BP社
売り上げランキング: 1,971

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

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

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

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

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

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

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