開発体制を振り返る(1社目 中小SIer)
今社会人になって4社目(フリーランスだから結構転々としてる)ですが、いろんな開発体制の会社※を見てきたので開発体制を振り返ろうと思います。
これ見てエンジニア目指す人はどの業種がいいか見分けられると嬉しいな😃
※現場数を書くとキリがないので印象に残ったやつだけ
案件
官公庁の給与システム
エンジニア数
8人〜12人ぐらいだっけな?
技術
こぼる
関連人物プライオリティ
顧客 >= 開発
プライオリティ理由
基本顧客次第だが、ちょこっと直すのにエゲつい金額がかかるので、開発もコントロール出来る
見積もり手法
プログラムステップ法
開発モデル
開発モデル詳細
人事院勧告によって仕様が変わる。
↓
どこがどう変わったか顧客が把握してるので教えてもらって見積り(ステップ法)
↓
顧客が予算と照らし合わせて再見積り
↓
基本設計書、詳細設計書作成
↓
基本設計書、顧客レビュー(大量の印刷物とともに)
↓
詳細設計をもとに開発
↓
コードレビュー(印刷したものをマーカーで引く)
↓
Done(繰り返し)
↓
単体テスト
↓
システムテスト仕様書作成
↓
システムテスト仕様書顧客レビュー(大量の印刷物とともに)
↓
システムテスト(もちろんエビデンスもね)
↓
システムテスト顧客レビュー(大量の印刷物とともに)
↓
Done
↓
リリース日設定
↓
顧客、開発スケジュール調整
↓
Done
稼働
月50〜80時間残業(稼働が一番高いとき、普段は月10)
成果物
プログラム
ドキュメント
エビデンス
テスト結果
最終報告
得た知見
社会保険の知識(標準報酬げつがく!)
こぼる
やりがい
技術を求めたい人は最悪。業務知識を求めたい人はそこそこ。
考察
人事院勧告によって要件定義がほぼないので確実でより正確なのは◎。仕様を把握して顧客と認識合わせ出来るなら即戦力。こぼるなので、詳細設計とほぼ同じコード、さらに依存するコードとかほぼ皆無なので問題が起きにくい。ただし、コード量は多い(ここら辺はステップ法と関連するところなのでビジネス的にこの設計になっている)。COBOL、JCLといったどこでも使えなさそうな技術をやり続けるのが辛い。なので汎用性のある業務知識に全振りする人多数(9.9割それ)稼働は高いが、SIerは残業手当が多いので、そこまで辛そうにしてる人は少ない(残業100時間以下の話)プロジェクトは必ず終わるので達成感があり、チーム仲も良い。
個人サービス公開して一年経ったので振り返る
このブログに何度も登場してるサービスですが、2018年の4/1に公開してから一年経ったので振り返ります。
結論から言うと、
全然上手くいってません!赤字です!
2018/4 公開!
当時はとにかく3月中にリリースする!という目標を持ってやってた。ほぼ3/31の夜にリリースし、ギリギリ間に合う。ただ、当時のデザイン、機能は最低ライン(今だったら絶対公にしないレベルで恥ずかしい)のレベルでドメインもAzureドメインのまま。さらにWindowsでしか開発出来ない.NetFrameworkで作ってしまった。当時の記事に失敗したことを書いていました。
2018/5 .NET Coreへ全てリプレイス
当時、Macminiのbootcampで開発してたのですがクッソ重くてさらにVS重くてそれだけで仕事後に開発するのが億劫になってました。そのときにちょうどMacBookを購入したのでリプレイス開始。サイト自体は管理画面で更新出来るので、運用しつつ裏ではリプレイス作業を行なってるという感じでした。リプレイス作業は4月中に終わらせる予定でしたが、データアクセスをEntity frameworkからDapperに移行したので、そこが思いのほか大変で5月半ばまで掛かりました。データアクセスはオレオレDapper拡張ライブラリを作ったりして、全て違う作りでリプレイスしました。多少のバグはあったのですが、管理画面に関するところだったのであまり影響はありませんでした。リプレイスは実際公開するまでの時間と労力の割にサービスが良くならないのでモチベが大変ですが、開発して得た知見をブログにすることでモチベを保てたのはよかったと思ってます。これとか👇
tekitoumemo.hatenablog.com
2018/6 SEOが爆上がりして1万PV達成
Googleハネムーンってやつですね。とりあえずモチベMAXなので記事増やしまくったりデザインを大幅に変えたり色々やりました。この頃に初めてReact導入して、いいね!など作りました。ユーザー数も6000と恐ろしいレベルで増えまくって希望に溢れまくってました。ただ、この頃はページ滞在率と離脱直帰率を全く意識してなかったのです。ここがサービスの作り手の分かれ道だと今は実感しています。。
2018/7 相変わらず好調で2万PV達成
相変わらず調子がよかったのです。この頃はユーザービリティを全く考えず、アドセンス導入やデザイン修正など小賢しい改善ばかり行なっていました。完全に調子に乗っていて、もともと考えていた「ユーザー操作が複雑な改善は極力しない」がバッチリはまったと自画自賛してました(心の中で)。はじめに書いた記事はちゃんと反省点を書いていたのですが、このときは全く反省は書かずに調子に乗った事ばかりかいてました。
tekitoumemo.hatenablog.com
7月末から激減するとは知らずに。。
2018/8 SEO爆下がりでPV激減
とにかく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。地味な機能ですが、このサイトになくてはならないものです。
次にキーワード検索。キーダウン毎にAPIを呼び出すと負荷がかかる可能性があるので入力が完了してからリクエストを投げる仕様にしました。人間のキー入力が完了するには0.3秒みたい。さらに部分一致検索なのですが、検索したキーワードが昇順で検索できるように以下のようにSQLを書きました。
where M.name like '%a%' order by (case when name like 'a%' then 0 else 1 end), name asc
こんな感じにソートされます。
さらにパフォーマンスは意識していて30ms程度の速度が出ています。この頃からサービスの傲りがなくなりちゃんとサービスを育てていこうと思いました。
2019/01 会員登録機能
始めと言ってることが180度変わりました。というのも地道に記事を追加して、見た目を変えていくだけだとサービスとして何も「面白くない!」と感じていました。Twitterを見てると洋楽を紹介する人がたくさんいてそもそも紹介するのは自分じゃなくても良いのではないかと考えるようになり、アンケートを取ってみました。
みんなの洋楽ランキングからお願いです!
— みんなの洋楽ランキング (@mygkrnk) December 19, 2018
現在、記事の投稿が追いついていない状況です。皆さんがどのようなお気持ちか知りたいので、アンケートのご協力お願いします!
記事を投稿して頂いた方にはTwitterのアカウントを載せたいと思っています!アカウントの拡散にも一役立てればと思っています!
びっくりしたのが、記事を書きたくないって人が一人もいなかったことです。このまま勢いで開発でもよかったのですが、作っても使ってもらえなければただのゴミなのでユーザーにどのような形で対価を与えられるか結構考えました。ただ、タラタラ考えてもしょうがないのでリンクを貼らずに会員登録機能を作り、管理画面にアクセスする為のロールやどのような情報が取れてどのように表示できればユーザーが喜ぶか作りながら検討した1ヶ月でした。敷居の高い会員登録を簡単にする為にTwitter、Facebookに絞ったり、記事投稿をTwitterの画面に寄せて簡単に誰でも書きやすいように作りました。
ちなみにGoogle認証は、画像が取得出来ないのでやめました。そのとき書いた記事です。
tekitoumemo.hatenablog.com
2019/02 会員登録+投稿機能を正式リリース
正式に公開して誰でも使えるようにしました。当然、宣伝しなければ使い方もわかりませんし会員登録するわけもないので1ヶ月ぐらい自分で投稿してみたり、会員登録したときのユーザー体験を感じマイページやユーザー紹介ページを作ったりしてました。ドッグフーディングはめちゃくちゃおすすめでとことんいろんな改善点が出てきます、しかも有力な。そこそこユーザーに使ってもらえる段階まで持ってこれたかなと。
2019/03 投稿機能を気合いで宣伝
3月半ばぐらいにユーザーに使ってもらえる段階になったのでモニターとして数人にDM。数人に記事を書いてもらえて特に使い方がわからないとの声もなかったのでひたすらフォロワーにDM。結果として11人、100記事近く書いてもらえるようになりました。まだまだ全然少ないですが、解説という敷居が高すぎる機能にこれだけの人が使ってくれたのはよかったかなと。さらに数ヶ月ぶりの1万PV達成。。SEOは相変わらずボロボロだけ運関係なく1万PV達成出来てよかった。
さらにさらにアドセンスの受け取り報酬に達したので当初から協力してくれた友人に報酬を支払うことが出来ました。
2019/04 引き続き投稿機能を宣伝
4/5時点で2500弱のPV数なので今月も1万PVは達成出来そう。ただ、これだけだと飽きられる可能性大なので宣伝の傍他のことを考えていきます。
振り返ってみると全然うまくいかないし、エンジニアあるあるのTwitterで公開とかしてないので注目度もありません。ただ、地道に継続すること、ユーザー体験を意識することを持ってサービスを運営するのはやっぱり楽しいです。これから伸びるのかどんどん縮小していくのかわかりませんがあと1年以上は続けていけるようにしたいと思います。
作った当初の目標が月1万PVだったので最後に達成出来てギリセーフ。週5で働いてここまで育てた自分を褒めたい!
ユーザー車検に合格したので流れを説明する
本日、中古で買った車の2回目の車検を受けて余裕で合格したので、車検の流れとやったことを書きます。
以前に車検を受けるまでにやった整備は記事にしてますので参考にしてもらえれば(参考になるかわからんが)
tekitoumemo.hatenablog.com
車検前の整備
過去の記事に載せてますが、一応。
タイロットエンドブーツ交換
タイロットエンドとは、ステアリング(ハンドル)を切るときに一緒に動く骨組みと思ってもらえれば良いと思います。そのタイロットエンドとタイヤが接地する面にゴムが入っているのですが、これが破れていたりするので破れそうor破れてる場合は交換した方がよいです。こんなやつです。
www.monotaro.com
ブレーキパッド交換
ここは説明しなくても問題ないかと思いますが、念の為。タイヤと密着させて摩擦で回転を止めるやつですり減ってると普通に危険なので交換しました。これは車検であまり見られませんが(おそらくディスクローターが削れてなければ見ない)減ってると危険なので交換しましょう。ディスクローター変えると高いですし。
www.monotaro.com
ウォッシャー液
これはめちゃくちゃ盲点だと思いますが、ちゃんと出ることを確認させられます。200円ぐらいで買えるので買っちゃいましょう。
ユーザー車検予約
ユーザー車検は予約が必要です。以下のサイトから予約しましょう。なんと登録するとパスが平文でメールに添付されます(くれいじー)
www.yoyaku.naltec.go.jp
僕は神奈川運輸支局で車検を受けました。
当日
受付時間が1時間30分ぐらいあるので余裕を持っていきましょう。
持ち物
この記事では僕が実際に受けて必要だったものを書くので、ユーザー車検行く場合は必ず他のサイトを見ましょう。
車検証
必須。車の証明書なので必ず必要です。
自動車損害賠償責任保険証明書
自賠責って呼ばれるやつで車所有する場合は必ず必要なものです。納車時、前回車検時など必ず持っているものなので忘れずに持っていきましょう。これは購入するものと前回購入したもの2つ必要です。
現地調達するもの
自動車検査票
車の検査をするチェック表。車台番号と住所書けばあとは係の人が勝手に書いてくれます。
自動車重量税納付書
重量税を収める用紙。印紙を買って貼り付けるだけ。
継続検査申請書
車検証を発行する為に必要な用紙。これも何書けば良いかわからないので全部聞いちゃって大丈夫です。
定期点検整備記録簿
これはかなりグレーな点なのですが、ユーザーが点検してるとの程で必須ではありません。車検証に「点検整備記録簿記載なし」って書かれるだけっちゃそれだけです。
ついに検査へ!
印紙を貼って受付にOKをもらったら検査に行けと言われます。初心者ですって言うと「○番に並んでください」って言われるのですが、その○番がわからないので適当に並べば良いと思います。どこに並んでも教えてくれます。
めっちゃ並んでる。。
ライトやらクラクションやらワイパーやらの検査が始まる
検査員に検査表一式を渡して指示された通りに車を動かすだけです。正直足回りとか適当に見てるだけです。写真取ればよかった。。
本検査
こんな感じのとこで検査します。ユーザー車検2回目なのですが、全然覚えてなかったので「初めてです!!」って係員に言ったらハザード付けといてって言われました。ハザード付けとくと係員が最初から最後まで親切に誘導してくれます。ここではメータ検査、ブレーキ検査、触媒検査などいろいろやりますが違法に改造していない限り余裕で通ります。強いて言うなら光軸がずれている可能性があるので事前に予備検査でチェックしてもらうのも良いでしょう。
そんなこんなで終了。
取れたー!!これであと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ほどの速度が出てビルダーマッピングをしてくれるライブラリがないのかなと思って探したらありました。
見る限りだとビルダーを備えてて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")
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に追加する
ASP.NET Identityを使っていて、ログイン後に任意の値を入れたいと思うことが多々あります。例えば、ユーザーを特定するIDやその他ユーザーに付随する情報など。ASP.NET Identityはセキュリティ上認証の際のみClaimに追加できないのでそのイベントのフックと追加方法を説明します。
外部ログインの追加は以下に書きましたので、知りたい方は以下へ。
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は特殊で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ライブラリが凄く良かったよ
SpotifyのApiをみんなの洋楽ランキングで使いたかったのでラッパーライブラリを途中まで作ってました。
github.com
が、相当完成度の高いライブラリがありましたので自前で実装するのをやめてSpotifyAPI-NETと言うものを使いました。
github.com
Client IDとClient Secretを取得
以下を参考にしてください。
dev.classmethod.jp
認証
超楽
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