きよくらの備忘録

「三日坊主と呼ばせない!日記」改め。主にソフトウェア開発関連の話題。

書籍レビュー:改訂新版JavaScript本格入門 ~モダンスタイルによる基礎から現場での応用まで

Twiterで行われてたWINGSプロジェクトの書籍レビュアー募集に応募し、献本いただきましたので少し遅くなったのですがレビューを書かせていただこうと思います。

 

体系立て無理なく入門できる本

全体的に丁寧に図示も交えながら体系立てて解説されているので、タイトルの通りJavaScriptをきちんと学習できる書籍だと思います。いわゆるサイ本などと比較すると言語仕様の深い部分での言及などは少ないですが、入門や脱初心者を目指すのであれば十分なレベルの内容だと思います。

他の初心者向けの入門書やWebサイトの入門者向けの記事などを見ながら始めてみた人が、ちゃんと文法や言語機能などに向き合い始めるのは最適の一冊ではないでしょうか。

 

改定の最大のポイントはES2015

この本は2010年に出版されたこちら https://www.amazon.co.jp/dp/4774144665 の改訂版でそちらも所有しているのですが、大きな改定ポイントはES2015について記述だと思いました。ES2015 については、独立したトピックスとして抜粋しているのではなく、各トピックスの中に自然に盛り込まれている(かつ、わかりやすいアイコンが付いている) スタイルで記述されています。

そのため、これからJavaScriptを学ぶのであれば自然にES2015の内容を取り入れることができるんじゃないかと思います。

そのほか、非同期処理で利用するPromiseについての記述が追加されていたり、StorageやWeb Workerなどについても追加されていたりします。逆に大きく削られているのはJQuery関連。このあたりから、最近のJavaScript界隈の情勢が反映されているな、という印象を受けました。

 

実務で抑えるべき周辺ツールにも言及

これは前の版からだったのですが、単に言語機能について記述しているのではなく、実務でJavaScriptを利用する上で最低限抑えておいた良いようなJasmineやJSDoc、GrurntやBableなどの周辺ツールについても言及があります。 もちろんそれらを使いこなすための細かなことまでには触れていませんが(それらのトピックだけで章や下手すれば本一冊分のボリュームになるでしょう)、そういったもの自体を知ったりとりあえず試してみるための糸口としては十分ではないかと思います。

ASP.NET CoreでEntity Framework Coreを使わずにDBに接続してみる

.NET CoreでDBアクセスといえば、各種紹介記事やドキュメント、チュートリアルでも Entity Framework Core がよく紹介されています。 個人的にはずいぶん小回りも効くようになってすごくよくなってると思いますし、.NET CoreでのDBアクセス周りは、まずはEntity Framework Coreを使うところから始めてよいように思っています。

とはいえ、そこはやはりコンテキスト次第ではあると思うので、後学のために調べてみました。

 

System.Data.SqlClientを使ってみる

では実際に試してみます。 適当にASP.NET CoreのWebアプリケーションを作成しておきます(認証は無しを選んでおきます)。環境はVS2015 Community 以上を想定します。 対処のDBはとりあえず SQL Serverとします。

CoreFxにおける非EFについのてドキュメントがぱっとみで見当たらなかったのですが、『きっとSystem.Data.SqlClientがそのまま存在するに違いない』と思って検索してみると……やはりありました。

www.nuget.org

ということでまずはインストールしておきます。

PM> Install-Package System.Data.SqlClient
  GET https://api.nuget.org/v3/registration1-gz/system.data.sqlclient/index.json
  GET https://www.nuget.org/api/v2/curated-feeds/microsoftdotnet/Packages(Id='System.Data.SqlClient',Version='4.1.0')
  OK https://www.nuget.org/api/v2/curated-feeds/microsoftdotnet/Packages(Id='System.Data.SqlClient',Version='4.1.0') 282ms
  OK https://api.nuget.org/v3/registration1-gz/system.data.sqlclient/index.json 376ms
'nuget.org' からパッケージ 'System.Data.SqlClient 4.1.0' を取得しています。
NuGet パッケージ System.Data.SqlClient.4.1.0 をインストールしています。
'System.Data.SqlClient 4.1.0' が CoreFxDbSample に正常にインストールされました
NuGet の操作の実行に 37.83 ms かかりました
経過した時間: 00:00:02.3787366

f:id:kiyokura:20161022000202p:plain

スクリーンショットにはないですが、ドリルダウンすると、System.Data.Common何かもちゃんと在って、見ていることが分かります。

 

プロバイダがインストールされたので、適当なSQL Serverに接続してみます。読むテーブルは取り合ずこんな感じのシンプルな奴だと思ってください。

