Windows IoT Core にリモートで接続する

世の中?は、dotnetConf で盛り上がっていますが、Windows IoT Core のリモート接続の方法を残しておきます。実は、まだ Inside Preview の状態でしか使えないのだけど、Closed Loop Control, Remote Sensors and Remote UX on RPi3 – Hackster.io のサンプルを見ると既に3月からできていたわけで、つまりは //Build/ 2016 の頃からできました、って話ですね。Build で Windows IoT Core の話があったかな…というのは後で調べます。

Remote Display Experience – Windows IoT

Remote display experience

そんな訳で、3か月遅れで試してます。が、結論から言えば、Windows 10 Inside Preview (現状では Slow Ring)を使うのと、Visual Studio で作成する UWP のバージョンが微妙に低いのと、Windows IoT Core 自身のバージョンが微妙に高いのとの兼ね合いで、画面のリモート接続はできるけど、リモートデバッグができません。つまりは Visual Studio からデプロイできないので、なんか変な感じで食い違っていますが、まあ、夏の正式リリースまでには揃えられるかと。というか、揃わないと困る。

Raspberry Pi 3 に Inside Preview 版を入れる

Windows IoT Core の Inside 版は Get Started – Windows IoT から、Raspberry Pi 3 の NOOBS 版からインストールするか、https://www.microsoft.com/en-us/software-download/windowsiot から直接ダウンロードします。どうやら、現時点で RPi3 対応は Inside Preview 扱いなので(正式リリース版ではない)どちらの方法でも 、14342 が使えます。NOOBS 版のほうは、微妙にサイズが大きくなって SD カードは 16 MB が必要です。

リモート接続を有効にする

ブラウザから http://miniwinpc:8080/ で接続すると「Remote」というメニューが増えています。このチェックを入れると、リモート接続が有効になります。

image

リモートアクセスのアプリを入れる

https://www.microsoft.com/en-us/store/apps/iot-remote-client/9nblggh5mnxz から Windows IoT Remote Client をインストールします。

無事接続できると、こんな風に Raspberry Pi 上のモニタが表示できます。マウスでぽちぽちすることもできるし、タッチパネルがあればタッチ操作ができます。

image

ただし、全画面転送しているらしくて妙に遅かったりします。現時点では解像度を 800×600 に落とすと使えるぐらいのスピードになります。

 

 

 

以下は、リモートデバッグしようと思ってあれこれやった結果です。

 

Windows のほうも Inside Preview 版にする

Windows IoT Core のアプリは UWP なのですが、このターゲットバージョンを揃えないといけません。さっき、14342 を入れたのだから、Windows 10 PC のほうも、14342 か、それ以上にします。現状では Slow Ring にして Windows Update すると自動的に入ります。

業務 PC に入れるのは難なので、Hyper-V 上に Windows 10 の環境を作ってバージョンを揃えています。

Windows 10 SDK を入れる

ホーム ページ – Windows Insider Program に参加して、プレビュー版の Windows 10 SDK をインストールします。実は、ここのバージョンが 14332 なので、PC や Windows IoT Core のバージョン 14342 よりも低いんですよね。たぶん、このおかげで Windows IoT Core に対してリモートデバッグができない状態なのだと思います。

でもって、Windows 10 SDK 14332 を入れた状態で Visual Studio からデプロイしようとすると、

image

2>DEP0800 : 必要なフレームワーク “C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.NET.CoreRuntime\1.0\.\AppX\ARM\Microsoft.NET.CoreRuntime.1.0.appx” のインストールに失敗しました。

のようなエラーが発生します。このエラー自体は、StackOverflow でよく見かけるのですが、解決できていません。大抵の回答は、SD カードの焼き直しなんだけど、どうもバージョン違いのような気がする。

アプリのデプロイ自体は、ブラウザから「Apps」→「Install app」で、appx ファイルをアップロードすれば ok です。このあたりはストアアプリと同じなので、デバッグはできませんが、ひとまずアップロードして Windows IoT Core 上で動かすことはできます。

image

そんな訳で、中途半端ですが、ひとまずリモート接続ができるところまで。

カテゴリー: Win IoT | Windows IoT Core にリモートで接続する はコメントを受け付けていません

WordPress に XSS が埋め込まれてから復旧まで

ざっと記録として残しておきます。

5/30 に悪質サイトに登録される

仕事上、執筆やらプログラミングの折りには自分のサイトを Google で検索するのが多いのですが、5/30 の朝に検索すると悪質サイトとして登録されていました。

Google ウェブマスターからはこんな感じ。

image

なんぞ、クラッキングされたのか?と思ったものの、直で moonmile.net からアクセスして当 blog にアクセスすると大丈夫。でも、Google 検索をさせると駄目という状態で。なんら表面上は大丈夫なように見えるんですが、妙にアクセスが遅いのが気になるところでした。ページにアクセスしようとすると、windows defender が警告を発する状態です。

ソースコードが保存できない

表面上、何もないということは XSS を仕組まれたか何かなので、ソースコードを見ます。Firefox ではガードされて見れなかったので、ひとまず Edge で見てエディタに貼り付けて保存しようとすると、windows defender が警告を出します。ってことは、コード自身に何かがある訳ですよね。

そんな訳でちょっとずつ HTML コードを削っていくと、妙な javascript が head タグにくっついているのを発見。それを削ると保存できるので、どうやらここが原因のようです。コード自体は公開できないのですが(悪質サイトになってしまうし)、kicrea[.]it に情報を送っています。

こんなスクリプトが wp_head() の後ろに埋め込まれます。IP のところは怪しいサイトに誘導されています。

image

wordpress の header.php を見る

google の Search Console https://www.google.com/webmasters/tools/home?hl=ja 名にたくさんのページが改竄されています。URL を見るとRSSまで改竄されているのと、先の head タグに書きもまれているので、どうやらヘッダ部分があやしいと推測します。

案の定 header.php に XSS が仕込まれているので削除します。

問題は、ここの blog のテーマだけでなく使っていないテーマの header.php や、相乗りしている header.php にも改竄がはいっていたことです。アクセスログを見ても wordpress からログインした形跡がないし(admin は消し去っています)、そもそも使っていないテーマの header.php を改竄すること自体おかしいし、ファイルの日付を見ると変更されていないので、どうやらターミナルコンソールのほうで何かあった感じ。

フォルダをリネームして google へ再申請

ひとまず、Google 検索で悪質サイトが出続けるのも困るので、フォルダをリネームして、Google に再申請します。元ページを削除した旨を連絡して、まっさらな index.html だけおきます。再申請のチェックは 12時間ぐらい掛かるので、まあ、早めに手を打っておこうかと。

たぶん、共有サーバーだから?

いくつかのサブドメインで運用している wordpress の header.php もやられてしまったので、これも修正します。当然、それらのドメイン(dotnetlab.net や openccpm.com)も悪質サイト扱いになっているので、同じように再申請しておきます。

