tekitoumemo’s diary

C#、.NET系の技術ブログを書いています。みんなの洋楽ランキングを運営しています。

個人サービス公開して一年経ったので振り返る

このブログに何度も登場してるサービスですが、2018年の4/1に公開してから一年経ったので振り返ります。

結論から言うと、

全然上手くいってません!赤字です!

2018/4 公開!


当時はとにかく3月中にリリースする!という目標を持ってやってた。ほぼ3/31の夜にリリースし、ギリギリ間に合う。ただ、当時のデザイン、機能は最低ライン(今だったら絶対公にしないレベルで恥ずかしい)のレベルでドメインもAzureドメインのまま。さらにWindowsでしか開発出来ない.NetFrameworkで作ってしまった。当時の記事に失敗したことを書いていました。

2018/5 .NET Coreへ全てリプレイス

f:id:tekitoumemo:20190405224220p:plain
当時、Macminiのbootcampで開発してたのですがクッソ重くてさらにVS重くてそれだけで仕事後に開発するのが億劫になってました。そのときにちょうどMacBookを購入したのでリプレイス開始。サイト自体は管理画面で更新出来るので、運用しつつ裏ではリプレイス作業を行なってるという感じでした。リプレイス作業は4月中に終わらせる予定でしたが、データアクセスをEntity frameworkからDapperに移行したので、そこが思いのほか大変で5月半ばまで掛かりました。データアクセスはオレオレDapper拡張ライブラリを作ったりして、全て違う作りでリプレイスしました。多少のバグはあったのですが、管理画面に関するところだったのであまり影響はありませんでした。リプレイスは実際公開するまでの時間と労力の割にサービスが良くならないのでモチベが大変ですが、開発して得た知見をブログにすることでモチベを保てたのはよかったと思ってます。これとか👇
tekitoumemo.hatenablog.com

2018/6 SEOが爆上がりして1万PV達成

f:id:tekitoumemo:20190405230846p:plain
Googleネムーンってやつですね。とりあえずモチベMAXなので記事増やしまくったりデザインを大幅に変えたり色々やりました。この頃に初めてReact導入して、いいね!など作りました。ユーザー数も6000と恐ろしいレベルで増えまくって希望に溢れまくってました。ただ、この頃はページ滞在率と離脱直帰率を全く意識してなかったのです。ここがサービスの作り手の分かれ道だと今は実感しています。。

2018/7 相変わらず好調で2万PV達成

f:id:tekitoumemo:20190405231842p:plain
相変わらず調子がよかったのです。この頃はユーザービリティを全く考えず、アドセンス導入やデザイン修正など小賢しい改善ばかり行なっていました。完全に調子に乗っていて、もともと考えていた「ユーザー操作が複雑な改善は極力しない」がバッチリはまったと自画自賛してました(心の中で)。はじめに書いた記事はちゃんと反省点を書いていたのですが、このときは全く反省は書かずに調子に乗った事ばかりかいてました。
tekitoumemo.hatenablog.com
7月末から激減するとは知らずに。。

2018/8 SEO爆下がりでPV激減

f:id:tekitoumemo:20190405232754p:plain
f:id:tekitoumemo:20190405233035p:plain
とにかくSEOが下がりに下がり、圏外まで行く事態となりました。タイトルを変えたりしょうもない改善ばかりしていました。そんなことしてても全く変わらないのですが、エンコードのせいにしたりITunesアフリエイトのせいにしたり最終的には.NET Coreにリプレイスしたせいだと謎な状態でした。その頃書いた記事。
tekitoumemo.hatenablog.com

2018/9 いつまでたっても爆下がりは改善されず。。

この頃はプライベートでちょうどめちゃくちゃ忙しく、細かい改善ばっかり。でもなぜかSEOは爆下がりしているけど毎月5000PVはありました。「洋楽 ランキング Youtube」で上位になってるのでそこがせめてもの救いだった気がします。

2018/10 そろそろ気にしなくなる

さすがに3ヶ月爆下がりで何もないともうどうでも良くなります。どうでも良くなるって表現が微妙ですが、PVあげる改善よりもリプレイスのときに出来なかったリファクタ、そしてなんと言ってもホスティングLinuxに。リファクタは.NET CoreのDIアーキテクチャに沿った改善、Linuxにする為に構成の整理とデプロイスクリプトの作成などエンジニアとして有意義な時間が取れました。モチベを違う方向にシフト出来たので精神的にもよかった。
tekitoumemo.hatenablog.com

