ガンプラ: ダブルオーシアクアンタ







 今年、久しぶりに作ってみたガンプラだが、とうとう塗装までやってしまった。機体のメインカラーをメタリック調にするって程度だけどかなり満足。あとゴテゴテした装備があまり好きではないようで、作ってもそこそこパーツを外して飾ってある。
comment: 0

ASP.NET Core MVCでなにかを作るのに、膨大なフレームワークを隅まで熟知している必要はないと思った

 ASP.NET Core MVCでブログを作ってみてちょっと振り返る。

 このブログのエンジンは突貫でASP.NET MVC Coreで書いたもの。このたびはそれのテストをぼちぼち書いていこうと思っていたが、あまりASP.NET MVCの機能に頼らなかった(スキャッフォルディングとか使ってないしEntity Frameworkとかも)せいか、テストがASP.NET MVCの便利さに頼らないオレオレテストコードになってしまいそうである。メンテを続けるつもりなのでそれはまずくて、じゃあどうせだしテスト駆動でASP.NET MVCの機能を有効活用したものに書き換えていく。その前に、一つのWebアプリをASP.NET MVCで作った個人的感想を、最近思うことに触れつつ書いておく。


 趣味以外でWebアプリを作ることがぼちぼちあるが、そこではPHPのフレームワークなしで書いている。著名フレームワークは使わないというのがそこのルールなので。
 なぜフレームワークを使わないかと聞いてみたところ、フレームワークに書き方を強制されて、個人のコードを書くパフォーマンスが出づらくなるからとのことだった。
 フレームワークは使わないが、メンテナンス性を下げないためにMVCで書こうという努力目標はある。だけどMVCとはなんぞという具体的な教育はないので、わかってる人以外が書くものは素のPHP + Apacheでメンテ性が著しく低いものが上げられている。だったらフレームワーク入れちまって、書き方をちょっと強制しちまえばと思う。メンテナンス性を高めるなら、デザパタ学んでなにかのルールをフォローするのは避けられないだろう。
 フレームワークを使うとなると、あとはコストの問題がと言われる。

 今回ぼくがこのブログのために使ったフレームワークはそもそもPHPではないが、MVCでかつ、いわゆるでかいフレームワークだろう。Railsに影響を受けたんじゃないかと個人的に思っているが、いろいろ機能がそろっている。そのフレームワークを使ってみて思ったが、フレームワークの隅から隅まで熟知していないければかけないということは全然ない。
 ぼくがこのブログのエンジンを作るのに要したのは、平日の会社から帰った時間を使った一週間程度だった。それまでASP.NET MVCなんて使ったことなかったし、そもそもMVCのてんこもりみたいなフレームワークも触ったことはなかった。それでも一週間という、フレームワークを習得するのに要するといわれる時間程度でできたのは、用意されている機能をなんでもかんでも使う必要がなかったからだ。
 ぼくがまずMVCフレームワークにお願いしたかったのは、MVCの切り分けである。ルーティングをしてくれるコントローラ、データ操作を行うモデル、ここではHTMLとし情報を表示するためのビューの切り分けである。これに加えてCSRF対策機能をフレームワーク内に見つけたので利用したが、逆に言えばこれぐらいしか機能を利用していない。スキャッフォルディングとかは利用していない。
 このブログのエンジンはMVCそれぞれをきれいに書きわけてある。そこにフレームワーク独自で勉強しないと読めないような機能を使ったコードは全然ない。モデルはデータベースであるMongoDBへの問い合わせ、ビューはありがちな書き方をするテンプレートエンジン、コントローラはこれも最近のWebフレームワークならありがちな正規表現でパスを書くタイプで、C#以外のものなんてことはない。
 フレームワークの根幹にあるMVCの分離というところはありがたく恩恵を得ている。使ったことのなかったフレームワークでここまで持ってくるのに、調べながら一週間程度だった。

 コードのメンテナンス性を高めたいなーと最近思っていたので、フレームワークを使うという一つの手を試してみた。MVCの分離というところはキッチリできたし、MVCの分離という十分条件をクリアする程度のフレームワーク習得なら大した学習時間も要さなかった。
 これから大規模化を想定してASP.NET MVC Coreが持つ便利な機能を探って導入していく。一方でここまでに作ったものを考えると、フレームワークを熟知しなければそれでWebアプリを作ることができないというわけではないようだというのが今回のまとめ(MVCを理解してなければフレームワーク習得とは別に時間が必要だろう)。このあたり他言語のでかいフレームワークはどうなってるんだろう。
comment: 0