このブログが乗っているのは、共有サーバーなのでたぶん100名ぐらいが同時に使っているんですよね。改竄された形跡から考えると、wordpress 経由とは考えづらく、ターミナルのパスワードが盗られたとも考えにくいので、共有の他のユーザーから漏れたのかなと。ただし、header.php のパーミッションは 644 -rw-r–r– なので、以前ロリポップ等でやられてしまったようなグループからは外れていると思うんですけどね。ルート権限からユーザーのパスワードが抜かれてしまったのかもしれません(ホスト側から連絡がないのでわからず)。

ひとまず、ターミナルへのパスワードを変更して、header.php を手作業で修正して様子見という状態です。2日間経って元に戻る気配はないので、ここで対処は終了。現時点では google から以前通りアクセスができます。

これ、個人の相乗り wordpress だったからよかったけど、商用サイトとかアフリエイトサイトとかだったら復旧が大変だったろうなと。

カテゴリー: トラブルシューティング | WordPress に XSS が埋め込まれてから復旧まで はコメントを受け付けていません

和風ペンタとブルーノートの比較の続き

和風ペンタトニックとブルーノートは酷似している | Moonmile Solutions Blog
http://www.moonmile.net/blog/archives/7893

の続き。タブ譜だけでは分かりづらいので、実際に弾いてみます。ブルーノートを弾いていてもちょっと和風ペンタっぽくなるのは私が日本人だから、ってことで勘弁してもらって、実際弾いてみるこんな感じになる。

和風ペンタとブルーノートの比較

ヨナ抜き(ファとシ)を覚えると大抵の童謡/民謡がこの音に乗っているのが分かる。ただし、完全に乗っているわけではなくてちょいちょいアクセントをつけるのがミソなんだけど、基本はヨナ抜きになる。サザエさんのオープニングもそうだし、ソーラン節もそうだし、植木等のスーダラ節もヨナ抜きになっている。実際に弾いてみると解るけど、ギターでヨナ抜きで上がり下がりをしていると無限に曲が沸いてくる、というか人工無能的にランダムに音を出したとしても和風ペンタに乗っている限りなんとなく曲に聴こえるから不思議だ。

で、ヨナ抜きのスケールをちょっとずらしたのがブルーノートになる。基本は同じスケールになるので、日本人にはヨナ抜きもブルーノートも時に同じように聴こえる。基音が違うので、そこだけ強調するのと、それっぽいリズム(和風ペンタの場合は音頭とか演歌風に弾く、ブルーノートの場合はブルース風にチョーキングを加える)になると、途端にそうなるから不思議だ。

動画の後ろのほうでは、ひとつの曲(っぽいもの)に和風ペンタとブルーノートを混ぜている。強引に混ぜるものだから途中でコードが変わったように聴こえるけども、実際は同じスケールを上がり下がりしているだけになる。

ちなみに、ブルースケールも、どんな風に弾いても大丈夫な感じなのは和風ペンタに似ている。

オレオレブルース G開放弦で – YouTube

ライトン・ホプキンズとジョン・リー・フッカーの真似事をしてみる。

ほんものはこっち

Baby, Please Don’t Go – Lightnin’ Hopkins – YouTube

Lightnin Hopkins – Lightnins Blues – YouTube

https://www.youtube.com/watch?v=DCSacpEIYWY

カテゴリー: ギター | 和風ペンタとブルーノートの比較の続き はコメントを受け付けていません

zo-3 のボリュームを交換する

yahoo! オークションで底値 2,400円也で手に入れた zo-3 なのですが、内蔵スピーカーから音が鳴ったり鳴らなかったりします。ボリュームを動かしてちまちまラジオのチューニングみたいなことをやると、がりがりという音と共に音が鳴るようになったりするのですが、ちょっと動かすとすぐに鳴らなくなります。どうやら、増幅回路んほうは大丈夫そうなので、ボリューム(ポテンショメーター)の交換をします。

image

amazon で見ると、エレキギターのボリュームスイッチは 500 ~ 2,000円で売っているようなのですが、そんな高価なのはいらないので秋月の 10kΩ のポテンショメータ 30円也を使います(どうやら、25kΩらしいんだけど、実測すると 10kΩちょっとだったので、手元にあるものでいいや、ということで)。

小型ボリューム 10KΩB: パーツ一般 秋月電子通商 電子部品 ネット通販
http://akizukidenshi.com/catalog/g/gP-00246/

裏側にある 9V 電池ボックスを取り外すとボリュームで使っているポテンショメータが見えます。これは交換した後に写したものです。

image

元についていたのがこれ。

  • ピックアップの線
  • 回路への線
  • コネクタケーブルへの線
  • グランド

が入ってくるので、まぜこぜになりますが。元のボリュームを参考にして配線&半田付け。一回、白い線を間違えて「あれ、鳴らん…」と焦ったは内緒です。テスターを持ち出してあれこれ調べました。

image

zo-3 の良いところは、スピーカーが内蔵されているところでアンプが無くても鳴らせるところです。定価だと 3万円ぐらい。中古だと1万円位で買えます。オークションだと 5,000円前後まで下がりますが塗装剥げや鳴らなかったりするのが曲者です。

回路はアナログ増幅回路だけ(だと思う)ので、適当なエフェクトを自作できるかなと思ったり思わなかったり。スペース的には RasPi Zero か Arduino Nano あたりが入りますね。いっそのことスピーカーを外してしまって、液晶モニタを埋め込むのもアリかもしれません。

image

この zo-3 が底値で買えたのは(競合が誰もいなかった)、弦がなかったのとナットが無かったからですね、たぶん。ネックの先のほうで弦を支えているのがナットです。…って、私も交換したことはなかった(交換するものとは思わなかった)ので、いくつか調べて池袋のギター屋さんで買いました。いくつか専用の器具がいるらしいのですが、面倒なので鉄やすりと糸のこで調節しています。ちょっと、削りが甘くて(疲れてしまって)弦高が高めなのですが、まあブルースを弾く分にはいいか、というのでそのままです。

image

そんな訳で、きれいに音がなるようになった zo-3 です。

指板のすれは、以前使っていた人のものです。きれいに12フレットまですれているので、きちんと弾き込んで使っていたものですね。フレットは減っている感じですが、まあ構わない。ネックの反りはないので、たぶん弦を外して、どこかでナットが外れてしまったまましまい込んでしまったのかなと。

ひとまず、ライトニン・ホプキンスとジョン・リー・フッカーの真似事からスタート。和風ペンタとブルーノートの組み合わせは後日。

カテゴリー: ギター | zo-3 のボリュームを交換する はコメントを受け付けていません

和風ペンタトニックとブルーノートは酷似している

プログラミングするときの手癖もあるのだから、ギターで作曲をするときの手癖があるだろうと感じで、あれこれやっていたらやっと原因が分かったという話です。

和風ペンタ(日本五音階)については下記を見てもらうことにして(’80年代は YMO のテクノブームがあったので、そのあたりから流れたところが真相っぽいですが)、

和風ペンタトニック・スケール(ヨナ抜き)~日本人の深層意識に響く民謡・演歌な音階:のびやかな暮らし
http://bossanovaday.hamazo.tv/e5967160.html

