VMware 仮想マシンを Hyper-V へ移行する これまで、Windows の開発環境で VMware Workstation Player (個人利用では無償バージョンを利用することができる) を使って開発用の仮想化環境 (Ubuntu Linux マシン等) を用意していましたが、 新しい PC の購入に伴い、開発環境を引っ越しすることにしました。 この引っ越しに伴って、仮想化マシンも Hyper-V へ引っ越しすることにしました。 Ubuntu OS の VMware 仮想マシンを Hyper-V へ移行するには以下の手順で行います。 VMDK 形式の仮想ディスクを VHD/VHDX 形式への変換 新しい仮想マシンを作成 (変換した仮想ディスクをアタッチする) open-vm-tools のアンインストール (オプション) 第2世代 Hyper-V 仮想マシン用の仮想ディスクへ変換 (オプション) Secure Boot の有効化 Hyper-V 統合サービスのインストール ステップ 1: VMDK ディスクを VHD/VHDX ディスクへ変換する VMware 仮想マシンでは仮想ディスクに VMDK 形式を利用しているため、Hyper-V 仮想マシンで利用できる仮想ディスク形式 (VHD/VHDX) とは異なります。 Hyper-V で同じ仮想ディスクを利用するためには、VMDK 形式を VHD/VHDX 形式に変換する必要があります。 仮想ディスク VMDK 形式は、マイクロソフトが 2014 年にリリースした MVMC (Microsoft Virtual Machine Converter) 3....

以前の記事で VSCode Server を使った開発サーバーについて触れましたが、この記事では、具体的なセットアップ方法について触れます。 セットアップ Visual Studio Code のサーバー機能(VSCode Server リモートトンネル)を使って、コード開発サーバーを構築します。 このコード開発サーバーでは、リモート環境の VSCode デスクトップアプリ版またはウェブ版からリモート開発を行うことができます。これによって、iPad などのモバイルデバイスのようにVSCode アプリをインストールできない環境でもリモート開発ができるようになります。 VSCode のインストール 自宅に余っている Windows コンピューター (8GBメモリ, 256GB SSD) があったので、このコンピューターを使ってコード開発サーバーをセットアップすることにしました。コード開発サーバーは、Ubuntu Server 22.04 LTS を使うことにます。 現在は VSCode Server 機能は VSCode バイナリに含まれてるため、VSCodeをインストールすることにします。 # Add a GnuPG trusted key for Microsoft package repositories curl -sLS https://packages.microsoft.com/keys/microsoft.asc | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/microsoft.gpg # Add VSCode repository sudo add-apt-repository "deb [arch=amd64] https://packages.microsoft.com/repos/vscode stable main" # Install VSCode (stable) sudo apt install code # Install VSCode (insiders) sudo apt install code-insiders VSCode の Webサイトからバイナリを直接ダウンロードしてインストールすることも可能です。...

