Laravel.shibuya #2 を開催しました

Laravel.shibuya #2を開催しました!

当日、参加してくださった皆様ありがとうございました！

Laravel.shibuya #2 無事に終わりました！参加して下さった皆様ありがとうございました！👏
そして、会場と美味しいご飯とお酒を提供して頂いた株式会社オウケイウェイブさん、改めてありがとうございました！！！！🍻#laravelshibuya pic.twitter.com/5MqdclXTpD
— Futoshi Endo 🎮 (@Fendo181) June 20, 2019

laravel-shibuya.connpass.com

今回も会場は株式会社オウケイウェイヴさんに協力して頂き、美味しいお酒とご飯を提供して頂きました!

本当にありがとうございます!!

www.okwave.co.jp

世界中のビールが飲めるという、ビール好きにはたまらない福利厚生となっております！

やばい！！！111
今回も株式会社オウケイウェイブさんに豪華な飲食物の提供して頂いております！！😭🙏
ありがとうございます！！！#laravelshibuya pic.twitter.com/PzqpGakQ8J
— Futoshi Endo 🎮 (@Fendo181) June 20, 2019

IRTについて

よつば(D.Horiyama)さんがIRTの参加した際の記事をまとめて下さったので良ければこちらもご覧下さい。

wand-ta.hatenablog.com

僕の方は最初に「PHP相談会」でお話をしたテストコードについて少しだけ、"個人的"な想いを書いておこうと思います

1回目でテストコードの話が出て、その際にテストコードは「エンジニアの不安を解消してくれる」話と、テストコード自体が仕様になる話をしました。

これは過去のブログでも書いたのですが、t_wadaさんが翻訳/監訳された、「テスト駆動開発入門」に載っていた言葉で、「テスト駆動開発はプログラミング中の不安をコントロール手法です」と書いてあってそこから得ています。

テスト駆動開発はプログラミング中の不安をコントロール手法だ。ここでは「不安」は悪い意味で使っているのではない(我々は赤ちゃんではないからね)。「これは困難な問題なので、最初から全てを見通せるわけではない」という真っ当な感覚の事だ。もしも痛みが身体からの「止まれ」というサインならば不安は「気をつけろ」というサインだ。慎重になるのは良い事だが、不安には悪い効果もある。

www.fendo181.me

この説明が「なぜテストコードを学んだほうが良いのか?」に対する質問の回答として、正しいかはわからないですが、機能を追加する際に処理の流れをまずは考えて手を動かすと思うのですが、テストコードを書くと自分の頭の中で想像している抽象的な動きを、より具体的なコードにできる = 仕様として決まってきます。

この一連の流れが個人的に最もコード書いている時の安心を生むと思っていて、イメージとしては一気に橋を渡るのではなく、一歩一歩足元を確認して橋を渡っていくので、渡り終わる頃にはそれが仕様になっている感じです。

勿論あくまでも「テスト」なので、本番で動いてこその話ではあるのですが、本番で動かす前に実際の仕様が決まってくるので、「本番で動かしても大丈夫だ」という一定の安心は得られます。(それで本番で動かしてバグが見つかるとかよくあるのですが...)

なので、テストコードは学んだ方が良いと思っている派です。

ただ、「全てのプロジェクトで全部テストコードを書いているのか?」と問われると、これは違くて開発には当然リソースと期限がある為、「テストコードを書くべき所」と「目視で十分なので書く必要はない」という所が出てきて、そこの線引はまだできてないのが本音な所です。

いずれにせよ、TDDを学ぶことは今後のエンジニアにおけるスキルアップとして必要と思っている知識なので、もし興味があれば「テスト駆動開発」を一読する事をオススメ致します!

因みに最後の「付録C」がとても良いので、そちらも読んでみると良いです！

テスト駆動開発

作者: Kent Beck,和田卓人
出版社/メーカー: オーム社
発売日: 2017/10/14
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

Laravel.shibuya #2 の振り返り

ちょっとまだアンケートの集計が終わってないので、振り返りとしてはまだ早いと思うのですが、それでも「 Laravel.shibuya #2」は、やっていく中で改善点がたくさんある事に気づいていて「ここ、こうすれば良かったなぁ〜」という部分が多くありました。

Laravel.shibuya 初めて参加したけど、エンジニア歴別に名札の色別れてたりしてなるほどーーー！って思いました。ただあれもうちょっと有効活用できてたり、初心者が楽しめる企画になってれば良かったのかなーと。内輪感難しいよね。
— はま子 (@hamaco) June 20, 2019

IRT いい試みだとは思うけど、発言者が偏るのがなぁ、最初あんまり話さないようにしてたけど、けっきょく喋ってしまった…申し訳ない…
— (def me (atom nil)) (@nunulk) June 20, 2019

勿論 #1で見つかった改善点を修正して良くできた部分もあってそこは良かったなと思っているのですが、今回は「どうやったらIRT中に発言がしやすくなるのか?」、「どうやったら初心者の方が交流しやすくなるのか?」と言った本質的な課題がある事に気付きました。

そこを次回改善できるよう、個人的なKPT振り返りをしようと思います。

K

部屋をそれぞれ別けた事で、前回隣が盛り上がりすぎた際に聞こえづらくなる問題が改善できた。
テーマをSlidoで募集するようにしたので、前回のようなテーマ決めに時間をかけるのが減った
まとめる時間を作るようにしたので、片方に参加しなくても話をした内容が聞けるようになった。

P

IRT中はどうしても喋る方と喋らない方が出てきて偏ってしまう。
エンジニア歴別で色をつけて初心者の方と認識できるよう、名札にシールを貼って配慮しようとしたが、IRT中は名札が机の下に落ちてしまって見えないのであまり意味がなかった...
「どこまでのレベルに合わせて話せばよいのか?」がわからない。
まとめる作業は司会者側に負担が大きい

T(具体的なAction)

相談会を増やして、1つのテーブルに参加する人数を5~10人ぐらいにして、もう少し発言がしやすい環境にする。
まとめ役を募集する(参加費を無料にして)
色付きのネックホルダーにして視認性を上げる
IRT中に初心者の方に「どのテーマについて知りたいですか?」と声をかけて、その話題について話すように考慮する。

今後も、こんな感じに見つかった改善点を、1つ1つ直して良くして行こうと思うので、次回開催時にまた参加して頂ければ幸いです！

運営メンバーである僕や、@blue_goheimochi さんや、@strtyuu さんは皆「Laravel.shibuyaを良い勉強会にしたい！」という気持ちしかないので、見つかった改善点は直して、今後ともIRTの勉強会として良い学びを提供できるよう頑張ります🍻#laravelshibuya
— Futoshi Endo 🎮 (@Fendo181) June 20, 2019

おわり！