同じく ‘80年代の頃にギターを覚えたときに、何故かブルーノートのスケールを弾いているのに途中で演歌っぽくなるのが不思議でした。

 

image

でもって、改めて開放弦を活用して書き出してみたのがこれ。コードを押さえてじゃがじゃがやらないので、開放弦なんか使わないのだけど、ブルーノートで E コードで弾いたときと、和風ペンタの G コードがほぼ同じなんだな。なので、途中で三連符を打ったときに、ブルーノートから和風ペンタになって、何故かブルースから演歌に移行してダサい感じになってしまうのです。

ジャズとかブルースは普通、G か A で演奏するので(A のほうがフレットが狭くて少し抑えやすい)のと、E はカントリーでよく使われる(開放弦をじゃかじゃかやる)。日本人以外には、和風五音階はなじみがないので、そっちには勝手に動かないけど、日本人には民謡が染みついているから、そっちにスライドしてしまう。1音半ずらせばいいので、あれこれと曲を弾いている間(ベース音がわからない間)は、ブルーノートなのか和風ペンタなのかが区別がつかないわけです。そして、どちらかのベース音が響くと、その瞬間にブルーノートになったり和風ペンタになったりする。

この部分は、実際に音を聴かないとわからないので、またあとで。

服部良一から渡辺岳夫の流れで完成された?

仮説ですが、ジャズやブルースを持ち込んだ服部良一が作った民謡や東京ブギウギを踏まえて、渡辺岳夫が作った「アタック No.1」や「魔女っ子メグちゃん」、「キューティハニー」を通して、その後のアニメ曲が作らてしまったのではないか、と考えています。まあ、最近のアニメの主題歌は JPOP だったりロックだったりするので、そこから外れていますが、いわゆるアニメっぽくない主題歌(ロボット系とかヒーローものは別)の感じはそこから出てきているのかなと。

編曲した後は別なんですが、主旋律を追っていくとギター特有の手癖が出てきます。運指の都合と、弾きやすさの都合から、ああやっぱりこの装飾音が効いてくるってな感じです。このあたり、同時期のアニメ曲と戦前からのジャズ/ブルーノートの流れを追っていこうかなと、主旋律だけを流してみたり。

人工知能的に和風ペンタを眺める

ここで、人工知能的に和風ペンタを眺めてみます。この話は、Electroharmonix フォントが何故、日本人に読めないのかを Tesseract-OCR で紐解く と同じです。Electroharmonix フォントは、カタカナをもとにしたアルファベットフォントなのですが、カタカナを知っている日本人には「カタカナ」に見えてしまって却って読めない。逆に、カタカナを知らない日本人以外にはアルファベットとして読める(と同時に、異国の「カタカナ」という文字にも似ているように思える)という訳です。OCR 学習をさせると、当然ですがカタカナを覚えさせたときには、カタカナにマッチさえつつ Electroharmonix フォントを読もうとするし、カタカナを教えずにアルファベットだけならば、アルファベットとして読もうします。

同じことが、ブルーノートと和風ペンタにも言えて、日本の民謡で育った日本人(育ってないひともいるからw)には、ブルーノートを弾いても、和風ペンタとごっちゃになってしまう。逆にそもそも日本の民謡を知らなければ、単に不思議な音階でしかなくてブルーススケールはブルースケールのままです。

試しに、ブルースの G コードでたらたらとフリージャズっぽくやっている間に、和風ペンタのヨナ抜きを入れると一気に演歌に聞こえてきます(リズム的にそうするのもあるけど)。でも、G のベース音を強調するように音を入れ替えるとブルースになるという不思議…というか、本能的にそうなってしまうところがあります。

で、機械学習で絵画とか文章はあるけど、音楽はちょっと難しいですよね。それらしく聞こえるとか、曲がいいとか悪いとか、そういうのはどういう「評価関数」を作るのか、どうやって「聴く」のかが思い描けないところがあります。Jukedeck – Create unique, royalty-free soundtracks for your videos. というのがあって、ある程度の曲調(コード)と転回だけ合わせておけばイージーリスニングっぽいものが量産できます。おそらく、既存の曲あるいは譜面を入れて、ブルースっぽくするとか演歌っぽくするのも可能かな(スケールとリズムを合わせれば、それっぽく聴こえるので)と思われるのですが、では、そこで「ブルースのように聴こえる」あるいは「和風ペンタのように聴こえる」とはどういうことか?という点が気になりますよね。

和風ペンタとブルーススケールの混在は日本人にしかないのだから、「日本人的な耳」を作って評価関数を作れば「既存のブルースが和風ペンタのように聴こえてダサい」と評価だろうし、「欧米人の耳」を作れば「ブルースだけに聴こえる」という感じになるかもしれません。このあたり、評価関数の取り方≒学習アルゴリズムになるので、将棋ソフトと同じようにソフトとによって戦略が異なる(将棋の場合、勝ち負けが明確なので、トップ以外の評価が難しいのですが)≒人によって指し方が異なる≒好みがある、と言えるでしょう。

ってなところまで考えたのですが、続きはもう少しブルーススケールとカントリーを演奏ってみてから。あと戦後のアニメ曲も。

カテゴリー: 雑談 | 和風ペンタトニックとブルーノートは酷似している はコメントを受け付けていません

Xamarin.Forms を XAML を使って書くために

昨日の続きを少し書き足しておきます。

Visual Studio Community 2015 で Xamarin.Forms を使う | Moonmile Solutions Blog
http://www.moonmile.net/blog/archives/7873

Xamarin.Android/iOS を使ってそれぞれのプラットフォームに向けて C# で書けるのはそれはそれで充分です。UI にしても最新機種にあわせる場合は、Java/Swift で書くだろうし、iOS のほうはタイムラグ無しで Xamarin.iOS が出ていたし、Android のほうも数週間ほどで追随してきます。おそらく、Xamarin が Microsoft に買収された今後も同じ方針でしょう。同じ方針だけど、プラットフォーム三社の思惑があるし、そこはどう動くかわからない。ただし、あまり「最新機能」にとらわれず、Android/iOS かつ UWP の3つのプラットフォームに対して同時にリリースすることを考えると Xamarin.Forms が非常に有効に働きます。v1 の場合は、実質 Android/iOS の二機種だったけど、v2 からは UWP が入ったので Android/iOS/Windows の三機種なのでメリットが大きいのです。

サンプルは XAML がコードで書かれている

Cross-Platform で PCL や Shared をすると、UI のサンプルコードも一緒についてきます。単純に画面に “Welcome to Xamarin Forms!” と表示するだけのものです。PCL(移植可能)なプロジェクトの App.cs に入っています。

public App()
{
    // The root page of your application
    MainPage = new ContentPage
    {
        Content = new StackLayout
        {
            VerticalOptions = LayoutOptions.Center,
            Children = {
                new Label {
                    XAlign = TextAlignment.Center,
                    Text = "Welcome to Xamarin Forms!"
                }
            }
        }
    };
}

見慣れたような見慣れないような、スタイルで ContentPage を構築します。WPF などでデザイナを使って XAML を書いたり、Android で AXML を使ったり、Xcode で storyboard を使ったりしていると「え?」な気分になるのですが…まあ、え?ってなります。

