Dockerコンテナ内でASP.NET Core 2.1 Webアプリをビルド・実行する

やりたかった事：

Macに.Net SDKを入れずにASP.NET Core 2.1のWebアプリを開発したい。

試した事：

Docker(Version 18.03.1-ce-mac64)でMS公式の.NET 2.1 SDKイメージを動かしてみました。

まずは、SDKの公式イメージからコンテナを起動します。

docker run --rm -it \
  -v `pwd`:/app/ \
  -w /app/aspnetapp \
  microsoft/dotnet:2.1-sdk

これを実行すると、Mac側のカレントディレクトリがコンテナの/app/ディレクトリにマウントされて、かつコンテナ内のカレントディレクトリが/app/aspnetapp になった状態でシェルが起動します。

ここから、

dotnet new webapi 

を実行すればWeb APIのひな形のコードが生成されます。

さらに、

dotnet run

を実行すればデフォルトの5000番ポートでWeb APIが実行されますが、このままだとポートマッピングの設定をしていないのでホスト側からはアクセス出来ません。

とりあえずこれはCtrl+Cで終了してコンテナを終了し、次にdocker runコマンドに -p オプションを付けた上で、シェルを開くのではなく「dotnet watch run」コマンドを実行してみます。

使ったコマンドはこちら。

PORT=8080
docker run --rm -it --name watcher \
  -p $PORT:$PORT \
  -v `pwd`:/app/ \
  -w /app/aspnetapp \
  microsoft/dotnet:2.1-sdk \
  dotnet watch run $PORT

任意のポート番号でアプリを動かせるように、事前にProgram.csファイルにちょっと細工をしておきました。

#########
#########

起動後、指定したポート番号でアプリが動いているのが分かります。

分かった事：

docker runでコンテナを起動する際に -v オプションでカレントディレクトリをコンテナ内のディレクトリにマウントしておけば、ソースコードはホスト（Mac本体）側で編集し、BuildやPublishはコンテナ内で行うという事が出来ました。

コンテナ内で動かすコマンドを「dotnet watch run」としておけばコードを変更したら自動でアプリを再起動してくれます。

これでMac本体に.Net SDKを入れずにASP.NET Core 2.1のWebアプリを開発するという目的が達成出来ました！

参考URL：

dotnet-docker/aspnet-docker-dev-in-container.md at master
https://github.com/dotnet/dotnet-docker/blob/master/samples/aspnetapp/aspnet-docker-dev-in-container.md
MS公式Dockerイメージを使って.NET Core開発を行う（Mac） - ryuichi111stdの技術日記
http://ryuichi111std.hatenablog.com/entry/2016/11/07/020326

.

JavaScriptで "B" + ["a", "a"].join("aaa" - 1) がBaNaNaになる理由

Ethereum開発者のVitalik氏がこんなツイートをしていたのを見ました。

試しにChromeのDeveloper Toolsを開いて実行して見ると、確かに「BaNaNa」と表示されました。

"B" + ["a", "a"].join("aaa" - 1)
"BaNaNa"

不思議に思ったので少しずつ変えながら何パターンか試してみます。

"B" + ["a", "a"].join("aaa")　→　"Baaaaa"

"B" + ["a", "a"].join()　　→　"Ba,a"

"B" + ["a", "a"].join("")　　→　"Baa"

"B" + ["a", "a"].join("" - 1)　　→　"Ba-1a"

"B" + ["a", "a"].join(1)　　→　"Ba1a"

"B" + ["a", "a"].join("x" - 1)　　→　"BaNaNa"

なるほど、分かってきました。

"aaa" - 1 の部分が「NaN」として出力されて、それがArray.join()の引数になるので

B + a + NaN + a

で 「BaNaNa」というわけですね。

なるほど！

　

TypeScriptを使うならstrictNullChecksオプションが便利

TypeScript の strictNullChecks オプションというものを知ったのでメモしておきます。

tsconfig.json の compilerOptions に

"strictNullChecks": true

を追加しておくと便利。

これをすることで、string や number などに null や undefined を代入することが出来なくなる。

let name: string;
name = null;                ← ここでコンパイルエラー

let count: number;
count = undefined;      ← ここでコンパイルエラー


null や undefined を代入したい場合は、型指定時に明示しておけばOK。

let name: string | null;
name = null;                ← これはOK

let count: number | null | undefined;
count = undefined;      ← これはOK


「ユニオン型」というらしいですね。

http://d.hatena.ne.jp/m-hiyama/20180117/1516157225

色々なシチュエーションで、「この変数の値は null/undefined になる可能性がある（もしくは無い）」という事を明示出来るのでnullチェック忘れや過剰なnullチェックを減らす事が出来ます。




　

高解像度のディスプレイでリモートデスクトップ接続をした時にアイコンや文字が小さすぎて見えない問題への対処

Microsoftから提供されている「Remote Desktop Connection Manager」を使うと良い感じになったのでメモしておきます。

ダウンロードページはこちら。
https://www.microsoft.com/en-us/download/details.aspx?id=44989



バージョン2.7の日付が2014年11月と古いですが、これ以上新しいバージョンは検索しても見つかりませんでした。


Remote Desktop Connection Managerを起動したら、まず File - New で新しいグループを作ります。

そのグループの右クリックメニューからプロパティを開いて「Remote Desktop Settings」タブを開き、「Full Screen」をチェックします。

次に「Display Settings」タブを開いて、「Scale docked remote desktop to fit window」および「Scale undocked remote desktop to fit window」のチェックをONにしておきます。

あとは、そのグループの下に個々の接続先サーバーの設定を追加して行けばOKです。

これで接続先の解像度が低い場合に文字やアイコンが小さすぎて操作出来ないという問題がなくなります。










　

GitLab CIを使ってWebAPIのPDFドキュメント生成を自動化する

前回は Web APIに組み込んだSwaggerが生成する swagger.json ファイルからコマンドラインでPDF形式のドキュメントを生成するところまで出来ました。

今回はこの一連の処理をGitLab CIを使って自動化してみようと思います。

大まかな流れは次のようになります。

1. GitLabにプロジェクトを作成する
2. 「.gitlab-ci.yml」ファイルを作成する
3. GitLabにプッシュしてCIが動作することを確認する
4. Web APIをAzure App Servicesに自動デプロイする
5. CIでPDFドキュメントを自動生成する
6. 生成されたPDFドキュメントをダウンロードする

1. GitLabにプロジェクトを作成する

CIサービスと言えば、Circle CIやTravis CI、Werkerなどたくさんありますが、今回は GitLab CI を使うことにしました。

まだ gitlab.com にアカウントが無い場合はユーザー登録しましょう。
ログイン後、「New Project」ボタンを押して新規プロジェクトを作成します。GitHubに既にプロジェクトがある場合はそちらからそっくりインポートする事も可能です。


2. 「.gitlab-ci.yml」ファイルを作成する

