RSS

素人の Per-Monitor DPI

先日、開発用のデスクトップPCを新調しました。その際に、話題の4KモニターDell UP2414Qを追加しました。

dell-up2414q-overview1

T221と比較してDisplayPortで接続出来るので、母艦のインターフェイスに悩まなくても済みます(実際は悩んだんですが、それはまた別の機会に)。また、60Hz行けるのが良い点です。

で、これをUXGAのL200Pと縦に並べました。

PerMonitorDPI1

下がUP2414Q、上がL200Pです。ここからが面白い。
Internet Explorerを下から上にドラッグして移動します。

PerMonitorDPI2

2台のモニターは解像度が違い過ぎるため、ドラッグ中のウインドウがL200P側ではみ出てしまっています。また、解像度が低い分、IE上のテキストや画像も物理的に大きく表示されています。ただ、違和感はありません。元々解像度が違う事を分かっているので、大きくなってしまうことは予想出来ます。そして…

PerMonitorDPI3

L200P側に半分以上?移動すると、このようになります。一瞬、「えっ?」と思うのですが、いきなりIE内のコンテンツが縮小され、しかし、ウインドウの外郭のサイズは変わらないため、妙に縮まって見えます。

これは、「Per-Monitor DPI」というやつかな。どれどれ、実測してみるか。

PerMonitorDPI4

UP2414Q

PerMonitorDPI5

L200P

少しサイズが違いますが、おおむね同じサイズとなるように、ピクセルが縮小されているようです。サイズが違うのは、L200PからDPIが供給されていない可能性があると思います。

さて、コンテンツだけを注目すると、非常に良い機能です。が、この「コレジャナイ」的な違和感… ウインドウの外郭も縮小されたらパーフェクトだったかもしれません。

… いやいや、本当にそうだろうか?

ウインドウの外郭クロームは、ずっと固定的なピクセルサイズを基準に運用されてきたので、今更これが変わるのは微妙かもしれません(見れないので分かりませんが)。

ウインドウの外郭に違和感を感じるのなら、ストアアプリならどうかなと思い、テストしてみました。

PerMonitorDPI6

UP2414Q

PerMonitorDPI7

L200P

これは素晴らしい!同じアプリケーションでありながら、極端に異なる解像度のモニターでも、表面的な違いはほとんどありません。そして、4Kモニターであれば、細かい文字も美しく描画されています。

PerMonitorDPI9

UP2414Q

PerMonitorDPI8

L200P

もちろん、デスクトップアプリにおいても「最大化」して使用すれば、ストアアプリとほぼ同じ結果が得られます(Per-Monitor DPIに対応していれば、です)。

このような事もあり、両方のモニターを同じ目的で使うつもりだったのですが、L200P側ではストアアプリ(主にNeuroniaとFacebook)を動かしたままで配置し、4Kの方で通常の作業を行う、という使い方に落ち着きました。2画面(又はそれ以上)のモニターをどれも同じ目的で使おうと考えている場合は、やはり同じモニターで揃えたほうが良さそうですね。

なお、Per-Monitor DPIについては、以下の記事が参考になると思います。

4大(?)ブラウザーの High DPI 対応 (だるやなぎさん)
アプリの高DPI(High DPI)対応について 第1回 ~ 高DPIとは ~ (田中さん)

広告
 
コメントする

投稿者: : 2014/08/02 投稿先 .NET, Devices

 

Visual Studio 2012/2013 の拡張機能を紹介 (2)

