HttpClient と using
C# の REST クライアントといえば HttpClient
。コイツは IDisposable
の実装なので、例えばこんな感じで using
したくなる。
public class MyClient { public async Task<string> Get(string url) { using(var client = new HttpClient()) { var response = await client.GetAsync(url); switch(response.StatusCode) { // ステータスで処理分けたり } return await response.Content.ReadAsStringAsync(); } } }
しかし…… HttpClient
は Dispose
されてもコネクションが残ってしまうようだ。そしたら using
はバッドプラクティスだ。
http://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/
スレッドセーフらしいので、こんな実装で回避できる。
public class MyClient { private static readonly HttpClient _client = new HttpClient(); public async Task<string> Get(string url) { var response = await _client.GetAsync(url); // 中略 return await response.Content.ReadAsStringAsync(); } }
もう一歩進むと、どうやらコネクションプールの管理は HttpClientHandler
がやってるらしい。コイツを static readonly
にして、HttpClient
のコンストラクタに渡せば、堂々と using
できる。第2引数は、HttpClient
が Dispose
されたときに HttpClientHandler
も一緒に Dispose
するかどうか。使いまわすなら false
。
public class MyClient { private static readonly HttpClientHandler _handler = new HttpClientHandler(); public async Task<string> Get(string url) { using(var client = new HttpClient(_handler, false) { var response = await client.GetAsync(url); // 中略 return await response.Content.ReadAsStringAsync(); } } }
非同期周りもハマりやすい HttpClient
、なかなか曲者だ。
MemoryCache でアプリケーション内キャッシュ
System.Runtime.Caching.Cache を使うと、アプリケーション単位にデータをキャッシュさせることができる。
Web サーバー起動時にデータを読み込んで永続化させたい時などに便利だ。
string GetContent() { var cache = MemoryCache.Default; var content = cache["content"] as string; if(content != null) { return content; } // キャッシュされてなかったら元データを取得してキャッシュする var policy = new CacheItemPolicy { absoluteExpiration = DateTimeOffset.Now.AddSeconds(100); }; return cache.AddOrGetExisting("content", ReadContent(), policy); } string ReadContent() { // DB とかファイルから読み込んで返す ... }
CacheItemPolicy
キャッシュ エントリーの有効期限などを保持する。
特に指定しない場合はキャッシュは削除されない。
削除された、または更新されたときのデリゲートを指定することもできる。
AddOrGetExisting
上記の例では content というキーでキャッシュを保存している。
このメソッドは、このキーで値を書き込みにいくが、すでに書き込まれていたらその値をそのままとってくる、というものだ。
Atomicity を担保するためのメソッド。マルチスレッドじゃなかったら Set でよい。
ConcurrentDictionary の GetOrAdd みたいなもんかと思ったがちょっと違った。
SI から Web に転職して半年が経った
ので、「よくある SI への不満」に対して、現状がどうなっているかを考える。 私は、 SI が嫌で嫌で辞めた……というクチではないので、そういう人たちの為になるかどうかは自信がない。
最新の技術、開発環境が利用できない
- 最新の技術ガンガン使っていこう!という会社じゃない。
- 私は、技術については新しいものに興味がないので不満はない。入社前からそのつもりだったので、ギャップもない。
- 開発環境については、 GitHub とか Slack とか、いわゆるモダンな環境で開発できてる。
- とはいえ、ツールの運用どうするん?とかの話はある。そのうえで、課題が挙がる度に改善できてるので、良い環境だと思う。
- 技術的負債との戦いは避けられない。
コード書けない
- 書いてる。
- コードレビューしあえる環境はマジで素晴らしい。
エクセルがクソ
- クソだけどたまに使う。
- テストケース作ったりするときはやっぱり便利。
- エクセルで設計書作ったり、はさすがにしない。
- ドキュメントはもっと残してもいいと思う。
ウォーターフォール(のような何か)がクソ / 客の言いなりになっちゃう
- 企画をするチームが開発チームと別にあるので、ウォーターフロー的ではある。
- 最近スクラムに移行してきた。
- 企画チームに意見をぶつけることはできるので言いなりとまではいかない。
- やってるサービスの性質から、エンジニアがユーザ視点をもちづらいので、企画は専門のチームに任せることで妥当な気がしている。
- 「納期は絶対!」って感じはない
- 間に合わなくなっても後からコントロールできる。
- とはいえプライドの高いエンジニアが多いので、メチャメチャ残業してる人もいる。
ユーザとの距離が遠くてやりがいがない
- B to B のサービスなので直で意見を聞ける機会はそんな多くない。
- 営業とかの人の話を聞いて補完してる。
- 営業の人たちのアツさはなかなか SI では味わえないんじゃないだろうか。
いわゆる「木こりのジレンマ」
- 社内勉強会とかもそこそこやってる
- 社外勉強会に行く人もそこそこいる
- 技術書読んでる人もそこそこいる
- けど思ってたより少ない。前職よりは多い。
エンジニアとコミュニケーション
前職で学生と面談するとき、次の質問が非常に多かった。
「エンジニア(SE)にはコミュニケーション能力が求められると言われるが、何故か?」
答えやすい回答としては「プロジェクトはチームで進めるものだから」がある。私も就職活動中にいろんなエンジニア(や人事の方)に上記の質問をしたところ、このように回答いただいたことが多かった。
だが、この回答は本質ではない気がしている。
もちろん、チームで物事を成すために、それぞれの人間性を掴む、空気を読む、気を遣う、という能力も円滑なプロジェクト推進の助けにはなる。しかし、私が質問した皆様も、それ以上に開発特有の何かを感じているはずだ。
開発は、具体化だ。曖昧な要件から、具体の塊であるシステムを生み出す。その架け橋となるのが人間同士のコミュニケーションだ。すなわち、コミュニケーションは曖昧性を取り除いていく役割を担っているわけだ。ここで必要となる能力は、「他者との関わりの中で曖昧性を明らかにする、その曖昧性を取り除く手段を考案し共有する」能力、等となろう。前述の「空気を読む」といった能力とはむしろ真逆だ。「空気を読む」とは、曖昧性をあえて残したうえで他者と共感することだからだ(これらの能力を使い分ける必要があるのも難しいところかもしれない)。
つまり、冒頭の問いに対する答えとして、私は「曖昧性のないコミュニケーションが求められるから」と言いたい。
CodeIQ感謝祭 春のエンジニアまつり
【Jason Danielson氏登壇決定!】第3回CodeIQ感謝祭「春のエンジニアまつり」 #codeiq39 : ATND
行ってきた。
講演者も懇親会も豪華。この規模のイベントを来場者無料でできるのがスゴイ。 どうやってスポンサーに営業かけてるんだろうな。 求人でマッチングしやすいのはあるだろうけど。
以下、Markdown を垂れ流します。 パネルディスカッションは話に熱中してメモとってなかった。。 日本dis感が強すぎた感はあった。
及川さん 情報共有から始めるチーム開発とキャリア戦略
情報共有の歴史
- 情報+人間がどう思っているか=知識、知恵
- 共有フォルダーだけでは知識を共有できなかった
- SECIモデル 形式化と共有
- 業務効率化→知識共有と協調作業
- CSCW グループウェア
- メディア的な共有 図面とかリアルタイム
- 電子メールでのワークフロー、これに合わせて人間が動きましょう
- そしてLotus Notesへ
- 今も研究はされてるよ 学会もやってるよ
情報共有と組織
- ツール使ってるけど情報共有すすんでるの?
- 情報漏えいへの不安
- メリットへの疑問
- システム、ルール、文化から決まる
- システム、ルールだけで縛ると破られる
- 画面を写真とったり
- システム、ルールだけで縛ると破られる
- 文化をどうするか
- Google: Share everything you can
- 社内での履歴書を書いてく
- コード
- 週報
- Slack
- ツールは人が好きな様に使われる
- そしてリモートワーク
- 通路での立ち話、Slackに書くのも面倒だよね
- メンタルモデル、メインオフィスがあってそこに個人がぶらさがるのでなく、全部がそれぞれにぶら下がるようになってないといけない
キャリア
- 中から外へ!
- 社内だけじゃなくて社外
- アウトプットから考える(持ってるものをアウトプット、ではなく)
澤さん プレゼンの話
- プレゼンは三層構造
- ビジョン: Why なんのため?
- 核: What なにをつたえる?
- 話術: How どうやって?
- 人に何か伝えるのはすべてプレゼンだよ
- ビジョンとスコープ
- ビジョン:理想の形、変更不可 決めるまで時間かけよう、チームだったら共有しよう
- プレゼンが終わったら、聴衆にどうなっていてほしい?
- 行動してもらわないと意味が無いよね → 未来が描かれてないといけない
- 報告と連絡は過去、相談は未来。相談(時間と空間を共有)もっとしっかりやろうよ。
- スコープ:各タスク、変更可能
- ビジョン:理想の形、変更不可 決めるまで時間かけよう、チームだったら共有しよう
- 核:聴衆が他の人に説明するときに1文で説明できるもの
- 言語化のプロセス
- 他の人に教えたくなるか?
- 伝言ゲームで内容が変わらないものこそ強い
- シンプルに!
- 数字は強調しよう
- 詳細は別の資料にしよう(読ませる!)
- アクションを言語化
- 誰が何をいつまでに
- 当事者意識。
- スライドテク
- 1枚にテーマ1つ、説明3つ
- アニメーションは視点誘導のためだけに使う
- 画面は意外と広い
- 書き過ぎない
- 文字を際立たせる(色で囲ったり)
- キーワードで画像検索するとイメージ広まるよ
- Photo AC
- 「最後に」スライド
- 印象付け、時間調整、途中参加の人も安心
- 話術
- 口癖を意識しよう
- 「簡単に」だけだったら同じ言葉だけだと薄くなる
- 腹筋を意識
- そうしないと姿勢が崩れる
- 均等に顔を見よう(じゃないと目が泳いでるように見える)
- アイスブレイク
- ちょっとずれた表現を使う
- おおげさにいう
- 部分的話しことば
- ユーザーの話ならそのユーザーの話し言葉で
- スライド飛ばすときは1ページずつ送ると余裕がなく見える
- ちょっとずれた表現を使う
- 話す速度よりゆっくり歩く(慌ただしさがなくなる)
- 聴衆は見方だよ!
Jason Danielson
- やりたいことやれよ
- なんかやるんだったらなんでやるのか考えろよ
2015年に読んだ本から再読したいものを5冊挙げる
40冊ちょいから5冊選んだ。観点は「再読したい」なので、「面白かった」「勉強になった」とは少しずれる。
熊とワルツを - リスクを愉しむプロジェクト管理
リスク管理。なんでリスク管理やらないといけないの?という話から、方法論の導入まで。結果的にうまくいったプロジェクトは正しくない!「やればできる」はクソ!意識づけが大事。次はもっと実践的な本にも手を着けたい。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
言わずもがな。トイレとかに置いてパラパラめくりたい。
CODE COMPLETE 第2版 下 完全なプログラミングを目指して
上巻よりエモい!パフォーマンスチューニングやデバッグの話からマネジメントの話まで。Amazonレビューをみると「上巻とは切り離せない」とかあるがそんなことはなく、別物としてもよいだろう。あとやっぱり内容が古いし定価が高いんで、盲目的に「プログラマは全員読むべき」ってのは正しくないように思う。
仕事は楽しいかね?
目標をもつのが必ずしも正しいわけじゃない。ぼんやりとした考えをより強固にしてくれた本。迷ったら読む。
小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則
自己啓発に最適。なんなら1ページごとはがして部屋/職場のいろんなとこに張っとくのがいいんじゃないか。
今年読んだ本はエモい側に寄りすぎた感がある。。堅い本も買ったけど半分くらいで挫折したものも多い。細く長くでいくか、時間とって読み上げるか……
「道は開ける」読んだ
「不安と闘う術を知らないビジネスマンは若くして死ぬことになる。」アレクシス・カレル
不安といかに立ち向かうか。簡単に書くと以下の内容である。
- 最悪の事態を想定する
- ほとんどの場合それよりマシだろう
- 紙に書きだしてみる
- 後で読み返したら大した悩みでは無くなっている
- 宗教の力を信じる
- (現代日本で暮らしているとちょっと……)
- 不安をプラスに転じることは出来ないか考える
- 短所を長所に変える
- ひたすら働く
- 忙しくしてたら不安なんて忘れる
- (これはどうかと思う)
- 無駄なことに悩まない
- 悩んでもどうしようもないことは多い
文章にするとなんてことないが、膨大な実体験とともに述べられると圧倒的な説得力をもつ。