ikasama over technology

忘れたくないことを忘れないために

Web API: The Good Parts を読んだ

Web API: The Good Parts を読んだので、感想とかを書いていきます。

www.oreilly.co.jp

全体を通して

  • 200ページ程度なのでサクッと読める
  • 6年ほど Web 開発の仕事をしている自分からすると、知っている内容が7割くらいだった
    • 断片的な知識と経験を振り返るのには役立った
    • これから Web 開発を学んでいく1〜3年目くらいの若手 Web エンジニアには学びが多そうでオススメ
  • HTTP メソッド、ステータスコード、ヘッダの取り扱いについて幅広く説明している
  • 有名な各種 Web サービスの実際の API 設計を見比べながら解説してくれる
  • RFC 的にこうあるべき」といった論より、デファクト・スタンダードを重視する主張が多い
  • 2014 年に書かれた本なので、少し古いかも、と思う部分があったりした

各章で気になったポイント

1章 Web API とは何か

  • Web API の重要性について説かれているが、2023 年現在だと当たり前の内容も多く、大部分は飛ばしながら読んで良い
    • この本が書かれた 2014 年当時は、これから Web API のエコノミーが拡大していく時期だったと思う
  • LSUDs (large set of unknown developers) と SSKDs (small set of known developers) の概念は知っておくと良い

2章 エンドポイントの設計とリクエストの形式

  • エンドポイント設計については考え方がほぼ同じだった
  • HATEOAS に言及しているところは良かった
  • 一貫した設計をしようという主張も激しく同意

3章 レスポンスデータの設計

  • JSON のトップレベルで配列を返すべきか、オブジェクトを返すべきかの議論はなるほど、と思った
    • セキュリティと一貫性から、オブジェクトを返すほうが優勢っぽい

4章 HTTP の仕様を最大限利用する

  • HTTP ステータスコードの解説が充実していてよい
  • Cache-Control 周りもしっかり説明があってよい

5章 設計変更をしやすい Web API を作る

  • 互換性やバージョン管理の話
  • 個人的に新たな発見はなかったけど、知っておいて損はない内容

6章 堅牢な Web API を作る

  • セキュリティ周りの話
  • HTTPS を使うのは当たり前になってきているので、そのあたりは昔話扱いでよい
  • XSSXSRF の解説があるが、これだけで攻撃のイメージができるはちょっと疑問
  • セキュリティ関連の HTTP ヘッダは読むべき

まとめ

  • REST API を設計するなら読んでおいて損はない本
  • 特に Web 開発入門者や初級者に読んで欲しい
  • Web 開発をそこそこ経験している人にとっては、経験と知識を再確認する本として有用

GitHub の Saved replies でレビューコメントにラベルをつける

f:id:ikasamak503:20210612100539p:plain

こういう感じで GitHub のレビューコメントにラベルを付けています。

効果として、

  • レビューコメントのスタンスがレビュイーに明確に伝わる
  • 対応するべきか、そのままでもいいかレビュイーが判断しやすい

などを期待しています。 ただし、それぞれの意味や対応方針をレビュアーとレビュイーの間で合意しておく必要はあります。

簡易的には、テキストのみのラベルでも十分伝わると思います。以前はそういう運用をしていました。 しかし、画像のほうが視覚的に判別しやすいと思い、最近は画像でラベルを表現するようにしています。

しかし画像を貼り付けるのは面倒

一方で、画像やその URL をレビューコメントに毎回貼り付けるのは少々手間です。 そこで GitHub の Saved replies に定型文として登録して、入力の手間を省きます。

GitHub Saved replies

https://github.com/settings/replies からアカウントの Saved replies を設定します。

f:id:ikasamak503:20210613134813p:plain
Saved replies の設定画面

画像ラベルの作り方

画像は https://shields.io/ で生成する SVG を使います

shields.io

