RubyWorld Conference 2018 参加記(1日目)
会社がスポンサーになったので、こちらに出席させていただいてます。
1日目のプログラムはまつもとゆきひろ氏の基調講演から始まり、Ruby Prizeの発表で終わりました。
Matz基調講演(The power of the community)
この基調講演では、Rubyがいつどのように生まれて、今日のように人気のある言語として広く使われるようになったのかを聴くことができました。
放置していたUTF-8対応、ドキュメント整備、ミートアップ開催、本の出版などはどれも、まつもとさん個人の力ではなくコミュニティの力で行われたことであり、特に人にプログラミングを教えるのはまつもとさんが苦手な部分だった(プログラミングできない人の気持ちがわからない)という話がありました。
また、こういったコミュニティの力を借りるために、コミュニティに対して面白いものを提供し続ける必要があるというようなことをおっしゃっていました。OSSコミュニティは止まったら死ぬ鮫のようなものだ、とも。
私はユーザーとして普段からOSSを使って仕事をしている身ですが、未だにOSSコミュニティは不思議に感じる部分が大きいです。仕事とも個人の趣味とも言えない、独特の雰囲気があります。
この基調講演でまつもとさんも、コミュニティに関わる人のモチベーションは知的好奇心、承認欲求、そこで発生するコミュニケーション、責任感、お金など人それぞれだとおっしゃっていました。
Ruby Prizeを受賞したk0kubunさんの発表
Ruby Prizeを受賞したk0kubunさんの発表も凄まじく良かったです。途中までブースにいて、内容を途中から聴いたのでYouTube動画あとで見返したい。
感想とか
今、Rubyはメジャーなプログラミング言語で、仕事はたくさんあり、学ぶ価値があるというのはすぐわかります。私も仕事で扱っているシステムはRubyで書かれていて、その開発や保守に携わって、日々生活するためのお金を頂いてます。Rubyで書かれたシステムが動いて、実際に価値を生み出していることは感じています。
しかし、そういったことが可能になる前からRubyそのものに携わってきた、作者のまつもとさんやコミュニティの中心で関わっている方々には、それとはまた違う気持ちがありそうです。
今日の講演などを聴いた上での私の想像ですが、知的好奇心を満たす手段として、純粋に楽しくてRubyに関わっていたのかなと、そんな風に思います。
何か技術的なことを学んだり、ものを作ったり、プログラムを書くことが、今の私にとっては仕事をしてお金を稼ぐためのものであり、それ自体が目的にはなっていません。しかし、もしそれ自体が目的になったり、少なくともそう感じられることが増えれば、とても幸せなことだと思います。
すごいエンジニアになってたくさんお金を稼ぐとか、偉くなりたいとか有名になりたいとか、そういったことではなく(もちろんそれも大事なんだけど)、やっていること作っているものそのものに没頭して、楽しさや喜びを見いだせるようなエンジニアになろう。基調講演やほかの素晴らしい発表を聴きながら、そんなことを考えることができました。
今さらReduxのSSOT原則とか状態管理について考える
Reduxを使ってウェブアプリケーションの開発をしていて、割と早い段階で、どうしてもReactのsetStateを呼びたい場面に遭遇しました。しかしReduxといえば、Single Source of Truthという原則があります。状態はすべて、Redux側で一つの状態ツリーで管理するものだと思っていました。
とすると、Reactコンポーネントたちは状態をpropsとして受け取って描画するだけ、ただのビューの関数であり、Reduxでの状態管理とReactでの要素表示の役割がしっかり分けられてきれいな世界になる...!!これがいまどきのきれいなウェッブアプリケーションなんじゃ!!!実装を始める前まではそんなものを想像していました。
ところが、実装を始めるとすぐにReactのsetStateを呼びたくなりました。それはもうすぐに呼びたくなりました。何かと言うと、いわゆるドロップダウンメニューの開閉表示状態です。今私が利用しているはてなブログの編集画面の、ここの部分みたいなものです。
クリックしたら開いたり閉じたりします。これ系の挙動をするコンポーネントは、だいたい何を作るにしても必要なものだと思います。
要は、この開閉状態を、Reduxで管理せず、Reactのそのコンポーネントのstateに持たせたくなったのです。
Reduxで管理する場合、きっと以下のようなコードが必要になります。
// components/DropdownComponent.jsx const mapStateToProps = ... const mapDispatchToProps = ... export default connect(mapStateToProps, mapDispatchToProps)(DropdownComponent) // actions/ToggleDropdown.js export default { type: 'TOGGLE_DROPDOWN' } // reducers/toggleDropdown.js const toggleDropdown = (state, action) => { switch(action.type) { case 'TOGGLE_DROPDOWN' : default: return !state } } export default toggleDropdown
ふむ...ずいぶんと多くのファイルを編集しないといけない。
対して、ReactのsetStateを使う場合。
export default class DropdownComponent { constructor(props) { super(props) this.state = { visible: false } } handleClick = (e) => { this.setState({ visible: !this.state.visible }) } render() { <div> <button onClick={this.handleClick}> {this.renderContent()} </div> } renderContent() { if (this.state.visible) { return <DropdownContent /> } else { return null } } }
こりゃいいや!!!このコンポーネントのなかで完結していてわかりやすい!
しかし、そんなことをして怒られないのでしょうか。この軽はずみな実装によってReduxの怒りを買ってしまいプロダクトが破綻してしまっては困ります。
調べてみると、ちゃんとReduxにこんなFAQがありました。
(質問)
Do I have to put all my state into Redux? Should I ever use React's setState()?
まさしく自分が知りたいことです。setState呼んでいいのでしょうか?
(回答)
There is no “right” answer for this. Some users prefer to keep every single piece of data in Redux, to maintain a fully serializable and controlled version of their application at all times. Others prefer to keep non-critical or UI state, such as “is this dropdown currently open”, inside a component's internal state.
なるほど、、全部Reduxで管理するやつもいるし、ドロップダウンの開閉状態みたいなものに関してはコンポーネントに持たせる人もいるよね、と。答えになってないじゃないか!
Using local component state is fine. As a developer, it is your job to determine what kinds of state make up your application, and where each piece of state should live. Find a balance that works for you, and go with it.
それはお前が考えることだ、と。ふぉ〜〜〜。そうですよね〜〜。
改めて考えてみると、もともとはReduxなんかなくてもアプリケーションは作れる。じゃあなんでRedux使うのかというと、コンポーネントの中ではなくアプリケーション全体で持ち回したい状態を一箇所でちゃんと管理したいから、ということになる。それだってRedux使わなくてもできるわけだけど、そうするとバケツリレーと呼ばれるあの、状態とコールバックを受け渡し受け渡しする見通しの悪い地獄みたいなコードを書かないといけなくなる。それは嫌だ。それだったらReduxを使う、となります。
まとめ
ReduxのSingle Source of Truthを厳密に守ろうとするのはきついと感じることもあり、しかしReduxみたい状態管理ライブラリは何かしら必要です。自分の精進が足りず、まだベストな方法を見つけられていない感がありますが、Reduxを完璧なフレームワークと思い込まず、問題があったらそれについて考えながら使いこなしていければと思います。
「Atomic Design 〜堅牢で使いやすいUIを効率良く設計する」を読んでる
読んでいます。Twitterで気になったところをメモして、あとで感想などまとめたい。
エンジニアとデザイナーの設計方法の違いについて
"エンジニアリングにおいては、「あるプラットフォーム上に置いて動作するものを作ること」が最優先です。そのためには、動作することが証明されている部品を使って大きなものを組み立てることが最も合理的な道です。 しかし、デザインとは... https://t.co/A1vgSCzULz
— gaaamii (@gaaamii) 2018年9月16日
インターフェースインベントリという手法があるらしい
"インターフェース・インベントリでは、アプリケーションの全画面に実装されている既存のUIのスクリーンショットを取って、同じ役割を持っているものごとに適当なドキュメント上に並べます。" https://t.co/9pjaqwBlp6
— gaaamii (@gaaamii) 2018年9月16日
コンポーネントをStorybookなどのカタログで管理することのメリットについて
"コンポーネント・リストとプロダクトでソースコードを共有すると、事実上、1画面を複数人で平行実装することが可能になります。" https://t.co/Y7XAhIo2wz
— gaaamii (@gaaamii) 2018年9月16日
コンポーネントリストに整理してあることでこんなことも可能になるんじゃという話
すごい "AbemaTVの開発では、Atomic Designをベースとしたコンポーネント・リストを作り、デザイナーやディレクターにコードを直接編集してもらい、GitHub上でプル・リクエストを出してもらうようにしていました。" https://t.co/ngAVKVPw4h
— gaaamii (@gaaamii) 2018年9月16日
感想
具体的な実装の話が多くて良かった。わかりやすい。
第6章には、Atomic Designを現場でどう取り入れるかというような話が書かれていてためになる。
#builderscon 2018の感想
TL;DR
- 9/6~9/8の3日間biuldersconに行っていろんな発表を聴いた
- 最高だった
詳しく
9/6~9/8の3日間、biuldersconに行っていろんな発表を聴いてきました。聴いたセッションすべてではありませんが、気になったものだけブログ記事にメモを残したりしました。
全体の感想
本当にお祭りという感じで、終始楽しかったです。
全体通してmicroservicesの話が多く、各社試行錯誤しているんだなという印象を受けました。Envoyについては全く知らず、昨日のとても丁寧なセッションを聞いても理解できたとはいえない感じだけど、これがmicroservicesの課題を解決できるんだとしたら、今後必要になってきそう。
今回感じたカンファレンス参加の意義みたいなもの
また今回会社のスポンサーチケットで参加させてもらったので、楽しいというほかに、こういうカンファレンスへの参加が普段の業務の役に立つのか?ということも少し考えました。
技術的な価値や負債に真っ先に気付けるのはエンジニアなので、自信を持って決断をするために、こういうカンファレンスに知見とか失敗談を持ち寄って共有し合うのはすごい価値のあることだと思います。もちろん、聴くだけの人間としては、カンファレンスに行けば正解が得られるというわけではないし、行くだけで自分のスキルが向上するわけでもありません。しかし、こういう問題あるあるだよねーと言ってゲラゲラ笑う発表、真面目に解決策を模索する発表、失敗談の共有、全く新しいことへの挑戦などなど、様々なタイプの発表を聴くことができ、学べることは多かったです。
こういうお祭りが一切なくなってしまったら、我々は日々向き合ってる地味でつらい問題をどこで笑い飛ばせばいいんだ...?新しい技術を試している人や問題の解決策を知っている人を、どこで見つければいいんだ...?みたいな気さえします。
まとめ
運営の方々、登壇者の方々、スポンサーになってくれた弊社(この記述でいいんだろうか)、本当にありがとうございました。 初めてのbuilderscon参加でしたが、最高に楽しかったです。
#builderscon 2018 参加記(2日目)
前夜祭、1日目に続き、行きました。
聴いた発表
- 「Web とは何か?」 - あるいは「Web を Web たらしめるものは何か?」
- すべてが gem になる - サービス密結合からの段階的脱却
- デザイナーとうまく協働する方法
- Webアプリケーションエンジニアが知るべきDNSの基本
- RDB THE Right Way ~壮大なるRDBリファクタリング物語~
- LT
気になったセッション
「Web とは何か?」 - あるいは「Web を Web たらしめるものは何か?」
https://builderscon.io/tokyo/2018/session/476a4a30-2f94-424c-bbc2-f6cb14f1c4cdbuilderscon.io
Webのアーキテクチャの変遷から現状と課題を見直すという話。Webを(使う/で作る/を作る)人たち、三者で見ているものが違うという前提を念頭に話が進む。
もともとHyper Media Systemとしてのウェブだったのが、Ajaxの発見で出てきたセキュリティの問題をOriginの制約によって解決。そこからアプリケーションプラットフォームとして進化してきたウェブが、今やデバイスへのアクセスまで手を出してOS化していっているという話でした。
「Webで作る」立場のウェブアプリケーションエンジニアの中では、ウェブに携わるようになった時期によって、今でもHyper Media Systemとしてウェブを捉えている人と、Application Platformとしてのウェブを最初から受け入れているような人がいて、そのどちらの人にとっても、今後のウェブについてどう考えていったらいいかが整理されるような話だったと思います。個人的にはOSとしてのウェブというのはまだ受け入れられないけど、「Webを作る」人たちの間ではそこに向かってすでに議論が行われて、実際そっちに向かっているということは知ることができました。
デザイナーとうまく協働する方法
https://builderscon.io/tokyo/2018/session/fd38108a-123f-4ef1-9a05-d50be4118df6builderscon.io
デザイナーとうまく協働する方法。内容的には、デザイナーが(他職種と)うまく協働する方法っぽかったです。
「よい」というニュアンスを自分の中ではなく組織内で共有するためのプロセスが必要で、それに基づいてデザインの評価は行われるべき。そうでないと、デザインがセンスだったり好みだったり偉い人が決めるみたいな状況になってしまう。そうならないよう、徹底した言語化と文書化が必要。
たぶん多くの現場で、デザイナーなりエンジニアが「いい感じ」にやってしまっていると思います。「これどうですか?」という漠然としたコミュニケーションは、よっぽど細かいガイドラインを作らない限りは生まれそうです。
こちらの発表を聴いて、じゃあしっかり言語化ができているチームではそこらへんの情報をどうまとめているのだろうと興味が湧きました。今後、他社の取り組みで注目すべきなのは成果物のUI/UXだけじゃなく、そこに至るための言語化,文書化のプロセスだったり情報共有の方法だったりするのかなと思いました。
RDB THE Right Way ~壮大なるRDBリファクタリング物語~
https://builderscon.io/tokyo/2018/session/ddba9bd5-819e-489e-9123-04d2291d506ebuilderscon.io
テーブル設計やDBリファクタリングの話。 主にテーブルの正規化ちゃんとやろうという話でした。
以下の4冊が紹介されていて、SQLアンチパターンとRefactoring Databaseは持っていなかったのでとりあえず買ってみました。
#builderscon 2018 参加記(1日目)
前夜祭に続き、行きました。
聴いた発表
- Electronによるアプリケーション開発事情2018
- Algorithms in React
- Webサービスにて200週連続で新機能をリリースする舞台裏
- 実録!ある担当者がみた「謎ガジェット」開発1年史
- Webサービスの品質とは何か?アラート地獄と監視の失敗、サービスレベル目標設計から学んだ3つの答え
- Envoy externals and "ideas" for people who wouldn't operate Envoy itself
気になったセッション
Electronによるアプリケーション開発事情2018
- Electronを使ってMastodonクライアントを作っているというお話。
- はじめから英語対応することで英語圏のユーザーにリーチしていてすごい。
- パフォーマンス改善の取り組みとして、Tootの描画件数を制限した話が良かった。
Algorithms in React
- 正直、話の半分も理解できずに終わった。
- 状態更新の優先度の話など。
- 動画上がったらもう一度聴く。
- 最後の方で紹介されていたSuspenseは普通に今後使いそう。
Envoy externals and ideas
- Microservicesのつらみを解決するためのパターン(?)
- わかったようなわからないような。
感想
わからないことも多いんだけど楽しい。
業務で何か必要が生じてキャッチアップするときと違って、こういうお祭り感の中で「はは〜、そういうものがあるんですか」みたいなノリでいろんな話を聞けるのが楽しい。謎ガジェット(電子名札)の話とか、内容としてはこれおれが聴いたところで業務でいつ役立つんだという感じだけど、uzullaさんの発表がくそ面白くて聴き入ってしまった。
明日も楽しみなセッションがいくつもあるので楽しみ。
会社がスポンサーになったので #builderscon にスポンサーチケット参加できて最高
buildersconに参加しています。
https://builderscon.io/tokyo/2018builderscon.io
今日も明日もいます。
なんで参加してるの
弊社スタディプラス株式会社は今年、buildersconのスポンサーになったので、希望者3人がスポンサーチケットでbuildersconに参加できることになった。
普通に参加するとチケット5000円するのでとてもありがたい。自分が所属してる会社のロゴがスポンサーに表示されているのも気持ちが良い。
昨日は前夜祭を見に行って、IoTとかVRの話を聞いた。
前夜祭
レベルの高い話とかSNS共有厳禁の話とかで、IoT門外漢の自分にはなんとも言えない感じだったけど、最後のペパボMake部のお二人の発表が個人的にはすごい良かった。IoT歯ブラシスタンドの話はすごい良くて、なんかしたらどっかにPOSTするというIoTは入門としてとても良さそうだし、アイデア次第でいろいろ面白いことができそう。実際IoT歯ブラシスタンドちょっと使ってみたいと思った。
今日と明日
ウェブアプリケーション周りの話を中心に聞いていきたいと思ってる。 またそれぞれブログ記事にしようと思っています。
「最高の人生の見つけ方」を観た
夏季休暇取ったのに台風直撃したせいでずっと引きこもっていた。そこで「最高の人生の見つけ方」という映画を観た。
余命宣告された2人が意気投合して世界旅行に出てひたすらやりたいことをやる映画。
人生で一番つらいことと向き合って、それを2人で思い切り笑い飛ばす感じがすごいよかった。
Elmやってるけどどうか(途中経過)
趣味でElmを書いていて、最近では仕事でも一部Elmを使わせてもらっている。作っているもの自体は大きくないし、人に説明できるような理解度でもないのだけど、やっていってる途中でどう感じてるのか雑に書いてみてもいいのではと思ってだらだら書いてみた。
関数シグネチャの読み方
Elmでは関数の引数は一つしか取れない。そのため関数はこういう形になる。
append : List a -> List a -> List a Put two lists together. append [1,1,2] [3,5,8] == [1,1,2,3,5,8] append ['a','b'] ['c'] == ['a','b','c'] You can also use the (++) operator to append lists.
関数を利用しているappend [1,1,2] [3,5,8]
の部分を見ると、なんか引数が2つあるように見えるけど、そうではない。append [1,1,2]
を評価して返ってくる関数に [3,5,8]
を渡している。
REPLで1つずつ試していける。
> List.append <function> : List a -> List a -> List a
List.append
は List a
を受け取って List a
を返す関数を返す関数だ。
> List.append [1,2,3] <function> : List number -> List number
List.append [1,2,3]
は、List number
を受け取って List number
を返す関数だ。
> List.append [1,2,3] [4,5,6] [1,2,3,4,5,6] : List number
List.append [1,2,3] [4,5,6]
は、List number
だ。
となる。ふむ。
謎の安心感
謎の安心感がある。型を合わせていけば何かが出来上がっていく感じがある。JS書いてると console.log
とか多用してたけどElmではあんまり Debug.log
してない気がする。型合わせていけばなんかちゃんとできるというのと、あとDebuggerという便利ツールがあって、状態の遷移がupdateを通る都度確認できるからというのもある。
Debugger
Debuggerはなんか普通に気に入った。Google Chromeの使いこなしテクニックとかいろいろ覚えるのしんどい。これくらいシンプルにアプリの状態見れるツールがあるのは嬉しい。
Elm Architecture
基本Model View Update の3つで、難しくないという印象。この印象のおかげで、Elmを始めた。
ただ、CommandとSubscriptionという副作用を扱うための登場人物がいて、これをちゃんと使えないとアプリケーション書けない。
Ports
JSとつなぐ仕組み。localStorage使いたいけどElm側から扱えないじゃんというような問題があって、そういうときはこの仕組みを使ってJSとつなぐ。
HTML見づらい問題
HTMLも関数で記述するので最初は見づらかったけどもう慣れた感がある。
モジュール分割
こうするべきというのがよくわかってない。コンポーネント分けについては以下のブログ記事を何度も読み返してる。
雑感
正直Elmを触りだしたのは半分冗談というか、社内LTネタになるかなくらいの気持ちだったんだけど、触り続けてるともうなんかJSとかTS書くよりこちらをやっていたほうが楽しいんじゃないかみたいな気持ちまで芽生えてきた。この謎の良さをもう少しちゃんと言語化できるようになるくらいまでは触り続けていきたい。
ElmでSPAの練習
NavigationとUrlParserのドキュメント見ながらこういうのを書いた。これでいいのだろうか。
仕事メモの取り方
仕事が遅れて気持ち的に辛い日々が続いている。どうにかしたいと思いながら過ごしていて、そんな中で学びもあった。それがメモの取り方。
仕事が遅れるとつらい。そして何が原因なのかわからないと無限につらい。なのでメモを取るようにした、という話。
改良しながらやっていきたい。
メモの取り方
- まず日付のページを作って、その日のタスクを書いておく
- 出勤してデスクについたら時間をそのときの時間を書いて仕事開始
- 違うタスクに着手する時に時間をメモする
というルールで、できたメモ(を社外に公開しても差し支えないように具体的な名前をすべてxxx
に改変したもの)がこちら。
# 2018/07/20 昨日:[[2018/07/19]] ## 仕事 - 11:00〜11:30 - 雑談とか - 11:30〜12:00 - [ ] xxx - [x] xxxのあたり修正 - 12:00〜12:30 - レビュー - 12:30〜12:44 - MTG - 12:44〜13:11 - レビュー - xxx - 直す - 13:11〜14:40 - [ ] xxx - あとなんだっけ - xxx画面の方だ - もうでかいし別PRにするか - これできたら昼飯いこう - 14:40〜15:00 昼飯 - 15:00〜16:00 - エンジニアMTG - 16:00〜16:55 - 雑談 - レビュー修正 - xxxしてない件 - xxxの件 - 17:00〜18:20 - MTG - 雑談 - 18:20〜19:00 - レビュー修正 - [x] xxxしてない件 - [x] 実装 - [x] テスト - [x] attr_readerの件 - [ ] `xxx` の件 - [ ] xxxカラムの件 - [ ] xxxの型の件 - なんかテストが落ち始めた ruby NoMethodError: undefined method `[]' for #<Tempfile:/tmp/xxx.png> - [x] xxxの型の件 - 19:00〜19:10 - Standup MTG - 19:10〜20:10 - デザイン相談とか雑談とか - 20:10〜21:08 - レビュー修正 - [x] xxxしてない件 - [x] 実装 - [x] テスト - [x] xxxの件 - [x] xxxカラムの件 - [x] xxxの件 - [x] xxxの件 - なんかテストが落ち始めた - 本物の`ActionDispatch::Http::UploadedFile`使ってないので `xxx`のところで落ちていた - 21:08〜22:00 - [ ] xxxをxxx画面に設置 - [ ] xxxにはxxxできないようにする - [ ] xxxフィルタ - [ ] xxx - [ ] xxx 明日 [[2018/07/22]] #private/日記
(念のため書いておくと、いつもこんな残業してるわけじゃない。昨日は残ってしまった。なるべく8時間で帰りたい)
これの何が嬉しいか
こうしておけばあとで振り返りができる。実際やってみて気づいたけど、試行錯誤や手戻りによって時間がかかること、雑談に思いの外時間を使っていたり、あとこの日は飯の時間が取れなかったのでおにぎり2つで済ました結果20時ごろからとてもイライラしていた。アホだ。
Githubやタスク管理ツール上でもなるべく小さい単位でタスクを管理・消化していけたらいいのだけど、それが最初から完璧にできたら苦労しないわけで、実際はやりながら「あれもやらないと、これも」みたいなことになる。「なんかPull Rrequestがでかくなってしまった」みたいな振り返りではなく、具体的に何をしたかを残しておくことで、膨らんだ部分を認識できる。次回からの見積もりの精度をあげたり、効率を上げるための仕組みづくりの必要性を感じたりできるかもしれない。
こういったことをいちいちメモしないでも覚えておけるという人はたくさんいると思う。しかし自分のように頭が悪めの人間はこういう工夫をしていかないとつらいことになるのでやっていきたい。
仕事遅い問題
前も書いたなこのお題…。
自分の仕事が遅くて仕方ないので、時間とやってることのメモを細かくとるようにしたら、かなり些細なところで長時間つまづいてるのがわかる感じになった。たとえばこういうやつ。
https://twitter.com/gaaamii/status/1019201848014602240
https://twitter.com/gaaamii/status/1019561987510898688
初めからドキュメント読めよって感じなんだけど、つまづいてる時はそのライブラリの使い方が原因ってことに気づいてないのでどうしたもんかという感じ。
自分はときどき、疲れてると特に、何となくで動かして挙動見がちなので、何を確認するのかを常に明確にして行動する必要がありそう。あとはエディタの設定やらwebpackのビルド時間とか地味に効きそうな環境改善も必要そう。
アプレンティスシップパターンを読み返した
前に買って本棚にあったんだけど、今読むとなおさら良い本だなと感じる。スキル不足やらキャリアに不安を感じていて、どうしたもんかと頭を抱えている自分のような人にオススメしていきたい。エモい。
この本には、見習いエンジニアにはたいていこういう問題があり、それにはこういう解決策があるというパターンがたくさん載ってる。全てが一対一できれいに解決できるように書かれているわけではなく、たとえば無知をさらすことと、無知と向き合うことのバランスについて触れられていたりして、そうだよな〜難しい〜と実感とともに読めて楽しい。
技芸を身に付けるにはチームの中で1番下手くそになるような環境に入るとよいというようなことも書かれている。そしてそうしたチームの中で、下手くそであるがためにうまく貢献できないときにはどうすりゃいいんだという問題についても、解決策が書かれていたりする。それは学習して成長していることを示したり、細かい面倒なタスクを引き受けることだったりする。
この本を読んで、結局のところ、これだけやれば明日から天才プログラマーになれるというような近道はないし、成長する上でつらいことはあるよなと改めて認識した。自分の好きなことのみ追求する芸術家や専門家ではなく、お客を喜ばせることのできる職人になるには、新しいことを学習したり失敗したりしつつ不安と向き合いながら、成長していく必要がある。
あと、何事もいきなり負荷をかけすぎると壊れる危険がある。そういう意味でも、短期間で急成長とかではなく、長い道のりをじっくりやっていくぞという気持ちにさせてくれて本当に良い本だなと感じた。