Visual Studio Code (VSCode) の開発の進化がすごい！ VSCode Web (vscode.dev) VSCode は、Microsoft によって開発され 2015 年にベータ版がリリースされた、オープンソースのコード開発の統合プラットフォームです。 当初は、商用版の Visual Studio 統合開発環境 (IDE) から、コンパイラやビルドツールを除いて、コード開発部分だけに注力したアプリケーションとして公開されたような位置づけでした。その後は、コード整形、文法チェック、テストなど様々な機能のためのプラグインの充実、コンパイラやデバッガを実行するためのターミナルセッションとの統合などにより、完全な統合開発環境として Windows だけでなく macOS, Linux でも動作する、開発者にとっては素晴らしい無料のアプリケーションとなっています。 2021年10月の vscode.dev の発表 でウェブブラウザーでも利用できるようになり1、iOS/Android などのモバイル OS 環境でもブラウザーを使って開発をすることができるようになっています。 GitHub Codespaces 当初のウェブ版の VSCode は、GitHub 上の Git リポジトリのコードの閲覧や編集に利用できましたが、GitHub Codespaces サービスのリリースにより、クラウド上でホストされた仮想マシンの開発環境を使って開発・テストなどの作業が実行できるようになりました。この GitHub Codespaces には、個人用アカウントに含まれる月間ストレージとコア時間が含まれているので、限られた時間内では無料で開発ができます。 このクラウド型のサービスでは、ソースコードやワークスペースは仮想マシン環境に配置されるため、個人のローカル環境におく必要はなく、複数のコンピューターを使い分けるシーンでもシームレスに開発を継続することができます。 VSCode Server - Remote Tunnels GitHub Codespaces と同じような開発環境を自前で用意できないものかと考えていたところ、2022年7月に VSCode Server のリモートトンネル機能のベータ版がアナウンスされました。 この機能は、これまでにリリースされたリモート接続による開発とは異なり、vscode.dev とコード開発サーバーの間にセキュアなトンネルを確立する方式のリモート接続による開発となります。 任意の物理環境や仮想環境で VSCode Server サービスを起動し、リモート環境の VSCode (デスクトップアプリ版またはウェブ版) からリモート開発を行うことができるようになります。VSCode Server リモートトンネル機能のアーキテクチャは以下のようなイメージと想定されます。 元々、2013年に発表された Visual Studio Online (コードネーム ”Monaco") の活動と Microsoft による GitHub の戦略的な統合がクロスした瞬間ではないでしょうか。 ↩︎

経営する企業のブログページで掲載したオリジナル記事 ("ビデオストリーミング技術の紹介") の転載です。 ビデオストリーミングの歴史 インターネットの普及に伴い、様々なシナリオで色々なビジネスに、デジタルビデオがあたりまえのように利用されていますが、デジタルビデオ技術はこれまでに様々な歴史を紡いできています。 2000年代から様々なビデオストリーミング技術が各社で開発され、色々な技術が世の中に溢れていきました。独自のプロトコルで独自のサーバー・クライアント技術を使ったストリーミング技術が開発され、それぞれの技術に精通する必要があり大変な時期でした。これらの技術では、再生するビデオやオーディオの品質はクライアントとサーバー間の通信で制御することもできましたが、ルーター製品やネットワークアドレス変換 (NAT) などのネットワーク環境によって、通信ができないなどの制限もありました。 と同時に、加速度的に普及する HTTP 技術とビデオストリーミングの親和性のために、2000年代後半に、HTTP ベースのアダプティブストリーミングのビデオ配信技術が各社で開発されました。ストリーミングの世界は、アダプティブストリーミングにより、これまでのビデオストリーミング技術がアップデートされました。単純な HTTP ダウンロードでビデオをファイルを再生する際には、たとえビデオをダウンロードしながら再生できたとしても、ビデオのダウンロード速度（ネットワークのバンド幅）とビデオの品質の関係が問題になってきます。 つまり、ビデオの品質（ビデオの1秒間のデータ容量）がダウンロード速度（1秒間にダウンロードできる容量）よりも遅い（大きい）場合は、ビデオの再生が追いつかず、ビデオが途中で止まってしまうということになります。 この問題を解決しようとするのが、アダプティブストリーミングという技術です。 アダプティブストリーミングでは、ビデオを複数のセグメントに分割し、分割したビデオごとにダウンロードして再生することを基本としました。1つのビデオのセグメントは、例えば、2~10秒という長さのビデオで、これらの分割したビデオセグメント群を様々な品質（ビットレート）と解像度でそれぞれ準備することで、ビデオを再生するプレイヤーは、ビデオを配信する Web サーバーとの通信の速度や状態によって、どの品質と解像度のビデオセグメントを再生するか選ぶことができるようになります。 この技術によって、再生するクライアントは、接続しているネットワークのバンド幅に合わせて、再生するビデオの品質をスイッチしながら再生することができ、途中でビデオが止まることがなく再生することができるようになります。 また、HTTP ベースのストリーミングであるため、HTTP キャッシングが可能な CDN (コンテンツ デリバリ ネットワーク) を使って、ストリーミングサーバーの負荷を最小限にしながら、大規模なエンドユーザー向けにビデオストリーミングを配信することができます。 アダプティブストリーミング アダプティブストリーミングとして、当時、3つのストリーミング技術が開発され、それぞれの技術では、ライブ、ビデオオンデマンドのどちらのビデオ配信シナリオをサポートし、専用のクライアントプレイヤーがそれぞれ用意されました。 Adobe HTTP Dynamic Streaming (HDS) Apple HTTP Live Streaming (HLS) Microsoft Smooth Streaming 当時の HTML 技術には、<video> タグや <audio> タグは定義されておらず、リッチメディアと呼ばれるビデオなどのメディアは、ブラウザーのプラグインを使って実装されたプレイヤーで再生されていました。このため、多くのユーザーに向けて配信するためには、コンテンツの配信側は、それぞれのプラグインに対応する3つのストリーミング方式に対応する必要がありました。 モバイルデバイスの普及、マルチデバイス化とともに、ビデオストリーミング技術の標準化やクライアントの標準化が課題となり、様々な企業がビデオストリーミングの技術の発展に寄与してきました。 ビデオストリーミング技術の標準化においては、MPEG-DASH (Dynamic Adaptive Streaming over HTTP) は、2012 年に最初に国際標準として制定されたアダプティブストリーミング技術で、Microsoft や Adobe は、これまで培った技術と経験をベースに、この MPEG-DASH の技術の開発に貢献しました。また、Akamai, Ericsson, Microsoft, Netflix, Qualcomm, Samsung が設立メンバーとして設立した DASH Industry Forumという団体において、標準化された MPEG-DASH 技術に関するマーケットで実際の互換性問題の解決や推奨事項のガイドライン化などを行いながら、技術の普及につとめています。...

はじめに この記事では、Wowza Streaming Engine での HLS 方式でのストリーミングに関する 技術的に詳細な設定・カスタマイズの方法について触れます。 HLS プレイリスト (マニフェスト) について HLS プレイリストには、EXT-X-VERSION タグと呼ばれる Apple HLS (HTTP Live Streaming) のプレイリスト互換性バージョンを示すタグが含まれています。 Wowza Streaming Engine の HTTPStreamer の既定の設定では、Apple HLS 互換性バージョン 3 のプレイリストを生成します。 #EXT-X-VERSION:3 VOD またはライブアプリケーションの Application.xml (/usr/local/WowzaStreamingEngine/conf/[アプリ名]/Application.xml) 内の 以下のパラメーターで HLS プレイリストの互換性バージョンを制御することができます。 Wowza Streaming Engine では、バージョン 3 から 6 までをサポートしています。 項目 内容 XML パス /Root/Application/HTTPStreamer プロパティ名 (Name) cupertinoExtXVersion プロパティのタイプ (Type) Integer プロパティの値 (Value) の説明 プレイリストの互換性バージョンを指定する (既定値: 3) Wowza Streaming Engine では、指定された EXT-X-VERSION (プレイリストの互換性バージョン) に基づいてプレイリスト機能を有効または無効にすることができます。...