5はなかなか意欲的なバージョンです。過去のプロジェクト構成を完全に捨て去っていくスタイルです。私は去年の暮れ*1に割とがっつり調べたのですが、その後に大きく変わった最近の状況にあまりついていけていませんでした。いうわけで最近の事情について調べた個人的メモです。vNextと呼ばれていました。5では、過去バージョンにあったWindows縛り・.NETランタイムのバージョン縛りや同一サーバ上への複数バージョンインストールに関する厄介事から解放されることになっています。実行環境自体がポータブルになり、サーバ上へのSxSデプロイも超絶簡単(容量面でもコンパクトかつバージョン競合を避けられる方式になる)になるというのが目玉です。Coreプロジェクト)はざっくりと2つに分けられます。軽量かつクロスプラットフォームなサーバ向けランタイム(CoreCLR)の開発クラスライブラリの整備(CoreFX)CoreFXでは画面描画系をごっそり無視しています。Environment)です*2。Coreプロジェクト自体が発表されておらず、非Windowsのクロスプラットフォーム動作においてはMonoを利用するという流れでした。Xを現状で不安定版サポートしている)の64-bitサーバ用環境として育っていくCoreCLRを見ていると不思議な気持ちでもあります。DNXでは依然.NETアセンブリの実行やアプリケーションコードのビルドにMonoを利用するランタイムオプションを提供していますが、Mono側のバージョン固定が多少面倒な部分は否めません*3。5の実サーバ運用においてはMonoが絡むシーンは少なくなっていくのでしょう。Runtimeと呼ばれていたものが改称されました。Monoに関しては基本的にどんどん最新版を使っていけばいいのですけれど。CoreベースのDNXがマトモに動作しないケースも多いため答えを出すまでもないのですが、私はおおむね中期(-3年)まではNo、と考えています。Coreが担っていくことは基本的にMonoとXamarinにとっても良いことと見えます。Monoの太古の需要のひとつは非Windows環境でのASP.NETシリーズ実行だったと記憶していますが、この領域は2015年時点でXamarinのビジネス領域から外れています。現時点のXamarinのビジネス領域は確実にモバイル向けのC#開発環境(可能な範囲でのクロスプラットフォームと共に)で、この領域で同社のリソースを振り向けたいことは山ほどあるはずです。そんななかで(外から見ている分には)Xamarinにとってのサーバ向け領域は「できればそろそろやめたい」エリアと見えます。CoreCLRが進化の果てに他領域(たとえばiOSでのfull-AOTサポート)までを広くカバーするようになり、CoreFXについてもGUIツールキットとの連携または取り込みと各OSの膨大なAPIライブラリに対するまともなバインディングが生えてきたとすると、「ん?これXamarin要らんのでは?」となる世界も想定はできます。innovationとなる可能性がありますね。それはつまりMicrosoftが本気でXamarinを殺しにかかっているタイミングで、おそらくは相応の資金を投入してXamarinを買収することによって実現すると考えるのが妥当に見えます。そのへんはきっと先の話なのでよくわかりません。機能的には以前調べたタイミングからあまり変わっていません。dnvmコマンドRubyのrbenvやNode.jsのnodebrewに相当するコマンドです。ホームディレクトリの下に.dnxというディレクトリを作成し、その下へ各バージョンのランタイムを突っ込んでいくスタイルです。Managerの略とされています。前述のポータブルなランタイムをネット上から拾ってきていい感じにシステム上へ配置し、複数のランタイムを共存させたり利用するバージョンを切り替えたりするために使います。ランタイムのアップデートなどがコマンドひとつで完結するので、これまでの.NET系環境と比較するとかなり楽という感じがします。今のところ非Windows環境でのデフォルトランタイムはMonoです。CoreCLRを明示してインストールするためには-r(-runtime)オプションでcoreclrを指定する必要があります。Xの場合)を使ってバイナリを実行していく流れです。以前はkvmというコマンドでした。kvmって他の用語と被りすぎにも程があるという感じのものだったのですが、dnvmとなりました。他のコマンドも芸なく先頭にdn(.NETの意)と付いて4文字になったのか、と思いきやそんなことはないので安心してください。dnuコマンドNode.jsのnpmに相当するパッケージ管理系を担うコマンドです。以前はkpmという名前で、そのまんまでした。DNXのアプリ定義ファイル(JSON形式)に記述されている依存ライブラリをネット上から拾ってきたりできます。依存ライブラリ管理のみではなく、buildというサブコマンドを使うとアプリのソースをもとにアセンブリを作成できたり、publishを利用するとアプリをデプロイ用に固めたりということができます。publishかけてrsync一発で動くような楽な感じの構成はとても良いですね。packサブコマンドを使うとプロジェクトのNuGetパッケージを作成できます*4。MyGetでの自社向けアプリコード配信とか、なかなか手軽な策になりそうで期待が持てます。Utilityという、色々と諦めた感じの命名です。CoreCLR環境では生成に失敗しますが、同Monoではうまく生成できます。dnxコマンドdnvmコマンドで拾ってきた.NET実行環境のエントリポイントとなるのがdnxコマンドです。X)環境で拾ってきたMono版のdnxコマンドの実体は前述のようにシェルスクリプトですがCoreCLR版は普通にMach-Oのバイナリです。以前はkreというコマンドでした。X)環境でのx64利用について考えるとDNXと組みにするのはMonoよりもCoreCLRのほうが今後楽しそうです。X環境で64-bitランタイムを使いたいシーンではMonoよりも扱いやすいです*6。X向けの通常ダウンロードで64-bit版バイナリを提供していない(自前でビルドはできる)ためですが。CoreCLR+DNXは、実行環境の取得・バージョン固定・アップデートが楽という特性により、クロスプラットフォームなコマンドラインツール*5を作るための優れた基盤となり得るものです。「クロスプラットフォーム動作するユーティリティをサクサク作りたいけどJavaScript書きたくないな〜〜」という人々の大半はPythonが2と3でゴタついている間にgolangへ行った感がありますが、そこC#でもよくね?と考えていくと夢が広がります。環境をあまり汚さずに導入できるし、Mac用の導入手順が公式サイトにある(http://docs.asp.net/en/latest/getting-started/installing-on-mac.html)のでMacの方も試してみて「なるほどなるほど〜〜」となってみると楽しいかも、という感想でした。あ、グラフィックス(GUI)系を扱う必要がある場合にはMonoを使うという具合です。いうかCoreCLRはまだきちんと32-bit構成持たないんじゃないかな。JIT実行にRyuJITのみを使ってるのなら。私の現時点でのPetaLinux認識は次のとおりです。Xilinxが提供しているカスタムLinux構成管理ツール兼カーネル・rootfsビルダー。Dockerで簡単にGPU対応のTensorFlow入りコンテナを作る方法こんにちは。作品群を読んでいたら連休が終わりそうです。本ページで記載している内容は100V、12Aという大電流を扱うものです。パーツの組み方や運用の仕方によっては火災や感電へ発展する危険があります。通りハングアップしました。2.0(AOA2.0)についてかなり久々の翻訳です。昨年末に同人ハードウェア製作をしていたのですが、自前設計の基板に正しく信号が流れているのか確認するのに苦労することが何度かありました。MacBookを4/10に注文、4/14出荷、届いたのは4/17だったので正確にはもうすぐ2ヶ月ですが。資料を補足するシリーズです。途中でやったことや、参考情報を書いていきます。APIのモックを作ったよー。ライセンスの下に提供されています。