何だか反響があるようなので、急いで書かなければ (;´Д`)
のっけからゆるい紹介です。


「Claudia IDE」

ClaudiaIDE

ClaudiaIDE_Settingsクラウディア窓辺さん、とは、…. いや、もう説明不要でしょう。殺伐としたIT業界の戦士たちを奮い立たせるため、Visual Studioのエディタ背景に舞い降ります。

エディタ内で活躍してもらうために、いくつかの設定が可能です。

クラウディアさん以外にも、プロ生ちゃんこと「暮井 慧」に舞い降りてもらう拡張機能もあります。こっちはアニメーションもしますよ。


「DevArt T4 Editor」

DevArtT4Editorpng

Visual StudioでT4テキストテンプレート(ビルド時にソースコードを生成できる、プリプロセッサベースのコード)を編集する場合の、コードハイライトやIntelliSenseっぽい補完機能が使えます。

T4を補助する拡張機能は他にもいろいろありますが、VSの濃色テーマ(スクリーンショットのような背景が暗いテーマ)選択時に、色が破綻していなかったので、これを使っています。もちろん、拡張機能が何もないと、とてもT4でコードを書く気になれません。


「Git Source Control Provider」

GitSourceControlProvider

Gitはソースコード管理システムの一種で、最近ではGitHubが知られるようになったので、ご存じの方も多いと思います。この拡張機能は、Visual Studio上でGitの操作が出来るようにするものです。

とは言っても、マイクロソフトもまたGitの拡張機能を公開していますし、ほかにも数種ありそうですが、謹製も含めてどれも今一つの出来です。ここで紹介した拡張機能は、その中でもまともな方かなと思います。

#この辺りは、こっちの記事でも紹介しましたので参考にどうぞ。私のお勧めは、残念ながら拡張機能ではなくSourceTreeです。


「Highlight all occurrences of selected word」

HighlightAllOccurrencesOfSelectedWord

もう、これが無いと生きていけない系です。

エディタで選択した単語と同じ単語を見つけ出し、リアルタイムで色を付けます。上の例では「value_」をダブルクリックしたところですが、エディタ上のすべての「values_」に緑色が付きます。

「単語なの?構文解析して意味的に同一なものじゃないのか?」と思う人も居るかもしれません。そういう機能もあればうれしいのですが、とにかく文字列一致でハイライトしてくれると良い点として:

  • C#に限らず、VBやXAML、C++など、テキストエディタ全てで有効なので、いつでも使える安心感がある。
  • 純粋に文字列を検索したい場合も、ままある。コメント上の単語や、リテラル文字列の単語など。

ということがあります。何よりイージーで効果が高いので、これが使えないとかなり痛いです。


「Java Language Support」

JavaLanguageSupport

基本、必要に迫られない限り、Javaでコードを書くことはあり得ないので、この拡張機能はスクリーンショットも取れなかったです。どうしてもソースコードを読みたい場合に備えて、ハイライト表示が出来るので入れてあります。

機能的にはデバッガも含まれているらしい(もちろん、Visual J++やJ#のようなモドキではなく、JVMで)ので、拡張機能としては気合が入っています。

今は、少なくともビルドやソースコード管理などを含めた、トータルでの開発環境として評価しなければ、真の価値は分からないと思うので、ここまでにしておきます。こう言う物もあるんだ的に捉えてもらえれば良いかなと。


「Productivity Power Tools」

ProductivityPowerTools

MS謹製のVS拡張機能です。VSの隙間を埋めます。この拡張機能、もうVSに取り込んでも良いんじゃないかと思うのですが…

かなり沢山の機能拡張が盛り込まれています。私のお気に入りとしては:

  • ソースコード保存時に、自動的にソースコード整形してくれる。また、C# usingの整理もやってくれる。まぁ、後者はやりすぎ感もあるので、オンにすべきかどうかは迷う所です。
  • ドキュメントタブを色分けして、ピン止め出来たりする。
  • スクロールバーに、編集箇所を色表示してくれる。
  • カラムタブ位置にガイドラインとなる線を引いてくれる。
  • 印刷時にソースコードの色付けをしてくれる。

などなどあります。勿論、人によって要不要は様々だと思うので、設定ダイアログから機能をオンにしたりオフにしたりして、自分なりにカスタマイズして下さい。

なお、リンクはVS2013用です。2012や2010用は同じ名前で別に存在するので、検索してください。


「RockMargin」

RockMargin

テキストエディタの縦スクロールバーが巨大になり、スクロールバーにテキストのサムネイル(?)が表示されます。青っぽく強調されている部分が、ビューに表示されているテキストの範囲です。

このブロードなバーはドラッグできて、それに合わせてビューがスクロールします。編集時には何となくソースコードの位置を「イメージ」で覚えておいて、ささっとスクロールさせる事ができます。

テキストエディタで如何に目的の場所に移動するかという事に注目した拡張機能はいくつかありますが、私はこれが一番直感的で素早く移動出来て良いと思います。

この拡張機能、ギャラリーではまだまだマイナー順位だったので、見つけたときには「掘り出し物みっけ!」と喜んでいたのですが、de:codeに参加したらエバンジェリストの方々がデモで皆使っていて、別の意味でがっくりしましたw


「SQL Server Compact Toolbox」

SQLServerCompactToolBox

Visual Studio 2012までは、SQL Server Compact Editionのデータベースファイル(*.sdf)を直接オープン出来、SQL Serverと遜色のない編集が可能だったのですが、2013になってオミットされてしまいました。

この拡張機能は、VS内でSQL Server Compactのデータベースを編集可能にします。ただ、まだ発展途上で機能も網羅されていないため、どうしても2012の編集可能である事と比較して、個人的には不満があります。

とはいえ、作者は結構頻繁にバージョンアップを繰り返しているので、徐々に問題も減ると思います。

余談ですが、面白い事に、Visual Studio User Voiceでも結構なvote数でCompact Editionの続投が入っています。

Support Sql Server Compact in Visual Studio 2013
Sql Server Compact 5


「Unit Test Generator」

UnitTestGenerator

Visual Studio 2010までは、MSTestを使用するユニットテストコードの生成が簡単に行える機能が内蔵されていたのですが、これまたVSから切り離されてしまった機能です。

今は、TFS ALM Rangersというプロジェクトでこの拡張機能がリリースされているのですが、VSから分離したというより、同じようなものを一から書き直しているようで、かなり機能が不足しています。

UnitTestGenerator_SettingsInternalsVisibleTo属性の自動適用や、プライメートメソッドへのアクセサコードの自動生成などがなく、非常にシンプルなテストコードの生成だけが出来る状態です。

本来、TDDではテストコードから記述するため、こういった機能は馴染まないという事も背景にあるのかもしれません。ただ、私的にはフレームワークの設計をやるので構築&破棄が多く、採用したいコードが出来た時点でテストコード書きたいという欲求もあり… 難しいところです。


「VSColorOutput」

VSColorOutput

これも、無いと生きていけない系です。ビルド時のログなどが表示される「出力」ウインドウの行に色を自動的に適用します。

法則などはあまり把握していませんが、warningとかerrorとかが行内に含まれていると、黄色や赤色で強調してくれます。

VSColorOutput_PreSettingsVisual Studioのデフォルトでは、ビルド経過はプログレスバーでしか表示されず、エラーが発生した場合は「エラー一覧」に表示されます。しかし、このエラー一覧は、表示の順序が発生した順序となっておらず、見ても関連性が全く把握出来ないため、とても残念な機能になってしまっています。

結局、エラー一覧を自動的に表示するというオプションを外し、必ず「出力」ウインドウを表示させるのですが、今度はログからエラーが発生している箇所を探すのが困難。

そんな時にこの拡張機能があれば、スクリーンショットのように一目瞭然です。ログの上から見ていって、最初の赤い行に注目すれば良いので、とても楽です。

ただ、自動で着色するアルゴリズムに若干まだ問題があり、着色に失敗する事があります。


私的な定番としては、このぐらいです。

ReSharper_CodeAnalysis2

近日ではとうとう「ReSharper」を使い始めました。これも解説はほとんど不要かと思います。というより、自分もまだ導入したてでレビュー出来ないと言う事もありますがww

上に含めなかったのは、この拡張機能が有償なためです。しかし、きちんとリファクタリングする文化があるのなら、きっと力になる拡張機能かなと期待しています。

 
コメントする

投稿者: : 2014/07/28 投稿先 .NET

 

Visual Studio 2012/2013 の拡張機能を紹介 (1)

Visual Studio 2010より、IDEの拡張機能を簡単に導入できるようになりました。

VSExtensions

現在の拡張機能についておさらいしておきましょう。

VS2010以降では、「ツール」メニューの「拡張機能と更新プログラム」を選択することで、拡張機能を管理するダイアログを呼び出す事ができます。このダイアログから、オンラインで拡張機能を検索したり、インストール済の拡張機能の更新やアンインストールを行う事ができます。

VS2008までは自力でセットアップコード(WixやInstall Shieldを使って)を用意し、独自の配布形態をとる必要があったのですが、VS2010からは「*.vsix」という形式の専用セットアップパッケージがサポートされ、負担が軽減した事が大きいと思います。拡張機能がvsix形式となっていれば、上記ダイアログから、ダブルクリック→インストールで、簡単に機能を拡張することができます。

※余談ですが、ツールメニュー内には「アドインマネージャ」という項目もありますが、これは拡張機能とは関係ありません。というより、ここに項目が追加されていることを見た事がない… 私も詳細は分かりません。

VSGResharper
また、vsixはユーザー毎にインストールすることが前提となるため、インストール時に管理者権限を要求しないことも、インストールの負担軽減に良いようです。
とは言っても、拡張機能の内容によっては、システムレジストリ(HKLM)を変更する必要があったりするため、インストール方法がvsixに統一されたわけでもありません。この辺りは、非常に扱いやすくなったNuGetと異なり、まだまだ洗練の余地があるように思います。

オンラインでの検索は、Visual Studio Galleryに登録されているソフトウェアが対象です。このサイトには個人で作った拡張機能でも登録できます。現在、約5000タイトルが収録されており、有償無償に限らず、こんな拡張機能があるのかという発見があります。


NuGet拡張機能やNuGetを殆ど使わない文化の所もあると思うので、その違いについても。

拡張機能はVSの機能を拡張します。たとえば、ソースコードエディタの機能を強化したり、デバッガの拡張を行ったり、Git/Subversionのようなソースコード管理ツールを統合したり、といった内容です。

NuGetはそうではなく、C#などのプロジェクトを開始後、そのプロジェクトのビルドに必要なサードパーティのライブラリを簡単に導入出来る仕組みです。

これまではこの部分も拡張機能が担っていたのですが、その場合は「参照設定」から、使用するライブラリを自分で探し出して、プロジェクトに追加する必要がありました。しかし、システムにインストールされた大量のライブラリから、目的のアセンブリ(DLL)を探し出すのは容易ではなく、また、大抵は組み合わせて使用するため、これを毎回行うのは頭痛の種です。

TooManyDependentLibraries2

ため息が出る、端的な例。

更に、サードパーティ(特にオープンソースプロジェクト)のライブラリは更新頻度が高く、新しいバージョンがリリースされても、ライブラリの依存関係を把握するのが困難で、いつまでも古いバージョンのライブラリを使い続けるという「あるある」状態になってしまいます。

そこで、プロジェクトへのライブラリの導入を簡単にするために生み出されたのが「NuGet」拡張機能です。そう、NuGetもまた、VSの拡張機能の一つとなっています。

NuGetはプロジェクトで「これを使う」のように指定する・されることが多いため、少し探せば目的のパッケージが見つかりますが、拡張機能は使ってみないと分からないこともあるため、私の使っている拡張機能を紹介してみようと思いました。

 
1件のコメント

投稿者: : 2014/07/27 投稿先 .NET

 

いまさら恥ずかしくてasyncをawaitした – 第9回まどべんよっかいち

本日、まどべんよっかいちで「いまさら恥ずかしくてasyncをawaitした」というお題目で登壇してきました。DoorKeeperはココです
ちょっとまくる進行の予定だったのですが、時間が長くとれたので、詳しく解説しました。

async-await-yokkaichi

ご清聴ありがとうございました。

非同期処理はここで解説した事を押さえておけば、大体OKと思って良いと思います。
他にもポイントはあるのですが、とても一回のセッションでは解説できないので省きました。次回にでも続きをやろうかと思います。

デモプログラムはGitHubに上げてあります。

スライドはこちら:いまさら恥ずかしくてasyncをawaitした_2.pptx

追記:忘れてました。ストアアプリの場合は、TaskクラスではなくIAsyncInfoというインターフェイスでawaitする事ができます。この話も次回出来たら良いなと思います。

このネタはリクエストがあったので、GeekBarでも再登壇する事になりそうです。決まったらまたtweetします。

 
コメントする

投稿者: : 2014/07/26 投稿先 .NET, Async, 勉強会

 

Async訪ねて3000里 (6) : I/O完了ポートによるワーカースレッドの運用

前回、TaskCompletionSourceによるタスクの継続に、APCコールバックを使用した場合の欠点を示しました。

APCコールバックはユーザーモードから見た場合の挙動がわかりやすい(コールバックが実行される)のですが、MsgWaitForMultipleObjectsEx APIなどのAPCコールバック対応APIで待機する必要があり、待機したスレッド(通常はメインスレッド)からコールバックが呼び出されるため、そのスレッドだけでI/Oの完了を捌く必要があります。

仮にシステムに多くのCPUコアが存在する場合でも、I/Oの完了による継続処理(翻ってawait後の処理)が、単一のスレッドだけで処理されることになり、パフォーマンスが上がりません。


手が遅いので指摘されてしまいました (;´Д`) 最後のピースを埋めましょう。

