哲学はなぜ間違うのか？を考えてみる

「哲学はなぜ間違うのか」というブログを購読しています。
http://blog.goo.ne.jp/tsutomui2000/e/7842ab0afd20d2afc7677e5831befffe

お気に入りで、毎朝更新を楽しみにしています。
自分勝手に、ふむふむ納得したり、んなこたぁないやろとツッコミ入れたりしますが、
たいがい期待したストーリーとは違う方向に展開していくので、どちらかというと心が乱れます。
オチはないような気がします。どうなのでしょう？？

コメントやトラックバックが表示されることはなく、いいねもひとつもないままですが、
カテゴリ別ランキングでは上位なので同じようにひっそり楽しんでいる読者が多いのでしょう。
一度どうしても答えが知りたくなりコメントでポストしてみましたが応答はありませんでした。
そうゆうところにも意図を感じます。

著者との直接会話は難しいとしても、読者同士で会話できる仕組みがあれば良いかもしれません。
もしかしてそうゆう場所はすでにあって、自分が参加できていないだけでしょうか
それとも、そうゆう会話に収穫はなくて、ひとりで悶々するのがやはり良いのでしょうか

ネット世界はスピードが速くて、ついていけなくなったというかついていくのをやめたというか
降りた電車が走り抜けていくのを茫然と眺めているような人は少なくないでしょう。
その人たちと話してみたい…

http://d.hatena.ne.jp/Chikirin/20171226
自分もやはりちきりんの言うつながりを求めています。
たぶん、ネットは最初からそのためにあって、今もそのとおり存在していて、
自分が迷子になっているだけなんだと思います。

VueなSPAがiphone4sで表示されない

巷には、Babelで始めるモダンなJavaScript！みたいな紹介があふれております。
import  from～とrequire(‘～’)のどっちがモダンか？は微妙ですが、
コードのパクリ元で使われていたのでモダンかどうかも考えずに使っておりました＞ES6

VS2017とChrome＠PCで作成していて全く気付かなかったのですが、
ieとiOS9以前safariではSPAのレンダリングが行われず真っ白なページが表示されてしまいました。
ブラウザデバッグしてみると、ところどころでES6なコードがひっかかっているようです。

ん？それってwebpack&babel-loaderが良きに計らってくれるはずじゃなかったの！
たしかに、import文は気にせず処理されているようです。
しかし、iOSでひっかかったのはconst文です。
いや流石にそれは変換してくれるはずでしょう＞babel

なので、たぶん自分のwebpack.config.jsのどこかに問題がありそうな気がします。
しかしそれが意味もわからずどこかからパクってきたものなので何が悪いかわかりません。
webで調査を始めると新旧玉石混交した情報で余計に混乱します。

test: /\.vue$/,
loader: ‘vue-loader’,
options: {
  loaders: {
    ‘js’: ‘babel-loader’
  }
}

このbabel-loaderが正常に働いてない気がします。
それはもしかするとvue-loaderのせいかもしれません。
が、なにもはっきりしたことは言えません。

昨日は何も問題がないと思えたVue.jsですがこの辺りは問題と言えば問題な気がします。
地道に人力Babelしようと思っています。
開発もVS2017→VS2015になり、
VS2015のエディタはES6に優しくない気がするのでちょうど良かったかもしれません。

追伸

原因はbabelのpresetsオプションが指定されていなかったからかもしれなくて、
.babelrcファイルを追加したところ解決されたような気がします。
原因を調べるために、vue-cliが作成する環境をみてみましたが、早々にくじけました。
vueモジュールをビルドするために、webpackやらbabelやらの知識が必要になりますが、
これらをほんとうにきちんと理解するのは簡単じゃないですね。
必要になる知識が次々に増えていき、いつまでも追いつけないのじゃない？
と思ってしまうのが辛いです。一歩一歩ですね。

Vue.jsアプリのスタートポイント

Vue.jsの検証アプリがだいたいできてきました。
他のフロントエンドフレームワークをやっていないので比較はできませんし、
簡単なアプリなので全部の機能を使いこなしたわけでもないですが、
特に気になったりひっかかったりするところはありません。
良いと思います＞Vue.JS