CREATE TABLE [dbo].[User] (
  [Id] INT NOT NULL,
  [Name] NVARCHAR (50) NOT NULL,
  [Email] NVARCHAR (255) NOT NULL,
  [BirthDay] DATETIME NOT NULL,
  PRIMARY KEY CLUSTERED ([Id] ASC)
);

データには何か適当にレコードを入れておきました。

 

とりあえずサンプルなのでHomeControllerに直接書いてみます。何の変哲もない、ADO.NETで普通に接続型でDBを読む場合とまったく同じコードだと思います。 接続文字列はVisual Studioのサーバーエクスプローラーで選択してプロパティからコピーしたものをそのまま使っています*1

// HomeController.cs
using Microsoft.AspNetCore.Mvc;
using System.Collections.Generic;
using System.Data.SqlClient;
namespace CoreFxDbSample.Controllers
{
  public class HomeController : Controller
  {
    public IActionResult Index()
    {
      ViewBag.Users = new List<string>();
      using (var con = new SqlConnection("<接続文字列>"))
      using (var cmd = new SqlCommand("SELECT Name FROM Users WHERE Id <= @Id", con))
      {
        cmd.Parameters.Add(new SqlParameter()
        {
          ParameterName = "Id",
          Value = 2,
          DbType = System.Data.DbType.Int32
        });

        con.Open();
        using (var dr = cmd.ExecuteReader())
        {
          while (dr.Read())
          {
            ViewBag.Users.Add(dr["Name"].ToString());
          }
        }
      }
      return View();
    }
  }
}

ついでに結果を見るためにHome/Index.cshtmlもばっさり書き換えておきます。

<!-- Home/Index.cshtml -->
@{
  ViewData["Title"] = "Home Page";
}
<h1>DataReader Sample</h1>
<ul>
  @foreach (var item in ViewBag.Users)
  {
  <li>@item</li>
  }
</ul>

実行してみると、普通に表示されます。 f:id:kiyokura:20161021233323p:plain

この例のとおり、DbConennction, DbCommand , DbParameter, DbDataReaderなど、ADO.NETの基本的な仕組みはポーティングされていて、SQL Server用のプロバイダでもちゃんと実装されていることが分かりました。

NetFxのADO.NETを接続型で使う場合と比較して特に違和感が無い…というか全く同じように使えることが期待できますね。

 

NetFxのADO.NETと比較した制限(2016/10/15 現在)

とはいえ、そのまま移植されているわけではなく、現時点(.NET Core 1.0.1)では利用できない機能がいくつかあります。

 

DataSetやDataTableはまだ実装されていない(もうすぐ入りそう)

DataSetやDataTable、DataAdapterなど、ADO.NETの非接続型の機能を提供するクラスは、現時点(.NET Core 1.0.1)では実装されていません(何か依存物のコンパイルを通すためか、DataTableのみ空で実装はされている模様)。

これらはNetFxでももはやレガシーな機能ですし、WinFormやWebFormなどDataSetを前提としたコンポーネントを活用する(これまたレガシーな)機能は.NET Coreで実装される予定が(今のところ)なさそうなので、このまま実装されずに終わるかな……と思っていたのですが、なんと、ごく最近になってcorefxのmasterにマージされました*2

ということで、近い将来のリリースあたりで入ってくるんじゃないかと思います。

 

 

DataTableに依存した機能は使えない(2016/10/15 現在)

DataTable自体を欲していなくても、DataTableが無いと利用できない機能というのがいくつかあります。私が思いついたのは以下です。 (ただし前述のとおりDataTableが実装されてくれば、将来的にはこれらもちゃんと機能するようになることが期待できそうです。)

Table Value Parameter (テーブル値パラメータ/TVP)

SQL Serverの便利な機能であるTable Value Parameterを.NETのコードから利用する場合、DataTableに格納して渡すことになります。しかし、.NET Core 1.0.1ではDataTableが実装されていないので利用することができません。

SqlConnection.GetSchema

接続先のスキーマ情報を取得するメソッドですが、この戻り値がDataTableだるため、現在は利用できません(GetSchemaが実装されていない)。

 

まとめ

.NET Core 1.0.1の現時点でもDbConnection, DbCommand, DbDataReaderなどの基本的なものは実装されていて、NetFxのADO.NETで利用するのと違和感なく利用できるようです。 現時点のリリースではDataSetやDataTableがまだ実装されていませんが、近い将来のリリースでは含まれてきそうです。

*1:SQL Server認証の場合はパスワードが*になるので書き換える必要があります

