Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
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
9.2k
インプットとアウトプットのサイクルを回す暮らし / 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
tparseでgo testの出力を見やすくする
utgwkk
1
180
go test -json そして testing.T.Attr / Kyoto.go #63
utgwkk
4
710
自動で //nolint を挿入する取り組み / Gopher's Gathering
utgwkk
1
1.5k
ゆるやかにgolangci-lintのルールを強くする / Kyoto.go #56
utgwkk
2
2.8k
君たちはどうコードをレビューする (される) か / 大吉祥寺.pm
utgwkk
21
16k
Dive into gomock / Go Conference 2024
utgwkk
14
8.2k
Goでリフレクションする、その前に / Kansai.go #1
utgwkk
4
3.6k
Go製Webアプリケーションのエラーとの向き合い方大全、あるいはやっぱりスタックトレース欲しいやん / Kyoto.go #50
utgwkk
7
4.2k
ありがとう、create-react-app
utgwkk
4
12k
Other Decks in Technology
See All in Technology
SSO方式とJumpアカウント方式の比較と設計方針
yuobayashi
7
490
計算機科学をRubyと歩む 〜DFA型正規表現エンジンをつくる~
ydah
3
190
生成AI時代の自動E2Eテスト運用とPlaywright実践知_引持力哉
legalontechnologies
PRO
0
210
AWS CLIの新しい認証情報設定方法aws loginコマンドの実態
wkm2
3
330
EM歴1年10ヶ月のぼくがぶち当たった苦悩とこれからへ向けて
maaaato
0
270
会社紹介資料 / Sansan Company Profile
sansan33
PRO
11
390k
手動から自動へ、そしてその先へ
moritamasami
0
280
最近のLinux普段づかいWaylandデスクトップ元年
penguin2716
1
660
MapKitとオープンデータで実現する地図情報の拡張と可視化
zozotech
PRO
1
120
なぜ使われないのか?──定量×定性で見極める本当のボトルネック
kakehashi
PRO
1
1.2k
pmconf2025 - 他社事例を"自社仕様化"する技術_iRAFT法
daichi_yamashita
0
780
プロダクトマネジメントの分業が生む「デリバリーの渋滞」を解消するTPMの越境
recruitengineers
PRO
3
720
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
34k
Making the Leap to Tech Lead
cromwellryan
135
9.7k
Embracing the Ebb and Flow
colly
88
4.9k
Reflections from 52 weeks, 52 projects
jeffersonlam
355
21k
RailsConf 2023
tenderlove
30
1.3k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Mobile First: as difficult as doing things right
swwweet
225
10k
Documentation Writing (for coders)
carmenintech
76
5.2k
Site-Speed That Sticks
csswizardry
13
990
Statistics for Hackers
jakevdp
799
230k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.8k
Rails Girls Zürich Keynote
gr2m
95
14k
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][感想]とかも使うことがある ◦ レビューしていて気づいたことがあったら書いておくと吉 ◦ そこから議論が発展して、よりよい解法に落ち着くこともある
なぜコードレビューの話をしたのか • コードレビューはコミュニケーション • 一種のインプット・アウトプットともいえる ◦ レビューする場合も、レビューしてもらう場合も ◦ こういう書き方ができる、こういう場合を考慮している、といった知識を 吸収できる
ここで一句 (まとめ) • サイクルを 回して質を 高めあう • 解説: インプットとアウトプットは両輪になっていて、両方のサイクルを 回して知識の質を高めていくことだなあ