カーネルモードからユーザーモードに、I/Oの完了を通知する方法は、APCコールバック以外にも方法があります。

ファイルハンドルやイベントオブジェクトなどのWin32カーネルオブジェクトは、「シグナル状態」と呼ばれる一種のフラグを持っています。このフラグは、それぞれ決められたタイミングで「非シグナル状態」から「シグナル状態」と変化します。たとえば、ファイルハンドルであれば、直前のI/O操作が完了した(IoCompleteRequest)タイミングで、ファイルハンドルがシグナル状態となります。

APCコールバックを使用する場合は、I/Oが完了した事をプロセス毎のAPCキューに挿入することで通知しましたが、シグナル状態による通知であれば、キューを操作するコストを削減出来、さらにAPCコールバック対応のAPIで待機することなく、完了した事を通知することができます。但し、シグナル状態による通知は、前述のとおり一種のフラグであるため、コールバックとは異なり、この契機で能動的に処理を行うことができません。

このシグナル状態は、WaitForSingleObjectWaitForMultipleObject APIで監視することができます。つまり、これらのAPIを使用すると、I/O処理が完了するタイミングまで、スレッドを効率よく待機(ハードブロック)することができます。

WaitForSingleObjectでは単一のスレッドがシグナル状態となるまで待機しますが、これをワーカースレッドによる複数のスレッドにまで拡張したものが「I/O完了ポート」です。I/O完了ポートを使用すると、複数のワーカースレッドをあらかじめ待機させておき、シグナル状態となる通知によって、次々とワーカースレッドを使って完了後の処理を実行することができます。