ソリューションの直下に .gitlab-ci.yml と言う名前のファイルを作成します。

Visual Studioを使っている場合はソリューションを右クリックして「追加」をすればSolution Itemsの下に表示されます。

ファイルの内容はとりあえずこんな感じにしておきます。




Dockerのベースイメージとして、Ubuntu 14.04 を使っています。

before_script の部分で apt-get コマンドを使ってJavaとRubyのインストールを行ない、script の部分で動作確認のためにJavaとRubyのバージョンを出力しています。

.gitlab-ci.ymlファイルの仕様は下のページに載っています。

https://docs.gitlab.com/ce/ci/yaml/README.html#gitlab-ci-yml

3. GitLabにプッシュしてCIが動作することを確認する

この状態でGitLabにプッシュして見ます。Pipelinesというメニューをクリックすると自動的にPipelineが作成されている事が分かります。

Jobsというサブメニューを開いて実行されたJobをクリックして詳細を表示すると、黒い画面でコンソール出力の結果を確認する事が出来ます。JavaとRubyのインストールが正常に行われて、最後にバージョン情報が表示されていれば成功です。

リポジトリへのPushを検知してGitLab側で自動的にDockerコンテナを起動して指定のコマンドを実行してくれているわけですね。

Circle CIなど他のサービスを使わずに、しかも無料でこれが出来るというのがGitLabの良い所だと思います。

ちなみに「CI Runner」というものを自前のサーバーにインストールしておけば、Dockerコンテナをそのサーバー上で起動させる様にする事も可能なようです。（むしろ元々は自前で用意するのが基本だったようです。）

4. Web APIをAzure App Servicesに自動デプロイする

Web APIのデプロイ先はAWSやGoogle Cloudなどどこでも構わないのですが、今回はAzure App Servicesを使います。

Azure App Servicesに自動デプロイするにはいくつかの方法がありますが、ここではTravis CIが作成している dpl コマンドを使ってみます。

GitLab CIのジョブでdplコマンドを実行するための設定は次のようになります。



Ubuntu 14.04を起動した後 Rubyをインストールし、さらに gem install dpl で dpl コマンドをインストールしています。

その後、dpl --provider=AzureWebApps で実行します。


ちなみに、

only:
    - /^release-.*$/

の部分は、「release-」で始まるタグ付きでプッシュされた時だけこのジョブが起動されるようにするための設定です。この2行を削除するとプッシュするたびに毎回起動されます。


さて、上の設定ファイルではデプロイ先のURLやデプロイ用の認証情報などを一切指定していません。それらはGitLab内のプロジェクト毎の設定画面に「Secret variables」として登録しておきます。

dplコマンドは

• AZURE_WA_SITE
• AZURE_WA_USERNAME
• AZURE_WA_PASSWORD

の3つの設定を自動的に読み込んで処理してくれます。

この状態で実際にGitLabにプッシュして見るとAzure App ServicesにWeb APIが自動デプロイされます。下はデプロイ成功時のジョブのログを表示したところです。

念のためAzure側のURLを開いてみると確かにWebAPIとSwagger UIが動いています。

5. CIでPDFドキュメントを自動生成する

さて、次はいよいよWeb APIのPDFドキュメントを自動生成します。設定ファイルにpdfというジョブを追加しました。

stages:
  - deploy
  - pdf

となっているので、「deployというステージが終わってからpdfというステージを実行する」という意味になります。ひとつのステージには複数のジョブを含める事が出来ますが、その場合はステージ内の各ジョブが並列実行されます。今回の設定ではそれぞれのステージに同名のジョブを一つずつ含んでいるだけという形になっています。

それぞれのジョブは別個のDockerコンテナとして起動されるので、pdfジョブの方でも再度Rubyのインストールが必要になります。こちらのジョブではJavaのインストールも必要なのでdeployジョブよりも少し時間がかかります。

cd ./MySampleWebApi.Doc && chmod +x *.sh && ./build.sh $SWAGGER_JSON_URL

MySampleWebApi.DocフォルダにあらかじめダウンロードしておいたJavaのコマンド（swagger2markup-cli-1.3.1.jar）やスクリプトを格納してあるので、そのフォルダに移動して build.sh を実行しています。

これで前回に実行したのと同じ一連の処理が動いて ./MySampleWebApi.Doc/pdf フォルダにPDFファイルが作成されます。

この時にSecret Variablesの設定から $SWAGGER_JSON_URL の値を読み込んでスクリプトに渡しています。

こうしておけばAzure側のデプロイ先が変わっても柔軟に対応出来るので便利ですね。

6. 生成されたPDFドキュメントをダウンロードする

最新の成果物へは下の形式のURLでアクセス可能になっています。

https://gitlab.com/(ユーザー名またはグループ名)/(プロジェクト名)/-/jobs/artifacts/master/browse?job=(ジョブ名)

このURLへはGitLabにログインした状態でかつ権限があるユーザーでないとアクセス出来ないので、実運用では .gitlab-ci.yml にさらにジョブを追加してAWSやAzureなどのストレージにアップロードするような処理を追加することになると思います。


あと、この設定のままだとジョブが起動される度に素のUbuntuに対してJavaやRubyのインストールから行っているので、終了するまでにかなり(数分程度)時間がかかってしまいます。

出来ればJava/Rubyが既に入った状態のイメージを探してくるか自分で作成するかして、それをベースイメージに指定した方が良いと思います。



今回作成したサンプルプロジェクトの全ソースコードは下記で参照可能になっています。

https://gitlab.com/mikehibm/AspNetCoreWebApiSwagger

SwaggerのAPI定義からPDFドキュメントを生成する

前回はASP.NET CoreのWeb APIプロジェクトにSwaggerを組み込んでAPIのドキュメントをブラウザ上に表示させるところまで実行しました。

これはこれで手軽にAPIの仕様を確認出来て便利なのですが、受託開発の際の納品物としてお客様に渡すには少し不便です。「納品は紙（PDF）で」と言われる事がまだありますよね？

ブラウザに表示されているものを印刷して渡してしまっても良いかもしれませんが、それだと今ひとつ見栄えが良くないので出来ればもう少しきれいなPDF文書を自動生成したいところです。

そこで調べたところ、次のような事が分かりました。

● swagger2markup-cli を使えばSwaggerが生成するJSONファイルから静的なHTMLやMarkdown、AsciiDoc形式のドキュメントなどを生成する事が出来る。

● asciidoctor-pdf を使えばAsciiDoc形式のドキュメントをPDFファイルに変換する事が出来る。

参考：
goa tips: swagger-ui がサービスできないときのドキュメントどうする問題 - 押してダメならふて寝しろ

asciidocをPDFに変換してみた（asciidoctor-pdf）

今回はこれらを使って

swagger.json → AsciiDoc → PDF

という流れでドキュメントを生成する事にします。