*2:これらレガシーな機能がまるっと実装された(だだしTableAdapter はなさそう)理由はよくわかりません。ただ後述のとおりDataTableに依存した機能がいくつかあって、そのためDataTableの実装を望む声は上がっていたようですので、そのあたりも関係しているかもしれません。DataSetについてはどうなんよと思うのですが、ちょっとDataTableのソースを眺めてみた感じではそのなかでもDataSetに依存したコードもあるように見えたので、そう簡単に切り離せるものでは無いのかもしれません。

Docker for Windowsを使用したASP.NET Core のデバッグ実行

Docker for Windowsを使うと、ASP.NET CoreのWebアプリのDockerコンテナをVisual Studioから簡単かつシームレスにデバッグ実行できるとのことなので、試してみました。

 

前提

以下が必要になります。 それぞれインストールしておきます。

また、Docker for WindowsHyper-V上で実行されるので、Hyper-Vが動くようになっている必要があります(OS・エディションが限定されます&ハードウェアの制約もあり)。

 

アプリケーションプロジェクトの作成

ASP.NET Core Web Application(.NET Core) テンプレートでWebアプリケーションを作成します。テンプレートは Webアプリケーションを選択します。とりあえず認証は認証なしにしておきます。

f:id:kiyokura:20161018163458p:plain f:id:kiyokura:20161018163505p:plain

 

Dockerでデバッグ実行を行うための準備

プロジェクトテンプレートが展開されたら、このプロジェクトでDockerを利用するための準備を行います まずはソリューションエクスプローラーのコンテキストメニュー追加-Docker Supportをクリックして、Dockerサポート関連の設定を追加します。

f:id:kiyokura:20161018163512p:plain

 

すると、Docker関連のファイルが追加されたり、launchSettings.json に Docker関連の設定が追加されたりします(今回はとりあえずこれらのファイルを編集する必要はありません)。

f:id:kiyokura:20161018163518p:plain

 

ツールバーデバッグ実行先を確認すると、IIS Expressやセルフホストに加えてDockerが存在することが確認できると思います。Dockerを選択し、デバッグ実行時に起動するブラウザを選択したら準備は完了です。 f:id:kiyokura:20161018163531p:plain

 

F5でデバッグ実行(ビルドエラー編)

実際にデバッグ実行を行ってみます。 適当にアクションメソッドにブレークポイントを張って、F5キーを押します。

f:id:kiyokura:20161018163538p:plain

 

ビルドが進んで、いざデプロイ…と思ったら、エラーが出ました。 f:id:kiyokura:20161018163555p:plain

 

メッセージを確認すると、「Unable to validate volume mapping 」「Docker Toolsのトラブルシューティングを見ろ」と書いてるので、まずは確認してみます。

Troubleshooting Docker Client Errors on Windows Using Visual Studio | Microsoft Azure

Volume mapping is required to share the source code and binaries of your application with the app folder in the container. Specific volume mappings are contained within the docker-compose.dev.debug.yml and docker-compose.dev.release.yml files. As files are changed on your host machine, the containers reflect these changes in a similar folder structure.

なるほど、『Docker for WindowsのShared Drivesの設定がされていない』ことが原因のようです。よくよく見ると、Visual Studio Tools for DockerのPrerequisitesの項目にも赤字で『IMPORTANT: Configure Shared Drives under the settings for Docker For Windows as Shared Drives are requried for F5 Debugging.』と注意書きされていました(オフィシャルのドキュメントはよく読みましょう)。

 

素直に設定してみます。 f:id:kiyokura:20161018163602p:plain

 

F5でデバッグ実行(再チャレンジ)

気を取り直して、再度チャレンジします。 念のため一度クリーンしてから、再度F5キーでデバッグ実行を行います。

すると、今度はデプロイが成功しブラウザが起動、ブレークポイントでもちゃんと停止することが確認できました。 f:id:kiyokura:20161018163612p:plain

 

まとめ

こんな感じで、Dockerコンテナを使ってLinuxにホストした状態でのデバッグ実行を非常に簡単に、そしてシームレスに行うことができました。Docker for Windowsさえ設定されていれば、IIS Expressでデバッグ実行を行うのと何ら変わりない感じで使えそうです。

SQL Server LocalDBのインスタンスを任意の名前で作成する

特定の名前&バージョンのSQL Server LocalDBのインスタンスを作成する必要があったので、メモ。

 

コマンド ラインで SqlLocalDB.exe の create オプションで作成可能でした*1

SqlLocalDB create "<インスタンス名>" バージョン

 

例えば、 バージョン12.0*2インスタンスを SomeInstanceV12 という名前で 作りたい場合は、以下のよにしてやればOKです。

> SqlLocalDB create "SomeInstanceV12" 12.0

 

実行結果はこんな感じです。

f:id:kiyokura:20160608191438p:plain

f:id:kiyokura:20160608191445p:plain