jsをビルドしてjsを生成する。←おもしろいですね。
このおかげ、Webアプリを昔から慣れ親しんだFormアプリのように作成できるわけです。
20年前にDelphiで作成していたようなアプリをひとつポンとWebページに貼りつける。
というイメージです。

template, style, scriptをひとつの.vueファイルにまとめて書く。のも気にいりました。
jqueryとajaxでページの部分更新を行ったりする場合、
必要になるscriptやcssをどこに配置するのがいいの？←で迷うときがありましたが、
そうゆうのが一番面倒なんですよね；から解放される気がします。

なので、簡単なアプリであっても最初から単一コンポーネント化して開始する。
のが良いと思います。
そして、templateが大きくならないようにどんどんコンポーネントに分解していく。
データの共有をどうするの？とちょっと不安がよぎることはありますが、
余計な心配はしないで、どんどん分解しちゃって良いです。
コンポーネントから別コンポーネントのメソッドを呼び出す仕組みもちゃんとあります。
その辺りも、silverlightで作るvmなんかよりもむしろ簡単なような気がしました。

ということで、webpackに食わせるapp.jsはこれで決まり！で良いと思います。
import Vue from ‘vue’
import root from ‘./root.vue’
new Vue({
    el: ‘#app’,
    components: { root },
    template: ‘<root/>’
})

どんなアプリであってもここから始めてコンポーネントに分解していく。
アプリ開発作業=コンポーネント分解作業。に単純化しちゃいます。
作業規模は単純にコンポーネント数のリニア関数です。いいでしょ？

そして分解したコンポーネントに用意するべきものは
components, props, data, methods, computed, created…
とコンポーネントのプロパティにきちんと整理されているも良いと思いました。
vue.jsをデザインした方はきれい好きな人だと思います。

MVC5のDIはAutofacで行う

MVC5で新しいプロジェクトを開始しました。
EntityModelを追加してAPIControllerをひとつ開始するまでにずいぶん手間取りました。

まず最初に悩むのはDBContextをどうするか？です。
プロジェクトにはすでにApplicationDbContextがあります。
そこに作成したModelのDbSetを追加すればよいのでしょうか？
DbContextがひとつであればMigrationで悩むことはなさそうです。
ですが、いずれ作成するServiceクラスでApplicationDbContextをどう参照すればいいのでしょう？
DIとか？そもそもIdentityの動作の仕組みをちゃんと理解してないのでとても不安です。

なので、DbContextは別に追加するのがまずは無難な気がします。
でも、できればDataBaseまで分けたくはない！ということはあるでしょう。
そして、プロジェクトにふたつになったDBContextをどうMigrationすればよいのでしょう？
幸いEF6以降ではひとつのDBに複数のDBContextをMigrationする手順があるようです。
そのページをみつけるのがまたひと苦労でした。

さて、ApplicationDbContextじゃないDBContextが準備できたので、
ServiceクラスとAPIControllerを作成して、つづいてDIを構成することにしましょう。
Unityをインストールしてみます。ログインできなくなりました！！
いったいなぜ？ よしんば対策があったとしてもそんなことしたくありません。
UnityをアンインストールしてAutofacをインストールしてみます。
問題なくログインできそうです。
それでは、DIするクラスをAutofacに登録していきましょう。
Unityには用意されていたInjectionFactoryのようなものが見当たりません。どうするの？
自前でDBFactoryを作成してDBContextの代わりにInjectする。で良いみたいです。

簡単なごく普通のプロジェクトの形だと思いますがやけに面倒な感じがしませんか？
私は疲れますた。もっとも、
MigrationもDIも必ずしも必要なわけじゃないので勝手に疲れただけと言えます。
でもやはり、「Migration、DI、Identityを考慮したDBContextをどう計画する？」
なにが正解？を知りたい気持ちを収められないのでした。

VisualStudio2017のSPAテンプレート

MVC5（.Netframework）の新しいプロジェクトでVue.jsを試しています。
フロントエンドフレームワークは、Angular,React,Vueあたりに人気が集まっているようですが、
VisualStudio2017に搭載されているSPAテンプレートは相変わらずknockoutのままです；
いまどき誰も使わないようなテンプレートがなぜ残っているのか？
おそらく、このテンプレートの主目的がknockoutの説明ではなくてaccess tokenの取得方法だからでしょう。
なのですが、その説明が不足していてその理解にはいつも手間取ります。
https://tsmatz.wordpress.com/2014/05/20/asp-net-spa-javascript-web-api-asp-net-identity-html5biz/
松崎さんのこの解説はとても助かるのですが、自分レベルにはまだ難しいです；