まず前提条件として、swagger2markup-cliを使うにはJavaのインストールが必要で、asciidoctor-pdfを使うにはRubyのインストールが必要になります。

Macで開発しているのあれば通常は両方とも既に入っていると思います。Windowsの場合はchocolateyを使えば簡単にインストール出来ると思います。



1. swagger2markup-cliでAsciiDocファイルを生成する

下のURLからjarファイルをダウンロードします。

https://jcenter.bintray.com/io/github/swagger2markup/swagger2markup-cli/

ダウンロード後、コマンドラインから下記を実行します。

java -jar ./swagger2markup-cli-1.3.1.jar convert -i [swagger.jsonへのパス] -d ./adoc

[swagger.jsonへのパス]の部分は 「http://localhost:49879/swagger/v1/swagger.json」のようにURLを指定しても良いし、「./swagger.json」のようにあらかじめダウンロードしておいたJSONファイルを指定しても構いません。

エラーが出ずに成功すれば、adocフォルダには overview.adoc, paths.adoc, definitions.adoc, security.adoc の4つのファイルが出来ているはずです。ファイルが分かれていると次のステップで困るので、1ファイル(out.adoc)に結合しておきます。

cat adoc/overview.adoc adoc/paths.adoc adoc/definitions.adoc > adoc/out.adoc

(security.adocの内容は特に必要がなかったので除外しました。)




2. asciidoctor-pdfでPDFファイルを生成する

gemコマンドでasciidoctor-pdfをインストールします。

gem install --pre asciidoctor-pdf

あとは入力と出力を指定して実行するだけです。

asciidoctor-pdf -o pdf/out.pdf adoc/out.adoc

これでpdfフォルダにout.pdfファイルが生成されます。サンプルはこんな感じです。

デフォルトのスタイルが物足りなければ、テーマを自作して色々とカスタマイズ出来るようです。

asciidocをPDFに変換してみた（asciidoctor-pdf）

さて、ここまででWeb APIからPDFドキュメントを生成する事が出来ました。ただ、APIに変更が発生する度にコマンドを打ち込んでPDFを再生成するのはちょっと面倒です。

そこで次回は、今流行りの「Continuous Integration（CI）」なるものを使ってソースコードの変更をプッシュするだけで自動的にPDFドキュメントが更新される、という事にチャレンジしてみたいと思います。

次回： GitLab CIを使ってWebAPIのPDFドキュメント生成を自動化する

ASP.NET WebAPIにSwaggerを組み込む

1. ASP.NET Core Web APIを新規作成する

Visual Studio 2017でASP.NET CoreのWeb APIプロジェクトを新規作成します。

デフォルトでControllersフォルダの中にValuesControllerがあるので、この名前をProductsControllerに変更し、さらにUsersControllerを追加します。

新規にResourcesフォルダを作成してその中にProductクラスとUserクラスを作成しておきます。

その後ProductsControllerとUsersControllerを編集してダミーのデータをJSONで返す様にした状態のソースコードが下記になります。（コミットにbefore-swaggerタグが付いています。）

https://github.com/mikehibm/AspNetCoreWebApiSwagger/tree/before-swagger

Ctrl+F5キーで実行すると商品とユーザーの情報がJSONで返って来るのが分かります。

この状態でWeb APIとしては動いているので、次にSwaggerを組み込んでAPIのドキュメント（メタ情報）に外部からアクセス出来るようにしてみます。

2. Swaggerを組み込む

Visual Studio内でPackage Managerコンソールを開いて、次のコマンドを打ち込みます。

Install-Package Swashbuckle.AspNetCore

その後、下のサイトを参考にStartup.csファイルを編集します。と言っても数行を追加するだけなので簡単です。

ASP.NET Web API Help Pages using Swagger

編集後の Startup.cs は下の状態になります。




この状態でCtrl+F5キーを押して実行し、http://localhost:xxxxxxx/swagger/ のURLを開くと、Swagger UIの画面が開いてAPIのドキュメントを閲覧する事が出来るようになっています。

ただこの段階ではせっかくソースコードに書き込んだコメントが反映されていないので、次にそれらが反映されるようにします。

3. XMLコメントをSwaggerに反映させる

まず、プロジェクトの設定で「XMLドキュメントファイル」の自動生成を有効化しておく必要があります。

この状態で一旦プロジェクトをビルドすると、指定したファイル名でXMLファイルが出来るはずです。このファイルをVisual Studioのソリューションエクスプローラ上で右クリックして、「プロジェクトに含める」を選択しておきます。

さらに、XMLファイルを選択した状態でF4キーを押してプロパティウインドウを表示し、下のようにプロパティを変更しておきます。これは後でこのプロジェクトをPublishする際に必要になります。

次に、Startup.csファイルの中で services.AddSwaggerGen() メソッドを呼んでいる箇所があるので、そのブロック内に下の3行を追加します。

var basePath = PlatformServices.Default.Application.ApplicationBasePath;
var xmlPath = Path.Combine(basePath, "MySampleWebApi.xml");
c.IncludeXmlComments(xmlPath);

これで再度実行するとソースコード内でクラス単位やメソッド単位で「///」を使って書いたコメントがSwagger UIの画面にも反映されます。

4. まとめ

ASP.NET CoreのWeb APIプロジェクトにSwaggerを組み込んでAPIのドキュメントを表示させるようにする事は、上の通りかなり手軽に出来ます。

ASP.NET Coreでなく従来のASP.NET MVCのプロジェクトでもほぼ同じ手順でSwaggerの組み込みが可能です。

次回はSwaggerが生成した情報を使ってPDFドキュメントを生成する方法を書いてみたいと思います。

ビットコインは通貨として生き残るのか？

世間ではビットコインの分裂騒動が話題になっていますが、その話ではなく、

この本を読み終わってのメモです。




『これでわかったビットコイン [生きのこる通貨の条件]』　斉藤 賢爾  (著)


2014年の本ですがこれからビットコインについて知りたいという人には十分役に立ちます。

本書は「入門編」「使い方編」「そもそも編」「しくみ編」の4部で構成されています。この中で「そもそも編」ではビットコインに否定的な意見を持つ筆者の視点を知ることが出来ます。

BTCの発行量上限が2100万と決まっている事について、筆者は「インフレ撲滅への開発者の強い意志」が反映されたものだと述べ、「でもそもそもインフレって悪いこと？」と疑問を投げかけます。

"たしかに、貨幣を持っている人たちにとっては重大な問題でしょう。みずからの資産が目減りしていくことを意味しているからです。" (p.66)

"逆に、デフレ状態では、商品にたいして貨幣の価値が相対的に上がります。これは富める者たちにとっては資産が自動的に増えることを意味します。" (p.66)

"ビットコインではデフレが起きるような設計がされていますが、うがった見方をすると、富める者たちがそれを利用してさらに儲けようとしている、ともいえるかもしれません。" (p.66) 