2018/11 〜 12 ちゃんとした機能を

振り返るとちゃんとした機能が全く作れてませんでした。ちょうどモチベも違う方向に向いたので、新機能追加に取り掛かりました。まずは大量に追加した曲が埋もれてしまうので検索機能を作りました。1つ目は日付から検索できる機能。日付API作ってフロントはReact。地味な機能ですが、このサイトになくてはならないものです。
f:id:tekitoumemo:20190406003923p:plain
次にキーワード検索。キーダウン毎にAPIを呼び出すと負荷がかかる可能性があるので入力が完了してからリクエストを投げる仕様にしました。人間のキー入力が完了するには0.3秒みたい。さらに部分一致検索なのですが、検索したキーワードが昇順で検索できるように以下のようにSQLを書きました。

where M.name like '%a%'
order by (case when name like 'a%' then 0 else 1 end), name asc

こんな感じにソートされます。
f:id:tekitoumemo:20190406005156p:plain
さらにパフォーマンスは意識していて30ms程度の速度が出ています。この頃からサービスの傲りがなくなりちゃんとサービスを育てていこうと思いました。

2019/01 会員登録機能

f:id:tekitoumemo:20190406011847p:plain
始めと言ってることが180度変わりました。というのも地道に記事を追加して、見た目を変えていくだけだとサービスとして何も「面白くない!」と感じていました。Twitterを見てると洋楽を紹介する人がたくさんいてそもそも紹介するのは自分じゃなくても良いのではないかと考えるようになり、アンケートを取ってみました。


びっくりしたのが、記事を書きたくないって人が一人もいなかったことです。このまま勢いで開発でもよかったのですが、作っても使ってもらえなければただのゴミなのでユーザーにどのような形で対価を与えられるか結構考えました。ただ、タラタラ考えてもしょうがないのでリンクを貼らずに会員登録機能を作り、管理画面にアクセスする為のロールやどのような情報が取れてどのように表示できればユーザーが喜ぶか作りながら検討した1ヶ月でした。敷居の高い会員登録を簡単にする為にTwitterFacebookに絞ったり、記事投稿をTwitterの画面に寄せて簡単に誰でも書きやすいように作りました。
ちなみにGoogle認証は、画像が取得出来ないのでやめました。そのとき書いた記事です。
tekitoumemo.hatenablog.com

2019/02 会員登録+投稿機能を正式リリース

f:id:tekitoumemo:20190406012616p:plain
正式に公開して誰でも使えるようにしました。当然、宣伝しなければ使い方もわかりませんし会員登録するわけもないので1ヶ月ぐらい自分で投稿してみたり、会員登録したときのユーザー体験を感じマイページやユーザー紹介ページを作ったりしてました。ドッグフーディングはめちゃくちゃおすすめでとことんいろんな改善点が出てきます、しかも有力な。そこそこユーザーに使ってもらえる段階まで持ってこれたかなと。

2019/03 投稿機能を気合いで宣伝

3月半ばぐらいにユーザーに使ってもらえる段階になったのでモニターとして数人にDM。数人に記事を書いてもらえて特に使い方がわからないとの声もなかったのでひたすらフォロワーにDM。結果として11人、100記事近く書いてもらえるようになりました。まだまだ全然少ないですが、解説という敷居が高すぎる機能にこれだけの人が使ってくれたのはよかったかなと。さらに数ヶ月ぶりの1万PV達成。。SEOは相変わらずボロボロだけ運関係なく1万PV達成出来てよかった。
f:id:tekitoumemo:20190406013657p:plain
さらにさらにアドセンスの受け取り報酬に達したので当初から協力してくれた友人に報酬を支払うことが出来ました。

2019/04 引き続き投稿機能を宣伝

f:id:tekitoumemo:20190406014200p:plain
4/5時点で2500弱のPV数なので今月も1万PVは達成出来そう。ただ、これだけだと飽きられる可能性大なので宣伝の傍他のことを考えていきます。

振り返ってみると全然うまくいかないし、エンジニアあるあるのTwitterで公開とかしてないので注目度もありません。ただ、地道に継続すること、ユーザー体験を意識することを持ってサービスを運営するのはやっぱり楽しいです。これから伸びるのかどんどん縮小していくのかわかりませんがあと1年以上は続けていけるようにしたいと思います。