/Account/Authorize にアクセスしてトークンを取得する。
それはその通りですがそのままで理解しようとすると、テンプレートのコードが複雑すぎ！と感じます。
もし”/”(ルート)以外の場所にSPAを設置している場合、リダイレクトURLを適切にする変更も必要でしょう。

/Account/Authorizeはリダイレクトを応答して、リダイレクトURLのフラグメントにtokenが格納されます。
なので、/Account/Authorizeコール時にSPAを設置したページにリダイレクトされるようにする必要があります。
をどうするの？が肝心のSPAテンプレートには書かれていないので手間取ります。
/Account/Authorize要求のクエリーにredirect_uriパラメタを指定すると、
ValidateClientRedirectUriのcontext.RedirectUriに格納されて通知されますので、それを確認してValidated()します。
ValidateClientRedirectUriにaccess tokenを必要とするSPAのURLを登録しておくイメージです。

そしてこの一連の処理がSPAコードの中で行われている。という辺りにも混乱が潜んでいる気がします。
/Account/Authorizeからトークンを取得するパターンは、
SPAの外側、つまりMVCのログインページでログインしていて、
そのログインのaccess tokenを取得してsessionStorageに格納するわけで、
また、その処理手順は、asp.net MVC5フレームワークに依存しているわけですから、
その一連の処理はSPAの外側で実行する。つまり、access tokenの取得～格納はSPAの役割ではない。
のが、わかりやすい気がします。

動画@MVC3

MVC3で動いているサイトに動画アップ機能を追加することになりました。
html5の<video>タグを配置するとページに簡単に動画プレイヤーを実現できます。
うまく動作するようになったと思ったのですが、Safariだけ動画ファイルをうまく読んでくれません;

他のブラウザではちゃんと動作しているようなのでどうにも原因がわかりません。
IISExpressでテストしていたのがさらに周り道になりました。
IISExpressだとContentsフォルダの動画ファイルもSafariではダウンロードさえできません。
これはもうSafariを疑ってしまうレベルでしょ。だって他ブラウザでは問題ないのですから。

結局、どうもmvc3のretun Fileがrange requestに対応していないのが原因だったようです。
今回はとりあえずこれを使って対応しました。感謝です。
https://jonlabelle.com/snippets/view/csharp/range-requests-in-aspnet-mvc

しかしなぜ他のブラウザではこの問題が発覚しなかったのでしょうか？
その他にも、間違ったContentTypeを気にしたりしなかったり、
同じ動画ファイルを再生できたりできなかったり、
<video>の中身はブラウザ毎にかなり違っていそうです。

昔、silverlightのウリのひとつが動画再生だったのを思い出しました。
最初に作成してみたxapもページに埋めこむための動画プレイヤーでした。
実現できること自体は当時とたいして変わってないですし、面倒が減ったわけでもありません。

今回の動画はオマケ的な機能なのでサイト内でホストしていますが、
いずれは、保存場所はどこがいいのか？を含めて機能分離を検討する必要があるかもしれません。
ユーザープライベートなデータをどうやって分離格納するのかがまずは課題です。
と同じことをsilverlight時代にも妄想していて実現できていません。
自分もまたあまり成長できていないですTT

時間連続協会

Gigazineの記事で「地球平面協会」というのがあるのを知りました。
考えつくおおよそのことはすでに誰かがどこかで考えている。に改めて驚きます。
イーロンマスクさんや多くの科学者がその理論展開に注文をつけているということですが、
それはつまり無視できない興味の現れで、その旺盛な好奇心にも関心します。

自分的には地球は丸いを確信できる証拠をこの目でみたことも体験したこともないので、
なのにそれを信じて疑わない（疑えない）のは、確かにこれはおかしなことです。
今日それを疑える人はだれもいないわけですが、ある意味それは幸せなことに思えます。
少なくとも平らな地球の果ては一体どうなっている？を疑わなければならない面倒から解放されるからです。
それで誰かと言い争ったりする必要もありません。
人類にとってとても都合の良い事実が発見されたと言える気がします。