"貨幣が希少で、かつ、貨幣がなければ何もできない世の中に生きていると、私たちは、どうにかしてそれを手に入れなければならなくなります。そして、貨幣を持っている人の言うことを聞くようになります。それは、自分が支配される立場におかれることを意味します...(略)" (p.69)

「通貨・貨幣とはなにか」について自分なりに考える良いきっかけになりました。

たしかに、発行数上限が近づくにつれて希少性が上がり「先行者有利」なまま「持てる者」と「持たざる者」の格差が指数関数的に広がっていく現状のビットコインの設計については、「これが本当に最善なのか」今一度じっくりと考えないと行けないのではないかと思いました。


この辺りの「より良い通貨の設計」というテーマについては岩村充教授の『中央銀行が終わる日: ビットコインと通貨の未来』でより詳細に議論されているのでこちらも一緒に読むと面白いです。



ビットコインのPoWの仕組み等についてさらに詳細に知りたい方には大石哲之さんの『ビットコインはどのようにして動いているのか？』(Kindle本)がオススメです。

Angularでサーバーから取得したPDFを表示する

Angularでサーバーから取得したPDFを表示するサンプルを作ってみました。

実際に動くものはこちら。

全ソースコードはこちら。

サーバーからPDFファイルを取得する部分

サンプルではGitHub Pagesからスタティックなファイルをgetしていますが、Web Apiから動的に生成されたファイルを取って来る場合でも全く同じです。

受け取ったPDFファイルをクライアント側で表示する部分

URL.createObjectURL(blob) でblobからデータURLを生成して、それをHTML側で object タグの data 属性にバインドして表示しています。

ただそれだけだとAngularのセキュリティ制限でエラーになるので、DomSanitizerのbypassSecurityTrustResourceUrl()というメソッドを呼ぶ必要がありました。


あ、それからこのサンプルは現時点ではIEでは上手く動かない様です。

ChromeとFirefoxでは問題無く動作しました。

MacのSafariではobjectタグでの表示はされましたが、Downloadのリンクをクリックしても別タブで表示されるだけでダウンロードはされませんでした。

ブラウザ	objectタグでの表示	aタグでのダウンロード
Chrome	◯	◯
Firefox	◯	◯
Safari	◯	△
Edge	×	◯
IE11	×	×

Lenovo Chromebook N22を購入

2ヶ月ほど前(2017年4月)に、Lenovo の Chromebook N22 を買いました。

LenovoのWebサイトを見ていたら、Outlet価格で$185(送料無料)になっていたので、タッチ対応でかつRAMが4GBである事を確認した上で即オーダーしました。

数日後に見たらサイトから無くなっていたので、即オーダーして良かったと思います。

軽いので持ち運びもラクラクです。液晶もきれいで見やすいです。

Web閲覧などで1日に1〜2時間ほど軽〜く使う感じであれば1回の充電で1週間ほど持ちます。

画面はここまで開きます。180度、と言いたい所ですが微妙にそこまで開かず、175度ぐらいまででしょうか。

実は一番気に入っている使い方はこれ（下）です。画面を一杯まで開いて、自分は寝転がってお腹のうえに本体を突き立てるようにして、片手で支えながらWebを見るのが最高に快適です。笑）

キーボード部分がちょうど良い支えになってくれるので、タブレットを空中で保持するよりずっと楽なのです。

さて、Chromebookを買った本来の目的は、「子供の勉強用」でした。学校にもChromebookが導入されているので、「これ使っていいよ」と渡すと何の違和感もなく早速使いこなしていました。

小・中学生に使わせるコンピュータとしては確かに最適だと思います。


そう言えば、初期化する時に「Devチャンネル」に設定しておいたからか、5月に入った頃から「Google Play Store」が使える様になりました。

試しにAndroidアプリをいくつか入れたりして見ましたが、全く問題無く動作しています。

自作のアプリも全て動作したので、結構感動してしまいました。


これからは、Androidタブレットにキーボードを接続してPCっぽく使えるようにするぐらいなら素直にChromebookを買うのが正解かも知れませんね。







　

Node, express, nginx で動くWebサイトへのファイルアップロードでサイズ超過エラーが出る時の対策

Node/Express.js で作ったWebアプリケーションをテストしていて、CSVファイルのアップロード時に一定のファイルサイズを超えると「413 Request Entity Too Large」というエラーになる事に気付きました。

調べた結果、

1. ExpressのbodyParserミドルウェア
2. MultiPartフォームデータの処理を簡単にしてくれるミドルウェアのMulter
3. そしてリバースプロキシとして使っているNginx 

の3箇所で許可するファイルサイズの最大値を設定する必要があることが分かりました。

1. Expressの設定

app.use(bodyParser.json({ limit: '20mb' }));
app.use(bodyParser.urlencoded({ extended: true, limit: '20mb' }));

2. Multerの設定

const upload = multer({
  limits: {
    fileSize: 1024 * 1024 * 20, // 最大20MBまで許可
  }
});

3. Nginxの設定

location / {
proxy_pass http://127.0.0.1:3000;
... (略) ...
client_max_body_size 20M;
}

最初1と2の設定を付けたのに上手く行かなくて、3の設定が必要な事に気付くまでに時間がかかってしまったので、メモしておきます。

　

ASP.NET CoreとEntityFrameworkで最速でWeb APIを作るには

ASP.NET Core, EntityFrameworkとVisual Studio Codeを使ってデータベースから情報を取得してJSONで返すWeb APIを作ります。

コードファーストは使わず、既存のデータベースが存在するという前提で作ります。
とりあえず Northwind というサンプルのデータベースが存在すると仮定してコーディングしていますが、データベース名、テーブル名やモデルクラスの内容は適宜手元の環境に合わせて読み替えて下さい。

以下ステップ０から８までに分けましたが、おそらく20分もあれば全部出来ると思います。


ステップ０ - .NET Core SDKとVS Codeをインストール
ステップ１ - プロジェクトを作成する
ステップ２ - 依存パッケージを追加する
ステップ３ - モデルクラスを作成する
ステップ４ - DbContextクラスを作成する
ステップ５ - リポジトリクラスを作成する
ステップ６ - 設定ファイルにDB接続文字列を追加する
ステップ７ - Startupクラスに設定を追加する
ステップ８ - Controllerを作成する

ステップ０ - .NET Core SDKとVS Codeをインストール

下のサイトからインストールして下さい。

https://www.microsoft.com/net/core

https://code.visualstudio.com

VS Codeをインストールした後、C#用の拡張機能をインストールしておいて下さい。

ステップ１ - プロジェクトを作成する

dotnet new mvc --auth None --framework netcoreapp1.1 -o MySampleWeb
cd MySampleWeb
dotnet restore
code .

VS Codeでフォルダを開いて、拡張子が.csのファイルを表示すると2〜３秒後にダイアログが表示されるので、「Yes」をクリックします。