最初に断っておきますが、モバイル機種のような小さい画面の場合には、結構 XAML のコードベースで作業をするほうが楽だったりします。PC などの液晶モニタに対して画面が小さい(解像度は同じだったりするけど)ので、操作するボタンとかアイコンを細かく配置するよりも、おおざっぱに位置を自動計算させたほうがうまくいきます。また、Android 機種は画面がまちまちなのでそれに揃えるためにもフローレイアウトみたいな感じで作るといいですよね、って感じです。Web のグリッドシステムと同じ感じで作るほうが手早いし、Xamarin.Forms との相性もよいです。

Forms Xaml Page を追加する

これをXAML形式で書けるようにします。

  1. PCL のプロジェクトに「Forms Xaml Page」を追加します。

PCL プロジェクトに Page1.xaml が追加されます。

  1. Label の Text プロパティを「Welcome to Xamarin Forms!」に書き換える。
<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="App4.Page1">
  <Label Text="{Binding MainText}" VerticalOptions="Center" HorizontalOptions="Center" />
</ContentPage>

Binding を使って ViewModel を使うようになっていますが、ここでは Text プロパティを直接変更します。変更はちょっとずつやると解りやすいので。

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="App4.Page1">
  <Label Text="Welcome to Xamarin Forms and XAML!" VerticalOptions="Center" HorizontalOptions="Center" />
</ContentPage>
  1. App.cs のコンストラクタを書き換える。

追加した XAML が表示されるように App コンストラクタを書き換えます。

public App()
{
    // The root page of your application
    this.MainPage = new Page1();
}

MainPage プロパティに表示したいページクラスを設定すれば ok です。名前が「Page1」になっています。

これをビルドして実行するだけでエミュレータ上での動作が変わります。

試しにボタンのクリックイベントを付けてみる

XAML界隈では嫌われ者のコードビハイドですが、まあ手軽に作るにはこっちのほうが便利です。

XAML を書き換えて、x:Name プロパティにボタンとラベルに名前をつけます。これで、Page1 クラスのプロパティに追加されます。

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="App4.Page1">
  <StackLayout>
    <Label x:Name="text1" Text="Welcome to Xamarin Forms and XAML!" />
    <Button x:Name="btn1" Text="Click Me" />
  </StackLayout>
</ContentPage>

コードビハイドを書く。

public partial class Page1 : ContentPage
{
    public Page1()
    {
        InitializeComponent();
        this.btn1.Clicked += Btn1_Clicked;
    }

    private void Btn1_Clicked(object sender, EventArgs e)
    {
        this.text1.Text = "クリックした";
    }
}

ボタンの Clicked イベントにラムダ式で書いても良いし、イベント用のメソッドを作ってよいでしょう。

実行すると、こんな感じでボタンが効くようになります。

現時点の Hyper-V のエミュレータのほうは、以下のようなエラーが出て2回目以降のコード変更が反映されません。エミュレータ再起動するか、Android 内で対象のアプリをアンインストールするかの対処が必要です。

04-06 11:01:12.659 D/OpenGLRenderer( 2235): Use EGL_SWAP_BEHAVIOR_PRESERVED: true
04-06 11:01:12.661 D/GLHostConnection( 2235): Waiting for host to establish connection for PID 2235 (App4.Droid)
04-06 11:01:12.662 D/GLHostConnection( 2235): HostConnection::get() New Host Connection established 0x9c319f40, tid 2235
04-06 11:01:12.687 D/GLHostConnection( 2235): Waiting for host to establish connection for PID 2235 (App4.Droid)
04-06 11:01:12.711 D/GLHostConnection( 2235): HostConnection::get() New Host Connection established 0x9c6e3050, tid 2260
04-06 11:01:12.713 I/OpenGLRenderer( 2235): Initialized EGL, version 1.4
04-06 11:01:12.719 W/EGL_emulation( 2235): eglSurfaceAttrib not implemented

MVVM化する

このままコードビハイドで書いていっても良いのですが、どうせなので Binding を使って MVVM 化します。Clicked の ICommand はそのままにして、Label のほうだけ。

  1. ViewModel クラスを追加する。

PCL プロジェクトに ViewModel のクラスを追加します。いろいろ引き継いできた BindableBase を継承します。
ラベルに表示する文字列を Text プロパティで連携させます。

using System;
using System.ComponentModel;
using System.Runtime.CompilerServices;

namespace App4
{
    class MyViewModel : BindableBase
    {
        private string _text;
        public string Text
        {
            get { return _text; }
            set { this.SetProperty(ref this._text, value); }
        }
    }
    public abstract class BindableBase : INotifyPropertyChanged
    {
        public event PropertyChangedEventHandler PropertyChanged;
        protected bool SetProperty<T>(ref T storage, T value, [CallerMemberName] String propertyName = null)
        {
            if (object.Equals(storage, value)) return false;

            storage = value;
            this.OnPropertyChanged(propertyName);
            return true;
        }
        protected void OnPropertyChanged([CallerMemberName] string propertyName = null)
        {
            var eventHandler = this.PropertyChanged;
            if (eventHandler != null)
            {
                eventHandler(this, new PropertyChangedEventArgs(propertyName));
            }
        }
    }
}
  1. XAML で Binding を使う

Label の Text プロパティを Binding に変えます。

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="App4.Page1">
  <StackLayout>
    <Label Text="{Binding Text}" />
    <Button x:Name="btn1" Text="Click Me" />
  </StackLayout>
</ContentPage>

  1. ViewModel を BindingContext に割り当てる

いろいろ XAML+MVVM でどのプロパティが使われているのかが混乱していますが、Xamarin.Forms の場合は BindingContext という名前になっています。

public partial class Page1 : ContentPage
{
    public Page1()
    {
        InitializeComponent();
        this.btn1.Clicked += Btn1_Clicked;
        _vm = new MyViewModel();
        this.BindingContext = _vm;
    }
    MyViewModel _vm;
    private void Btn1_Clicked(object sender, EventArgs e)
    {
        _vm.Text = "MVVM でクリックした";
    }
}

これで無事 MVVM 化ができます。

本家のサンプル

本家のサンプルが github にあるので、ごっそりダウンロードして試してみるとよいです。

GitHub – xamarin/xamarin-forms-samples: Sample apps built using the Xamarin.Forms framework
https://github.com/xamarin/xamarin-forms-samples

これを何処に使うのか?

まあ、一般的な話で言えば Android/iOS のアプリを同時に作れるという話が順当です。が、もうちょっと話を飛躍させると、こんな感じになります。

「FlashAir+Arduino鉄道模型制御-1」 by 綾瀬ヒロ│MakersHub
https://makershub.jp/make/1030