実はasync/awaitの非同期インフラストラクチャーは、APCコールバックではなく、I/O完了ポートによって実装されています。I/O完了ポートに紐づけられるワーカースレッド群は、ThreadPoolクラスのI/Oスレッドとして内部的に割り当てられています。ThreadPoolクラスのワーカースレッドは、古くはIAsyncResultインターフェイスによる初期の非同期インフラの駆動用として使用されてきました。.NET 3.5以降でThreadPoolの実装が見直され、より効率よく動作するようになり、TaskAwaiterのコールバック駆動用として使用しています。

つまり、APCコールバックではAPC待機APIの呼び出しで待機したスレッドがコールバックを実行していましたが、現在の非同期インフラはThreadPoolクラスが保持するI/Oスレッド群が、TaskAwaiterのコールバックを実行しています。そして管理はI/O完了ポートで行っているため、大量のI/O要求の完了処理も、複数のスレッドで同時に処理できるのです。

MSDNブログに、.NETにおけるI/O完了ポートの使用方法が示されていたので、参考にして下さい。


以上をまとめると、async/awaitによる非同期処理は、ハードウェアからの完了通知としてもっともロスが少ないと考えられ、理想的な環境であれば、余計なワーカースレッドは使われません。但し、I/Oの完了がユーザーモードに通知された際に、TaskAwaiterのコールバック処理(await文以降の処理)を実行するためにスレッドが必要なため、この時に限り、効率的にプールされたワーカースレッドを使います。

唯一このタイミングでのみ、わずかな期間(IoCompleteRequestからI/O完了ポートでスレッドが処理に割り当てられるまで)ですが、スレッドのハードブロックと見なせる空白の時間が存在しますが、その他の手法と比べて無駄がありません。モニタAPIや待機APIによる、余計なハードブロックを起こさないのですから、多数のCPUコアで並列実行する場合でも、コンテキストスイッチによるロスは皆無です。