プロジェクトフォルダ直下に.vscodeフォルダが作られ、ビルドやデバッグ実行用の設定ファイルが自動的に作成されます。

この時点でShift+Ctrl+B（MacではShift+Cmd+B）を押すとビルドが実行されるのでエラーが無いことを確認しておきます。

ステップ２ - 依存パッケージを追加する

dotnet add package Microsoft.EntityFrameworkCore.SqlServer

上のコマンドを実行すると「MySampleWeb.csproj」ファイルにEntityFrameworkでSqlServerに接続するためのパッケージ参照のエントリが追加されます。

ステップ３ - モデルクラスを作成する

プロジェクト直下にDataというフォルダを作って、そこにCustomer.csファイルを作成します。

ステップ４ - DbContextクラスを作成する

コンストラクタのパラメータでoptionsを受け取るようになっている点に注意して下さい。これを忘れるとデータベースに接続出来ずエラーになります。

ステップ５ - リポジトリクラスを作成する

とりあえずGetAll()とFind()のみ実装しておきます。

CustomerRepositoryクラスのコンストラクタでNorthWindContextのインスタンスを受け取れるようになっている点に注目です。

ASP.NET CoreではDbContextなどのインスタンスはこの様にDependency Injection（DI）で受け取るというのが原則です。

ステップ６ - 設定ファイルにDB接続文字列を追加する

SQLサーバーの指定、ユーザーID、パスワードの指定は適宜変更して下さい。

ステップ７ - StartupクラスにDIの設定を追加する

AddDbContext()

このメソッドでDbContextのDIを設定しています。


AddScoped()

このメソッドでリポジトリクラスのDIを設定しています。「ICustomerRepositoryのインスタンスがどこかで要求されたら、CustomerRepositoryのインスタンスを生成して注入してね」という意味になります。

AddSingleton()やAddTransient()などもありますが、それぞれ注入されるインスタンスが維持される期間が異なります。

Dependency Injection in ASP.NET Core | Microsoft Docs
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection

AddScoped()の場合はひとつのHTTPリクエストについてひとつのインスタンスが生成されます。リポジトリクラスの中で使っているEntityFrameworkはスレッドセーフではないので AddSingleton() はここでは使えません。

ステップ８ - Controllerを作成する

ControllersフォルダにCustomersController.csファイルを新規作成します。



コンストラクタでリポジトリクラスのインスタンスを受け取るようになっています。ここでステップ７で設定したDIが効いてきます。

通常のWebアプリケーションとして動いている場合は、このDIのおかげでASP.NET Coreが自動的にCustomerRepositoryのインスタンスを生成してコントローラに渡してくれます。

でも単体テストでコントローラの動作をテストしたい場合などでは、自前でモックのインスタンスを生成してコントローラに渡すことが出来ます。DIを使うことでクラス同士が疎結合になっているわけですね。

密結合と疎結合の概念やDIについては下のページの説明がとても分かりやすいと思います。

ASP.NET - 依存関係の挿入による ASP.NET Core でのクリーンなコードの作成

これでカスタマーの情報を取得するWeb APIが出来ました。

VS Code上でF5またはCtrl+F5(MacではCmd+F5)を押して実行して見てください。ブラウザが開いてデフォルトのHomeページが表示されるので、下のURLを手入力します。

先頭から3件取得
http://localhost:5000/api/customers?offset=0&limit=3

カスタマーIDを指定して取得
http://localhost:5000/api/customers/ANATR

データベースから取得した情報がJSON形式で表示されれば成功です！


これからは.NETでのWeb開発といえば「ASP.NET Core」という事になって行くと思います。

WindowsでもMacでもLinuxでも全く同じように開発が出来るのがいい感じです。


今回のソースコードはこちらにあります。

https://github.com/mikehibm/AspNetCore-MySampleWeb



参考URL：

ASP.NET Core MVC with Entity Framework Core - Tutorial 1 of 10

チュートリアル: ASP.NET Core MVC で Web API を作成する | Microsoft Docs 

　

REST APIに代わる効率的なバックエンドサーバーとの通信方法とは

最近ReactやAngularでREST APIを呼んで動くアプリケーションをいくつか作っています。

ただ、特定の画面を表示するためのデータを得るために何回にも分けてAPIを呼び出す必要があるような場面が結構あり、なんとなくモヤモヤしたものを感じていました。

調べてみると2015年ぐらいからNetflixやFacebookといった企業からREST APIに代わるモノが出てきているようです。

Falcor

Falcorで実現する効率的なfetch - Falcorとは | CodeGrid

Falcor入門 1日目 Falcorとは何者か - Qiita

これらを読んだかぎりでは Falcor 良さそうな気がしますが、GitHubを見ると最近はあまり活発に更新されていない(?)ような感じもします。どうなんでしょうね。

GraphQL

GitHub APIから学ぶ次世代のAPI実装方式GraphQL - Qiita

GraphQL入門 - 使いたくなるGraphQL - Qiita

Apolloを使って、React-Reduxの世界にGraphQLを持ち込む



GraphQLについては前から聞いたことはありましたが、何やらややこしそうなので近づかないようにしていました。

ただ今回下の動画を観てGitHubのAPIが昨年からGraphQLに対応していることを知り、これはと思って調べてみました。これからもう少し勉強してみようかと思います。

Phil Haack - GitHub | On .NET | Channel 9 


今年は GraphQL の人気が上がって来そうな気がなんとなくしています。

リバースプロキシを使っているWebサイトでHTTPからHTTPSに自動的にリダイレクトさせるための設定

IIS 8.5 での設定方法です。

まず、Webサーバーに「URL Rewrite」モジュールをインストールします。

URL Rewrite : The Official Microsoft IIS Site
https://www.iis.net/downloads/microsoft/url-rewrite

次に、該当のサイト直下のWeb.configを編集してsystem.webServerセクションにrewriteの設定を追加します。

リバースプロキシ（例えばAzureのApplication Gatewayなど）を使っていない場合は、こちらのサイトにある方法で問題無いと思います。

WebサイトでHTTPSへリダイレクトさせる | たんたか
http://blogs.gine2.jp/taka/archives/2790

リバースプロキシを使っている場合は、この方法だとリダイレクトが無限ループになってしまいます。

そこで下のように書き換えます。




これで無事思った通りにHTTPからHTTPSにリダイレクトしてくれるようになります。


リバースプロキシから送られてくるX_FORWARDED_PROTOヘッダの値をチェックして、「https」でない場合だけリダイレクトするという条件になっています。


また{REQUEST_URI}を使った場合は「appendQueryString="false"」を付けておかないと、REQUEST_URI自体が既にクエリー文字列を含んでいるためにURLの「?」以降の部分が2回重複して追加されてしまうようです。

URL Rewriteモジュールを使うとプログラムを書き換えずに対応出来るので便利ですね！

