ASP.NET Identity でユーザーを作成するときは必ず UserManager を使うこと

マイグレーションで Seed データを投入するとき、 ユーザーを作成するところで UserManager を使わずに、 IdentityDbContext を使って直接データベースに保存してしまっていた。

そのせいで、ログインするときに ClaimsIdentityFactory が内部でクレームを作成する箇所で ArgumentNullException が発生して嵌った。

ユーザー作成では AspNetUsers テーブルにユーザー情報を追加するだけではダメだったのか。 今まで IUserStore を実装したカスタムストアばかり使っていたから、こんなところで躓いてしまった。

ASP.NET Identity のソースコードを見てなんとか解決できたけど、半日費やしたよ…。 ASP.NET Identity を素直に使うなら、ユーザー作成はちゃんと UserManager を通さないとダメ。 ゼッタイ。

プリンター買い換えた

社会人 1 年目に購入した Canon の MP600 が壊れたので、 プリンターを買い換えることにした。 購入してから 9 年。 今までご苦労さま。

新しく買うプリンターは WiFi 対応必須。 今まで、印刷するために MacBook をわざわざプリンターの近くに持っていって USB 接続していたので、 これは絶対。 あとコピーも結構使うので、買うならやっぱり複合機。 値段は安いに越したことはない。

そんな条件で家電量販店やネットを調べて、brother の『PRIVIO DCP-J562N』を購入した。 4色インクだけど印刷した写真はキレイだったし、複合機にしてはコンパクトな方だし、 WiFi に繋がる。というか、WiFi でしか印刷できない。 USB 接続もできた方がいいか考えたけど、多分繋げることは無いだろうな。 欠点といえば、カラーの印刷がちと遅い。 ただ、印刷もコピーも白黒にすることが大半だから、まぁ許容範囲。 それに安かったし。

届いたからさっそくセットアップして試し印刷してみたけど、 リビングの椅子に座ったまま、となりの部屋にあるプリンターで印刷できるのは便利だ。 さっさと買い換えておけばよかったな。

『マイ・インターン』見た

映画『マイ・インターン』の DVD をレンタルして見てみた。 DVD を借りて映画を見るのは久しぶり。 昨年旅行先で見たアナ雪以来だ。

アン・ハサウェイ目当てだったけど、 それよりもロバート・デ・ニーロが演じるベンが格好良すぎた。 70 年の人生経験を生かし常に最適なアドバイスを伝える紳士かと思いきや、 (ちょっとネタバレだけど)社長の母親の自宅に侵入するという案を提案し実践するという ヤンチャ(?)な一面も持ち合わせていて、 こんな老人になりたいと思える人物だった。

というか、ベンが主人公だったのか。 正式タイトルは The Intern だけど、それが『マイ・インターン』という 邦題になったのはプロモーションの都合なんだろうね。

そんな大人の事情はいいとして、久しぶりに見た映画だったけど当たりだった。

Podcast を 1.5 倍速で聴いたら捗った

通勤時間と昼休みに Podcast を聴いているが、エピソードの配信ペースが上がったり、 サブチャンネルが増殖したりして、いよいよ消化が間に合わなくなってきた。 このままでは未読の一覧が緑のアイコンで埋め尽くされてしまう。

購読する Podcast を減らすなんて選択肢は無いし、 興味の無いエピソードも一応聴いておきたい。

そこで、試しに 1.5 倍速で聴いてみたら、結構聴けるもんだ。 聴き取れない単語はほとんど無い。 これくらい早口でしゃべる人いるよね、ってくらいには聴いていて違和感無い。 あまりに違和感無かったので、そのつもりがなかった Rebuild まで 1.5 倍速のまま聴いてしまった。

その結果、未読のエピソードを一気にすべて消化。 次の配信が待ち遠しい。 購読する Podcast を増やそうかな。

『Selenium 実践入門』読んだ

Selenium 大全と呼ぶにふさわしい一冊

Selenium WebDriver だけでなく、 Geb・FluentLenium・Capybara といったサポートライブラリや Selenium IDE、 さらには Appnium まで網羅している。

ページオブジェクトパターンや CI といったベストプラクティスもあり。

巻末には CSS セレクタや・XPATH・WebDriver API の早見表も載っていて、 リファレンスとしても使える。

本書のサンプルコードはほとんど Java

他の言語でも API はだいたい同じだし、 巻末の早見表もあるので無問題。

Selenium サポートライブラリに関しては、 こればっかりは使おうと思ったら言語も Groovy や JavaRuby を使うしかない。