ケースバイケースですが、従来は自前ワーカースレッドによる複雑な実装しか選択肢が無かったものが、async/awaitの構文だけで効率の高い処理を簡便に実現できるようになったのです。ぜひ、非同期処理を実践して行きましょう。

せがゆうさん、ありがとうございました!

 
コメントする

投稿者: : 2014/07/16 投稿先 .NET, Async, WDK

 

Visual Studio Onlineを始める

以前、Team Foundation Serverのクラウド版とも言うべきTeam Foundation Serviceがベータ版で運用されていましたが、正式にVisual Studio Onlineとなったので、オンプレで使っていたTFSからリポジトリを乗り換える前提で、とりあえず使ってみました。

vso4

Visual Studio Onlineは基本契約は無料で、プライベートなリポジトリを持つことが出来ます。巷では無料のリポジトリサービスがいろいろありますが、ほとんどの場合はリポジトリに格納するプロジェクトをオープンソースとして公開することが前提です。

もし、ちょっとしたプライベートなプロジェクトを格納しておく場所に困っているなら(ローカルで自前でTFS・Git・Subversionなどを立ち上げるなど、いくら簡単にインストール出来ても保守は面倒です)、Visual Studio Onlineを検討する価値はあるでしょう。

また、他のサービスと異なるユニークな点は、Professional契約以上(月額45ドル/人)で、開発環境としてのVisual Studioが使えることです(インストールが必要)。さらにAdvanced契約以上では、アジャイルソフトウェア開発で有用な、プロジェクト管理システムもフルで使えます。これは、従来のTFSで使用している機能が、SaaSとして利用可能になったものです。

vso5

CI(継続インテグレーション)も可能です。但し、ビルド時間に制限があります。時間を超えると課金が必要です。未確認ですが、オンプレミスサーバーにVisual Studio Agentをインストールして、CIだけオンプレミスで実行させる事が可能なようです。これならば、大幅な課金を回避しつつ、サーバー管理の負担を軽減することが出来ます。

オンプレミスのTFSを使えばもちろん課金は不要ですが、TFSの管理にかかるコストの事を考える必要があります。TFS(に限らず、類似システムも含め)プロジェクト管理システムは大掛かりなため、全ての機能を使用して維持するのは、それ相応の準備と計画が必要になります。この点を肩代わりしてくれるサービスだと考えれば、課金をペイ出来る開発チームもあるでしょう。

公平の為、このようなクラウドサービスとしてAtlassianも推しておきます

また、Visual Studio Onlineは、従来のTeam Foundation Server方式のソースコード管理に加え、分散バージョン管理システムのGitを使用することもできます。これは、オンプレミスのTFS2013では実現出来ないため、Visual Studio Onlineのみのアドバンテージです(将来は改善されるか?)。


vso1

物は試しということで、Visual Studio OnlineでGitを使用してリポジトリを作り、Visual Studioを「使わずに」接続してみました。この図のように、あらかじめアカウントのProfile画面からCredentialタブを選択し、Basic認証を有効化しておきます。Gitクライアントからはhttpsで接続しますが、この時に使用するパスワードをここで入力して下さい。私はLive IDのパスワードを入力し続けて、暫く嵌っていました。

この操作は面倒ですが、恐らくはセキュリティ上の措置(Basic認証では平文パスワードを保持する必要がある)の為と思われます。念のため、Live IDのパスワードとは変えるようにします。

Windows環境のGitクライアントはいくつか選択肢があります。Git開発者の公式なパッケージはbashを含むMSYSベースのCLI環境です。どのクライアントを使うにしても、このパッケージはインストールしておいたほうが良いでしょう。何故なら、他のクライアントがこのパッケージ内のバイナリを使う事があり、かつすべてのクライアントがGitのすべてのオペレーションをサポートしているとは限らないためです。

vso2

Visual Studio内で使用できるプラグインGitクライアントも数種類あります。問題は、どれもまだ品質が一歩劣るという所でしょう。マイクロソフトも純正のGitクライアントプラグインをリリースしています。これはVS2012用で、VS2013には初めから搭載されています。しかし、Gitで使用する頻度の高いコマンドがサポートされていない・複数のリポートリポジトリに接続出来ないなどの問題があります。石坂さんのブログに詳しいので参考にして下さい。ボチボチ使えるのがGit Source Control Providerです。窓の杜の記事も参考にどうぞ

プラグインではないクライアントとして有名処ではTortoiseGitがあります。が、Tortoiseシリーズは思う所があり、私的にはSourceTreeをお勧めします。このクライアントは独立型(いわゆるVSSクライアントのような)で、Mercurialもサポートします。

操作感についてはそこそここなれている印象です。バックエンドを普通のCLIベースのGitクライアントで賄っているため、スムーズさは今一つですが、どのクライアントもこの方式なので仕方が無いでしょう。それ以外の点では、自分が何をやろうとしているのかが把握しやすいのが良い点です。そして、SourceTreeは前段で紹介したAtlassianが開発しているというのも、説得力があります。

vso3