MSBuildでVisual Studioのプロジェクトをビルドした時に参照しているDLLが出力フォルダにコピーされない問題の対処法

表題の通りの問題にぶつかって、今日は解決策を見つけるまでに数時間もかかってしまいました。せっかくなのでメモしておきます。


事の発端は、あるASP.NET MVCのプロジェクトでActiveReportsのバージョンを更新したことでした。ライブラリの参照やソースコードを自動で更新してくれるツールがあるのでそれを使ってプロジェクトを更新しました。

するとその直後から、MSBuild.exeを使ってコマンドラインからビルドした場合にアウトプット先のフォルダにActiveReportsのDLLファイルがコピーされないという現象が発生しだしました。

Visual Studio の中でビルドを行った場合には全く問題ありません。


色々調べましたが結局、該当のプロジェクトファイル(.csproj)をエディタで開いて以下のように直接書き換えることで解決しました。

変更前

変更後

<Reference>タグの中に<Private>True</Private>という記述を追加すればOKです。

この設定は Visual StudioのSolution Explorer の表示上は「Copy Local」というプロパティに当たる部分になります。

問題は、これが初期状態だと「True」と表示されているのに、実際にはプロジェクトファイルでは上の画像の変更前の状態にあるとおり、<Private>True</Private>という記述が無いということです。このせいでMSBuild.exeが正しく動作しなかったという事みたいです。

プロジェクトファイルを直接書き換える他にも、Visual Studio上で「Copy Local」を一旦Falseにして保存して、Trueに戻してからもう一度プロジェクトを保存する、という手順でも同様の効果がある様です。



参考URL：
visual studio - MSBuild doesn't copy references (DLL files) if using project dependencies in solution - Stack Overflow






　

今さらながら Toshiba dynaPad を買ってみた

年末にChromebook FlipをeBayで買ったところ不良品にあたって失敗したので、どうしようかな～と考えていました。

結局、1年以上前に発売された機種ですが 「Toshiba dynaPad」を買うことにしました。

Microsoft Storeでこんな感じで$449でセールされていました。

今調べたら発売当初の定価が$569らしいので、落ち着いて考えると1年落ちのモデルでこの価格というのは本当にお買い得なのかどうかちょっと微妙な感じもします。

でも12インチサイズで560gという驚きの軽さと、ワコムと共同開発したという2048段階筆圧感知の「TruePen」に惹かれました。


今のところ考えている用途は、次の3つです。

1. 家族がリビングでさっとWebを見たり動画を見たりする。
2. 子供の宿題やお絵かき用
3. 紙のノートを置き換えることが出来るか、僕の実験用。

デザインが良いのでリビングに置いておくのに良いかも。

縦置きでのWeb閲覧も快適。

2週間ほど使っていますが、今のところ良い感じです。特に6.9mmという薄さとこの軽さは最高です。

Webサイトや動画の閲覧には、同時にたくさんのタブを開かないようにさえ気をつければ全く問題ありません。

子供に使わせるとすぐに独占されてしまいそうなので、まだ使わせていません。（笑）

仕事のミーティングなどで紙のノートの替わりに使えるのか、という点についてはかなり実用的に使えそうです。付属のペンの書き味は僕がMicrosoft StoreやApple Storeの店頭でSurfaceやiPad Proを触った感触と比べてもまったく遜色ありません。というよりもこちらの方が若干反応が良い気がします。細かい文字を素早く書いた時でもきっちり追随してくれます。ただ画面がつるつると滑るのでそこだけは紙の感触とはだいぶ違って慣れが必要だと思います。

CPUがAtom x5-Z8300 なのでところどころで一瞬待たされる感じはあります。これは価格からすると仕方ないのかなとは思いますが、今後i5やi7バージョンが出たらぜひ仕事用にも買いたいと思わせられる機種です。






 .

『新品同様』のAsus Chromebook FlipをeBayで落札した結果

1年ちょっと前にこんな記事を書いていました。

Asus Chromebook Flipがかなり気になる - 米Amazonで249ドル！

まだ次期モデルが出ず、同価格帯で他に欲しい機種もなかったのでついにこれを買うことにしました。

eBayで探すとメモリ4GBの中古品が大体150〜180ドルぐらいで落札されているようです。発売から1年以上経つのにあまり価格が下がっていません。

とりあえず2件ほど入札してみましたがなかなか買いたい価格で落札出来ませんでした。

オークション終了の15秒前に入札するという方法で3件目をついに落札。「新品同様」のものを送料込みで199ドルで買う事が出来ました。

実はこんなに必死になってeBayのオークションをしたのは初めてです。終了時刻が近づくとドキドキして、落札出来た時は興奮しました。たまにはオークションで買うのも楽しいですね。

さて、5日ほどかかって届いたAsus Chromebook Flipですが、9.7インチのiPadとほぼ変わらないコンパクトさで、外観もアルミニウムの質感が出ていてとても良い感じです。

https://www.cnet.com/products/asus-chromebook-flip/2/

「これは良い買い物をしたな〜」と満足でした。

ところが、です。

フル充電してからさあ初期設定してみようと自分のメールアドレスを入力するところで、いきなり予想外の問題に遭遇してしまいました。

なんと、o, p, s, w などいくつかのキーが反応しないのです。さらにEnterキーとBackspaceキーも無反応。。。

一時的な問題かなと思ってシャットダウン後電源ONしてから試しても同じです。試しにUSBで外付けのキーボードをつないでみると問題ありません。

外付けキーボードをつないだままなんとかログインして、OSを最新版にアップデートして再起動してみましたが、やっぱり同じでした。本体のキーボードの動作不良であることは間違い無さそうです。

確かにこのキーボード、写真や動画で見る限りは気付きませんでしたが、実物はかなり安っぽいですね。もし正常に動作していたとしてもこのキーボード部分だけは好きになれなかったと思います。

もうこのままタブレット端末として使おうかとも一瞬考えましたが、やっぱりそれでは悲しいので返品する事にしました。

そもそもこういう、キーボードをくるっと裏返してタブレットモードにするタイプの機種だと、テーブルに置いて使う分には良いですがそのまま片手で持って使おうとすると裏面のキーが指にあたってどうも使いづらいですね。これも実際に試してみないと気付かなかった点です。

そういうわけで早速翌日に送り返して、今返金待ちの状態です。



今回学んだこと

● 安っぽいキーボードなら付いてない方がマシ。むしろ自分の好みのものを接続して使える方が有り難い。

● eBayの「新品同様」品には要注意。既に一度返品されたものがそのまま出品されている事もあるらしい。






　

Androidで18万DLされた自作アプリをWindowsストアに移植した結果

Androidで18万回以上ダウンロードされた自作アプリをWindowsストアに移植して約2ヶ月経ちました。

移植作業にはなんだかんだ言って1ヶ月近くの工数がかかってしまったのですが、その結果をまとめてみました。

