Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
インプットとアウトプットのサイクルを回す暮らし / Kichijoji.pm 29
Search
utagawa kiki
April 12, 2022
Technology
1
8.8k
インプットとアウトプットのサイクルを回す暮らし / Kichijoji.pm 29
吉祥寺.pm 29
https://kichijojipm.connpass.com/event/244184/
utagawa kiki
April 12, 2022
Tweet
Share
More Decks by utagawa kiki
See All by utagawa kiki
ありがとう、create-react-app
utgwkk
2
7k
mockgenによるモック生成を高速化するツール bulkmockgenのご紹介 / Kyoto.go #43
utgwkk
1
1.5k
SPAでもデータをURLでシェアしたい / Kyoto.js 19
utgwkk
1
1.4k
prototype大全 / YAPC::Kyoto 2023
utgwkk
0
3.9k
なんでもPull Requestにする / Kichijoji.pm 31
utgwkk
2
5.9k
prototypeとjust epic. と私 / YAPC::Japan::Online 2022
utgwkk
0
9.3k
GraphQLを使った共同開発の心構え 〜 フロントエンドの視点から / Hatena Engineer Seminar #18
utgwkk
0
8.7k
他言語ユーザから見たPerlのおもしろさ / YAPC::Nagoya::Tiny 2019
utgwkk
1
8k
VJに使えそうなコマンドたち、そしてjustifyのご紹介 / YAPC::Nagoya::Tiny 2019 LT
utgwkk
0
5.4k
Other Decks in Technology
See All in Technology
オブジェクトのおしゃべり大失敗 メッセージングアンチパターン集 / messaging anti-pattern collection
ytake
0
340
コードレビューを支援するAI技術の応用
akkie76
2
170
Autify Company Deck
autifyhq
1
30k
Elementaryを用いたデータ品質の可視化とデータ基盤の運用改善
10xinc
6
1.7k
Azureコストは水道代/The_47th_Tokyo_Jazug
aeonpeople
3
390
私のRSpecの書き方 / How I write RSpec
tmtms
4
840
バッチ処理のSLOをどう設計するか
rynsuke
7
590
技術広報経験0のEMがエンジニアブランディングをはじめてみた
coconala_engineer
1
140
匠MethodとRDRAとICONIXとDDDで実現する一気通貫オブジェクト指向開発
haru860
4
2.1k
GraphQLに入門してみた
chiroruxx
2
130
今さら聞けない!? AWSの生成AIサービス Amazon Bedrock入門!
minorun365
PRO
11
2.7k
LLM + RAG を使った SORACOM Support Bot の裏側の歴史
soracom
PRO
1
640
Featured
See All Featured
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
28
5.9k
How STYLIGHT went responsive
nonsquared
92
4.7k
StorybookのUI Testing Handbookを読んだ
zakiyama
10
4.5k
A Tale of Four Properties
chriscoyier
150
22k
JazzCon 2018 Closing Keynote - Leadership for the Reluctant Leader
reverentgeek
178
11k
Pencils Down: Stop Designing & Start Developing
hursman
115
11k
Web development in the modern age
philhawksworth
201
10k
Happy Clients
brianwarren
91
6.3k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
153
14k
Bash Introduction
62gerente
604
210k
Product Roadmaps are Hard
iamctodd
43
9.6k
Documentation Writing (for coders)
carmenintech
59
3.8k
Transcript
インプットとアウトプットの サイクルを回す暮らし 吉祥寺.pm 29 @utgwkk (うたがわきき)
自己紹介 • @utgwkk (うたがわきき) • 株式会社はてな Webアプリケーションエンジニア • 主にTypeScriptとReactを書いて 暮らしています
これまでのあらすじ • アルバイトエンジニアとしてサーバーサイドのコード (Perl) を書いていた ◦ たまにJavaScriptも書く ◦ アルバイトはコードレビューのレビュワーにならない •
2021年に新卒入社 ◦ TypeScriptとReactを使う新規案件のエンジニアになる ◦ サーバーサイドのコードは書かない !! • 暮らしぶりがガラッと変わる
先に1年間暮らしてきた感想 • 思ったよりはやっていけていると思う • 今のところ、行き詰まっている感じもなく暮らせている
振り返ってみる • 試行錯誤をする • いろいろ目を通してみる • アウトプットをする • コードレビューをする
手を動かすのが手っ取り早い • ドキュメントやチュートリアルを読むだけだと実感がわかない • 世界観を把握するのには手を動かすのが手っ取り早いと思う ◦ ドキュメントを読むだけでは分からなかった実感を持てる ◦ うまくいく体験・うまくいかない体験ができる
簡単に試行錯誤できる環境を作る • 簡単にセットアップできるツールがあると良い ◦ Reactならcreate-react-appとか • 趣味なら何をやっても・いくら壊してもよい • 作りたいものを作ってみるのが手っ取り早い ◦
他言語からの移植でもよさそう ◦ 例: twitter-textのPerl実装 Twitter::Text を公開した - 私が歌川です
いろいろ目を通してみる • 片っ端からドキュメントを読む ◦ チュートリアルからAPIリファレンスまで ◦ たまに思い出して役に立つこともある • 片っ端から型定義ファイルを読む ◦
たまに役に立つものが見つかる • 分からなかったら実装を読みにいく ◦ git cloneしてVSCodeで読み進める ◦ GitHubの定義ジャンプがけっこう使える
規格書にあたってみる • そもそもどういう振る舞いが想定されているのか、が分かる • 意外となんでも規格書に書いてある • 例: Webフォントを分割して読み込む際にunicode-rangeを指定しなかったらどうな るのか -
私が歌川です ◦ 先に実験してから規格書を読んで確かめた
規格書を読むコツ • 1つのWebページに長大な規格が書いてあるとページ内検索が難しい • 必要そうなセクションだけエディタにコピペすると検索しやすい ◦ 関係ありそうな箇所を片っ端から持ってきたとしても、 元の規格書よりはだいぶ短くなるはず • 用語集に目を通しておく
わかったことをアウトプットする • 知識を反芻して理解を深める • チーム内にアウトプットする ◦ 調べたこと、検討したこと、やったこと、などなど ◦ 個人ではなくチームの知識にする •
インターネットにアウトプットする ◦ ブログ記事にまとめる
アウトプットのコツ • 前提を書く ◦ ランタイムやライブラリのバージョン ◦ いつ時点の情報か • 事実と考察を分ける ◦
何が起こった・何が出力された (事実) ◦ こういうことかもしれない (考察) ◦ 検証した結果も書けるとよさそう • 参考にした情報源を書く • 「理科系の作文技術」を読む
以前からやってた • Webフロントエンド開発にガッツリ携わる前も同じようなことをやっていた • 新しいことをやっても基本的なエッセンスは変わらなさそう ◦ 試行錯誤する ◦ 分からないことがあったら調べる ◦
分かったことをまとめる
ところで、コードレビューの話 • コードレビューやっていますか • アルバイトの頃はレビュワーをやっていなかった • いざレビュワーをやってみると考えることがけっこうあると気づく ◦ コツはある ◦
コードレビュー - hitode909の日記 • 油断するとコードレビューに時間を使いすぎてしまう ◦ さくさくコードレビューしまくる問題 - 私が歌川です ◦ 午前中に自分用のレビュータイムを取ってみている
コードレビューで心がけていること • レビューコメントに[MUST][SHOULD][MAY][nit]など (温度感) を書く ◦ 必ず修正してほしいのか、実装方法の提案ぐらいなのかを明確にする ◦ 温度感が違っていたらチューニングできる •
[memo][感想]とかも使うことがある ◦ レビューしていて気づいたことがあったら書いておくと吉 ◦ そこから議論が発展して、よりよい解法に落ち着くこともある
なぜコードレビューの話をしたのか • コードレビューはコミュニケーション • 一種のインプット・アウトプットともいえる ◦ レビューする場合も、レビューしてもらう場合も ◦ こういう書き方ができる、こういう場合を考慮している、といった知識を 吸収できる
ここで一句 (まとめ) • サイクルを 回して質を 高めあう • 解説: インプットとアウトプットは両輪になっていて、両方のサイクルを 回して知識の質を高めていくことだなあ