作った当初の目標が月1万PVだったので最後に達成出来てギリセーフ。週5で働いてここまで育てた自分を褒めたい!

ユーザー車検に合格したので流れを説明する

本日、中古で買った車の2回目の車検を受けて余裕で合格したので、車検の流れとやったことを書きます。

以前に車検を受けるまでにやった整備は記事にしてますので参考にしてもらえれば(参考になるかわからんが)
tekitoumemo.hatenablog.com

車検前の整備

過去の記事に載せてますが、一応。

タイロットエンドブーツ交換

f:id:tekitoumemo:20190306215336p:plain
タイロットエンドとは、ステアリング(ハンドル)を切るときに一緒に動く骨組みと思ってもらえれば良いと思います。そのタイロットエンドとタイヤが接地する面にゴムが入っているのですが、これが破れていたりするので破れそうor破れてる場合は交換した方がよいです。こんなやつです。
www.monotaro.com

ブレーキパッド交換

f:id:tekitoumemo:20190306215924p:plain
ここは説明しなくても問題ないかと思いますが、念の為。タイヤと密着させて摩擦で回転を止めるやつですり減ってると普通に危険なので交換しました。これは車検であまり見られませんが(おそらくディスクローターが削れてなければ見ない)減ってると危険なので交換しましょう。ディスクローター変えると高いですし。
www.monotaro.com

ウォッシャー液

これはめちゃくちゃ盲点だと思いますが、ちゃんと出ることを確認させられます。200円ぐらいで買えるので買っちゃいましょう。

ユーザー車検予約

ユーザー車検は予約が必要です。以下のサイトから予約しましょう。なんと登録するとパスが平文でメールに添付されます(くれいじー)
www.yoyaku.naltec.go.jp
僕は神奈川運輸支局で車検を受けました。

当日

受付時間が1時間30分ぐらいあるので余裕を持っていきましょう。

持ち物

この記事では僕が実際に受けて必要だったものを書くので、ユーザー車検行く場合は必ず他のサイトを見ましょう。

車検証

必須。車の証明書なので必ず必要です。
f:id:tekitoumemo:20190306221024p:plain

自動車損害賠償責任保険証明書

自賠責って呼ばれるやつで車所有する場合は必ず必要なものです。納車時、前回車検時など必ず持っているものなので忘れずに持っていきましょう。これは購入するものと前回購入したもの2つ必要です。
f:id:tekitoumemo:20190306221209p:plain

自動車税納税証明書

自動車税を納めた証明書。とくになにも言われなかったから必要なかった。
f:id:tekitoumemo:20190306221448p:plain

印鑑

これもいらなかった。

持ち物としては以上で、あとは全部運輸支局で調達できます。ただし、自賠責は場所によってないかもしれないので下調べ必要です。

現地調達するもの

自動車検査票

車の検査をするチェック表。車台番号と住所書けばあとは係の人が勝手に書いてくれます。
f:id:tekitoumemo:20190306222018p:plain

自動車重量税納付書

重量税を収める用紙。印紙を買って貼り付けるだけ。
f:id:tekitoumemo:20190306222220p:plain

継続検査申請書

車検証を発行する為に必要な用紙。これも何書けば良いかわからないので全部聞いちゃって大丈夫です。
f:id:tekitoumemo:20190306222356p:plain

定期点検整備記録簿

これはかなりグレーな点なのですが、ユーザーが点検してるとの程で必須ではありません。車検証に「点検整備記録簿記載なし」って書かれるだけっちゃそれだけです。

印紙

これらを適当に書いて「これでどうすればええん?」って受付の人に聞けば、どこで印紙と自賠責を買えば良いか教えてくれます。
ちなみに僕は2年車検なので以下の値段です。

  • 自賠責:25,830円
  • 重量税:24,600円

こちらで計算できます。
naspa.jp

  • 検査手数料:1,700円