綾瀬ヒロさんも Xamarin を使っていますが、この手のタブレット操作画面を作るのに Xamarin.Forms が有効なのです。スマートフォンじゃなくて、iPad や Surface、大き目の Android タブレット(候補としては Amazon タブレットぐらいしかないのですが)で操作系のアプリを作ろうと思うと、スマートフォンのような小さな画面とは異なった作りが必要になります。かつ、タッチパネル使える/必須なので、操作としてはスマートフォンっぽい感じで使えるのが良い訳です。
UWP が使えるので、Windows IoT Core on Raspberry Pi でも使えますよね(実際使える)。なので、このあたり UWP だけで閉じていれば、Surface, IoT Core 画面でデバッグができる&操作が同じにできるという話なのですが、もうちょっと Android/iPad に範囲を広げると Xamarin.Forms で画面を構成するのは結構有効です。IoT 絡みになれば、スマートフォンの通信や加速度センサーだけでなく、具体的に自作したセンサーの類を使えるわけですから、UI まわりをさっくりと作る(ある意味で、スマートフォンの最新機能には依存しない)ことができます。高めではありますが、Android 組み込みボードのほうでも Xamarin が使えるようになるとよいかなと思ったりしてます。

そのあたりを含めて、入門的に手を付けるのがお薦めです。

カテゴリー: 開発, Xamarin | 1件のコメント

Visual Studio Community 2015 で Xamarin.Forms を使う

//Build/ 2016 で Xamarin が Visual Studio で無償で利用できるようになりました。ということで、一応、素の環境から Visual Studio Community を使って入れます。

Windows で Xamarin 開発をしたい方はインストールする前に読んでほしい – Xamarin 日本語情報
http://ytabuchi.hatenablog.com/entry/2016/04/05/142525

田淵さんがスタート向けを書いてくれたので、私のほうは既存の Visual Studio に追加というスタイルで話を進めます。

 

Visual Studio Community 2015 をダウンロード

https://www.visualstudio.com/ja-jp/products/visual-studio-community-vs.aspx から Visual Studio Community をダウンロードしてインストール

image

最初のオプションで「C#/.NET (Xamarin)」を入れてもいいのですが、今回は既定のままインストールした後に Xamarin を入れます。

image

Xamarin をインストールしていない状態でプロジェクトを作ろうとすると

新しいプロジェクトで「Visual C#」→「Android」あるいは「iOS」の下にひとつだけプロジェクトがあります。この状態は、まだ Xamarin がインストールしていない状態です。

 

image

試しにプロジェクトを作って開くと、Xamarin のサイトからダウンロードせよ、というプロジェクトが開かれます。

image

Download ボタンを押して xamarin.com からダウンロードしてもよいのですが、ここは再び Visual Studio のインストーラ(vs_community_JPN)を起動して、改めてスイッチを設定します。

image

Xamarin をインストールする

「C#/.NET (Xamarin)」をチェック。UWP も作りたい場合は「ユニバーサル Windows アプリ開発ツール」もチェックしておきます。

image

Android が入るので Java も入りますね。Hyper-V の Android エミュレータも込みです。
この時点で「共通ツールおよびソフトウェア開発キット」を開いて

  • 「Android SDK セットアップ(API レベル22)」
  • 「Android SDK セットアップ(API レベル23)」

もチェックしておくと、後ろのほうにある Xamarin.Forms をビルドするときの不可思議なエラーがなくなります。ここではあえてチェックせずに進んで、わざと「ハマり」ますw

image

Xamarin がインストールできるとこんな状態になる。

image

「Cross-Platform」を選ぶと Xamarin.Forms を使える。

image

PCL でプロジェクトを作った直後

image

最初の Xamarin.Forms を動かしてみる

このままの状態で Xamarin.Forms をビルドして動かそうとするとビルドエラーになります。最初のテンプレートをダウンロードしてビルドしようとしただけなのに「何で動かないのこれ!?」と思うぐらい変な感じです。

image

Xamarin.Forms のバージョンは「2.0.06482」というちょっと古いものが使われています。

これ、ちょっと事情があって、

  • Xamarin.Android は、下位の Android に対応するためにいくつかの Xamarin.Android.Support.* を用意している。
  • Android SDK のバージョンは Xamarin とは別に更新される。
  • Xamarin.Android 本体と Xamarin.Forms ライブラリは、別口で更新される。
    NuGet Gallery | Xamarin.Forms 2.1.0.6529

という微妙な関係があって、タイミング的に Xamarin.Forms のビルドがうまく通らないことが多いのです。NuGet から取得すると Xamarin.Forms の依存関係は以下のようになっています。

image

最新の Xamarin.Forms 2.1.xx は、Xamarin.Android.Support.* の v23.0.1.3 に依存しているのですが、現時点で Xamarin.Android.Support.* の最新バージョンは  v23.2.1 なのが厄介なところです。さらに、Android SDK のバージョンが絡んでくるので、それぞれの最新版を利用しようとするとうまくいかないことが多いのです。

このあたりは、Xamarin.Forms 自体が OSS 化されるということなので、最悪は自前で Xamarin.Forms のビルドをして最新の Android.SDK に合わせる(正確には Xamarin.Android の最新にあわせる)スタイルになるでしょう。まあ、今後も Xamarin.Android のバージョンアップとタイムラグが出るのは仕方ないところです。

エラーのほうは、values-v23 と出ているので、Android SDK 6.0 が由来っぽいです。「ツール」→「Android」→「Android SDK Manager」を見ると、Android SDK 6.0/5.1 が入っていないので、これを入れます。

image

Visual Studio のインストーラーのほうに Android 6.0/5.1 がないのが問題じゃないかな…というか、良く見直せば「Android SDK セットアップ(API レベル22)」と「Android SDK セットアップ(API レベル23)」があるので、これにチェックを入れれば Android 5.1/6.0 が入りそうです。

image

この状態で、ひとまずエラーがなくなります。

Visual Studio Emulator for Android を使う

Android のエミュレータは、Hyper-V を有効にして Windows Phone と同じ感じで動くものをツあくとよいです。

どうせなので Android SDK 6.0 のものを選択してダウンロード。

image

実行すると、結構なスピードで動きます。

image

Google Play が入っていないこと以外は、だいたい実機と同じように動きます。逆に言えば、Google Play からダウンロードして試してみる、ってことをやる場合には実機か別のエミュレータを使います。

image

XAML はどのように書くのか?

Xamarin.Forms の売りは2つあります。

  • Android/iOS/UWP等の複数のプラットフォームの UI を一気に書けます。
  • XAML + MVVM で書けます。

複数プラットフォームの UI を共通化するのであれば、適当なコンバータを作れば UI の同時生成ぐらいはできるのですが、もうひとつの要素があわさっていることが重要です。UI の記述(この場合は XAML のコード)が「共通化」されたのであれば、それを内部的に動作さえるロジックも「共通化」できるだろう、という発想です。具体的には Model だったり ViewModel だったりするわけですが、現実問題としてはプラットフォームに依存した UI は共通化できないし、それぞれのプラットフォームごとに記述するしかないですよね。そのあたりも含めて、大まかなところは XAML で共通化させてしまって(ついでにロジックも共通になる)、別々なところはできるだけ小さくなるように設計をします。

で、もともとの Xamarin.Forms の UI コードが、コードに記述になっているので、どうせだから PCL に XAML を含めて書いてみようってのが次のステップです(これ自体がテンプレートで含まれてもいいと思うんだけど、含まれてない)。

