Microsoft MVPを再受賞しました。最近は新規受賞者は毎月審査して発表、継続受賞者は1年に一度7月1日に発表となっています。
たしかここ2年ほどAzureカテゴリでの受賞だったのですが、今年はAzureとDeveloper Technologiesの2つのカテゴリで受賞となりました。
今回で8度目の受賞らしいのですが、最初の受賞からしばらくはC#(とそこから名前が変わった.NETなど)カテゴリでの受賞でした。2年ほど前からAzureカテゴリでの活動も増えたのでAzureカテゴリのみの受賞になったのですが、今年は両方のカテゴリで受賞することができました。正直、片方ずつだと活動量たりないかも？と思っていたので非常に驚いています。
今年も昨年に引き続き、Azure、C#、Q#あたりの分野で活動していく予定です。特にQ#はオンライン化が進む中であまり活動できていないので、さっそくなにかやろうと考えています。
活動もますますオンライン化が進む1年になりそうですが、引き続きよろしくお願いします。
しばらくQ#の記事を書いていなかったのですが、最近のQ#の更新でC#のクラスが不要になっていたので久しぶりに記事を書きたいと思います。
少し古い記事ですが、Q#プロジェクトというのは、プロジェクトとしては.NET Coreのプロジェクトで、エントリポイントとなるMainメソッドを含むC#クラスが存在し、そこから呼び出されるＱ#のソースが存在する構造でした。
ですが、今年4月にリリースされたVersion 0.11.2004.2825からこのC#クラスが不要になりました。
例えば最新のQ# SDKでプロジェクトを作るとこのような構造のProgram.qsファイルとcsprojファイルのみのプロジェクトが作られます。
namespace Quantum.QSharpCompilerExtensionLab {
open Microsoft.Quantum.Canon;
open Microsoft.Quantum.Intrinsic;
@EntryPoint()
operation HelloQ () : Unit {
Message("Hello quantum world!");
}
}
この@EntryPoint()というのがC#のMainメソッドに相当するものになります。これがどのように動くのかが気になるので、コンパイル（トランスパイル）結果を見てみましょう。最新のバージョンでもQ#コードはいったんC#にトランスパイルされてからコンパイルされます。C#としての出力は、/obj/qsharp/src以下にあります。
このProgram.g.csのほうが以前と同じQ#コードをC#コードにトランスパイルしたもののようです。もう一つのProgram.EntryPoint.g.csのほうがMainメソッドを含むエントリーポイントのためのコンパイル結果です。実際にはこのようになっています。
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
namespace Quantum.QSharpCompilerExtensionLab
{
using System;
using Microsoft.Quantum.Core;
using Microsoft.Quantum.Intrinsic;
using Microsoft.Quantum.Simulation.Core;
internal class __QsEntryPoint__ : Microsoft.Quantum.CsharpGeneration.EntryPointDriver.IEntryPoint<QVoid, QVoid>
{
public string Summary => "";
public System.Collections.Generic.IEnumerable<System.CommandLine.Option> Options => new System.CommandLine.Option[] { };
public string DefaultSimulator => "QuantumSimulator";
public EntryPointInfo<QVoid, QVoid> Info => Quantum.QSharpCompilerExtensionLab.HelloQ.Info;
public IOperationFactory CreateDefaultCustomSimulator() => throw new InvalidOperationException();
public QVoid CreateArgument(System.CommandLine.Parsing.ParseResult parseResult) => QVoid.Instance;
private static async System.Threading.Tasks.Task<int> Main(string[] args) => await new Microsoft.Quantum.CsharpGeneration.EntryPointDriver.Driver<Quantum.QSharpCompilerExtensionLab.HelloQ, QVoid, QVoid>(new __QsEntryPoint__()).Run(args);
}
}
MainメソッドはDriver.Runというメソッドを呼び出しており、このDriverクラスが以前のQ#プロジェクトで書いていたC#クラス内の処理を行っているように見えます。また、SummaryやDefaultSimulatorみたいな項目もありますが、現状@EntryPointにパラメーターを渡せないで、この辺はまだ変更できなさそうです。もしかすると今後のバージョンアップで機能追加されるかもしれません。
本記事はMicrosoft MVPブログ企画の記事として投稿しています。その他の記事はこちらからご覧ください。
昨日、オンラインでTeamsとVisual Studio Live Shareを使ったオンラインハンズオンを開催しました。
Visual Studio Live Shareを使ってコードを見せながらオンラインハンズオンをやるのは割と便利だったのですが、少し注意しないといけない点もあったのでまとめてみます。Live Shareの概要についてはこちらを。
Live Shareはペアプロみたいな用途を想定されていると思われるかもしれませんが、読み取り専用アクセスでも共有できるのでハンズオンのような講義用途も想定されています。
Visual StudioおよびVisual Studio Codeでお互いに共有できるのでいずれの環境でも見ることができます。またプレビュー版ですがブラウザからアクセスすることができます。
.NET Coreというクロスプラットフォームな開発ツールのハンズオンだと、参加する人は自分の普段使っているデバイスを使いたいわけですが、それを実現することができます。
TeamsなどWeb会議ツールを併用すれば、今説明しているコードそのものを見せることは可能です。IDEで共有することによって、さらに見ているコード近辺の気になる部分であったり、参照関係にあるコードなどを自分の好きなタイミングで見ることができます。この時説明している人のコードを見失っても、参加者一覧の中の説明している人をダブルクリックすることでそのコードに戻ることができます。
今までも、クラウド環境などを使って同一環境を複数準備して、それぞれにログインしてもらってハンズオンを行うという方法はありました。ただ、クラウドのコストがかかったり、環境を作るのが手間だったりしました。Live Shareであれば、基本的には自分がハンズオンの手順通りにコードを書いていくだけで、それをそのまま共有することができます。今回用意したのは、このリポジトリだけです。
共有ローカルサーバーという機能があって、自分がプロジェクトをデバッグ起動したとき、そのポートに参加者の方がアクセスするようにできます。
また今回あまり活用できませんでしたが、シェルを共有する方法もあります。
デフォルトだと5名までしか参加できません。設定変更で最大30名になります。
今回は、テスト接続時に5名までの上限にぶつかって、設定確認したところ30名への引き上げがすでに有効になっていたので、動かないのではと不安になりました。結局Visual Studioを再起動したら5名以上参加できました。
まもなく音声やチャット共有がサポートされるらしいのですが、またリリースされていなかったので今回はTeams会議を併用しました。
オフラインだと会場をスタッフが見て回ってうまくいっているか確認できますが、オンラインだとこちらから確認する方法がありません。ですので、参加している方が困ったときにすぐヘルプを求める方法を用意しておくのがよいです。Live Shareを逆向きに（参加者の方が自分の画面をスタッフに共有する）するのもありですし、zoomのブレイクアウトセッションが使えるのであればデスクトップを共有することも可能です。（Live Shareだとコードを直接編集できる、デスクトップ共有だとLive Shareに行く前のトラブルシューティングも対応できる、と異なったメリットがあります） なお、参加者の方がLive Shareする場合、MicrosoftアカウントもしくはGitHubアカウントでログインしておく必要があります。
今回は初回ということもありうまくいかなかった点もありますが、改善していけばかなりオンラインハンズオンも十分に運用できる見込みが立ちました。参加していただいた方、ありがとうございました。