SourceTreeを使用して、Visual Studio Online上のGitリモートリポジトリに接続し、ローカルリポジトリにコミットしたコードをpushしてみました。当然のことながら、全く問題ありません。一点、Visual Studio Online上のリポジトリURLがどこから取得出来るのか分かりにくいという問題があります。以下の図を参考にして下さい。

vso6

ソースコードエクスプローラーで、ツリーのリポジトリをクリックしたときに表示されているURLが、Gitクライアントで入力すべきURLです。URL末尾のリポジトリ名の手前に「_git」という識別子が入るので、確認してください。


これからGitを始めるという方は、VSS・TFS・Subversionと同じと思って掛かると挫折します(笑) Gitは同じバージョン管理システムでも全く異なる仕組みを持ちます。必ず知識をつけておきましょう。

Gitポケットリファレンスを、お勧めします。

 
コメントする

投稿者: : 2014/07/02 投稿先 .NET

 

BUILD 2014のWindows Phone 8.1 Word Flow世界最速タイピング

もう界隈では周知ですが、BUILD 2014のDay1 KeyNoteで、スタローン似の御仁(Joe Belfiore)から、Windows Phone 8.1の機能について発表がありました。

最も注目されたのは「cortana」と呼ばれる、iPhoneで言うなら「Siri」のライバルとなる、音声認識エージェント機能です。
ただ、cortanaはまだ日本語を理解できないし、実機のWindows Phoneでもcortanaを使う場合は、表示言語を英語に設定する必要があります。日本語対応cortanaたんに期待しましょう。

で、個人的にもっと強烈に印象を受けたのが「Word Flow」という新しいタイピング機能です。これは、ソフトウェアキーボード上を「なぞる」だけで、単語の入力が出来てしまうというものです。

Channel 9: BUILD 2014 Day1 KeyNote

build2014d1kn1

Word Flowのデモは、49分辺りからです。実際、実機+WP8.1DPでも、こんな感じで入力できます。一度慣れてしまうと、もう指を離したくなくなるぐらいのインパクトです。

また、その後のタイピングレコードの映像では、脅威的とも思える速さで入力しています。ガラケー+JK並の破壊的速さを、スマートフォンで実現出来たと言えるのではないでしょうかww

build2014d1kn2

しかし、これまた残念なことに、Word Flowは日本語キーボードでは使えません。ただし、英語キーボードに切り替えるだけで使う事は出来ます(表示言語を英語に設定する必要はありません)。

動画と実機のWord Flowの働き具合を見ている限り、トレースするキーの位置が不正確でも問題なく入力できているようです。恐らくは、トレースラインの屈曲する位置を検出して、その付近のキーをリストアップし、それらの組み合わせで最もふさわしい単語を候補としているように思います(+文脈も見ているかも)。そうであれば、日本語キーボードでは使えない理由も自明ですね。

早く日本語対応Word Flowが使いたいものです。

 
コメントする

投稿者: : 2014/06/08 投稿先 Phone

 

「de:code報告」 – Microsoft Azure 勉強会

JAZUG名古屋で、Microsoft Azure勉強会が開催されました。ATNDはココです。
私は、先週の「de:code報告」というお題目で、セッションを行いました。

decode

今回は、de:code遠征の成果、のような内容で発表を行いました。
そのため、コードレベルの内容は無しですが、楽しんで貰えたでしょうか?

早速次回の予定が組まれたりと、活発なJAZUG名古屋をよろしくお願いします。

プレゼンはココです。

それでは、また。

 
コメントする

投稿者: : 2014/06/08 投稿先 Azure, 勉強会

 

Async訪ねて3000里 (5) : TaskCompletionSourceでTaskの継続へ

とうとうAPCコールバックが呼び出されました。ここで、TaskCompletionSourceクラスSetResultメソッドを呼び出して、結果をユーザーモードのコードに返却します。これは、疑似的に以下のようなコードとなります。

// ReadFileEx APIのAPCコールバックエントリーメソッド(疑似コード例)
private static void OnReadCompleted(uint errorCode, uint bytesTransferred, ref OVERLAPPED overlapped)
{
	// OVERLAPPED構造体のメンバーに保存しておいたTaskCompletionSourceを得る
	var taskCompletionSource = overlapped.TaskCompletionSource;

	// TaskCompletionSourceに結果をセットする
	taskCompletionSource.SetResult(overlapped.Buffer);

	// (アンマネージ構造体の解除など)
}

前回の説明で示したように、このコールバックはAPCキューを拾い上げたスレッドが実行します。そのため、何らかのスレッドが、事前にSleepExやWaitForMultipleObjectsExなどのAPIを呼び出し、APCの待機状態でなければなりません。それはさておき、これでTaskCompletionSourceクラスのTaskが非同期処理を継続できることになります。

ここまでの長い道のりで重要なのは、

  • 非同期I/Oを要求してから、非同期処理が完了するまでの間、いわゆるワーカースレッドで「疑似的」に並列動作を行っているのではなく、デバイスのハードウェア並列実行性をそのまま使用して、CPUが完全にフリーな状態を作り出している。

ことです。

async8