参考(MSDN): コマンド ライン管理ツール: SqlLocalDB.exe

*1:作成したいバージョンのSQL Server Express LocalDBがインストールされていることが前提です

*2:12.0はSQL Server 2014の内部バージョン

SSDTの「スナップショット プロジェクト」機能は割と使える気がしました

私はSSDT(SQL Server Data Tools)を普段から使っているのですが、多機能なこともあり普段使ってない機能はまったく触れずに過ごしています。そのため、”実はよく知らない機能”がまだまだあります。

先日不意に、ソリューションエクスプローラーのコンテキストメニューの上のほうにいつも表示されている『スナップショット プロジェクト』ってなんやねん、というのが気になってしまったので、どんな機能か少し試してみました。

f:id:kiyokura:20160606232232p:plain

 

機能の説明

「スナップショット プロジェクト」機能が何をするかについては、以下がすべてのようです。

  • 現在のデータベースプロジェクトのオブジェクトの定義情報のスナップショットを取得する
  • 取得したスナップショットはdacpacファイルで保存される

……そのまんまです。

実際にやってみると、ソリューションエクスプローラ内にSnapshotフォルダが作成され、その中にタイムスタンプ付きのファイル名でdacpacファイルが作成されました。

f:id:kiyokura:20160606232440p:plain

 

ちなみにdacpacファイルですが、ざっくいえばデータベースのオブジェクト定義情報をXML形式で記録してzipで固めたファイルです。 詳しくは以下のMSDNドキュメントを見てみてください:データ層アプリケーション

 

何が嬉しいの?

この機能、前述のとおりプロジェクトのソースコードの現時点のスナップショットファイルが作成されるだけ、といえばそれだけです。もしソースコードのバージョン管理を何もやっていないのであれば、これは有効なソリューションかもしれません。しかしSSDTを利用して開発しているのであれば、通常は何らかのVCS*1を利用しているケースが多いはずです。であるなら、この機能はあまりうまみが無いように思いました。

 

ですが、少し触ってみると、利点も見えてきました。 個人的に感じた一番の利点は、「スキーマ比較機能で簡単に比較・差分更新が出来る」という点です。

SSDTのスキーマ比較機能は、プロジェクトやデータベースインスタンスなどのスキーマ同士を比較し、差分の検出や差分を埋めるための更新(スクリプトの生成と実行)を行ってくれる非常に便利な機能です。このスキーマ比較では、比較のソースとしてプロジェクトやデータベースインスタンスのほかに、『データ層アプリケーションファイル』、すなわちdacpacファイルががそのまま利用できます。

f:id:kiyokura:20160606233357p:plain

この機能とスナップショットを組み合わせると、任意のタイミングのスナップショットと現状のスキーマを比較して、「特定のオブジェクトだけ変更を元に戻す」というような操作も簡単にできます。

もちろんVSCを利用してバージョン管理されていれば、変更履歴から戻すことは可能です。しかし、(コミットの粒度やツールなどにも依存するとは思いますが)一度コミットした変更を履歴をさかのぼって戻すのはそれなりに煩雑だったりしますし、コミット全体ではなく『特定のオブジェクトの変更のみを戻したい』という場合にはさらに面倒になるかもしれません。

 

利用シーン(?)

全体的な作業の進め方によっても利用シーンは変わってくるとは思いますが、例えば以下のような使い方が出来るように思います(VCSとしてgitを想定しています)。

  1. 作業ブランチを作成してチェックアウト
  2. とりあえずスナップショットを作成
  3. 試行錯誤しながら作業(必要があればスナップショットから戻したりし再度スナップショットをとったりしつつ)
  4. ある程度作業がまとまったらコミット、マージ

なお、あらかじめ.gitignoreを利用するなどして、スナップショットファイルがリポジトリに含まれないようにしておくと楽な気がします*2

 

注意点

一つ注意しておかなければならないと思ったのは、『DBプロジェクトがエラーのない状態である必要がある』点です。dacpacが作成されるときに内部でビルドが行われるのですが、この際にエラーがあるとdacpacの生成に失敗します。 ですので、『いじっている最中でまだコンパイルがうまく通らない』という状態のDBオブジェクトがある場合はスナップショットが作成できません。

 

まとめ

SSDTの「スナップショット プロジェクト」機能はシンプルな機能ですが、作業の進め方によっては十分に便利な機能です。VCSによるバージョン管理とも決して排他ではなく、組み合わせることでより便利で柔軟な開発作業を行う道具として利用できる可能性がある機能だと思いました。

*1:version control system, gitとかtfsとかsvnとか……

*2:スナップショットを追加するとsqlprojファイルにも変更がかかったように見えますが、dacpacのエントリが追加されているわけではないようです