合計:52,130円
8年目のコンパクトカーの法的費用はこれぐらいだと思います(前回4万ちょいだったのに、、

ついに検査へ!

印紙を貼って受付にOKをもらったら検査に行けと言われます。初心者ですって言うと「○番に並んでください」って言われるのですが、その○番がわからないので適当に並べば良いと思います。どこに並んでも教えてくれます。
f:id:tekitoumemo:20190306223747j:plain
めっちゃ並んでる。。

ライトやらクラクションやらワイパーやらの検査が始まる

検査員に検査表一式を渡して指示された通りに車を動かすだけです。正直足回りとか適当に見てるだけです。写真取ればよかった。。

本検査

f:id:tekitoumemo:20190306224159p:plain
こんな感じのとこで検査します。ユーザー車検2回目なのですが、全然覚えてなかったので「初めてです!!」って係員に言ったらハザード付けといてって言われました。ハザード付けとくと係員が最初から最後まで親切に誘導してくれます。ここではメータ検査、ブレーキ検査、触媒検査などいろいろやりますが違法に改造していない限り余裕で通ります。強いて言うなら光軸がずれている可能性があるので事前に予備検査でチェックしてもらうのも良いでしょう。

そんなこんなで終了。

f:id:tekitoumemo:20190306224613j:plain
取れたー!!これであと2年は乗れます!

感想

車検では、走る、止まる、安全が守られていれば余裕で通ります。この観点で車を整備(業者に丸投げでよし)すれば、必ず受かることがわかりました。ぶっちゃけ想像以上に適当でぶっ壊れてるところがない限り全く問題ないので初心者でも余裕です。はじめに予約すると書いたのですが、全く確認されることもなかったのでなにも予約せずに突入しても車検受けられるっぽいです。所用時間も混んでても2時間しないぐらいなのでなんかこんなことに法的費用の2〜2.5倍の値段を取られるのはめちゃくちゃ馬鹿らしいのでできる限り自分でやった方がお得で勉強にもなるので良いと思いました。

まとめるとクッソ適当で余裕で受かる。

現場を去る理由

明日行ったら無職だいやっほい!

フリーランスになって業務委託なのですが、10ヶ月もいたので一応備忘録として残しとこうと。

行った会社

誰でも名前は知ってるどデカイ会社

やったこと

新規サービス立ち上げ。まぁそんなカッコいいもんでなくコーディング要員足りないからひたすらガリガリしてただけ。やった技術は以下

Angular 5 クッソやった、だいたいわかる
.Net Core あまりやってない。だいたいわかる
fluentd 軽くやった。あまり知らない。やれって言われたら出来んだろレベル
ansible ちょっとやった。まぁだいたい出来んだろ
knockoutjs ちょっとやった。一生やりたくない
.Net framework もうやりたくない
nginx 軽く。知らね。
要件定義チックなやつ ちょっとやった。振られるチケットの内容全く決まってないから直接顧客と相談する感じ。

期間

新規サービス立ち上げ 4ヶ月
保守 5ヶ月
休みを含めたら10ヶ月程度。

良かったところ

新規サービス立ち上げのメンバーが優秀すぎた。リーダー優秀過ぎてなんかクッソ暇だったよw。ためのやついたけどイかれてるレベルで優秀。とりあえず俺いる意味ない感じ。なんか人の金で勉強ってことことだなと。保守のメンバーは比較的若め?レベルは高い人いなかったけど、人は良かった。若い子いておじさんホッコリする。同世代のおじさんと仲良くなった。フリーになりたい子に紹介出来た。なんか送別会もやってくれたし

悪かったところ

新規サービスメンバーは言うことなし。塩対応だったけど、特に人と関わる必要ないと思ってるからクッソ楽だった。保守メンバーは開発プロセスが酷すぎ。一生おわんねーよこれって感じ。俺は愛想良い感じに見えるけど、めんどいことはさっさと終わらせたい感じなので性に合わなかった。

現場変える理由

なんかサーバーサイドで入ったつもりなんだけど、全然興味なくなってきた。去年はAngularとReactをやったからフロントの方ができる幅と面白さが違うなと。おそらく、あと一年ぐらいは残れそうな感じだったけどWindowsで開発したくないのが決定的な決め手。とにかくWindowsだとセキュリティソフトやらWindowsUpDateの原因不明なバグやらbash使えなくてdocker使ったりとかいちいちダルすぎる。さらにクッソ重いしなんかまともに開発出来ねーじゃんって感じ。そこら辺やりたくなさすぎてfluentdとansibleのような無法地帯に手を出した。そのくせC#好きな人多いから技術負債(その場しのぎのリファクタもこれ)が溜まりまくってサービスとしてなにも提供出来てないのが不毛すぎた。前職から思ってたけどサーバーサイドしかやらねーWebエンジニアはいらねーなと思って、ここに恐怖を持ってReact案件をひたすら探した。

ほんとはもうちょっと早めに離脱する予定だった

はじめ4〜5月までで延長してもらって8月末まで。ほんとはここでさらばの予定だったが、また延長の話があって半月ほど休み取りたいとかとかクソみたいなこと抜かしたらまさかのオッケー(普通に有難い)ちょうど結婚式と新婚旅行と子どもが出来てとにかく金が必要だったから延長。12末までになって確定申告があるから定時で帰れる現場がいいなぁと思って延長。確定申告終わったんでさらば!という感じ。

次のとこ

割と有名?なのかわかんないけど、AngularやらReactやらやる。支給PCがMacで良かった。結構忙しそう。なぜか単価上がった。

なぜそこまでWindows離脱にこだわるか

個人的にはWindowsでなんでも出来るし、割と好きだからこだわりない。ただ、Windows環境の案件は頭打ち感(Unityは別)があって今後技術的に伸びそうにない。基幹系の業務が多いので基本目新しいことが出来ず、スキルチェンジがクッソ難しい。自分でスキルチェンジ出来てて基本業務経験ないとお払い箱っす。個人的にlinux環境で開発してるのに業務経験でさよならされんのはムカつくから意地でも離脱してやろうと思った。ただ、単価を下げてまでスキルチェンジしたくないので、フロントエンド推しで、自然とサーバーサイド変える作戦に。何だかんだ3回面談して1回だけしか落ちなかったよ。

フリーランスは安定を求める意味なし

業務委託やってるレベルなんで安定を求めてるんだけど、この現場を去ったら仕事なくなるとか考える必要ないなと。むしろ一年なんかいたくねーからさっさと変えるレベルが安定。今の時代は景気が良いから残る方が勿体ない

まぁ、結構良かったよこの案件。

C#史上最強なORマッパーを使ってみた

C#のORマッパーはEntity Framework(以下EF)をはじめ、Dapper、PetaPoco等が有名ですが、とにかくどれも微妙な完成度でRailsのActiveRecodeみたいなものがありません(Entity Frameworkがそれですが、とにかく遅い)。Dapperほどの速度が出てビルダーマッピングをしてくれるライブラリがないのかなと思って探したらありました。

sqlkata.com

見る限りだとビルダーを備えててDapper依存しているから確実に早いだろうと予測。Joinも含まれてるのでマッピングしてくれれば、おそらくC#史上最強なORマッパー。ってかなんて読むのこれ?えすきゅーえるかた?

使ってみます。

まずNugetから

SqlKataとSqlKata.Executionを落とします。現在(2/15時点)は1.1.6が最新です。

dotnet add package SqlKata --version 1.1.6
dotnet add package SqlKata.Execution --version 1.1.6

今回はSQLServerを使うのでSqlClientも取ってきます。

dotnet add package System.Data.SqlClient

SqlKataを使う準備

using SqlKata;
using SqlKata.Compilers;
using SqlKata.Execution;
using System.Data.SqlClient;

var connection = new SqlConnection("");
var compiler = new SqlServerCompiler();
var db = new QueryFactory(connection, compiler);

compilerはビルダーからSQLを生成するオブジェクトでdbを使ってビルダーを使います。

ビルダーを使う

まずはSELECT
db.Query("Posts").Select("Id", "Title", "CreatedAt as Date");

これが以下になります。

SELECT [Id], [Title], [CreatedAt] AS [Date] FROM [Posts]

次はJOIN

db.Query("Posts").Join("Authors", "Authors.Id", "Posts.AuthorId");

これが以下になります。

SELECT * FROM [Posts] INNER JOIN [Authors] ON [Authors].[Id] = [Posts].[AuthorId]

ここら辺はドキュメントが豊富なので以下を参考にしてください。
sqlkata.com

データを取得する

なんどデータ取得も出来ます。Dapperにフル依存してるので。

取得にはGetを使います。

db.Query("Posts").Select("Id", "Title", "CreatedAt as Date");.Get()

これだと戻りがdynamicなのでジェネリックで指定します。

db.Query("Posts").Select("Id", "Title", "CreatedAt as Date");.Get<Posts>()

これでPostクラスの型でマッピングされます。

Joinしたデータを取得する

ビルダー備えてマッピングまでやるならJoinでいけるのか!?という疑問があったので試してみました。
クラスを用意します。

public class Hoge {
    public int Id { get; set; }
    public int PiyoId { get; set; }
    public Piyo Piyo { get; set; }
}

public class Piyo {
    public int Id { get; set; }
}

ビルダー

var query = db.Query(nameof(Hoge))
     .Join(nameof(Piyo), "Hoge.PiyoId", "Piyo.Id")
     .OrderBy("Hoge.Id").Get<Hoge>();

queryをみましたがPiyoは入ってませんでした。やっぱりC#ではまだ無理そうです。EFかDapperで頑張りましょう。

SQLを生成する

ビルダーとしてはかなり優秀なのでSQLを生成してみます。ちなみに以下ではSQLを生成出来ません。

db.Query("Posts").Select("Id", "Title", "CreatedAt as Date")

ビルダーからSQLコンパイルします。

var compiler = new SqlServerCompiler();
var query = db.Query("Posts").Select("Id", "Title", "CreatedAt as Date")
var sql = compiler.Compile(query).Sql;

これでビルダーで作ったSQLが取得出来ました。

使ってみた結果として、ビルダーとしては優秀ですがマッピングはDapperと一緒なので結局は微妙なとこです。C#インピーダンスマッチは幻想なので無理に自作ライブラリなど作らずSQLゴリゴリ書いた方が効率が良いです。マッピングまでしてくれたら自分が作ったDapperの拡張ライブラリとさよならかと思ってましたがしばらくは付き合っていくはめになりそうです。
github.com
コネクションやDapperが依存しているとはいえ、ビルダーは依存させなくても使えるようです。

var db = new QueryFactory(); // なにも指定しなくておけ
var query = db.Query(nameof(Hoge))
    .Join(nameof(Piyo), "Hoge.PiyoId", "Piyo.Id")
    .OrderBy("Hoge.Id");
var sql = compiler.Compile(query).Sql;
// sql -> SELECT [Id], [Title], [CreatedAt] AS [Date] FROM [Posts]

どうしてもSQLを書きたくない人はこんな感じで使ってみても良いかも。構文ミスとかなくなるのでそこらへんは便利かも。
今後はマルチマッピングもIssueに上がってるのでキープしといても良いかも
github.com

ASP.NET Identityの外部ログインで任意の値をClaimに追加する

https://josealvarez.gallerycdn.vsassets.io/extensions/josealvarez/measpnetidentity/1.0/1482143264518/210260/1/screenshot.png

ASP.NET Identityを使っていて、ログイン後に任意の値を入れたいと思うことが多々あります。例えば、ユーザーを特定するIDやその他ユーザーに付随する情報など。ASP.NET Identityはセキュリティ上認証の際のみClaimに追加できないのでそのイベントのフックと追加方法を説明します。

外部ログインの追加は以下に書きましたので、知りたい方は以下へ。
tekitoumemo.hatenablog.com
tekitoumemo.hatenablog.com

tekitoumemo.hatenablog.com

FaceBook & Google

認証後はOnCreatingTicketへフックされ内部で処理が可能です。

.AddFacebook(facebookOptions =>
{
    facebookOptions.AppId = "";
    facebookOptions.AppSecret = "";
    facebookOptions.Fields.Add("picture");
    facebookOptions.Events = new OAuthEvents
    {
        OnCreatingTicket = context =>
        {
           context.Identity.AddClaim(new Claim("{ユーザーIDのKey}", {ユーザーIDのValue}));
           return Task.CompletedTask;
        }
    };
})

ちなみにFaceBookで画像を取得したい場合は以下のように指定します。

$"https://graph.facebook.com/{facebookのID}/picture"

Twitter

Twitterは特殊でTwitterEventsというものを扱います。ですが基本的にはOAuthEventsと同じです。

.AddTwitter(twitterOptions =>
{
    twitterOptions.ConsumerKey = "";
    twitterOptions.ConsumerSecret = "";
    twitterOptions.Events = new TwitterEvents()
    {
        OnCreatingTicket = async context =>
        {
            Identity.AddClaim(new Claim("{ユーザーIDのKey}", {ユーザーIDのValue}));
            await Task.CompletedTask;
        }
    };
})

SNSのIDを使いまわしても良いのですが、結構めんどい部分が出てくるので任意の値を入れられるのは良いと思いました。あと意外にこの手の記事がなかったよ.NET 普及しろ

Spotifyの.Netライブラリが凄く良かったよ

http://www.scdn.co/i/_global/open-graph-default.png

SpotifyApiをみんなの洋楽ランキングで使いたかったのでラッパーライブラリを途中まで作ってました。
github.com
が、相当完成度の高いライブラリがありましたので自前で実装するのをやめてSpotifyAPI-NETと言うものを使いました。
github.com

Client IDとClient Secretを取得

以下を参考にしてください。
dev.classmethod.jp

Spotifyインスタンスを生成

おそらくHttpClientを使ってるからstaticなのだろう

private static SpotifyWebAPI _spotify;

認証

超楽

var auth = new CredentialsAuth(clientId, clientSecret);
var token = await auth.GetToken();
_spotify = new SpotifyWebAPI() { TokenType = token.TokenType, AccessToken = token.AccessToken };

検索

_spotify.SearchItems("ariana grande", SearchType.Artist);
_spotify.SearchItemsAsync("ariana grande", SearchType.Artist);

アーティスト検索

_spotify.GetArtist(id);
_spotify.GetArtistAsync(id);

スタートガイド

ざっと始めるにはここ見れば一瞬でわかります。ドキュメントも豊富で超便利!
SpotifyAPI-NET/gettingstarted.md at master · JohnnyCrazy/SpotifyAPI-NET · GitHub

APIのwrapperライブラリのメリット

この手のライブラリのメリットはC#だとモデルクラス作る手間がなかったり、API側のバージョンをライブラリに任せられるのが良いですね。ググってライブラリが見つかってStart50以上あったらだいたい使っても大丈夫っす。これは500以上あるのでかなりよいかも。CoreTweetでも200前後だし。あとこれも日本語情報ないよなぜに!?

vscodeのCode Helperが100%になる問題を解決した

https://blog.launchdarkly.com/wp-content/uploads/2018/10/visualstudio_code-card.png

僕はvscodeで開発してるのですが、最近デバッグすると激重になってデバッガをほとんど使っていませんでした。Reactベースの開発がほとんどでChrome DevToolでサーバーサイドは対してデバッグする必要ないので気にしてなかったんです。ただ、最近構造を大幅に変更することもあってとてもじゃないけど開発出来るレベルじゃなかったので解決方法を気合いで探しました。解決できたのでやったことをいくつか書きます。

files.wathcherExclude

ファイルの監視対象から外すやり方。「vscode 重い mac」とかで調べると必ず出てくる方法。node_moduleとか対象に入ってると激重になるのですが、監視対象を外しても意味なかったです。
qiita.com

プラグインをひたすら外す

TSLintやらAzure系のプラグインやらひたすら外しました。これも全く関係なかった。

リクエスト系のミドルウェアの見直し

これは.Net Core限定っす。app.UseやHeadersでキャッシュさせない設定が入っていたので全部外す。Httpsも外す。全く意味なし。

package.jsonの見直し

これはフロントエンド使っている人限定。まず使ってないやつを削除。効果なし。次に「hot」って書いてあるプラグインを疑う。だいたいリロードしなくてもJSを更新したりTypeScriptを更新したりするもの。超絶怪しいのでまずはバージョンをあげて様子見。効果なし。僕の場合はCtrl+Sで全ファイル保存のショートカットを入れていたのでTypescriptを保存しないように変更。サーバーサイドのファイル更新でも激重。意味なし。

もう諦める

「....」
https://2.bp.blogspot.com/--X2z5ldMf2A/WEOPX4Y31HI/AAAAAAABALg/pc0SbFkluPo4ImDnJxxQgGT2mq-96C9IACLcB/s400/neet_man2.png

Mac OS「Mojave」でNVIDIAのドライバが動かないという記事を見つける

NVIDIAのドライバのせいでElectron系(ATOMとか)のソフトが軒並み重くなったらしい。Macbook airなので関係ないがhigh sierraに下げようか検討する。流石にだるくてやめる

やっぱwebpackが怪しいよ

やはり保存する度に重くなる。絶対これだ。vscodeデバッグコンソールを眺めながらエディタを動かしまくる。

「....」

「これだ!!!」

f:id:tekitoumemo:20190207224858p:plain

__webpack_hmrってのが404になってるじゃないですか!!調べてみるとHMR(Hot Module Reloading)の更新通知に用いられるもの。絶対これと思ったが適当なReactプロダクト作って試しても重くない。。

「あ、これだ」

tekitoumemo.hatenablog.com
以前作ったエラーハンドリングが引っかかって毎回Viewを表示してる。絶対これ。Startup.csを変える

app.UseStatusCodePagesWithReExecute("/xxxxxxxx");

すげー適当だけどこれでルーティングに引っかからないから大丈夫なはず!

結果

元通りになりました。