image

これを使った例を後日。

カテゴリー: Xamarin | Visual Studio Community 2015 で Xamarin.Forms を使う はコメントを受け付けていません

ギター練習とプログラムコードの手癖

うっかりして ギター練習を再開しました | Moonmile Solutions Blog にプログラムコードの手癖の話を入れるのを忘れていたので追記。

楽器の「コード」とプログラミングの「コード」に引っ掛ける訳ですが、意外と通じるものがあります。というか、通じるようにやってます。

ギターの手癖

Julian Lage の講義の映像を見ると「こんな風に上がり下がりして、ギターらしく弾くところに留まってしまいますよね」という科白があります。オレオレブルースを引いてブルーススケールに慣れてくると、上がり下がりだけで満足してしまうことが多いです。先のストアアプリのギターソロ練習も、ヘビメタのそれらしいスケール(それはそれでギターリストの個性なんだけど)の早弾き方法がたくさん載っています。が、実際やってみると(そんなに早弾きできるわけではないし、きちんとできたらそれでそれで面白いのだろうけど)それらしくはなるけど、それ以上になりません。

人間の指の反応がどれくらいのスピードに耐えられるのか分かりませんが(32拍で区切ると、1/32だから 30msec ぐらいで弾くことになります)、まあ16拍(50msec程度)でオルタネイトすることもあるでしょう。というか、そもそも16拍すべてを打つ必要はなくて、11拍目に打てば、16拍を感じることができるという技もありますよね(4:8:11:16で打つと、12拍からずれた1拍分を16分として感じられるというあれです)。

そのあたりも含めて、ブルースのリズムに乗って弾けば「ブルース風」になるし、jazz スケールで引けば「jazz っぽく」聞こえます。フラメンコもカントリーもそれらしいリズムとスケールがあって、だからこそ「フラメンコ」や「カントリー」に分類されているという逆の意味もあります。フリージャズとか音楽理論とか、理論方面は別として、感覚的に「そう聞こえる」ということです。

試してみると、グレンミラーのリズムで弾くと、ブルーススケールでも「グレンミラー」のように聴こえます。また、アタックNo.1の最初の「くるしくたって…」の部分をブルースに入れると「アタックNo.1ブルース」が出来上がります。なんだかよくわからないけど、自分でやってて面白いのです。

「ガンダム」と「魔女っ子メグちゃん」と「アタックNo.1」の音を拾っていくと、作曲した頃の渡辺岳夫を感じることができます。「ああ、ここはギターの運指上、ハンマリングの音がなるよね」ってな具合で、ギターで作曲するときの癖が随所にでてきます。たぶん、ピアノの場合とは違った癖があって、逆にピアノの作曲でもそれ相応の癖がでると思うんですよね。それは、指の動きの「制限」であったり、作曲家の癖であったり、同時にソロ演奏するときの手癖であったりします。

くそまじめにメジャースケール、マイナースケールと練習するのもよいのですが(私の場合は、きちんとスケール練習していないので、スケールのほうをちょっとやらないとダメなんですけど)、自分の「こうなって、こういう音が鳴って、そして運指がこうなって」という繰り返しをしていくと、なんとなく自分の好きな指の動きが作れます。まあ、それで何が弾けるというわけでもないけど、10分ぐらいはソロ演奏やっていても「自分を」楽しませる程度には弾けるようになります。

プログラムコードの手癖

同じことはプログラムのコードにも言えます。コーディングする人の「性格」ではなくて、「手癖」のようなものですね。「性格」≒「手癖」は似た感じではあるのですが、「良い性格」「悪い性格」というのではなくて、その人を形作っている「手癖」(良いも悪いもない)というものです(まあ、性格に良いも悪いもない、という意味での「性格」ならば、それでも ok です)。

コードの手癖というのは、先のブルースケールやジャズスケールやカントリーのようなもので、その人の通奏低音みたいなものです。最初に C 言語を習った人は C 言語風にプログラムを書くし、Java だったら Java 風に書きます。C# だったら、 C# 風にって具合ですね。あと、Perl とか Ruby とか PHP とか色々あります。

ひとつのプログラム言語を一生使うことは稀なので、最初に習ったプログラム言語からそのほかの言語を覚えます。プログラム言語にも潮流があるのですが、プログラム言語を習う側にも潮流があるので、それが交差します。Java で C 言語風に書いたり、C# で Java 風に書いたりします。それぞれが、それぞれの潮流≒歴史を持っているのと、プログラム言語自体の歴史があるし、同時にこうありたいという個人の願望と、プログラム言語自体の願望があって、「いろいろな書き方」ができてきます。また、いろいろな制限を持ち込まれますよね。LINQ 禁止とかのアレです。

まあ、禁止事項は別として、一定の品質を保ったプログラムコードであっても、いろいろな書き方ができます。そういう時、新規の場合は「好みですよね」で済ますのですが、とあるコードに加筆するようになった場合(いわゆる改造とか改修案件とかいうものです)、もともとあるコード作成者の「手癖」をうまく延長しないと、そこだけ違った色合いになります。まあ、ガコっと欠けてしまったときには、速乾パテでも塗らないといけないわけで、時と場合によるんですが、できるだけ元コードの「手癖」をまねると、コードがなじみます。感覚的に言えば、元コードにうまくなじむので、なんとなく品質も高くなるし、再び同じ場所のコードを修正しようとしたときに、コードが修正しやすくなります。手癖が同じですからね。

コード規約とか、社内標準とか、補完機能を使って「強制的に揃える」のがよいのか、通奏低音としての「手癖」にあわせるのがよいのか、これも時と場合によるんでしょうが、どちらの使い分けがあってもいいですよね。

そういえば、ソフトウェア開発をオーケストレーションとして扱おうと思ったことがあるけど、それれぞれの演奏者は「プロ」の技を競うのだから、コーディングの協調性(ここでは「悪い意味での協調性」)を求められる時に困るし、いわゆるバックバンド的なスタイルでコーディングを求められることもあるのだから、ソフトウェア開発のオーケストレーションも一手段にすぎないのだな、と思い直したりしてます。

カテゴリー: 開発 | ギター練習とプログラムコードの手癖 はコメントを受け付けていません

ギター練習を再開しました

再開とは言っても、大学の頃と新人の頃にちょこっと練習していただけなので25年振りという感じですね。当時も今も、何を弾けるという訳ではないので何か疲労できるわけではないのですが(「東京ブギウギ」とか「アタックNo.1ブルース」とか変なブルースソロだけうまくなっています)、少し自由に楽器が弾けるようになると、プログラムとか電子工作の発想に良いかなと。年男なので48歳の手習いですね。

ちょっと自分のメモ用に書き残しておきます。

再開の発端は Julian Lage から

Julian Lage Workshop (Japanese Subtitles)
https://www.youtube.com/watch?v=pfOWWcQeP3Q

常々、死ぬまでにはカントリーとフラメンコぐらいは弾きたいと思っていたのですが、かといって何か対策をしている訳ではありません。ギターも引っ越した後に押し入れの中に突っ込まれたままでした。