ダウンロード数：　339回
広告表示回数：　1,745回
Fill Rate：　　　　約20％
広告クリック数：　　6回
広告収益：　　　48セント (約50円)


なんなんでしょう、この結果は。。。


あまりの少なさにがく然としています。（笑）

Windows 10のタブレットや2 in 1も増えて来たので、そろそろ行けるかな〜と期待していたのですが、Windowsストアからアプリをダウンロードして使うという使い方はまだまだそんなに広まっていないのかも知れませんね。


ちなみに広告はUWPアプリではAdMobが使えなかったので標準の「Microsoft advertising ad」というものを使ってバナー広告を表示しています。これですがFill Rateが20％って、AdMobと較べて低すぎですよね。


もちろん、宣伝の仕方やアプリのカテゴリなどによって結果は大きく変わると思います。


ただ個人的には次のアプリからはしばらくWindowsストアはパスという事に決定です。


とりあえず試してみて大体の感触が分かったのでまあ良しとして、次に行きます。^^)





　

cocos2d-xで作ったアプリをWindows 10 UWP対応にした時のメモ

結構苦労したので将来の自分のためにメモしておきます。

● Cocos2d-xを最新版に更新

1. cocos new コマンドで新しいCocosプロジェクトを作成。
2. 必要なソースコードや画像・音声などのファイルを古いプロジェクトからコピー。

- 共通のもの
 Classes ディレクトリ
 Resources ディレクトリ

- iOS固有のもの
 Images.xcassets ディレクトリ
 ios/AppController.*
 ios/RootViewController.*

- Android固有のもの
 app/src/org/cocos2dx/cpp/AppAcitvity.java
 app/res ディレクトリ
 app/jni/Android.mk
 app/jni/Application.mk
 AndroidManifest.xml
 ProGuard設定ファイル

- Windows固有のもの
 App/Assets ディレクトリ

● ソースコードの文字コードを「UTF-8 BOM付」に変換

Windows版をビルドするために使うVisual StudioはUTF-8でかつBOM付きのファイルしか正しく扱えないので、nkfコマンドを使って全てのソース・ファイルをUTF-8 BOM付きに変換します。

カレントディレクトリ直下のファイルのみを対象にする場合

  nkf -W -w8 --overwrite *.cpp *.h

カレントディレクトリ以下の全てのディレクトリで再帰的に実行する場合

  find . -type f -name "*.cpp" -exec nkf -W -w8 --overwrite {} \; 
  find . -type f -name "*.h" -exec nkf -W -w8 --overwrite {} \; 

ちなみにこの処理をWindows上で実行する場合は、下のソフトウェアが便利です。

文字コード変換ツール「KanjiTranslator」(フリーソフト)

● 各種エラーを修正

Windows上で実行した時にLabelの文字列などが文字化けする場合は、.cppファイルの先頭に下記の#pragmaを付けると良いかも知れません。（これで直ったのか他の事で直ったのか、記憶が定かではないのですが。）

#pragma execution_character_set("utf-8")

● 日本語フォントファイルをアプリに含める

Resources/fonts ディレクトリに使用したいフォントファイル（例えば「YuGothic.ttf」など）をコピーしておきます。
ソースコードではフォント名を指定する部分で "fonts/[フォントファイル名]" を使う様にします。

● Windows版で不要な機能をコメントアウト

今回はWindows版ではアプリ内購入で広告を消す機能は省略したので、アプリ内購入に関する処理を全てコメントアウトしました。

iOS Meetupで関数型言語を勧められたのでメモ

Elixir

[翻訳] なぜ私はElixirに賭けたか - メンテナンスプログラマになりたくなければ君もそうしろ - Qiita

Rails, Node.js の次はこれだそうです。ミリ秒ではなくマイクロ秒の単位でレスポンスを返す事が出来て、さらに200万の同時(?)接続を1台のサーバーでさばけると。来るべきIoT時代には必須の言語かも知れません。

大規模なオンラインゲームとかLINE並みのチャットサーバーとかには向いてそうだけど、現時点ではちょっと自分には必要ないかなあ、とも思うのですが上の記事を読むと確かに面白そうなので一応かじっておきたいなという気はします。

そういえば「プログラミングElixir」という本がちょっと前から気になっていてAmazonのカートに入ったままになっているので、こんどこそ買おうかな。

Clojure/ClojureScript

Clojure の Web アプリケーション開発について 1 から 10 くらいまで - Qiita

Webアプリのサーバーサイドが関数型言語で作れるとの事。


今思い出せば、私が初めて関数型言語というものの面白さに少しだけ触れたのはこのClojureについてのKindle本を通じてでした。



この本はオススメです。（たったの100円！）



FacebookのReactをいい感じに使えるReagent

ClojureScriptを使えばクライアントサイドも同じ言語で書けて、さらにビューはReactで生成出来ると。


そしてさらにClojureScriptはJavaScriptに変換されるのだから、React Native を使えばモバイル用のネイティブアプリも作ることが出来ると。

ClojureScriptとReact NativeによるiOSアプリ開発 - Qiita 

re-natal: Bootstrap ClojureScript React Native apps 


なるほど。これはぜひ試してみたいけど、まずはClojure勉強しないと。

Elm

Elmというミニマムでフレームワークにもなる関数型altJS言語を触ってみよう！！！ - Qiita

関数型リアクティブプログラミング言語Elmに学ぶ フロントエンド開発の新しい形 【前編】 (1/5)：CodeZine

ちょっと見た感じではこちらの方がClojureScriptよりもとっつき易そうな感じでしょうか。

ちょうどいつもお世話になっているEggHeadという動画学習サイトに最近Elmのコースが追加されたのでブックマークしていたところでした。

Start Using Elm to Build Web Applications * - Course by @splodingsocks @eggheadio

テスラ Model Xに試乗して来ました！

先日アラモアナショッピングセンターに行った時にふとTeslaのショールームに寄ったのですが、前から試乗してみたいなと思っていたので軽い気持ちで「試乗出来るの？」と聞いてみたら「もちろん！」と言われたので、じゃあ試乗してみようという話になりました。

その場でタブレットにメールアドレスや電話番号を記入して、試乗のスケジュールを確認。結構空いているみたいでしたが、ちょうどその日から3日後の午後3時がこちらとしても都合が良かったので予約しました。

そして当日、奥さんと2人で午後3時ちょっと前に再びショールームを訪れました。名前を言って試乗に来た旨を告げると、係の人（サム君）が来て水のボトルをくれました。しばらく待つと奥の部屋に通されます。そこは外に通じるガレージになっていて、真ん中にはあの「Model X」が待っていました。

一通り充電の仕方などの説明を聞いたあと、サム君がiPhoneを取り出して何やら画面をタップすると、目の前のModel Xがひとりでに動き出してガレージから外のパーキングに移動します。

早速、私が運転席、奥さんが後部座席、サム君が助手席に乗り込んで出発です。

