ひたすら人々がエスカレーターで昇っていく動画です。
4種類のエスカレーターがあり、右から、
を表しています。
ソースコードは、Tools-2016 (GitHub) にあります。
参照
Escalator Simulator (YouTube)
エスカレーターは歩かずに立ってるほうが結局速い。ロンドン地下鉄が実証
WPF などの GUI アプリケーションでマウスのドラッグ操作を扱うには、
例えばマウスのドラッグ中の各点の情報も通知するなどの要件に合わせて、
基本的には自分で実装することになると思います。
従来であれば、MouseDown などの各イベントごとにイベントハンドラーを登録して実装していましたが、
リアクティブ プログラミングにすることで、より抽象度の高い形式で扱えるようになります。
今回は、WPF のマウスのドラッグ イベントを Reactive Extensions (Rx) で実装してみます。
WPF アプリケーション プロジェクトを作成して、NuGet で System.Reactive をインストールします。
そして次のクラスを作成します。
イベントと IObservable は、本質的には等価です。
まず Observable.FromEventPattern メソッドを使って、
MouseDown などの既存のイベントを IObservable<MouseEventArgs> に変換します。
ドラッグの実装方法については、
MouseDown が発生してから MouseUp または MouseLeave が発生するまでの間、MouseMove を通知させます。
これが MouseDown の発生のたびに開始するため、
MouseDrag の型は IObservable<IObservable<Vector>> のような入れ子になります。
ここでは、MouseDown イベントが発生した位置からの変位を通知することにしています。
(要件によって実装方法は異なるでしょう。)
次に、上で実装した MouseDrag を利用するには、次のコードのようになります (主にコンストラクターの部分)。
完全なソースコードは MouseRx2Wpf (GitHub) にあります。
ウィンドウには、変位とそれを表す 8 方向の矢印を表示しています。
この方法はマウス以外にも応用できます。
Leap Image Pinch は、Leap Motion Controller を使って空中で 2 本の指でつまんで画像をドラッグする例です。
作成したサンプル
MouseRx2Wpf (GitHub)
バージョン情報
.NET Framework 4.5
参照
System.Reactive
Reactive Extensionsの概要と利用方法
Leap Image Pinch
前回のメディアアートについてで書いた通り、アートの基本となるのは概念の抽出です。
アーティストが作品を制作する際にはテーマに対する徹底的なリサーチが含まれており、そのプロセスはさながら研究といえるでしょう。
(こういうプロセスが不要な人は天才と呼ばれます。)
今回は、アートのプロセスについて考えてみたいと思います。
現代美術の展覧会を鑑賞すると、「難度の高い IQ テスト」という感想を持つことがあります。
作品を見ても最初は「これは何だろう」で思考が停止してしまうのですが、
作品の意味を聞くと納得でき、もはやそういうものにしか見えなくなります。
むしろ、なぜ最初に気付けなかったのだろう、と思うのです。
これに近い現象は他の分野でも起こります。
数学や MENSA においても、良い問題というのは
「解き方を知ってしまうとその解き方が当然のように見えてしまうが、それに気付くのは難しい」という側面があります。
実はプログラミングにおいても、「プログラミングの知識があるからといって、実装ができる人とは限らない」ということがあります。
では、なぜこのような非対称性が発生するかというと、
という違いがあるからだと考えます。
仮説的推論 (仮説形成、アブダクション) とは、不確実性下で尤もらしい解を導くことです。
演繹では結果が保証されますが、仮説的推論では結果が 100% 保証されるとは限りません。
簡潔な説明が Wikipedia の論理的推論に載っています。
人工知能などのコンテキストで、仮説的推論や帰納は、より人間らしい創造的な能力であると説明されます。
プログラミングにおいては、学習時には主に演繹の形式で理解するのに対して、開発の現場では仮説的推論が必要になります。
現場で品質がばらばらになるのはこのためです。
この意味で、プログラミング自体が創造的な側面を持っているといえるでしょう。
(ちなみに、対比のメタファーとして、製造業のアルバイトが挙げられます。
製造業のアルバイトでは、作業手順のマニュアルがあるため、それに従えば一定の品質が保たれます。)
このように考えると、アーティスティック (芸術的、審美的) な研究のプロセスでは
「どのように作ったか」よりも「どのように思い付いたか」が重要になってきます。
前者を知って真似することはできても、後者を知って真似することは難しいはずです。
短期的な投資をする人たちにとっては前者でよいですが、長期的な投資のためには後者が必要です。
そしてそのために必要なものは何かというと、概念をより多く知ることではないかと考えています。
パターンを増やす、多様性、ともいえます。
上位のコンテキストを捉えられれば、より汎用的な能力を身に付けることになります。
例えば数学の研究において、概念を拡張することは重要な仕事の一つですが、
概念を拡張するには、「このように定義すれば、さまざまな事象を共通的に記述できるだろう」と気付くことが必要です。
既知の概念やパターンが増えてくれば、同時に「まだ整理されていない事象は何か」「未知の領域は何か」に気付きやすくなり、
考察の対象を絞り込めるようになるでしょう。
前回: メディアアートについて
私はこれまでに、2015 年の菅野創＋やんツー「SEMI-SENSELESS DRAWING MODULES #2 – Letters」および
2016 年の菅野創＋やんツー「Asemic Languages」というメディアアートの作品の制作に、技術協力として参加してきました。
この 2 つの作品はいずれも、入力となる筆跡データに近い新たな筆跡データを生成して機械が描くというもので、
私は新たな筆跡データを生成する部分を担当し、機械学習を利用して実装しました。
さて、私は美術を専門とはしていませんが、
以下では、これまでの活動を通じてメディアアートについて得られた知見を書いていきたいと思います。
一般の多くの人たちが思い浮かべる「美術」は、自身が高校生以前の「図画工作」「美術」の授業で扱った内容の知識で
止まっていることと思います。それらはおそらく、古典美術やビジュアルデザインなどに分類されるものでしょう。
美術のカテゴリの中で、とくにコンセプトを問うのが現代美術 (contemporary art) で、
さらに現代技術 (ハードウェアやソフトウェア) と融合したものがメディアアートです (個人の見解です)。
アートの基本となるのは、概念の抽出やパターン認識です。これは数学や哲学でも同じです。
事象から概念を抽出し、それらの関係を変化させることで美しさや非日常的な興を生み出すことができます。
アーティストは作品を通じて、鑑賞者に概念的な気付きを与えてくれます。
現代美術の作品は、答えではなく問いである、といえるでしょう。
答えが出てしまっているものは、アートではなくデザインです。
プログラマーは既に経験した技術を使い、デザイナーは既存の概念を使い、アーティストは概念を問うたり創り出したりします。
例えば上で紹介した作品では、「線が文字っぽく見えるとはどういうことか」
「人工知能やロボットが自発的に生成した絵画は、特定のアーティストの作品と呼べるのか」 などということを世の中に問うているのです。
時には芸術作品の意味が理解できないこともあるでしょう。
同じように、例えば哲学や経営の本を読んだとき、賛否を論じる以前にピンとこない、難しい、著者の意図が分からない、
ということがあると思います。この状況はすなわち、これまでの人生でその概念を獲得できていなかったということを示します。
より高い概念を獲得した人たちの間では共通認識、暗黙の了解のようなものが生まれ、より複雑な状況下での判断ができるようになります。
言うまでもなく、アートは現代に始まったものではありません。
日本の歴史においても、庭園、茶道、茶器、絵画など、さまざまな種類が挙げられるでしょう。
時代劇などでも地位の高い人を招いて美学やわびさびを論じさせるという描写があり、その応対を通して、
相手の人物がどの水準の概念を獲得できているか、空気を読めているか、大局的な判断ができるかなどを鑑定していたことが想像できます。
これについては現代社会でも同様だと思います。
アルス・エレクトロニカは展覧会のほかにも Futurelab という研究機関を併せ持ち、
メディアアートから企業のイノベーションまでをつなぐサイクルが成り立っています。
アルス・エレクトロニカの運営資金は、リンツ市が 35～40% を支援しているそうで、
研究開発の成果は都市のいたるところにインストールされています。
日本では芸術祭の開催に積極的な都市もあり、このような都市が登場してくる可能性はあります。
将来、創造性の低い職業はロボットで置き換えられていき、利益率も下がると言われていますが、
取って代わられない職業の最たるものがアーティストです。
アーティストはコンセプトを見出す能力や 0 から 1 を創り出す能力に優れているため、例えば自社の製品を作品に使ってもらったり、
ワークショップを開催したりするなど、アーティストと連携していくことが効果的であると考えています。
第一線の創造的事業を継続するためには、本業を軸として芸術分野に投資することも求められていきます。
「本業で」というのがポイントで、例えば、自動車業界であれば F1 をはじめとするモータースポーツを通じて、
自動車の研究開発を世に問うています。 また、現在では多くの企業が博物館をはじめとする展示施設を運営しており、
そこからそれぞれのテーマに関する新たな知見を得ていることでしょう。
次回: アートのプロセスについて
Azure Web ジョブでバッチを実行するための簡易的な作業手順と、タイムアウトなどの注意点について記述します。
まず、Azure Web ジョブを配置するまでの基本的な流れは次の通りです。
これらについて、以下に詳細を書いていきます。
Azure ポータルで、ストレージを 1 つ作成します。
厳密には、
の 2 種類なのですが、1 つのストレージに両方の役割を持たせてもかまいません。
また、後の手順で接続文字列を使うため、[キー] からコピーしておきます。
Azure のポータルで、Web App を作成します。
[アプリケーション設定] の [接続文字列] で、「AzureWebJobsDashboard」をキーとする設定を追加します。
これで、WebJobs ダッシュボードを利用できるようになります。
Visual Studio で、新規のプロジェクトを [Azure WebJob] のテンプレートから作成します。
App.config を開くと、接続文字列の設定が 2 種類あります。
この両方に、先ほどと同じ接続文字列を設定します。
以下、Web ジョブの開発の流れを簡単に書いておきます。
なお、今回作成したサンプルは TaskWebJob (GitHub) にあります。バッチ処理の題材として、素数を求めています。
(1) 手動またはスケジュールで開始する場合
詳細は Web ジョブ SDK を使用して Azure テーブル ストレージを使用する方法などを参照。
(2) キューをトリガーとして開始する場合
詳細は Web ジョブ SDK を使用して Azure キュー ストレージを操作する方法などを参照。
以上で、Azure Web ジョブにバッチを配置することができました。
さて、バッチを実際に実行してみると、タイムアウトしてしまうことがあります。
以下では、タイムアウトについて書いていきます。
既定では Web App の [アプリケーション設定] の [常時接続] がオフに設定されており、
Web App (というより Kudu？) が 20 分ほどでタイムアウトしてしまいます。
[常時接続] をオンに設定すれば解決します。
無料プランでは、[常時接続] をオンにできません。
バッチの実行がタイムアウトする原因は 2 つあります。
したがって、WebJobs ダッシュボードなどを表示したままにして、
かつ CPU 使用率の低いバッチであれば実行可能ということになります。
そこで、例えば Thread.Sleep メソッドをコードに含めるという方法があります。
Thread.Sleep などでスレッドを中断しながら実行すると、CPU 利用率を激減させることができます。
CPU 時間の使用量は [クォータ] で見ることができます。
作成したサンプル
TaskWebJob (GitHub)
参照
Azure Web ジョブのリソース
Azure App Service に .NET Web ジョブを作成する
Web ジョブ SDK を使用して Azure キュー ストレージを操作する方法
Web ジョブ SDK を使用して Azure テーブル ストレージを使用する方法
Web ジョブでバックグラウンド タスクを実行する
Visual Studio を使用して Web ジョブを展開する
WPF で、Border や Grid などの枠の中に、その領域をはみ出すようなコントロールを配置して、
それを Transform などで移動させるとします。
すると、そのコントロールの一部が切り取られてしまったり、外枠にはみ出てしまうなど、期待通りの動作にならないことがあります。
以下では、この現象をどうすれば回避できるかを試していきます。
(追記: Canvas で ClipToBounds="True" とすればよい、とコメントを頂いたため、後半に追記しました。)
Blend for Visual Studio で WPF アプリケーション プロジェクトを作成して、
Border の中に Rectangle を配置して、Rectangle を期待通りに動かせるかどうかを調べます。
Window の領域を 4 つに分けて、以下の方法を試してみます。
ScrollViewer を使うことで、外側にはみ出さないようにします。
スクロールバーを消すために、VerticalScrollBarVisibility プロパティを Disabled に設定します。
また、ScrollContentPresenter は、ScrollViewer の中で使われているコントロールです。
すると、Blend for Visual Studio のデザイナーでは次のように表示されます。
この時点で、右上の方法では外枠の Border の上に描画されてしまうことがわかります。
また、この 4 つの Rectangle に対して、TranslateZoomRotateBehavior を設定します。
(Blend for Visual Studio のアセットからドラッグ アンド ドロップします。)
これで、実行時にタッチ操作などでコントロールを動かせるようになります。
全体の XAML は次のようになります。
このアプリケーションを実際に動かしてみます。
ここで、よねやんさんから、Canvas の ClipToBounds プロパティの値を True にすればよい、とコメントを頂きました。
右上の Canvas を変更して実行してみます。
期待通りです。
というわけで、ScrollViewer などは不要になりました。
Canvas を配置して、ClipToBounds="True" を設定するだけです。
作成したサンプル
FrameLayoutWpf (GitHub)
バージョン情報
.NET Framework 4.5