SVG を生成する URL のパターンは https://shields.io/ に書いてある通りで、 https://img.shields.io/badge/<LABEL>-<MESSAGE>-<COLOR> で指定します。

f:id:ikasamak503:20210613134407p:plain

たとえば、 Suggest の場合は以下の URL を使っています。色は好みのものを使いましょう。

https://img.shields.io/badge/review-suggest-success.svg

https://img.shields.io/badge/review-suggest-success.svg

あとはこれを Markdown で見れる形にして Saved replies に放り込むだけです。

![suggest](https://img.shields.io/badge/review-suggest-success.svg)

実際に Saved replies を利用して画像ラベルを挿入する様子

f:id:ikasamak503:20210613141012g:plain

おまけ

以下は、僕がレビューコメントで用いているラベルとその意味です。

must Must fix

  • 絶対直してくれというレベル
    • Request changes で投げることが多い
  • 明らかに仕様を満たしていないとか、セキュリティ的にまずい実装など
  • あるいはコードにコミットするべきでない物が混入したときなど
    • 何らかのシークレットや顧客の情報など、コードが漏洩した際に悪影響があるもの

should Should

  • 言葉通り、こうすべき、というニュアンスで使う
  • 機能仕様は満たしてるかもしれないけど、パフォーマンス上の懸念があるとき
  • フレームワークの扱い方

suggest Suggest

  • こう書いたほうがいいよ
  • 後述の In my opinion より、客観的に推奨するもの
  • たとえば、 Laravel にはこういう便利なヘルパーがあってな、とか

imo In my opinion

  • こういうふうに書いたほうがいいと思う、という意見
  • あくまでレビュアーの意見の一つでしかなく、取り入れるかはレビュイーに任せる、という扱い

nits nits

  • typo やコーディングスタイルなどの軽微なミス
  • これ直したあとでマージしてよ、くらいのノリで Approve と一緒に投げることもある

ask Ask

  • レビュイーへの質問

boyaki Boyaki

  • ぼやき、そのまんんま
  • コードスメルがありそうなところ
  • このレビューを通して修正するには問題が根深かったり、大きすぎるとき
  • いずれリファクタリングしたいねというような結論にして、 issue を切る事が多い

参考

qiita.com

Google CTF 2020 に参加した感想

f:id:ikasamak503:20200825232932p:plain
最初の問題が解けた瞬間はかなり興奮した

Google CTF 2020 に参加しました。

capturetheflag.withgoogle.com

Google CTF 2020 は日本時間で 8/22 9:00 ~ 8/24 8:59 の間、開催されました。 僕は 8/23 の夕方〜24 時ごろまでやってました。 CTF 自体は入門者ですが、会社の同僚に誘われる形で参加しました。

解いた問題

Web を 2 問解きました。 とはいえ、いずれも、最終的には CTF 経験者である同僚の力を借りてなんとか解けたという感じです。

詳しい Write-up は他の人に譲ります。 以下、ざっくりとした解説。

PASTEURIZE

  • XSS の問題
  • サーバー (Node.js/Express) とクライアント (HTML/JavaScript) のコードは提供される
  • BotXSS を踏ませるせることで、 BotCookie にある Flag を盗む
  • POST 時にサーバーサイドのコードでバリデーションをかけていない+サニタイズが弱い
  • そこにオブジェクトを突っ込むことで XSS を起こした

LOG-ME-IN

  • SQL インジェクション? の問題
  • サーバー (Node.js/Express) とクライアント (HTML/JavaScript) のコードは提供される
  • Flag を持っているユーザーで偽装ログインすることで Flag を盗む
  • ログイン時のユーザー照合 SQL はちゃんと Prepared Staatement 使ってるので、 SQL インジェクションではないと最初は思った
    • 結局これもリクエストパラメータをバリデーションしてないので、オブジェクトを突っ込むことで SQL インジェクションみたいになった
  • 他の問題用のコードが紛れていて、だいぶ惑わされた

結果

我らが Tomatosalad は 4 問解いて 163rd に落ち着きました。 600 チームくらい参加してるので、いいほうなんじゃないでしょうか?

f:id:ikasamak503:20200825234829p:plain

感想

  • CTF 初参加で問題解けてよかった
  • Web は頑張ったらもうちょいいけそう
    • Web の仕事してるしそりゃね、、、
  • 同僚に教えてもらった、BotXSS 踏ませて Cookie を抜く手順はとても参考になった
  • Write-up で解けなった問題の解説を見るのも楽しい(そしてちょっと悔しい)
  • 他の分野もいずれ挑戦してみたい

Trello で夫婦共同 ToDo List を作った

個人的には少し前から Trello で ToDo List を作っていたけど、 最近は妻 *1 にも脳のメモリをオーバーするタスクが増えてきたので、一緒に管理することにした。

f:id:ikasamak503:20200107021139p:plain
Trello ボードの様子。ボード名は 人生

ルール

運用始めて一週間も経ってないので、まだ暫定だけどこんな感じ。

1. 週に一度、その週にこなすタスクを計画する
  • weekly レーンに今週やる予定のタスクを優先度順に並べる
  • 各レーンのタスクの優先順位や来週以降のざっくりした計画を確認する
2. 完了したタスクは都度 Done レーンに移す
3. 思いついたタスクはいつでも各レーンに投入してよい
  • 優先順位も好きに並び替えて良い
4. 週に一度、その週に完了したタスクを振り返る
  • Done レーンのタスクの完了を確認してアーカイブする
  • 完了した数や完了できなかった原因を振り返って、次回の改善にネタにする

あらゆるタスクを漏れなく管理するのは息苦しいので、 ぱっと思いついたが忘れたくないものをカジュアルにメモしておいて、 忘れないようにしていくのが無理がなくていいと思う。

妻の反応

妻は Trello のようなタスク管理ツールを使ったことはあまりないと思うけど(たぶん)、 アプリもサクッとインストールしてもう使いこなし始めている様子。 運用初日で 2 つのタスクを Done レーンまで持っていっていた。えらい。

f:id:ikasamak503:20200107032707p:plain
報連相もできている。えらすぎる。

期待する効果

  • 忘れるとまずいタスクを忘れずこなせるようにする
  • お互いのタスクを見えるようにして、負荷の確認やサポートができるようにする
  • うまくできたことを褒める習慣をつくる。良いコミュニケーションのきっかけにする。 *2
  • QoL の改善

まとめ

  • 夫婦共同の ToDo List を Trello のボードとして作った
  • 毎週振り返りして改善や褒めるなどする

しばらく運用してみて、何かアップデートがあったらまた記事を書こうと思う。

*1:厳密にはまだ入籍していないので婚約者。近日入籍予定。なので ToDo List にも入籍タスクがある。

*2:僕が寡黙で家であまり喋らないので

PHP カンファレンス北海道に行ってきました

phpcon.hokkaido.jp

セッション → アンカンファレンス → スポンサー LT → LT → 懇親会 という流れで見てきました。

感想: セッション

以下のセッションを聴講しました。

speakerdeck.com

PHP だけに限定せず、 汎用的なプログラミングや、 PHP を用いたアプリケーションの作り方を含んだ学び方・考え方の話。 職業エンジニアとなるための実践的な道標だと思います。いくつかは僕も過去に通った道ですが、またどこかで改めて振り返ってみようと思いました。


speakerdeck.com

フルリニューアルの話、前職では医療系のマッチングサービスをやってて、やっぱりフルリニューアルしてたので、しきりに「わかる」と心のなかで連呼していました。*1

  • 目的を見失わない。フルリニューアルはゴールではなく、スタート。新しい価値を素早く届けるための基盤を作ること。
  • フルリニューアルを行ってマイナスのインパクトが無い、ということはない

このあたりは金言だと思います。


speakerdeck.com

ブラウザテストがあると安心できるよね、やってみよう、という話。僕もほぼ同意見です。 API サーバーなら JSON 返してくるだけなので PHPUnit の Feature Spec で十分なんですが、 HTML をサーバーサイドでレンダリングする Web アプリケーションの場合はそうはいかないのでこういうテストが欲しくなります。

Selenium の難点は若干重いこと。ここさえなんとかなれば・・・。 あと Laravel Dusk を知れたのは大きな成果でした。次の Laravel Web アプリ案件に導入する予定です。


speakerdeck.com

AWS CDK、初耳でした。 プログラミング言語からコンパイルして CloudFormation テンプレートができて、デプロイまで出来るやつ。すごい。 似たようなツールに Pulumi があるけど、コレはお金がかかるので、 AWS がサポートしていて無料で使えるのは導入しやすそう。 でも僕は Terraform をやっていきたいので CDK は一旦様子見かな……。

感想: スポンサー LT

speakerdeck.com

弊社です。 書いてあることは社内の人からするとあるある、という感じの内容なんですが、社外の人はどういう印象を持たれたのか気になります。


speakerdeck.com

ス・マイル制度がいいな〜って思いました。特にアウトプットの価値を定量化するところは、見習っていきたい。

感想: アンカンファレンス

speakerdeck.com

MySQL, PostgreSQLアーキテクチャの違いとかあまり意識したことなかったので、それを知れるきっかけができたのは良かったです。

感想: LT

LT らしい LT を聞いたのは意外と始めてでした。 内容よりも、時間きっちりで喋りきってたり、勢いがすごいな〜、という印象のほうが強かったです。 個々のスライドのリンクは以下の Qiita 記事を参照してください。ちなみに LT 以外のスライドもほぼ網羅されています。

qiita.com

感想: 全体を通して

PHP カンファレンスと銘打ってますが、それに関連する技術も幅広く取り扱っていて多彩でした。 知らない技術スタックや考え方にふれるキッカケを得られたのが、自分にとっては大きな収穫だったなと思います。

その他

いま担当している案件で一緒に仕事している札幌オフィスのメンバー数名と直接会って話ができました。 今回の PHP カンファレンス北海道の参加の裏目的として達成できたので良かったです。

勉強し放題制度

カンファレンス参加に伴う旅費や宿泊費はゆめみの勉強し放題制度を利用して経費精算できます。*2 すごいぞゆめみ! でも本当は怖い。 経費精算するためにはアウトプットが必要なので、今必死になってコレを書いています。

www.yumemi.co.jp

懇親会のメシ

f:id:ikasamak503:20191001162152j:plainf:id:ikasamak503:20191001162155j:plainf:id:ikasamak503:20191001162158j:plainf:id:ikasamak503:20191001162200j:plainf:id:ikasamak503:20191001162204j:plain
懇親会のメシの写真。めちゃくちゃウマかった。

札幌についての知見

*1:僕はフルリニューアルの途中で辞めちゃったけど。今どうなってるのかなあ(遠い目)

*2:今回は金額が約 8 万円とでかいので、レビューが入ることになっています

株式会社ゆめみに入社して 2 ヶ月が経ちました

2019 年 7 月 1 日に入社したので、ちょうど 2 ヶ月です。 1 ヶ月や 3 ヶ月で振り返ることが多い気がしますが、個人的にはこのタイミングがちょうど良かったのと、気分も少しのったので、書くことにしました。

振り返り

7 月: オンボーディング、 Laravel と AWS 認定の勉強

最初の 1 ヶ月は、会社の売上に直接貢献する仕事はありませんでした。

ゆめみでは職能ごとのチームに所属した上で、そのチームが担当しているプロジェクトに参画するのが主流です。 私が所属したチームには 7 月の当初、ちょうどいいプロジェクトがありませんでした。 なので、使用予定の技術スタック ( Laravel, Lumen ) や AWS 認定の勉強をしていました。 結果的に AWS 認定は SAA を取得できたし、Laravel や Lumen に関しては腰を据えて勉強できて良かったと思います。

ikasamak503.hatenablog.com

ちなみに、資格取得の受験費用は勉強し放題制度によって全額補助されます。

note.mu

仕事がなくなったときこそ冷静に

一方で、入社時期に関わらず、メンバーや職能によってはクライアントワークが無いという状況は度々発生しています。 例えば、

  • 新規案件の受注を見据えて稼働予定を埋めていたが、最終的に失注した
  • サーバーサイドの開発規模を縮小することになった
  • その他、やんごとなき事情

とまあ、いろいろな理由で仕事がなくなることがあります。なくなったものは仕方ないですね。 とはいえ、仕事がなくなったからおしまい、とはせず、失注や仕事がなくなった事象に対する振り返りは行われているようです。 また、クライアントワークがない時期は自己研鑽や社内用ツールの企画・開発を通して将来への投資も行っています。

オンボーディング

note.mu

ここに書いてあるように、オンボーディングはまだ試行錯誤している最中という感じです。 僕が感じた課題点としては、

  • 情報が様々なツールやサービスに分散していて検索性が悪い
  • チームごとのオンボーディングは独自形式でバラツキがある

といったところです。 ちなみに、オンボーディングの一つの目安として「会社批判ができるようになる」という目標があって、 未だに会社批判をあれこれ考えていたりします。

8 月: クライアントワーク

4 月から開発している新規案件で、既存メンバーの引き継ぎという形で参画しました。 サーバーサイドの設計・開発という立場ですが、ものはほぼ出来ているので、いまはバグ改修や内部の改善といったタスクがメインです。 意外と Docker や AWS 関連の知識がチーム内で一番長けていたので、その分野でよく手を動かしたりレビューをやっていました。

入社して 1 ヶ月だけどお盆は 1 週間有給をとりました

ゆめみのメンバーは有給取り放題です。これは入社して間もないメンバーも対象です。

note.mu

法律や就業規則としては入社して半年経ってから有給付与ですが、それまでの有給が無い期間、この制度によって有給を取得することができます。

リモートワーク

週1回程度の頻度でリモートワークを実施しています。 現時点でリモートワークは、関わるプロジェクトマネージャーに確認をとる承認制となっています。 これは、プロジェクトによっては物理オフィスに出社してもらわないと困るとうケースがあったり(あるのか?)、 オフィスワーク推奨という考え方もまだあるためです。

note.mu

個人的には、IT エンジニアが働く場所なんてどこでもいいと思っているので、オフィスワーク推奨はよくわかんないですね。 一方で、リモートワーク推奨にしようという委員会ができていたり、 直近だと来年の東京オリンピックの時期は通勤どうするんだ、リモートワークか? という議論がされていたりします。

リモートワークの工夫の話をすると、最近は札幌オフィスのメンバーがプロジェクトにジョインされたこともあって、 ミーティング時は東京オフィスに数名集まっていても、全員が離れた場所から Zoom に繋ぐということをしています。 こうすることでビデオ会議で聞こえづらくなりがちな拠点内の会話がなくなって、全員が対等にミーティングに参加できていて良いです。

他、体験したゆめみの文化・制度

ウェルカムランチ制度

ざっくりいうと新入社員とランチ行く場合は会社から補助するよ、という制度。 いろんな人とランチ行けるので、入社時の繋がりブーストとして良いと思います。

プロポーザル・レビュー・リクエス

やりたいことをを明文化して誰かにレビューしてもらう制度。 全社員 CEO なので、やりたいことがあれば誰もが何でもやれる権限を持っているんですよね。 とはいえみんなそれなりに常識人なので、最初からぶっ壊れたプロポーザルが出てくることはないようです。

Bad News Fast

ゆめみには Bad News Fast という文化があり、「悪い情報」や「リスク」を最速で共有する Slack チャネルがあります。 これには、2 つの側面があると解釈しています。

  • 重大な問題を隠さずに報告できる雰囲気を作ろう
  • 全社をあげて一緒に問題を解決しよう ( 誰かを責めるものではない )

なかなか慣れない人も多いようですが、とても良い文化だと思います。

感想

  • 仕事がないとか、そんなこともあるんだ
    • 自社サービスをやっていた頃は無限に仕事があったので逆に新鮮
    • 勉強する時間がとれたのは良かった
  • 社内制度が素早いサイクルでアップデートされていくので、全部を追うのは大変
    • AWS みたい
    • 必要なものだけウォッチしよう
  • 制度の背景にある考え方を身につければ、すぐにキャッチアップできると思う
  • 有給取り放題やリモートワークで生活に融通がきくようになってよかった
  • ( オフィスのディスプレイがでかくて良いので ) 久しぶりに出社したいという気持ちになった
    • しかし、たまに冷房が効きすぎていて体調を壊す

次の目標

次は入社半年たったあたりで振り返ります。年末か年明けになると思います。

  • 会社批判
  • AWS 認定をもう 1 つとる
  • 通勤が楽なところに引っ越す
    • まだ、なんだかんだ物理オフィスへの出社が求められてる雰囲気がある
    • 今の通勤はさすがに時間がかかってしんどい
  • ゆめみの制度を使い倒す
  • 月 2 回程度のアウトプット

We are hiring!

株式会社ゆめみでは、成長意欲が高く、会社の制度やルールのあり方を再考して変えていきたいと考えていて、 入社して1ヶ月はタダ飯食いまくりたいし、有給もとりまくりたいと思っているメンバーを募集しています!

www.yumemi.co.jp

選考に入る前にざっくばらんな話ができるカジュアル面談もあるので、話を聞いてみたいという方は何らかの手段で僕に連絡をとるか、 以下の求人一覧ページの応募フォームからご連絡ください。

hrmos.co

awswakaran.tokyo #1 に行ってきました

www.awswakaran.tokyo

↑主催の開催後記です。 スライドへのリンクとかはこちらを参照ください。

感想

あるある要件を実現したい時のハマりがちポイントとその対策がわかった

「CloudFront にだけ IP 制限かけるだけで本当に大丈夫ですか?」 by @euxn23 さん 「Universal Application にありがちな LB ガチャ問題を解消する」 by @potato4d さん

  • どちらもフロントエンド向けのインフラ話でした
  • サーバーサイド勢からすると最初は「???」という感じ
  • 最後まで聞くと、ちょっとわかった気がした
  • 弊社はフロントエンドに最適化したインフラ構成を誰が考えているんだろう?

ようわからんけど入門するときのとっかかりが知れた

AWSが分からん人に送るFargateのススメ」 by @nametaketakewo さん 「CI/CDわからん」 by @y_ohgi さん

  • Fargete はちょうど使い始めたところだったので、色々学びがあった
    • 例えば Rails + Sidekiq worker とかはそれぞれ別サービスに分けちゃって良さそう
    • migration も別サービスに分けて完了したら即死させるとか
      • ここは単なるタスクの実行でもいい気はする
  • Ci/CD 話、 migration は 1 回 / 1 デプロイ!

当日限定の非公開コンテンツ

「そんなことあるんだAWS」 by オタクさん

  • 話聞いてるだけで面白かった
  • AWS の裏側がどういう挙動をしているのか探求する物語
  • そんなことあるんだ……
  • AWS ドキュメントの正式版は英語版、翻訳はあくまで参考なので違和感を感じたら原典にあたろう!

まとめ

  • ぜんぜんわかってない AWS が少しわかった
  • S3 難しい
  • そんなこともある
  • 英語のドキュメント読もう!