通ったルートは下の通り。アラモアナから高速（H1）に乗ってカハラまで。往復40分以上は走ったので結構な距離です。




高速に乗ってしばらくすると、サム君が「自動運転を試してみる?」というので、どきどきしながらやってみました。

ウィンカーの下に短めのレバーがあり、それを手前に2回動かすと自動運転モードになりました。おそるおそるアクセルペダルから足を離し（ここまではいわゆるクルーズコントロールと同じですが）、さらにハンドルからもそっと手を離します。

もちろんテスラは緩くカーブしたH1の真ん中のレーンを何事もなかったかのようにペースを保って走り続けます。

思わず「Wow!」と口から出てしまう体験でした。

ただしばらくその状態を続けるとすぐに慣れてきて、「近い将来には全てのクルマがこうなるんだろうな」という実感が湧いてきました。不思議なものです。

自動運転モードのままでウィンカーを操作すると「自動レーン変更」が始まります。これも試してみましたが、あまりにもスムーズ過ぎてそれほど感動が無く「ふーん...」という感じでした。

一番感動したのは、一旦高速を下りて見通しが良くなったところで「ここなら思いっきり加速していいよ」と言われた時でした。

「え、いいの？」と思いながら、思い切ってアクセルペダルを踏み込むと予想通り一気に加速して身体がシートに押し付けられます。後部座席の奥さんが軽く悲鳴を上げたほどでした。それでもサム君は「今ので大体フル加速の10％ぐらい」と言っていました。もうちょっと踏み込んでおけば良かった。。。(笑)

それにしても面白いのはいくらアクセルを踏んでもエンジン音がしない点です。なんとも妙な感覚ですが、これが電気自動車なんですね。

さて、次に面白かったのは住宅街の道路で「自動縦列駐車」を試した時でした。「さあ、ここでストップして」と言われたところで停めてから、画面上のボタンを押すとクルマが勝手にハンドルを切ってバックして、ほんの10秒ほどで縦列駐車が完了です。いや、実際には10秒も掛かっていなかったかも知れません。奥さんはこれに最も感動していたみたいです。

カハラからアラモアナへの帰り道は運転を奥さんに代わり、私は後部座席に座りました。乗り心地はもちろん文句なしです。

帰り道、世間話をしながらサム君は「どう、このクルマ気に入った？」と我々が購入する気がありそうかどうか、探りを入れてきます。値段を確認してみると、3年のリース契約で月約1,100ドル（初期費用約6,500ドル）だそうです。

お値段を聞いて固まっている私達を見て、サム君はすかさず「今度出るModel 3なら月500ドルぐらいだよ。1000ドル払えば今すぐ予約出来るよ。」と勧めてきます。ただModel 3は今予約しても納車は2年後ぐらいになるそうです。

返事をうやむやにしながら話題をそらせたりしているうちに、アラモアナショッピングセンターに帰ってきました。Model Xの前で記念写真を撮ってサム君と握手して、楽しかった試乗が終わりました。


電気自動車、完全自動運転。

今はまだ価格も高くて珍しい存在ですが、数年後には確実にもっと普及して当たり前の存在になっているだろうと思います。今回の体験でその感触をはっきりと確かめられた気がします。





　

Nexus 6から中古のiPhone 5sに変えて起こった変化とは

1ヶ月ほど前に、愛用していたNexus 6を硬い床の上に落としてかなり派手に画面を割ってしまいました。実はまだ24回払いの残金も残っているというのに。（涙）

それから、余っていたiPhone 5sを仕方なくメインの携帯として使っています。今までアプリ開発のテスト用にたまに触るぐらいだったiPhoneですが、毎日使ってみると（予想通り）やっぱり使いやすいですね。

なんと言っても、まずポケットに入れたときの収まりの良さが違います。（笑） まあこれは単にサイズの違いなんですが。

ただ画面が小さい分文字を読むのが辛く感じます。

Nexus 6だと、FeedlyでRSSをチェックしてからSmartNewsで最新ニュースを読んで、その後Twitterをダラダラと眺める、という流れでゆうに1時間ぐらいはスマホの画面を見続ける事が出来たのですが、老眼が入ってきつつある眼にはiPhone 5sの画面サイズで同じ事をするのはきついです。


そこでこの1ヶ月で起こった変化とは、、、



Nexus 7(2013年モデル)の復活！！ 



でした。

最近全然使わなくなっていたNexus 7ですが、このところ毎日活躍しています。このサイズ感は本当にいい感じです。

Googleからもうすぐ新しい7インチクラスのタブレットが出るらしいという噂もあるので、そちらも楽しみです。








　

Visual Studio Code で .js.map など特定のファイルを非表示にする

VS Codeで TypeScript のソースコードを書いていて Webpackやtscコマンドでトランスパイルした時にデフォルトでは .map ファイルも自動的に作成されます。

このソースマップファイルをエディタ上のファイル一覧には表示したくないので、その設定方法のメモです。

{
    "files.exclude": {
        "**/*.js.map": true,
        "**/*.js": {"when": "$(basename).ts"},
        "**/.git": true,
        "**/.DS_Store": true
    }
}

"**/*.js": {"when": "$(basename).ts"}

と書くと、「同じ名前で拡張子が .ts のファイルが存在する場合だけ .js を非表示にする」という事が出来るとの事。

これは便利。

【VSCode】Visual Studio Code 0.5.0の新機能まとめ - Tumbling Dice http://outofmem.hatenablog.com/entry/2015/07/20/154030

[VSCode]ファイルツリーの表示制御｜杏z 学習帳
https://anz-note.tumblr.com/post/126106378651/vscode%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%83%84%E3%83%AA%E3%83%BC%E3%81%AE%E8%A1%A8%E7%A4%BA%E5%88%B6%E5%BE%A1

Azure Blob StorageにJavaScriptから直接アップロードする

Azure Blob Storageにブラウザ(JavaScript)から直接アップロードする必要があったので、簡単なサンプルを作ってみました。

https://github.com/mikehibm/AzureDirectUploader

JavaScriptでHTML5のFile APIを使ってフォルダ内のファイル一覧を表示し、「Upload」ボタンを押すと選択されたファイルを一つずつAzure Storageにアップロードします。


ブラウザから直接アップロードするとは言っても、最初に一度だけサーバー側の処理を呼び出す必要があります。ASP.NET WebAPIはそのためだけに使っています。

これはAzure Storageアカウントのアクセスキーをクライアント側に渡さずに、一時的に「Shared Access Signature（共有アクセス署名）」というものを生成してそれをクライアント側で使える様にするためです。

一度SASを取得してしまえば、有効期限が切れるまでそれを使ってブラウザからAzure Storageにアップロード出来ます。サンプルでは有効期限が切れたら再度SASを取得し直してアップロードを継続する様になっています。

クライアント側から直接アップロード出来ればサーバー側の負荷が減って便利ですね。






.