ASP.NET Core MVC: DockerでWebアプリのテスト用DBを用意してもろもろの設定

 このブログのバックエンドはASP.NET Core MVCで作っていて、これからもメンテナンスを続けていく。それなのに、.NET Coreのリリースが迫っているときに突貫で作ったために、CI(継続的インテグレーション)の準備ができていない。だからこれから整えていく。まずはテストを用意するため、テスト用のDBを用意するところから。

 一番手っ取り早いDBの準備方法は、開発マシンにDBをインストールしてしまうことだろう。だけどそれでは不要に開発環境が汚れて好みではない。仮想環境に用意してそこに接続したい。そこで今回はそういったことが簡易にできるDockerを使うことにする。DBはMongoDBで。

 ぼくの環境ではDocker Machineが入っているのでそれで適当な名前のDocker環境を用意して、そのDockerへSSH接続する。
docker-machine ssh dev


 Docker環境(コンテナホスト)に入ったらMongoDBが入ったイメージを落として、外部からコンテナの中で動いているMongoDBにアクセスできるようにポートをバインドする。
docker pull mongo

docker run --name bolog-test-mongo -p 80:27017 -d mongo



 Dockerの外部である開発環境からMongoDBへ接続をから接続を試す。今回はMongoDBに付属しているmongoを使う。


 あとはデータベースに必要なデータをつっこんでおく。

 データベースの準備ができたので、Visual Studioで作ってあるWebアプリのプロジェクトからアクセスできるように接続文字列などを設定する。

 まずテスト用DBの接続文字列設定。appsettings.jsonにMongoDB接続の文字列を追加。パスワードとか入っていないローカルネットワークオンリーのDBなので接続文字列が公開されてしまっても大丈夫。
{

"ConnectionStrings": {
"Mongo": "mongodb://192.168.11.5"
},
"Logging": {


 続いてAzureのほうに、本番用DBの接続文字列を入れる。アプリケーション設定のところに入れられる場所があるのでそこに。今回はCustomというカテゴリで、テスト用DBと同様にMongoという名前で値を入れた。


 アプリケーション内でのDB接続文字列の呼び出しは下記で行う。
using Microsoft.Extensions.Configuration;

// *******
Configuration.GetSection("ConnectionStrings")["Mongo"]


 これでテスト、本番で使用するDBを自動でわけつつ、本番用は一般には入れない場所に接続文字列を置くことができた。Githubからデプロイしたい場合、パブリックリポジトリにシークレットなデータを置くわけにはいかないのでこれを使えば回避できる。

 DBを用意したので引き続きCI構築としてテストを作っていきたい。
comment: 0

.gitignoreに加えたファイルよ、リポジトリからさようなら

 .gitignoreに加えたディレクトリがいつまでもリポジトリに残っていて邪魔だと感じたので消してみた。

 まず.gitignoreに不要なディレクトリを追記(今回は.vsというディレクトリ)。続いてgitのキャッシュから消す。今回消したいのはディレクトリとその下のファイル丸々なので、再帰で削除するオプション"-r"を付加。
git rm --cached -r .vs/

 GithubのGUIでやるとエラーでコミットが失敗したのでGitBashからコミット。
git commit -m "clean"

 あとはプッシュ。
git push

 完了したらリポジトリへ行って、消えていることを確認。
comment: 0

C# + MongoDBでログイン認証

 ASP.NET MVC + MongoDB環境でこのブログを作っている。今回はパスワード認証あたりが平文だったので、データベース直いじりで登録済みのパスワードをSHA256ハッシュにして、認証ロジックをそれに対応させた。

参考:http://dobon.net/vb/dotnet/string/md5.html

 パスワードにさらにユーザー名を付加し、それをなにかしらの文字列を使ってハッシュ化する。下記のようなメソッドを用意した。
private static string GetSHA256 (string userName, string pw)

{
//HMAC-SHA1を計算する文字列
var s = $"{userName}@{pw}";
//キーとする文字列
var key = "somestring";

//文字列をバイト型配列に変換する
byte[] data = System.Text.Encoding.UTF8.GetBytes(s);
byte[] keyData = System.Text.Encoding.UTF8.GetBytes(key);

byte[] bs;
//HMACSHA256オブジェクトの作成
using (var hmac = new HMACSHA256(keyData))
{
//ハッシュ値を計算
bs = hmac.ComputeHash(data);
}

//byte型配列を16進数に変換
var result = BitConverter.ToString(bs).ToLower().Replace("-", "");

return result;
}


 ハッシュ値を得るメソッドは用意したので、MongoDBに保存してあるユーザー情報と照会する。
public static bool Login(string id, string pw, IResponseCookies cookies)

{
var userCollection = DbConnection.db.GetCollection<BsonDocument>("user");
var filter = Builders<BsonDocument>.Filter.Eq("_id", id);
var doc = userCollection.Find<BsonDocument>(filter).FirstOrDefault<BsonDocument>();
if (doc == null)
{
return false;
}
else
{
var sha256 = GetSHA256(doc.GetValue("_id").AsString, pw);
if (sha256 != doc.GetValue("pw").AsString)
{
return false;
}
else
{
// 認証処理が続く
comment: 0