さて一方、時間の端についてそれはまだ当面謎のままと思えます。
どこから始まってどこまで続いていくのか？
その問いは、宇宙の始まりと膨張に似ているため、
最新の物理学では時間と空間は表裏一体として捉えられているようです。
いつかこのフロンティアにも都合の良い事実が発見されるとしたら…
地球に端がなかったように、時間にも端はなくてメビウスの輪のように連続している。
という想像がもっとも妥当な推論に思えます。
宇宙の果てが自分の身体の細胞の中の小さな分子の中に発見されるという可能性はないでしょうか？
これは私たちにとってどう都合良いのでしょう？？

おそらくたぶん、すでにどこかにあるような気がします＞時間連続協会。
冬休みになったら探してみたいと思います。

こんにちわVue

MVC5でVueを試してみました。
もっとも簡単な手順をみつけました。
http://www.mithunvp.com/working-vuejs-asp-net-mvc-5-visual-studio/

むかしあったknockoutなSPAテンプレートに比べてずっと意味がわかりやすいと思います。
余計な手順に翻弄されることもないので助かりました。
あまりにも簡単なコードなので、これでわかった気になるのは早すぎですが、
最初の印象は大切ですね。長く付き合えっていけるでしょうか？
よろしく＞Vue

こんにちわNode.js

Kindle Unlimitedのひと月無料お試しを使って、「Node.jsビギナーズガイド」を試してみました。
ASP.NETerが入門するにはとてもわかりやすい説明になっていました。
せっかちなもんで、どこが同じでどこが違うの？を手っ取り早く知りたいわけですが、
チュートリアルを進めていくとそうゆう疑問に順番に答えが得られたような気がします。
「Expressを導入しよう」まで進んで、これまでと同じように開発できる確信が持てました。
「PostgreSQLを使おう」で、でもまあやっぱまだasp.netでいいかも；と確信しました。

asp.netがマルチプラットフォーム対応になった今となっては、
積極的に選択する理由はあまりなくなった感じがしないでもありません。
今後どうなるかはわかりませんが、asp.net開発にもnodeのあれやこれが入り込んできているので、
ASP.NETerにもやはり必要なわけです＞Node入門。
なにかいろいろ微妙に絡まっていて困ったものです；

さて、今回Node入門の先にMeteor入門があったわけですが、
こちらはKindleに見当たらず、本家チュートリアルをやってみました。う～みゅ
手順とおりに進めればそのとおりに動くアプリケーションが作成でききるわけですが、
なんでしょう？過去に覚えた言葉で理解できないまま進んでしまうところがあるような気がします。
なので、このチュートリアルを終えてもこれで準備ができた！という確信まで至りません。
とりわけ、ASP.NETerには躓き所がいろいろありそうで、その霧が晴れるのには時間がかかりそうです。
たぶん心をもっと真っ白にして進んだほうが良いのでしょう。

Windows Subsystem for Linuxを動かした。の後は？

Fall Creators Updateを行いました。
Windows Subsystem for Linuxが正式版として提供されているそうです。
WindowsストアからUbuntuもインストールして、無事Bashなコマンドも打てるようになりました。
Bashから、pythonだとかmeteorだとかも起動できるみたいです。
これでLinux入門の準備ができたような気がします。めでたし。

さて、githubからmeteorなプロジェクトをgit cloneしてmeteor-build-clientなどもしてみました。
あ～流石bashシェルです！プロジェクトサイトの説明通りコマンドがすんなり動作します！
これで、このマシンでon Linuxな開発もできるようになるのかあ！！

をVisual Studio Codeを使って行えるのか？←がよくわかりませんT.T
Visual Studio Code＠WindowsでWSLのファイルをいじるのはやばい気がします。
んだば、WSLにもVisual Studio Codeをインストールすればええんでね？←できるの？←がわかりません；
コードはVisual Studio Code＠Windowsで行って、ビルドとかだけbashで行えばいいのかも
などといろいろ考えたりしているうちにあんまりたいしてうれしくなくなりました＞WSL
すなおにVMでやればよくね！てか、macでやればいいんでね！みたいな；
うう～～みゅ どうも一旦お蔵入りしそうです＞WSL