ツイッターで勧めらていた Julian Lage のギター教室の映像なんですけど、彼は5歳からギターを弾いていて、映像現在で23歳です。映像自体が5年前なので、現在は28歳です。暫くジャズ・ギターの曲なんて聴かなかったのですが、これはすごい。演奏もすごいけど、彼の理論的な追及の仕方がすごいです。体系的に音楽理論を語っている訳ではないのですが、スポーツ選手が自分の走り方を科学するように、彼はギターの弾き方を科学しています。「科学する」ってのは、現象があって、それを再現できること、少し変えてみて試すことができることですね。漠然とギタースケールを弾いているのではなくて、次のステップにつなげるようにギターの練習方法を語ります。実に実践的です。

私が参考にしたフレーズ(彼の科白)を抜き出せば、

  • 6弦を低音/中音/高音の2本ずつに分けてフレーズを作る。これで、ギターを横に(フレット方向に)使える。
  • 横方向に長くスケール練習する。音が出る前は分からないので、音を聞きながら新しい組み合わせを読み取る。そして再現する(再現できないかもしれないけど、耳が覚えている)。
  • ギターの弾き方に制限があるけど、それは手で押さえることがぐらい。そして手癖がある。
  • ピックを持つ右手は、もっと敏感になれるから、ギター/弦から伝わるピックの圧力をうまく感じればオーケー。

ってな具合です。本当のフレーズは彼のビデオを見ると解ります。この探求の仕方に感動して、立て続けに3回ほど通してみて、2週間ほど練習しています。

服部良一に再会する。

山寺の和尚さん 歌詞と試聴
http://www.worldfolksong.com/songbook/japan/doyo/yamadera.htm

私の場合、基本的にオレオレブルースしか弾けないので、コードが弾けません。高校生の頃にフォークギターで指が痛くって投げたしたあたりからコードが押さえられません。まあ、今だと何となくコツがわかったので、オレオレブルースをやる分には大丈夫なぐらいなのですが、ふと「山寺の和尚さん」の突き当りました。

「カジノロワイヤル」をアマゾンプレミアムで見て、ああ、こういう音楽でもいいなと思いつつ、どうせならば「東京ブギウギ」ぐらいさかのぼってもよいだろうということで、さらに戦前までさかのぼります。大正、昭和ヒトケタまでさかのぼるのは、また別の意味があるのだけど「山寺の和尚さん」が服部良一のデビュー作であることを知りました。なるほど。こっちの路線でもよいわけです。

Julian Lage がエーデルワイスを弾くように、日本人が山寺の和尚さんを弾いてもよいわけで、昔なじみの民謡やおなじみの歌謡曲を jazz アレンジにしても良いですよね。矢野顕子も山下洋輔もやっています。

魔女っ子メグちゃんを弾いてみる

何故、覚えているのかわからないのですが、小学生の頃にリアルタイムで見た覚えがあります。なんか、オープニングの曲だけ印象的でずっと覚えていた曲なのですが、改めて調べてみると 渡辺岳夫 の曲でした。アタックNO.1 もキューティハニーもガンダムも彼の作曲です。

ギタースケールを練習していくと自分の手癖がわかります。弾きやすい運指と弾きにくい運指があります。オレオレソロをやると、どうしても弾きやすい運指に偏りがちですよね。おそらく、アニメの主題歌も作るときに手癖があるのじゃないか、と思ったりするのですが、どうやらあるみたいです。魔女っ娘メグもガンダムも同じ手癖で作られていることがなんとなく分かります。忙しい時期は、3日に1曲ペース(週に3日間スタジオにこもっていたらしい)っぽいので、もう頭の中のフレーズと手癖と好みだけでばりばり作っていく感じじゃないでしょうか。疲労のためか50歳半ばで亡くなっています。

そうやっていくつかの曲を真似てみると、世間的な音楽自体は5,6年という短いペースで流行が変わっていくけど、ひとりの作曲家/演奏家にとっては、当然のことながら3,40年という長いペースで音楽を作っていることがわかりますよね。ひとりの歌手/グループを追うのと同じでもあるし、彼や彼女が作る音楽の変遷というもの(それは学習だったり影響だったりするわけで)が現れてきます。

ウェス・モンゴメリーを改めて聴く

渡辺貞夫の最盛期をよく知らないのですが、サックス奏法がギターに取り入れらて、その逆もあるんでしょうけど、ウェス・モンゴメリー を改めて聴きます。 というか、ジャズ喫茶とかCD買ってたりして聴いていたのだけど、ああ、自分が生まれるより前の音楽なんですね。ってことは、オレオレブルース(B.B.キングの真似っこだったり)も、ずっと歴史をさかのぼっていってもいいのかー、っての分かって、昭和ヒトケタの日本から再開しているところです。

ギターで遊ぶために

ギターはまずコードを押さなければー、みたいな感じがしますが(まあ実際そうなんだけど)、コードをじゃかじゃかやっているだけでも音楽っぽく聴こえるのがよいところです。

GuitarStudio という iPhone のアプリがあってコードを指定してじゃかじゃかできます。本来はこんな音になるんじゃないかなぁ、と楽しむのがよいかと

iPhone Guitar Cover – Losing My Religion – YouTube
https://www.youtube.com/watch?v=yqgEl_Rt2lE&ebc=ANyPxKrVOPJsTWZkSi59VDdnBtRXGSDUjW8ohfoJHYnCy40I5ErwBWNxSLwYc-kc376ljVI2jsI7wN3L0Cw5LcWriz5sQr2ugA

Windows ストアアプリに教本っぽいものがあります。

ギターの練習で困るのは、運指をどうするかのですが、これだとスロー再生もあるので便利です。もちろん、youtube で運指をアップにしてもよいですよね。昔はビデオを買ってスロー再生だったので環境的にはよくなったかな。

「初心者講座」ってことになっていますが、どこまでの初心者wを対象にしているかわかりません。程よく弾ける人じゃないとついていけないんじゃないだろうか。けど、「~風」って発想が面白くて繰り返し見ています。

弾いてみよう!カントリー風(アコギ編)【ギター初心者講座】 – YouTube
https://www.youtube.com/watch?v=GKZEV102Ry8
弾いてみよう!フラメンコ風(アコギ編)【ギター初心者講座】 – YouTube
https://www.youtube.com/watch?v=8O1uIAuCcWY
アコースティック ソロギター道場|メロディ・パートとベース・パート by J-Guitar.com
http://www.j-guitar.com/ha/solo/index.html

リズムを合わせればそれっぽく聴こえるってことの実践ですよね。

そうそう、ぼちぼちタブ譜のほうでもやってみないと。

DLmarket / 【TAB譜】マクロス フロンティア (娘たま♀)15曲+おまけ4曲セット アコースティックギター伴奏譜 [ダウンロード版]
https://www.dlmarket.jp/products/detail.php?product_id=305177

カテゴリー: 雑談 | ギター練習を再開しました はコメントを受け付けていません

往年の Turbo C++ を触ってみよう

もうちょっと前に書こうと思っていたのですが、Turbo C++ のフリー版があるよ、ということで記事を残しておきます。

