はてなブックマーク

※最終更新日: 2020/5/24 正式リリース版に対応修正しました。 1. Blazorとは 公式Docsでは以下のように書かれています。 Blazor is a framework for building interactive client-side web UI with .NET 「Blazorは、.NETでインタラクティブなクライアントサイドWebユーザーインターフェイスを構築するためのフレームワークです。」ってことですね。 エンジニア的には、抽象的なモヤモヤ感のある文章ですね。 具体的に出来ることを簡単に言うと、今までJavaScript(+各種JSフレームワーク)でやってた事を、.NET Core(つまりC#)で作ることができるよ、ってものです。 「JavaScript(or TypeScript) + React」とか「JavaScript(or TypeScript)

1. はじめに ごめんなさい。タイトル負けしている内容なので先に謝っておきますm( )m Flutterも大分成熟したようで正式版リリースが待ち遠しいですね。 日本でも、もう既にプロダクトに採用されている事例もあるようでアーリーアダプターではない私も手を付け始めています。 新しい言語、新しいフレームワークなどに手を付ける場合、一番つまずく可能性が高いのは入り口の部分ですよね。 そこをクリアすれば、その技術のテーストが理解でき、感覚的に前に進めるものです。 ということで、この投稿では「何も入っていない、まっさらな MacBook にFlutter開発環境を構築するまで」の軌跡を たらたら ペタペタ 記述＆貼り付けしていきます。 今回使った環境： macOS High Sierra(初期インストール直後) 2. コツ？ Flutterの開発環境構築は 公式サイトの説明 及び 診断コマンド（fl

1. はじめに 以下のような構成のスマホアプリを作ってみようと思います。 一般的な、HTTP経由でサーバと通信するタイプのスマホアプリです。 で、タイトルの通り「OpenAPI 3.0でWebAPIを定義」し「golangでWebAPIを実装」し「Flutterでスマホアプリを実装」する、ということをしたいと思います。 また、OpenAPI 3.0定義からサーバ及びクライアントコードを自動生成するために OpenAPI Generator を使用することとします。 github.com 今回利用した環境 macOS Mojave 10.14 Flutter 0.8.2 go 1.10.3 openapi-generator 3.3.2 2. 準備 Flutter / go 環境は構築済みの前提とします。 openapi-generatorは以下のbrewコマンドでインストールします。 $

2017/3/11、「Visual Studio 2017 リリース記念勉強会 & まどすた #2」に参加してきました。 1コマ目のセッションとして、岩永 信之(@ufcpp)さんの「C# 7」セッションを聞かせていただきました。 C# 7の新機能について非常に細かく説明していただきましたが、その中で Tuple についてフォーカスしてブログっておきます。 ※以下は、セッションでの解説内容ではなく、それを受けて私が調査した内容になります。 Tuple は戻り値が複数の時に便利 ということで、C# 7 で使い勝手がよくなった Tuple ですが、複数の戻り値があるメソッドで使うのが最も美しい使い方だと思いました。 （Tupleは乱用すると見通しの悪い、属人 巧 のコードが生成される可能性があると思っているので） では、以下のCompanyクラスをベースに説明を進めます。 // 会社クラス p

本コンテンツは「Azure Cosmos DB入門」の（２）です。 ryuichi111std.hatenablog.com 2 Cosmos DBの主要概念 前回の「Azure CosmosDB入門（1）」では、Cosmos DBの「特徴」と「Hello Cosmos DB」と題した簡単なサンプルについて説明しました。 早く具体的なデータベース操作に入りたいところですが、その前にCosmos DBを利用する上で押さえておきたい主要な概念について説明します。 ここでは、各技術要素の説明に関して「主要概念」の範囲にとどめます。 RU(Request Unit)やパーティショニングなどは、より複雑な内容を理解する必要がありますが、それは「Azure CosmosDB入門（4）」で説明する事とし、ここではCosmos DBプログラミングを始めるための概要を理解することを目的とします。 2.1 デ

本コンテンツは「Azure Cosmos DB入門」の（３）です ryuichi111std.hatenablog.com 3 Cosmos DBプログラミング ～ DocumentDB編（前編） 3.1 まず、はじめに 3.1.1 DocumentDBとSQL 3.1.2 REST API(DocumentDB API) と クラスライブラリ 3.2 準備 3.2.1 Cosmos DB(DocumentDB)データベースアカウントの作成 3.2.2 Visual Studio 2017プロジェクトの作成 3.2.2 データベースとコレクションの作成 (1)接続情報等の定数定義 【コラム】プライマリキーとセカンダリキー (2)基本名前空間のusing定義 (3)接続クライアントオブジェクトの定義 (4)データベース作成メソッドの追加 【コラム】CreateDatabaseIfNotExi

本コンテンツは「Azure Cosmos DB入門」の（１）です。 ryuichi111std.hatenablog.com 1 Cosmos DBとは Cosmos DBはAzureで提供されるデータベースサービスの1つです。データベースの種類としては、いわゆる「NoSQL」データベースとなります。 公式ドキュメントにおいては、まず以下のように説明されています。 「グローバル分散可能なマルチモデルデータベースサービス」 1.1 特徴 Cosmos DBの代表的な特徴は以下ような点があげられます。 グローバル分散可能 柔軟なスケーリングが可能 超高速な応答速度 マルチデータモデル 多様な一貫性モデル 高いレベルのSLA 上記項目について、それぞれ順番に見ていきましょう。 1.1.1 グローバル分散可能 Azureは世界30ヶ所以上のリージョンでサービスが提供されています。Cosmos DB

本コンテンツは「Azure Cosmos DB入門」の（８）です ryuichi111std.hatenablog.com 8 Cosmos DBをもっと知りたい 8.1 一貫性レベル(Consistency Level) CAP定理 多くの分散型NoSQLのアプローチ 8.1.1 Cosmos DBの提供する一貫性レベル（Consistency Level） (1) Strong（強固） (2) Bounded Staleness（有界整合性制約） (3) Session（セッション） (4) Consistent Prefix（一貫性のあるプレフィックス） (5) Eventual（最終的） 8.1.2 既定の一貫性レベル 8.2 RU(Request Unit)詳細 8.2.1 RUの設定方法 8.2.2 消費RUの確認方法 8.2.3 RU/s超過時のレスポンスコード429 レスポ

「Azure Cosmos DB入門」目次 DocumentDB が Azure Cosmos DB としてリニューアルされたので、改めてこのサービスの全体像を整理したコンテンツ（ブログ）を「Cosmos DB入門」として書こうと思います。 目次は以下の通り。順次コンテンツを追加していく予定です。 ※ 2017/07/09に(1)～(8)のコンテンツが揃いました。今後もCosmos DBのトピックをブログに継続してエントリーしていきます。 Azure CosmosDB入門（1） 1 Cosmos DBとは 1.1 特徴 1.1.1 グローバル分散可能 1.1.2 柔軟なスケーリングが可能 1.1.3 超高速な応答速度 1.1.4 マルチデータモデル 1.1.5 多様な一貫性モデル 1.1.6 高いレベルのSLA 1.1.7 Cosmos DBは自分たちが普通に使うものか？ 1.2 Hell

MSDNブログ（↓↓↓）で Azure Functions 関連の記事を見たので自分でやってみました。 blogs.msdn.microsoft.com 上記ブログに記述されている事、そして今回自分で試した事を要約すると以下の内容です。 Azure FunctionsをVisual Studio 2017で開発＆デバッグする（つまりローカル実行するということ） Azure Functionsをクラスライブラリとしてビルド＆パブリッシュする 1 は、まあ 開発効率を上げるということですね。 Azure Functions自体はAzureポータルでコーディングできますが、本格的実装はローカルで行いたいですよね。 2 は、クラスライブラリとしてアセンブリ（dll）にしてデプロイすることで実行パフォーマンスを上げる意味を持ちます。 Azure Functionsは5分間非アクティブであるとアイドル

Visual Studio 2017がいよいよ正式リリースされました。 個人的感想としたは「超目玉！！！」な機能は、感じられていないのですが、個々の技術要素は非常に興味深く思っています。 昔に比べて、各情報は小出しにリリースされるので上記のような感想を持つ形になるのでしょう。昔は大きな区切りで一気にいろんな機能がリリース、という流れだったので・・・ で、今回はVisual Studio 2017を利用し、ASP.NET Coreアプリ を Docker Support で開発実行してみようと思います。 Docker for Windowsのインストール まずは Docker for Windows をインストールします。 以下のURLにアクセスし Stable channel 版をインストールすればOKです。 Install Docker for Windows - Docker Docu

ASP.NET Coreにおける構成情報（ユーザー定義の構成）の読み込みについて記述したいと思います。 ということで全体のアジェンダは以下の通り。 従来のASP.NETでの構成ファイル ASP.NET Coreでの新しい構成ファイル JSONファイル形式 階層型データ形式 INIファイル形式 XMLファイル形式 複数構成情報ファイルのオーバーライド オプションパターンによるオブジェクト構成とDI 従来のASP.NETでの構成ファイル アプリケーションでは多くの場合、外部の構成設定を利用します。 DB接続先設定であったり、動作モードであったり、フューチャーフラグのようなものであったり・・・ハードコーディングしたくない諸々の設定情報をビルド対象外の構成ファイルに記述します。 従来のASP.NETでは Web.config という仕組みが用意されていました。 Web.configには「ASP.N

（非常にピンポイントな話題ですが）Xamarin FormsのStackLayoutにおける、子コントロールの配置で、「VerticalOptions(HorizontalOptions)」指定時の動きについて纏めたいと思います（特にExpandsに焦点を当てて）。 このネタ、先日の「Xamarin.Forms本 邦訳読書会 #2」にて私が「どんな動きでしたっけ？」と言って、皆さんを（闇に引き込み）こんな動きだよーと口頭で説明していただいたものなんです（でも、誰が説明しても分かりにくい的な話もあり、やはり、厳密には自分でコーディング＆実行で検証する必要がありました） xamarinformsbookreading.connpass.com VerticalOptions / HorizontalOptions プロパティ 「VerticalOptions / HorizontalOptio

こんな事ないですか？また、初心者な人、悩む事ないですか？的な記事です。 プロジェクトへの「パッケージ参照（アセンブリ参照）追加」は、Visual Studio などの統合開発環境を使用しているとGUI操作のみで完了してしまいます。 しかし、CLIやVisual Studio Codeを使って開発をしている場合、project.json もしくは .csproj ファイルに手動で参照の追加を記述する必要があります。 【補足】project.json と .csproj 2016.11.23現在、.NET Coreではバージョンによってプロジェクトファイルの形式をproject.json形式としているバージョンとMSBuildの.csproj形式としているバージョンが混在しています。今後は .csproj 形式に統一（移行）すると見られます。 利用したいクラスのヘルプ及び名前空間を調べる 例え

昨今の開発言語やフレームワークにおいて「データバインディング」は非常に重要で有益な技術となっています。 Xamarin Formsにおいても データバインディング がサポートされており、これは WPF / Silverlight などから引き継がれた技術になります（といっても、詳細についてはWPF / Silverlight / Xamarinでは実装内容・実装レベルが異なりますが・・・WPFではDependencyPropertyであったものが Xamarin FormsではBindablePropertyであったり・・・）。 データバインディングは、Xamarin Formsアプリを開発するすべてのエンジニアが利用する技術だと思います。 そして、手軽に利用することもできるし、結構深い技術であるとも思っています。 自分自身の知識の整理も含めて、これから何回かに渡って「Xamarin Fo

AutoMapperも既に.Net Coreへの対応が行われております。 ということで、ASP.NET CoreでAutoMapperを動かしてみたいと思います。 テスト環境 テスト環境はMacで、dotnet --info の結果は以下の通りです。 ryuichi:coreMvcAutoMapper daigo$ dotnet --info .NET Command Line Tools (1.0.0-preview2-1-003177) Product Information: Version: 1.0.0-preview2-1-003177 Commit SHA-1 hash: a2df9c2576 Runtime Environment: OS Name: Mac OS X OS Version: 10.12 OS Platform: Darwin RID: osx.10.12-x

Entity Framework Core 1.1 Preview1でのCode First（コード・ファースト）による開発（というか、まず初めにC#でモデルクラスを定義。モデルクラスからデータベース定義を自動生成の流れ）について見ていきたいと思います。 「コード・ファースト」という言葉については、ここでは詳細は触れません（ググればいっぱい出てきますよね・・・）。 簡単にいうとソフトウェアを開発するにあたり、「リレーショナルデータベース設計ありき」ではなくて「作成するソフトウェアの”ドメイン領域の分析”に注力し、データベースはモデルのあるタイミングにおけるシリアライズ結果を保存する入れ物」的な考え方が基本となっていると思います。 リレーショナルデータベースとドメインオブジェクトは、その概念の相違から「インピーダンス・ミスマッチ」が発生することは必然であり、ソフトウェア側の人間としては、ドメ

.NET Coreのいくつかの開発環境・ランタイム環境のDockerイメージ（Dockerfile）はMicrosoft公式としてDocker Hubで公開されています。 microsoft/dotnet - Docker Hub ターゲットOSは Linux のものと Windows Server 2016 Nano Server がありますが、ここでは Mac(OSx)をホストとして Linux サーバー .NET Core開発環境を作成したいと思います。 では、上記URL内の「1.0.0-preview2.1-sdk」を利用したいと思います。 下準備 Macのターミナルを開き「/Users/daigo/docker」ディレクトリをベースに進めていきたいと思います。 また、Dockerコンテナには、プログラムソースの作成・保存場所として、ホスト側（Mac）の「/Users/daigo/

2016/5/19に ASP.NET Core もRC2になりましてGo-live licenseも付きました。と、いうことでASP.NET Core 1.0について整理しておこうかな、と。 個人的にはK runtimeと言われたあたりからちょろちょろっと注目し始めて、RC1から本格的に見始めた感じです。 まず、本記事ではASP.NET Core 1.0とは何なのか？について概要を整理しようかと思います。なので具体的なプログラムは登場しません。 ASP.NET Core 1.0の歴史 まず、ASP.NET Core（というか、.NET Coreというもの）は2015年あたり（？）から新しい.NETランタイムとして「Kランタイム」なんて言われていていましたね。で関連コマンドについても、その後、BETA４かBETA５あたりで「K」→「DNX」との名称変更があり、RC２からは「DNX」→「dot

ASP.NET Coreでは「DI(Dependency Injection)」を基本として使用するアーキテクチャが採用されています。 DI自体は古くからある考え方であり、Javaなどでは昔から、そして今でもメジャーに使われている技術です。 勿論 .NET 開発者の間でも利用されています。古くはSeaserコンテナから始まり、MEF(Managed Extensibility Framework)、Unity、Ninject、AutoFac・・・等いくつものDIコンテナが存在しています。 DIは基本的に「特定の具象クラスに依存した実装を行わない」ことを実現します。つまり、あるオブジェクトAがあるオブジェクトBを使用する（依存する）場合、Aの中で直接 new B() のようなことはしないのです。 以下が非DIな実装です。ShoppingCartControllerクラスは、ShoppingC