ワーカースレッドによる疑似的な並列実行では、並列性を担保するために「CPUコアのコンテキストスイッチング」を使用します。この機能は強力で、全く無関係なコードグラフ(実行単位)を、あたかも同時に動作させているかのようにふるまわせる事が出来ますが、切り替えには大きなオーバーヘッド、そしてメモリを消費します。

しかし、今まで述べた非同期I/Oに必要なオーバーヘッドは、「仕方なく必要となるリソース」以外にありません。仕方なく、とは、

  • 割り込み処理ではどうにもならないためにDPCキューを使うこと
  • スレッドとプロセスを特定するためにAPCキューを使うこと
  • 各ドライバ階層の個別に必要となる処理で要求されるリソース
  • WDMとカーネルがI/O要求を処理するために必要とするリソース

の事で、これ以外の処理は、何をしても「追加リソース」としてオーバーヘッドを伴うことが分かります。よって、非同期I/O要求は最小のコストで実現出来る、同時並列実行を高めるよい方法となります。


ところで、あまり突っ込んで説明していないが重要なポイントがあるので、さらに掘り下げておきましょう。

本当にワーカースレッドは使われないのか?

実はこれは巧妙な嘘です。というのも、これまでに紹介した非同期I/Oの流れは、いわゆる「最適な場合」に相当します。

async9

WDMではスタック化されたドライバ群が存在しますが、その中間処理で「ワーカースレッド」を使っている可能性があります。そこでは、独自の何らかのキューを使用して要求をバッファリングし、ワーカースレッドで処理を行っていると思われます。これは、サードパーティ製ドライバは勿論、Windows標準のカーネルモードドライバにも当てはまります。
(そして、若干ですが、処理の都合上避けられない理由のためにワーカースレッドを使うこともあります)

デバイス寄りのドライバコードであれば、ここにデバイス製品の優劣が生まれます。如何に最小のコスト(ワーカースレッドを使わない)で、I/O処理を捌く事が出来るかによって、製品の性能が左右されることになります。ユーザーモードのコードと同様に、完全に非同期I/O要求だけで駆動するドライバの開発は難易度が高くなり、処理をオフロードするため、ハードウェアにリッチなロジックが必要になる可能性があります。または、ワーカースレッドを使うことで、CPUリソースを消費してしまうものの、安価にデバイスを開発できる可能性もあります。

あるいは、デバイスによってはハードウェア割り込みが限定的にしか機能せず、「ポーリング」という古典的なループ処理で実現しなければならない場合もあります。これは勿論、ワーカースレッドで半永久ループを行うことで実現しているため、CPUリソースを消費します。

APCコールバックを実現するためのスレッドをどうやって待機させるのか

APCコールバックを実行するためには、あらかじめスレッドを待機状態にしておく必要があることは説明しました。SleepExやWaitForMultipleObjectsEx APIをコールすることで、APC待機状態を作る事が出来ます。

これらのAPIのバリエーションに、「MsgWaitForMultipleObjectsEx」もあり、これを使えばUIスレッドのメッセージループ中で、メッセージを待機しながらAPCも待機する事が出来ます。メインスレッドのメッセージループでこのAPIを使うことで、非同期I/Oの完了をメインスレッドで受け取り、APCコールバックをメインスレッドで実行する事が出来ます。

これはつまり、APCコールバックメソッド中で、自由にウインドウ操作が可能になることを意味します。

しかし、.NETのTaskクラスは、async/awaitで待機・継続するときにUIスレッドを自動的にキャプチャ出来るので、余計なお世話に見える

その通りです。APCコールバックを使用することで、本来ならTaskAwaiter.OnCompleteメソッドのUIスレッドキャプチャ処理がやってくれた作業が不要となります。しかし、.NETの世界でTaskクラスを使うのが前提であれば、APCキューを使った結果の返却は、却ってオーバーヘッドのように見えます。

async10

また、APCコールバックが実行されるためには、メッセージループでMsgWaitForMultipleObjectsExを使用する必要がありますが、これは大きな制限です。.NETの世界ではこのようなAPIを直接使用することはまれであり(通常、Applicationクラスに隠ぺいされている)、また既存の実装との親和性が気になります。

更には、APCコールバックでは、処理に対応するスレッドが限定されてしまうため、I/Oの完了が立て込む時にパフォーマンスが悪くなります。APCキューはまさしく「直列化されたキュー」に相当し、スレッドが一つずつ処理を行うため、完了した非同期I/Oの後続処理を並列実行したい(例えばシステムにCPUコアが沢山存在するなど)場合でも、APCキューのために並列実行が制限されます。

 
コメントする

投稿者: : 2014/04/21 投稿先 .NET, Async, WDK

 

Async訪ねて3000里 (4) : I/Oの完了とAPC

前回からの続きです。

DPCのキューからキューエントリが取り出されて、DPCコールバックエントリが実行されます。ここで、ディスクデバイスからの結果を処理し(場合によっては、DMAで転送されたデータを移動や加工する)、「I/O要求の完了」とします。

I/O操作を完了するには、「IoCompleteRequest」カーネルモードAPIを呼び出します。これで、STATUS_PENDINGしていた要求が完了した事になります。