Turbo C++ or C for Windows 7, 8, 8.1 and 10 32/64-bit Full Screen Free Download – Home
https://turboc.codeplex.com/

Windows 10 でも動くので、そのままダウンロードしてインストール。起動すれば ok です…が、全画面になってしまうのが困りものなので、起動時に「full screen mode…」のチェックを外します。するとウィンドウモードで動きます。ただし、カーソルが取られてしまうので、Ctrl+Tab で他のウィンドウにフォーカスを移してください。なんか Tab キーが暴走してしまいますが。

かれこれ30年前の C++

私が大阪で大学生をやっていた頃なのでかれこれ30年前のことです。マンデルブローを描きたかった頃(確かCマガジンで特集をやっていたような気が)に N88 BASIC で組むと遅いから C 言語で組むんだということで、日本橋に行って買いました。店頭で「Turbo C++ を下さい」というと、冒頭のように「X1 Turbo」を出されたのは良い思い出ですが、きちんと Turbo C++ も出てきました。確か、2,3万円で買えたと思います。当時、MS-C が高値の華で8万円ぐらいした頃なので以上に「安かた」んですね。LSI-C 試食版があったような時期なんですが、実行サイズに制限があったので買うしかなかったという感じです。いや、正確に言えば、Unix が出てきて、Minix が動いたか動かなかったかで、Linux が出たか出なかったの頃なので gcc はあったような気がします。実際、2年後ぐらいには、研究室で DOS/V 機に Linux を入れてワークステーションにログインさせていました。

当時、貴重な1台しかもっていない PC98 RX に DR-DOS(MS-DOS の互換OSですね)を入れて、ぽちぽちとプログラミングしたり大戦略したりしていました。そうそう、大戦略していた頃の神戸大震災に遭ったのでした。たまたま、午前5頃までゲームともプログラミングともつかない生活をしていたので地震があった当時に起きていたのですが(机が50cmほどずれました)、寝ていたら本棚の下敷きになっていたと思います(まあ下敷きになる程度で死ななかったとは思いますが)。

そんな頃の C++ なのですが、この Turbo C++ はきちんと「統合開発環境」になっています。そうそう、当時「emacs は環境である」というセリフが流行ったのです。emacs の中でプログラミングもできるし、メールも打てるし、シェルも動かせるというやつですね。それと同じように、Turbo C++ には付属のエディタがついてて、この中でコードを書いたりコンパイル&実行をしたりすることができます。上の画面キャプチャを見るとわかるんですが、コードに色がついています。今の IDE のように候補がでることはありませんでしたが、キーワードには色がつきました。あと、テキストベースのウインドウを重ねることで、複数のソースコードを開くことができました。

当時の Macintosh にはマウスが必須でしたが、MS-DOS(DR-DOS)の時代には、まだマウスはついていませんでした。ついていませんでしたが買って、マウスドライバーを乗せることでテキストベースではありますがマウスカーソルを動かすことができました。

ノスタルジー以上のもの

昔はこうだった…の本が流行っているようですが、感傷(ノスタルジー)以上のものではないので、もう少し前向きな話をしましょう。

見て分かる通り、Turbo C++ の環境には上部にメニューがあります。メニューの位置がウィンドウに張り付いたり、Mac のように上に張り付いたりしますが「メニュー」があるという点では同じです。当時、Windows 3.1 が出た頃に MDI/SDI という概念があってダイナミックメニュー(メニュー自体が切り替わる)という方式が生まれましたね。その頃から DocView パターンがあったし、GoF の原著をみれば MVC パターン自体が相当古いところからある概念だということがわかります。それはともかくとして、

  • 上部にメニューがある。
  • メニューが階層化されている。
  • モーダルダイアログがでる。
  • ウィンドウがあって、前面と背面がある。

のような基本的なところは今の Windows でも変わっていません。当然、Visual Studio もその形を踏襲しています。この画面は Turbo C のものですが全体的にこの傾向は変わりません。Linux の X-Window ですら同じスタイルです。

じゃあ、このスタイルが完全であり将来的にもよいもの≒効率のよいものなのか、というとあまりそうとも言えません。ツールバーがついたり、MS-Office にリボンがついたり、スタートボタンがあったりなかったりする時代を考えれば、常に試行錯誤の段階であることは明白です。Windows が最初に出たころ(Macintosh が世間に浸透した頃かもしれません)に、科学的なユーザーインターフェースの指針としてマウスの動きとか、目の動きとかを使って「有利である根拠」を示したものもありました。当時、私もそういうものに気を使っていた時期もあるのですが、今考えれば「対案が出ていない」時点であまり科学的とも言えなかったのでは?と感じています。そう、比較対象がないんですよね。

Squeak のメニューの出し方は独特で、カーソルの周りにメニューアイコンが出ていた…ような気がするんですが、別の言語でしたかね?今だと、ふつうのコンテキストメニューが出てきます。まあ、そこは他のOSとの操作感の兼ね合いでもあり、淘汰でもあるのですが、現在のメニューシステムはキーボードとマウスを中心にして作られているので、スマートフォンやタブレットのように指先を使うとか別の入力デバイスを使うときには別の方法があるはずなんですよね。実際、スマートフォンのスクロールはマウスを使ったスクロール方法とは違うし、指を2本使ったピンチのような拡大縮小はマウスではできない方法です。そういう、新しい入力デバイス(タッチパネル≒指)が出てきたときに初めて、Turbo C++ の開発環境のようなメニューやウィンドウの表現との「決別」ができるのではないかな、と思っていますし期待しています。

じゃあ、VR のように仮想空間でこねこねしながらプログラミングするのがよいのかとか、仮想キーボードを使って仮想ターミナルを開くのがよいのかという模索もありますが(実際、あれは面白いし、なんかそっちの方向に行きそうな気もしています。空中に浮かんでいる複数画面の映像はあの VR 空間で実現できますよね)。

Scratch をはじめとするブロックプログラミング環境にしても、条件分岐の書き方とか非同期動作の書き方とか(実は Scratch はイベントを非同期で発生させられる可能性をもっています。今も非同期で動いている?)まだまだ書き方はたくさんあります。特に if 文が一次元(コードを書く方向≒文章を書く方向)であらわされていますが、多数に分岐させて2次元に遷移図として展開させることは可能ですよね。Unity のスクリプトがそんな感じです。

MDA(モデル ドリブン アーキテクチャ)を再開するならば(私は再開してもよいと思います)、ブロックの内部実装(低レベルの詳細実装≒戦術)と、ブロックを組みあわせる問題解決の層(高レベルの実装≒戦略)とは分けて考えてもいいのではないでしょうか。実際、Azure の機械学習はそれに近い感じになっています。そういうところを考え合わせると、マウス以外の入力デバイス(タッチパネル,VR 空間、その他のアナログな入力デバイス)も併せて、もう少し「過去とは断絶した」開発環境ができるのではないかな、と思ったりしますし、それを作りたいなと。

カテゴリー: 雑談 | 往年の Turbo C++ を触ってみよう はコメントを受け付けていません