音声認識による音声の文字化という視点からお話させていただきます。
HoloToolkit-Unityが5.6.1f1対応になりました。
HoloLensでのMIxed Realityアプリ作成に不可欠なUnity。そのUnityでMixed Realityアプリを作成するときに便利な機能を提供してくれるのがHoloToolkitです。
最新のUnityは5.6.1となります。そして、HoloToolkitが5.6.1f1対応になりました。
アセット自体は
こちらの方からダウンロードできます。Unityで使うならアセットの方が使いやすいかな。
Unity自体はこちらから。
build 2017雑感
build 2017も残すところあと1日となりました。
1日目、2日目のキーノートとセッションに参加して感じたことは、AI - Cognitive、HoloLens、Xamarinということでしょう。
そしてすべてのセッションには英語字幕がついている(これ、音声認識なのか、どこかに会場音声を飛ばしてキー入力している人がいるのか不明。後者なのかな)点も見逃せませんでした。
今回の会場は道路を挟んで2つの建物で行われていました。キーノートや展示会場もあるWCC側のセッションでは手話通訳者の人がスピーカーの話す内容を手話にしていました。もちろん、キーノートでも。
AI - Cognitive
画像認識を使って危険予知や体調を推測するなど、Cognitive Serviceで提供されている機能を使うことで、人の気配りを機械にさせることができるようになるかもしれません。
疲れることも気分にも左右されない機械がいろいろなところに入ってきて、それによって生まれた余裕を使って臨機応変の部分で人が対応できるような未来が感じられるのが今年のbuildの特徴の1つでしょう。
そしてもう一つの未来がキーノートで紹介されたマイクロソフトリサーチの研究
パーキンソン病の症状の1つである手の震えを二軸のモーターで相殺する腕時計デバイスです。動画中にもあるような小型化できたのも、機械学習による成果と言えるでしょう。
HoloLens - Microsoft Mixed Reality
今までは文字通り箱入り娘のようだったHoloLensですが、今回のbuildの展示会場では、普通のブースにもHoloLensを展示している企業さんがいて、HTCやOculusのように気軽にかぶせて自分たちのアプリを体験させていました。
そして、Microsoft Mixed Realityに準拠したAcerのHMDの体験コーナーもありました。AcerのHMDですが、HoloLensのように単体動作ではなく、PCに接続して使う従来型のHMDです。ですからHoloLens向けに作成したアプリをローカルコンピュータで実行すればAcerのHMDに表示されるという寸法です。
Mixed Reality AcademyでもHoloLensとAcerの両方が試せました。同じアプリが両方で試せるのは素晴らしいですね。Acer HMDですが今までにない綺麗さでした。いわゆるフルダイブ型ですが装着感もいいし、これでVRコンテンツをプレイしたら楽しいかなと思いました。
Mixed Reality Academy #MSBuild pic.twitter.com/EusLWhZRgy
— はつね (@hatsune_) 2017年5月12日
Xamarin
そして今年もXamarin界隈は元気ですね。セッションもたくさんあるし。
Visual Studio for MacがGA(正式提供)されたり、Xamarin Live PlayerやXAML Standardなどのいままでかゆかったところに手が届くような発表もあり、今後もXamarin界隈は元気な感じですね。
■Xamarin Live Player
AndoridやiOSでの実行(画面表示?)をシミュレートしてくれるインタープリター環境です。VMのように重たくもないし、実機デプロイと違って、Visual Studio側での変更もリアルタイムに反映ができます。
もちろん、シミュレーターや実機のように厳密には動作が違う部分もあるかもしれませんし、(実はインタープリターなのでMacなくてもPCだけで)iOS画面が確認できるといっても、まだまだ基本的なXAMLページしか対応できていないし、実機デプロイやストアへの登録はMacが必須なのは変わりませんが、この方向が示されただけでも、また、初学者の人が入門記事を試すのにも最適化なんじゃないかな。
■XAML Standard
現状、Microsoft XAMLとXamarin XAMLは同じように書けそうで、コントロール名が違っていたり、プロパティが違っていたりします。そこで、XAML Standardという考え方を入れて共通化していきましょうというものです。
私としては、コントロール名やプロパティ名を共通化するときに、全部、Microsoft XAMLによせるのではなくて、例えば、VisibleプロパティなんかはIsVisibleプロパティのようにXamarin XAMLにしてもらった方がConverter書かなくていいのになーと思ったりするので考慮してほしいなぁーと思ったりもしています。
それ以上に期待するのが、各プラットフォームごとに動きの差異が最小になるようにしてほしいという点です。それができるならば、コントロール名やプロパティ名が違うくらい外側の話ですから使う側でいくらでも補完できます。
若干、今回のXAML Standardの発表を否定的にとらえているようなコメントもTwitter上で見かけますが、build現地の空気感や使う側の開発者にしてみれば、XamarinがMSに買収されたときから【長い間】「こうなるはずだよね?」と思っていたことが【やっと公式に表明】されたという点が大きいわけで、個人的にはそれこそ去年のbuildで表明されてもよかったくらいだと思うので、それは素直に評価して喜んでいいじゃないかって思うところです。
ゴースト・イン・ザ・シェル
ということで公開初日だったのでみてきました。
士郎正宗的な光学迷彩って、そうそうこんな感じ!このノイズが入る感じが素敵!
街は明るいブレードランナー市街地って感じで、これもGood!
で、少佐ってもう少し少女っぽいイメージだったんだけれど体形が…ってのは置いておいて。
バドーいいね!バドー。
あと電脳ダイブする瞬間の映像もいい感じ。
何よりももうMR!MR!MR!な世の中素敵ですよ。
実家にあるブラックマジック初版本とかアップルシード初版本とかまだ保存されているかなー。
さて、初音は、高校進学したときに同じ中学出身が過去にも将来もいないような高校に行ったので(実家暮らしだったけど)そこで人間関係リセットしちゃったし、大学も高校の人間関係あまり引きずらなかった(とはいえ、仲が良かった同級や先輩とは今も年賀状やりとりしている)。そういえば仕事で入札にいったらN社の担当者が高校の同級生だったことはあったわ。
そんな感じなので同窓会とか小学校、中学校、高校、大学も一回も行ってない(いや、そもそも開催されているのか?)わけで、そうなってくると色々昔の記憶が霧に包まれている感じになって、実家に帰って散歩しても都内なのにシャッター商店街があるくらいさびれているところだし再開発も進んでいるので、あれれ?って感じだったりと、「私の過去はなんだろう」的な不安感にリアルに陥ったりできるわけです。
今は、きっとネットがあるのでそういったことも少ないでけれどね。
だから、この作品のとあることがすごくよくわかるというか、見終わった後のエンドロールみているときに妙な不安感に襲われちゃいましたね。
まあ、そんなことで、私の魂はシェルの中にあるかなーということで。
そうそう。荒巻課長もよかったですよ!
MicrosoftのTranslator Text APIもDNN翻訳に対応しています(しかももっと簡単にお安く)
上記より抜粋
--
ニューラル ネットワークによる翻訳は、音声 API およびテキスト API を使用する開発者が使用できます。
- 本日より、音声 API 呼び出しでは、すべてニューラル ネットワークが利用されます。
- テキスト API 呼び出しでは、標準カテゴリー (標準カテゴリーの詳細についてはこちらを参照してください:英語)「generalnn」を使用し、サポートされている 10 言語の任意の組み合わせを使用することで、ニューラル ネットワークを利用できるようになります。
--
ということで、Microsoft Azure Translator Text APIであればFreeプランであってもCategolyにgeneralnnって指定するだけでニューラルネットワークによる翻訳がビシバシ使えちゃいます。
これ使わない手はないですねほんと。
Translator Text APIを使うためにはAzure Poralでキーを取得したら、コードでキーからトークンを作ります。
トークンの作り方はこちら。
https://github.com/MicrosoftTranslator/GetAzureToken
トークンができたらそれをAuthorizatonヘッダに設定して
http://api.microsofttranslator.com/v2/Http.svc/Translate?text={0}&from=|1|&to={2}
のような感じで呼び出せば翻訳結果を取得できます({0}には翻訳したい原文、{1}にはjpなどの原文言語コード、{2}にはenなどの翻訳先言語コード)。
Xamarinで作ったAndroidアプリをGoogle Playストアに登録する
Visual StudioでXamarinを使ってAndroidアプリを作成してストア登録するときの手順が最近(2017年3月末)変わりました。
以前の方法
以前であれば、[ツール]-[Android]-[Publish Android Application]メニューでダイアログを立ち上げて、そこでKeystoreなどを選択してapkファイルを作成しました。
そして、apkファイルを手動でGoogle Play Developer Consoleにアップロードして公開していました。
新しい方法
新しい方法では、ソリューションエクスプローラーでAndroidアプリのプロジェクトを右クリックして、そこで[Archive]を選ぶ方法に変更されました。
[Archive]メニューを選ぶとArchive Managerが立ち上がり、該当プロジェクトのアーカイブが進行します。
この時、ソリューション構成は[Release]を選択しておきましょう。
ビルドがうまく通ればapkファイルが所定のフォルダに作成されます。
ただし、このapkファイルは未署名のものなので、そのままではGoogle Playストアに登録できません。
[Distribute]ボタンを押して署名を行いましょう。
Select Channel
Ad HocなのかGoogle Playなのか配布方法を選びます。Google Playストア経由で配布するので[Google Play]を選択します。
Signing Identity
署名を行います。
Keystoreファイルがすでにあるならば[Import]ボタンをクリックしてファイルを取り込みます。
既存のKeystoreファイルがないのであれば[+]ボタンをクリックして、新規にKeystoreファイルを作成します。
Alias:別名など(プロジェクト名とか)
Password:パスワード
Validity:25以上の数字。1000とかでもOK。
Full Name:発行者のフルネーム
Organization Unit:部署名(個人なら入力しないでもOK)
Organization:会社名(個人なら入力しないでもOK)
City:市区町村区名
State:都道府県名
Country Code:JP
Google Play Accounts
Google Playストアに登録するアカウントを指定します。
Google PlayストアにログインしているIDとパスワードではなく、Google API AccessのClient IDとClient Secretを指定します。
これにはGoogle Play Developer Consoleにログインして「APIアクセス」のところでOAuthクライアントを作成してその認証情報からコピペします。
Google Play Track
ここまでできたら、アルファ版、ベータ版、段階的公開、製品版のどれで公開するかを指定します。
少し説明が必要そうなのは、段階的公開(Rollout)でしょうか。これはバージョンアップ版の公開を一度にすべてのユーザに対して公開するのではなく、徐々に公開していく方法です。
こうすることによって、致命的な障害があった場合に全台に影響がないようにします。また、新バージョンの最初の起動の時だけにアクセスするようなデータがあった場合の負荷分散にもなります。
段階的公開が必要なくらいの利用者数があるアプリとか夢のようですよね。
新しい公開方法は以上です。
以前に比べるとGoogle Play Developer Consoleへの配置までできるので便利ですね。
Visual Studio 2017がローンチされました
Visual Studio 2017がローンチされました。
インストールが早い!
Visual Studio 2017をインストールしようとしてまず驚くのはインストール時間の早さです。
「何をしたいか」を選ぶことで必要な機能のみがインストールされます。
起動が早い!
そしてインストールして起動するとさらに驚くと思います。とにかく起動が早い。
体感で半分くらいの起動時間になっているのではないでしょうか?
かっこいいコードに仕立てあげるまでが早い!
リファクタリングが強力になっていて、例えば、次のような初期化部分をかっこいい(どこからどこまでが初期化コードであるかがわかりやすい)形にリファクタリングする提案をしてくれます。
ユニットテスト実施が早い!
ライブユニットテストという新機能が楽しいです。
ユニットテストを記述しておいて、それに対してグリーン(要はテストが通る)となるコードを書き始めたとしましょう。コードを書いていてビルドエラーがなくなるとユニットテストが自動的に行われてテストが失敗した行に「X」が表示されます。もちろん正しいコード(つまりグリーンになる)に修正すれば自動的に「X」は消えます。
これって、仕様を満たしたコードになった瞬間がわかるってことです。コードを書いている途中で実はグリーンになっていたのにそこに気づかずに書き進めてユニットテストしたらグリーンじゃなかったとなるよりも早く正解のコードにたどり着けると思います。
もちろん、これ以外にも様々な新機能があります。
使い始めたらVisual Studio 2015には戻りたくなくなりますし、「VS?いいんだけど起動遅いし」という今まで避けてきた勢も評価を改めることになるんじゃないかなって思いました。