Async6但し、(2)で解説した通り、WDMドライバはスタッキングした階層構造になっています。ディスクデバイスの処理が完了しても、そこに至るまでの各階層のドライバが、個別に完了処理を行いたい場合があります。ここではその方法は述べませんが、あらかじめ準備しておけば、これらのドライバも完了と追加処理のタイミングを得る事が出来ます。

重要なのは、この一連の処理は、単一のCPUスタックコンテキスト(スレッドは不明なのでスレッドコンテキストではない)で実行される事です。階層の途中のドライバが再びSTATUS_PENDINGで処理を保留にしない限り、DPCのコールバックからの連続したコールスタックで実行されます。つまり、ここでもワーカースレッドは使われていない、と言う事です。

話を簡単にするため、全ての階層ドライバがI/Oをそのまま完了させたとします。すると、この階層化されたI/Oの要求の出発点である、「ZwReadFile」カーネルモードAPIまで辿ります。ここで本来の(カーネルモード)I/O要求が完了した事になります。

ZwReadFile APIはユーザーモードに遷移して、この事を元のプログラムに通知しなければなりません。ユーザーモードのReadFileEx APIは、処理完了時にAPCコールバックを呼び出す事になっています。しかし、ここに大きな壁があります。

  1. I/O要求が完了した時、コンテキストはDPCのCPUスタックコンテキストです。そのため、Windowsカーネルから見ると、スレッドさえ良く分からないという微妙な状態にあります。このままでは、ユーザーモードに遷移する事は出来ません。
  2. ユーザーモードに遷移するためには、呼び出し元のプロセスが特定出来なければなりません。上記のようにスレッドが不明では当然プロセスは特定出来ません。これは2つのパターンがあります。
    • DPCがCPUコアのアイドル状態から呼び出された場合は、スレッドは完全に不定です。スレッドが不定では、プロセスも特定出来ません。CPUがアイドリングでストールしている状態を、「アイドルスレッド」のように表現する事がありますが、このようなスレッドが実際に存在するわけではありません。実際、スレッドを管理するためのTEB(Thread environment block)構造体は存在しません。
    • DPCが不特定なスレッド(Arbitrary thread context)から呼び出された場合、理論上は何らかのスレッドのスレッドコンテキスト上で実行していることになりますが、このスレッドは、呼び出し元のプロセスとは全く関係ない可能性があります。というよりも、殆どの場合、知らないプロセスの知らないスレッドのスレッドコンテキストを間借りして実行しています。

スレッドについて補足:Windowsカーネルは、全てのプロセスの全てのスレッドを等価に扱います。ユーザーモードから見ると、まずプロセスが存在し、その中にスレッドが存在するように扱われていますが、実際にはすべてがスレッドで、スレッドの一部にプロセスが割り当てられているというイメージです。また、カーネルモードで生成されるスレッドは、特定のプロセスに紐づいていません。この連載で「スレッド」と呼ぶ場合は、これらをひっくるめたすべてのスレッドを指します。

Async7I/O要求を完了するときのDPCを実行するコンテキストが、「偶然に」呼び出し元のスレッドと同じという可能性は殆どあり得ません(タスクマネージャやProcess Explorerで確かめて下さい。Windows稼働時は、常にシステム全体で数千のスレッドが待機しています)。従って、このコンテキストでそのままユーザーモードに遷移し、APCコールバックを呼び出す事は出来ない事になります。


さて、APCコールバックを「APC」と呼んでいる理由を説明する時が来ました。APCの響きはDPCに似ていますね。実は、概念的にAPCとDPCは良く似ています。APCは「Asynchronous Procedure Call」の略で、カーネルモードからユーザーモードに遷移する時に、APCキューに要求を入れ、目的のプロセス空間の目的のスレッドでキューエントリーを取り出して実行するために使います。

DPCキューが割り込み処理からDPCコールバックコンテキストで実行させることを目的としたのに対し、APCキューが異なるスレッドから目的のプロセスのスレッドコンテキストで実行させることに対比出来ます。

(1)の解説で、ユーザーモードのReadFileEx APIからI/O要求を投げていたので、この時のスレッドでAPCキューの内容を取り出して、このスレッドコンテキストでコールバックを実行させる訳です。しかし、このスレッドは、わざわざ非同期I/O処理を要求したので、ReadFileExがERROR_IO_PENDINGを返した直後から、何か別の処理を行っている筈です。そのため、このスレッドが明示的にAPCキューを確認する機会を与える必要があります。

ReadFileEx APIで非同期I/Oを実行した後、何らかの並列実行を行って「手持ちぶたさ」が生じたときに、「SleepEx」ユーザーモードAPI「WaitForSingleObjectEx」ユーザーモードAPI「WaitForMultipleObjecstEx」ユーザーモードAPI「MsgWaitForMultipleObjecstEx」ユーザーモードAPIのいずれかを呼び出すと、APCキューがチェックされ、キューエントリーが存在すると、それに対応したAPCコールバックが実行されます。キューエントリーが無い場合は待機し、新たにキューエントリーが追加されるとAPCコールバックを実行します。

これらのAPIを呼び出していないと、元のスレッドでAPCコールバックを実行する事が出来ないため、キューの内容は保留されたままとなります。

 
1件のコメント

投稿者: : 2014/04/08 投稿先 .NET, Async, WDK