ただ、E2E テストは何も Web サービスと同じ言語でないと書けないわけではないし。 Web サービスは C# だけど、E2E テストは Ruby というのも全然アリ。

E2E テストでテストデータ投入とクリーンアップ

Selenium 使った E2E テストでは、どうすればいいんだろうね。

単体テストなら、テストメソッド実行前にトランザクション開始してからテストデータ投入して、 テスト後にロールバックする手が使えた。

E2E テストの場合、実際の登録用 API を使うという手法がさらっと紹介されていた。 あまりオススメではないみたいだけど、テスト専用 API を作るという手もある。

Rails のときはトランザクション使わずに、 ActiveRecord でデータ投入して database-cleaner でクリーンアップしていたけど、 JavaC# でも同様の仕組みが要るのかもな。

サイボウズDeNA の事例も載っている

どちらも E2E テストの数が増えて、すべて実行するのに非常に時間がかかる問題に直面していた。 どちらも並列化で対応していたけど、サイボウズSelenium Grid、DeNA は Jenkins のマスター/スレーブと、 アプローチが異なっていて参考になる。

本書にも書いてあるけど、E2E テストは単体テストと比べて時間がかかるので、 ユーザーシナリオに重点を置いたテストをやるのが現実的。 重箱の隅は単体テストでつつくのがベターか。

Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)

Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)

AWS CLI を使って CloudWatch のメトリクスを取得するメモ

セットアップ

AWS CLIPython 版を使う。

$ sudo pip install awscli

AWSAPI キーやリージョンを設定する。

$ aws configure
AWS Access Key ID [None]: <アクセスキーを入力する>
AWS Secret Access Key [None]: <シークレットキーを入力する>
Default region name [None]: ap-northeast-1
Default output format [None]: json

取得できるメトリクスの一覧を表示

例えば

$ aws cloudwatch list-metric --namespace AWS/RDS

Amazon RDS のメトリクス一覧を取得できる。

後述するメトリクスの値を取得するときに指定が必要な dimensions が分からないときは

$ aws cloudwatch list-metric --namespace AWS/RDS --metric-name <メトリクス名>

で調べることができる。

メトリクスを取得

Amazon RDS の CPUUtilization を取得するならこんな感じ。 5 分間ごとの平均値を取得している。

$ aws cloudwatch get-metric-statistics \
    --namespace AWS/RDS \
    --dimensions Name=DBInstanceIdentifier,Value=<DBインスタンス名> \
    --metric-name CPUUtilization \
    --statistics Average \
    --start-time `date -u -d `date -u -d '5 minutes ago' +%Y-%m-%dT%%TZ` \
    --end-time `date -u +%Y-%m-%dT%%TZ` \
    --period 300

『リモートチームでうまくいく』読んだ

リモートチームとは、チームとしてのリモートワーク。 一昔前に話題になった、働く場所や会社に縛られないノマドとは違う。 リモートチームは会社に所属しながらもリモートで働く。 しかもチームで。 ソニックガーデンは社長を含め社員全員がリモート勤務可らしい。

リモートチームは会社と社員の双方でメリットがある。 社員は会社に所属しながらも働く場所や時間の自由が得られる。 会社は優秀な人材を場所にとらわれずに採用することができる。 リモートワーク可というのが転職の決め手になることもありそうだ。

ただ、全員がリモートで働けばリモートチームになるかといったら、 そんなわけはなくて。 リモートチームが上手く機能するように、ツールを導入したり、情報共有を徹底したり、 働く時間をそろえたり、といったさまざまな工夫が必要。

なにより、リモートチームを実現するためには、 セルフマネジメントが出来る人でチームを構成する必要がある。 これが一番高いハードル。 セルフマネジメントとは、本書によると 「自分の時間やリソースを自身で管理した上で、どんな仕事にどれだけのコストをかけるかを考えて、 誰かに指示・管理されることなく成果を発揮することのできるスキル」のこと。 つまり、優秀な人材だけでチームを構成しないと成立しない。

既にいろんな社員を抱えている会社がやるのは困難を極める。 急に人を増やすこともできないので、急成長したいスタートアップにも適さない。 「納品のない受託開発」という、 顧問エンジニアみたいな急成長はないけど手堅いビジネスをやっている、 ソニックガーデンだから実践できている。

そういえば、『強いチームはオフィスを捨てる』を書いた Basecamp 社も、 ベンチャーキャピタルから資金を調達せずに、自分達の売上で着実に成長していったな。 そういった手堅いビジネスをやっている少数精鋭の会社と、 リモートチームは相性がいいんだろう。 もし自分が起業するなら、リモートチームの実現させたいとは思う。