$30 off During Our Annual Pro Sale. View Details »
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
190
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
20251209_WAKECareer_生成AIを活用した設計・開発プロセス
syobochim
5
1.4k
Reinforcement Fine-tuning 基礎〜実践まで
ch6noota
0
160
日本Rubyの会の構造と実行とあと何か / hokurikurk01
takahashim
4
940
Microsoft Agent 365 を 30 分でなんとなく理解する
skmkzyk
1
1k
pmconf2025 - データを活用し「価値」へ繋げる
glorypulse
0
700
モバイルゲーム開発におけるエージェント技術活用への試行錯誤 ~開発効率化へのアプローチの紹介と未来に向けた展望~
qualiarts
0
660
regrowth_tokyo_2025_securityagent
hiashisan
0
170
AWS re:Invent 2025で見たGrafana最新機能の紹介
hamadakoji
0
130
“決まらない”NSM設計への処方箋 〜ビットキーにおける現実的な指標デザイン事例〜 / A Prescription for "Stuck" NSM Design: Bitkey’s Practical Case Study
bitkey
PRO
1
580
品質のための共通認識
kakehashi
PRO
3
220
[JAWS-UG 横浜支部 #91]DevOps Agent vs CloudWatch Investigations -比較と実践-
sh_fk2
1
240
今からでも間に合う!速習Devin入門とその活用方法
ismk
1
510
Featured
See All Featured
Site-Speed That Sticks
csswizardry
13
990
Building Applications with DynamoDB
mza
96
6.8k
Context Engineering - Making Every Token Count
addyosmani
9
490
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.2k
RailsConf 2023
tenderlove
30
1.3k
Thoughts on Productivity
jonyablonski
73
5k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
Unsuck your backbone
ammeep
671
58k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.3k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Building Adaptive Systems
keathley
44
2.9k
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][感想]とかも使うことがある ◦ レビューしていて気づいたことがあったら書いておくと吉 ◦ そこから議論が発展して、よりよい解法に落ち着くこともある
なぜコードレビューの話をしたのか • コードレビューはコミュニケーション • 一種のインプット・アウトプットともいえる ◦ レビューする場合も、レビューしてもらう場合も ◦ こういう書き方ができる、こういう場合を考慮している、といった知識を 吸収できる
ここで一句 (まとめ) • サイクルを 回して質を 高めあう • 解説: インプットとアウトプットは両輪になっていて、両方のサイクルを 回して知識の質を高めていくことだなあ