2021年のふりかえり
今年も気がついたら年の瀬になっていました。
もう四捨五入で三十路になる圏内に入ってしまいましたね。年々時間の流れが早くなってきている…。結婚もしたし、このまま中年まっしぐらでいつ若手と呼ばれなくなるのかと内心ソワソワしてます。
せっかくの年末なので、今年1年をふりかえっていきます。
仕事について
ちょうど年始の時期に今のプロジェクトにアサインされました。
何だかんだはじめてのプロジェクト異動でしたし、AWSを仕事で触るのもはじめてだったので、とても学びが多かったです。
（がんばるぞ！！と意気込んでいた矢先に前プロジェクトで問題が起きて2週間ほど古巣に呼び戻されたんですけどね……）
新しいプロジェクトだと実力勝負感があっていいですよね。
そんな中でも、いくつか特に印象に残ったことをつらつらと書いていきます。
AWS
仕事でAWSを触るのははじめてでしたが、プライベートでEC2とか触っていたので割とスムーズに慣れました。
Dockerはサクッと環境を作るのが好きで個人開発するときはもっぱらコンテナ作っていたのが活きて、FargateやCodeシリーズもある程度使いこなせるようになりました。
今年はECS Execがリリースされたのがうれしいポイントでした。コンテナ内に潜り込めるのは調査や検証に大いに役に立ちましたし、Fargateのメタデータエンドポイントをお試しするのもやりやすくなりました。
自分が担当した案件ではCloudFormationを活用できたのも良かったポイントです。インフラはメインの担当ではないですがCFnで構成案作って引き継いだとき、インフラ構成の意図をコメントに残せたり複数環境構築することの容易さのメリットを実感できました。「インフラは職人技で作った人以外わからない……」となることを防げるので、これからもIaCを推していきたいですね。
性能テスト
性能って難しいですよね。とても広い知識の幅が求められるので。
計算量やEC2のEBS帯域幅、Oracleの仕組みやメモリ管理、ガーベジコレクションなどなど調べながら性能評価をしていました。
メモリの線形増加が発生するトラブルもありましたが、JavaのFlightRecorderの確認やコンテナに潜り込んでRSS/PSSの確認、Javaの内部実装の確認やメモリアロケータの変更による検証など、割と各要素の奥深くまで潜れる機会でもあったので、自分の中の知識の点と点を繋ぐいい機会だったかなと今となっては思います。
大半の開発の現場には「アプリ」「インフラ」とかの組織の構造は少なからずあるかと思いますが、コンポーネントチームになっている場合では性能トラブルのように「アプリ」「インフラ」などの構造の積み重ねに対する課題を解決する速度が鈍化してしまいます。（代わりに個々の組織構造の単位の中で生じるトラブルの解決スピードは早かったりはしますが）
そういったときにチームの機能の境界を超えて自分で調べたり、一緒に議論をすることでスムーズに解決できたりするので、お互い共通言語で話せて越境することの有意義さを改めて感じました。本当はクロスファンクショナルチームを目指すのがいいんだろうなあ。
この記事もとても参考になりました。
道の真ん中をきれいにするプロジェクトマネジメント～イケてるチームになるための10原則～ - Qiita
スクラムマスター
気がついたらスクラムマスターをやっていました。
無免許なので、そろそろ資格を取ろうかな……。
はじめてのスクラム経験でしたが、まだチームもクライアントもウォーターフォール開発の慣習から抜けきれておらず、モヤモヤした毎日を過ごしています。
ウォーターフォールであれば包括的なドキュメントを作ってそれに沿って制作していきますが、慣れていないスクラムではクライアントが今までの経験則に従って包括的なドキュメントを要求してくることもあります。本来届けたい価値は動くソフトウェアが提供するものであり、動かないドキュメントは必要最小限に留めたいのですが、なかなか脱却ができません。
開発メンバーも精一杯応じようとオーバーワークでカバーしてしまおうとしたりしてしまいます。
また、WBSとガントチャートによって得られる中長期のスケジュールの完全性と同様のものを求めてしまうとせっかくのバックログと優先順位による柔軟なコントロールを放棄してしまうことになりますが、ある程度の計画は必要なので難しい領域だと感じています。
理解が十分ではないとスクラムマスターが従来のリーダーのように「責任者」という扱いにされてしまいがちなところも、意識を変えたいと思いつつなかなか変容に至っていないところです。
開発チームをサポートすることに責任を持って、よりスクラムチームをよくしていきたいですね。
勉強会
gitや性能の考え方など、できる範囲で開発メンバーに興味を持ってもらおうと勉強会を何回か開催することができました。
なかなか勉強会って最初の一歩がハードルが高いんですよね。知ってる知識かもしれないし、興味のない話かもしれない。そもそもみんなの時間をもらってまでやることじゃないかもしれない。そう思って中々最初の一歩が踏み出しづらかったこともあります。
ですが、後輩くんが勉強会やりたい！と言ってくれて動機を作ってくれたので、不定期ではありますがネタ候補の中から投票数が多かったものを勉強会で話したりするようになりました。スクラムの障害にナレッジに関するものがあると感じた場合には、そのナレッジに特化した勉強会にすることもあります。
案外メンバーからの反応もよく、他のプロジェクトでもやらないかと言ってくれたりするので、発表者冥利に尽きますね。
こういう機会を作る雰囲気を作ってくれた後輩くんには感謝です。
家庭について
いろいろとありましたね。いままで忙しさを理由に全然親の顔を見に行っていなかったのですが、気がついたらカオスな状況になっていて毎週後始末のために片道2〜3時間で往復していました。
諸々の処分費用も100万は超えましたね……。貯蓄って大事なんだなぁ()
あと、結婚して半年が過ぎました。いい意味で結婚する前と変わらず、気楽に幸せに過ごせています。
結婚した当日、星野源さんと新垣結衣さんの結婚発表があったのでネタツイっぽくなっちゃいました。
結婚した
— なずな🌱 (@akaa07_pg) 2021年5月19日
読んでよかった本
カイゼン・ジャーニー
「スクラムマスターやらない？」と言われて急ぎアジャイル開発とスクラムを勉強するときに一番最初に読んだ本でした。
一人からはじめる改善と、越境するというのが印象に残っていて、スクラム開発をはじめてやる人にはおすすめしている一冊です。
エンタープライズアジャイル開発実践ガイド
スクラムで開発を進めていく中、いろいろ教科書通りに進められないなと思ったときに手に取った本でしたが、「あれ、これうちの現場見てるの？？」というレベルでドンピシャな指摘があったりして、読んでいて楽しくなる一冊でした。少しずつ理想形に近づける、まさにガイドとして活用しています。
Software Design
定期購読はじめました。
最初は2020年12月号のAWS特集がきっかけでしたが、「チーム開発の視点が変わる アジャイル開発の新常識」や、「UNIXテキスト処理の極意」などのシリーズも面白く、毎号読んでチームメンバーに布教してます。
買ってよかったもの
Jabra Elite 85t
前のBluetoothイヤホンがご臨終したので、はじめて完全ワイヤレスイヤホンを試してみました。
連続再生時間が若干足りない気がしましたが、使ってみたらそんな心配はなく普通に使えています。充電ケースすげー
外音取り込みは結構優秀ですね。SONYくんとどちらにしようか悩みましたが、物理ボタンのほうが誤操作しなさそうだと思ってJabraくんにしました。そのうちSONYくんも試してみたい。
Oculus Quest 2
なんとなく128GBモデルを買ったはいいものの、あまり活用できてないです。
でもたまに映画を見ると大画面でごろ寝しながら見れるので没入感が良いですね。
あとホーム画面が落ち着くのでぼーっとしたりもします。
さいごに
今年もいろんな方にお世話になりました。
来年もよろしくおねがいします。
資格勉強サボってたのでやらなきゃ
2020年の振り返り
2020年の振り返り
仕事
5月くらいまではずっと去年からやっていた大きめの案件の業務リーダーをやっていて、無事終わってクライアントからも評価された。
長期間の案件を責任をもって通してやるというのは今まで経験がなかったので、システムのインフラや方式などの知識も身につけるいい機会だったと思う。
（今振り返ると、いわゆる若手向けのチャレンジ枠扱いだったのかなと思ったり）
その案件で実現した内容については社内で論文を書いたりもしたけれども、細かく書きすぎるとバレるので割愛。
それが終わってからは運用保守リーダーを任され、課題対処やトラブル対応（たまに提案や見積など）をこなす毎日だった。
所謂24365対応のシステムなので、夜間・休日に電話が来ることも幾度かあり、最初は気が休まらなかったけれども次第になれると「ああ、またか」みたいになるので慣れは怖いなと思う。
担当プロジェクトは運用保守チームへアプリケーション・インフラ問わずに問い合わせが来るので、直前の案件でインフラ知識が少しついていたのは奏功だった。
12月になってからは異動の話が上がり、引継ぎネタを整えたり教育したりと忙しかった。
引継ぎは自分の中のあるべきリーダー像を整理するきっかけにもなったので、いつかLTのネタにでもするかな。
前から改善系のタスクを勝手に作ってコツコツ活動してて、1年である程度進められた。 - リモートワークに向けた整備（VC導入やルールの整備だったり） - テストコードの布教に向けてライブラリの開発 - 改善チームを作ってテストコード導入のPoC - Redmineを導入してExcelタスク管理脱却に向けて準備
特にテストコードのところはチームメンバーにも楽しいと思ってもらえてるようだし、取り組んでよかったな。
レガシーなプロジェクトを少しでも良くしていきたい。（プロジェクト異動するけど要請もあり見続ける予定）
勉強
忙しさを言い訳に全然できなかった。たまに本を読むくらいで、資格勉強とかは全然できなかったな。
カフェに行って勉強するスタイルだったけど、外出自粛等で全く行かなくなり、つられて勉強の時間も減った。
勉強がてら過去に自分が作ったものをリファクタリングしたりしてるけど、ファット過ぎて全然終わってない。誰だこのコード書いたやつ。
まずは勉強する方法を勉強したり、習慣化する工夫だったりしたほうがいいと思い始めた（n回目）。
あとブログも何だかんだ書かなくなってたな。
来年に向けて
- AWS認定アソシエイトレベル合格したい。
- 情報処理安全確保支援士の勉強再開しておきたい。
#PHPerKaigi 2020参加レポ day2
PHPerKaigi2020 day2（本編2日目）に参戦してきました。
phperkaigi？
PHPerによるPHPerのためのお祭りです。
PHPerKaigi 2020
聞いたトーク
- 自作して理解するxUnit
- マスターデータの管理運用と実装について
- マスタデータはデータベース管理＋管理画面で実装することが多い
- 都道府県名表示するだけでわざわざDBにつなぐのはめんどくさいしHTTP通信するのもめんどい
- 簡単に変更できて、管理画面を作る必要がなくて、エンジニア以外でも更新できるのがあるんですよ、Excelっていうんですけどね
- ExcelはJOINができるんですよ…VLOOKUPっていうんですけどね
- 異常なデータの混入はテストで弾く。データのためのテストも有効なアプローチ
- 12万件のレコードを吐き出したマスタファイルはメモリを使うけどOPcacheがあるから2回目はメモリの使用量は減る
- 「モデリング上のベストプラクティス」≠「運用上のベストプラクティス」
- 良いモデルを作っても「わかりづらい」と言われることがある
- 運用シーンを考えながらツールの選定や要否を考える
- PHPerがこれから「型」とお付き合いしていくために
- 型システムは元は数学とかで用いられてきた型理論という分野
- 型推論はプログラムのふるまいを推論するためのツール、効率よく計算するなどの目的
- 型システムでエラー検知や安全性を高めたり効率を高めることができる
- データ構造の不整合を許容しないので、コンパイラから見てきれいなコードを維持しないといけない
- 「安全」の定義がまちまち（方安全やメモリ安全などいろいろある）
- 柔軟性とはトレードオフになりがち
- 静的と動的に優劣はない、その場その場の有利不利はあるが双方に越えられない壁はある
- PHPのタイプヒンティングで性能劣化するのは過去の話、PHP7以降ではむしろ性能があがる
- PHPが型を手に入れると後方互換性との兼ね合いが心配になる
- まずはPHPDocなどで型を書いていこう
- クリーンな実装を目指して
PHPerチャレンジ
PHPerたちの戦い PHPerチャレンジ
最終戦績は 64,250ptで6位でした。
最終日は大分取りこぼしやコードゴルフで苦戦して、ランキングダウンしました。
正直凄い疲れた。でも楽しかった
アンカンファレンス ゲリラLT
ういろうさんとおかしょいさんの作ってくれた流れにのって、オフショア開発の話をしたりしてました。
オフショア開発ってなかなかイメージが付きにくい話でしたが、最後に落ちをとれたので満足です。
そのうち真面目に資料作って話してもいい気がする。
全体を通しての感想
PHPerKaigiに参加したのは2回目ですが、オープニングの「すべてのみなさんの同窓会でありたい」というのがとても響きました。
去年全然右も左もわからない状況で参加して初めてお話しした方も多かった中、1年後またお会いして「お久しぶりです」と言ってお話を出来る機会というのは中々貴重だなと思っています。
またぜひ来年もまた参加したいですね。
また、今回は初めてLTに挑戦しました。以降お声がけいただけたり、お話しすることができてとてもうれしかったです。
今後も機会とネタがあればアウトプットしていきたいと思います。ネタ作りしないとですね。
今回の早期チケット購入特典だった、トレーディングカードはいろんな人と話すきっかけにもなりますし、記念品にもなって良いアイデアだなと思いました。
長谷川さんのアイデア、まつぴーさんのデザイン、どちらも素晴らしかったです！
ありがとうございました！
スタッフ、スポンサー、スピーカー、参加者の皆様、楽しい時間をありがとうございました！ 来年もまたお会いしましょう！！
#PHPerKaigi 2020参加レポ day1
PHPerKaigi2020 day1（本編1日目）に参戦してきました。
phperkaigi？
PHPerによるPHPerのためのお祭りです。
PHPerKaigi 2020
聞いたトーク
- E2Eテストに向き合う
- 自動化されたE2Eテストはテスティングピラミッドの頂点ではない
- E2Eテストはなんで失敗したのかわかりにくいから失敗すると原因を突き止めるに時間がかかる
- E2Eはコストが高いので最小限に抑えた方が良い
- パフォーマンスの観点を忘れずに
- ブラウザ自動化ソリューション Puppeteer
- 便利
- 軽い
- ブラウザ側に判定ロジックを持っているので壊れづらい
- PHPとEventSauceで始めるイベントソーシングアプリケーション
- エキサイトの大改造を大解剖！
- エンジニアが働きやすくなるように制度を改革した
- 給与テーブルを変更して「ここまでしか上がらないのか」と思わせないようにしてモチベーションが下がらないようにした
- 週3で働ける正社員「サンシャイン制度」などを検討中
- 働きやすい環境を整えてから採用にアクセルを踏むようにしたいと考えている
- AWS Lambda にCustom RuntimeでPHPを導入したシステムに改修を加えてUT導入まで行った話
- カンファレンス初心者が全国行脚を始め、登壇するまで
- カンファレンス行ってみたら楽しかった
- スタッフやるのも楽しい
- 遠征するのも楽しい
- 懇親会ぼっちはあるあるだから気にしない
- Laravelから始めるテスト駆動開発
- 機能追加でテストケースが増加
- バグで霊圧が消えた
- かけないところはE2Eテストでカバー
- 小さく始めていく
- 「明日からフロントもよろしく！」 と言われたとき備える Atom Design でのフロントエンド設計
- Atomic Designでコンポーネントの責務を分ける
- UIはパーツの集合体
- 開発保守がやりやすい
- テストが書きやすい
- 分離の基準を決めるのは原著にはあまり書かれていないので自分自身で
PHPerチャレンジ
PHPerたちの戦い PHPerチャレンジ
本日の戦績は42,050pt, 現在2位。
トップのちゃちいさんと差が中々埋められない….。成瀬さんの攻略法を参考にがんばります
ルーキーズLT登壇しました。
めちゃくちゃ緊張しました。
[PHPerKaigi2020]Laravelで家電を操作してみよう
何人かにお声かけていただいて、おもしろかったと言っていただけてうれしいです。
そのうちobnizネタでQiitaかブログでも書こうかな…。
明日もがんばりましょう！
PHPerKaigi 2020参加レポ day0
PHPerKaigi2020 day0（前夜祭）に参戦してきました。
phperkaigi？
PHPerによるPHPerのためのお祭りです。
PHPerKaigi 2020
聞いたトーク
- Deep Module in PHP
- モジュールの複雑さ≒プログラムの複雑さ
- Deep Moduleはインターフェイスのコストが小さいが機能のベネフィットが大きい
- Shallow Moduleはインターフェースのコストが大きいが機能のベネフィットが小さい（隠蔽しきれていないなど）
- なんでもかんでもメソッド化するのもメソッド化するコストと比較したとき良くないことがある
- マルチパラダイムモデリング 〜異なるモデリングパラダイムから見るモデリングの勘所〜
- Inside SWOOLE：非同期処理はどのようにして動くのか
- swooleはタスクの切り替えにアセンブリを使ってる
- 一見魔法のように見えても一つ一つ辿っていけば理解できる
PHPerチャレンジ
今年もあります、PHPerたちの戦い PHPerチャレンジ
本日の戦績は2900pt, まだまだ取り損ねているポイントが多いので、明日頑張りたいです。
ルーキーズLT登壇します
今年は、ルーキーズLTにチャレンジします！！
ネタはPHPer界隈じゃあまり聞かないIoT系なので、ぜひ聞きに来てください！
2019年の振り返り
今年はいろいろ自分にとって初めてのことにチャレンジした年になりました。
参加したイベント
Laravel JP Conference 2019
人生で2回目のカンファレンス参加になりました。
一度目のカンファレンスよりも規模が大きく、はじめて懇親会に参加したカンファレンスでした。当時の私は社内でちやほやされているだけのエンジニアで、それとなくしか開発というものに取り組めてしかいませんでした。
そんな中動向を知っておこうと思って参加してみれば、そこには開発を追及する人たちがたくさんいて、その方々の熱量、そして視点を初めて知って衝撃を受けた覚えがあります。
ういろうさんやまつぴーさん、そーだいさんなど様々なきっかけをくれる人たちと出会うこともでき、私の中ではとても印象に残っているカンファレンスです。
2020も参加します！PHPerKaigi 2019
ひたすらトークン集めに走り初日はいい感じの上位にいれたのですが、2日目は寝坊したことで上位争いから脱落しました。
徳丸先生からの挑戦状という企画とセキュリティ関連のトークなどがあった影響でセキュリティに対しての関心が強まり、今では情報処理安全確保支援士取得に向けて勉強を進めています。 トークンを探し回る中、いろんな方とお話しさせていただいたのもいい思い出です。
2020も参加させていただき、ルーキーズLT枠でお話しさせていただく予定です！
Laravelで家電を操作してみよう by なずな | トーク | PHPerKaigi 2020大改修！劇的ビフォーアフター
レガシーコードというか、クソコードを量産してきた私にとっては非常に刺さる内容ばかりでした。
自分の関わっているプロダクトに対してもリファクタリングしたいと思いは以前からあったのですが、方向性だったり進め方だったり不安な中にいたので、プランを整理するきっかけにもなりました。
新原さんのライブコーディングを見ていたらとてもPhpStormが欲しくなったのですが、ホビーユーザだしなあ…と思い悩んでいるところ。 はじめて吉田あひるさんにお会いして、フリー素材通りの方で安心しました。PHP Conference 2019
規模も歴史も今まで参加したカンファレンスの中で最も大きく、知っている方も多くいてワクワクして参加した覚えがあります。
PHPerKaigiとかで頂いていた名札をもっていかなかったことは今でも後悔しています。 夜は終電逃すまで飲んでいたのであまり記憶にありません。。。
仕事について
上期と下期でやっている仕事ががらりと変わって色々苦労はしましたが、評価は上々でした。
上期では去年から引き続きオフショア開発チームのリーダーとしてわちゃわちゃやっていました。
人の育成、プロセスの改善、仕事の管理などマネジメント面で学ぶことは非常に大きかったと思います。
（残念ながら私が離れたのち色々な事情でそのチームは解散となりました……）
下期では新規案件のアプリ系を担当するチームのリーダーとなりましたが、ネットワーク等の基盤系、案件の進め方など今までとは違った知識が必要で、手間取っていました。
また、既存案件から離れてしまったのでリファクタリングなどやりづらい立場になりましたが、準備だけ進める分にはポジションは関係ないと思ってライブラリの整備などは進めています。
勉強について
8月上旬まで英語の勉強は基礎復習を進め、8月中旬からは情報処理安全確保支援士に集中して取り組んでいました。
結果として情報処理安全確保支援士は午後Ⅱが49点で脱落でした。
高度の集中力維持に不安があったため午後Ⅰ・Ⅱぶっ通しの過去問練習をメインにしましたが、理解度の低い箇所への対策が疎かになってしまったので、次はちゃんと受かれるよう対策していきたいと思います。
基本情報も応用情報も1回目が微妙なラインで落ちて2回目で合格という流れで来たので、今回もそのパターンに収められるようにしていこうかな。
英語の勉強は、オフショアチームを抜けたことであまり重要度は高くなくなってしまったのだけれど、いずれにせよ今後必要になる機会はあるので引き続き取り組んでいきたいです。
読書
マネジメントに思い悩んでいたのでその系統の本を漁っていました。詳細は割愛。
来年は技術書をもっと読んでいきたいと思います。
アウトプット
ブログは始めてみたものの、仕事の忙しさを理由に続けない日が続いてしまったことで断絶していました。
LTなどは全くなく、来年のPHPerKaigiで初めて勇気を出してやってみます。今年は元ネタをそろえ中…。
来年の抱負
- LTとかアウトプットについてチャレンジいろいろやってみる
- 知り得たことなどを出来るだけブログに書いてみる
- 健康診断で再検査なし（今年はやらかしたので）
- 自分の周りのものをリファクタリングする
- 情報処理安全確保支援士合格する
- 英語もそこそこ頑張る（参考書2冊は終わらせたい…）
「PHPカンファレンス2019」に行ってきました #phpcon #phpcon2019
どんなイベント？
今年で20回目となる、国内最大規模のPHPのテックカンファレンスです。
PHP Conference Japan 2019 - #phpcon
PHP Conference Japan - YouTube
セッション
PHP における並列処理と非同期処理入門（@m3m0r7）
PHP における並列処理と非同期処理入門 - Speaker Deck
- 趣味はバイナリファイルを読むこと。
- 並行処理 !== 並列処理
- マルチスレッド !== マルチプロセス
- PHPでの非同期処理 !== できない
- 並行処理は小さいタスクに分割してそれぞれ処理するが割り込みが入るから順序保証はされない
- 並列処理はコアにタスクを割り振っていき、並列処理の上に成り立っている。
- スレッドはプロセスの一つであり、スレッドはプロセスではない。
- 非同期処理はAの処理を実行中にBの処理を実行してもAの処理を止めない。実装は並列処理でも並行処理でも良い。
- PHPで並列処理を実装するにはpcntlやpthreadsなどがある。
- pcntlはプロセスフォーク
- pthreadsはスレッドフォーク
Laravelにはジョブキューがあり、DBレコードを介して別プロセスで非同期処理を実現しているのでそれを使ったことはあるけれど、それ以外の非同期処理はやったことがなかったので参考になりました。
今のところ単一リクエスト内で非同期処理を行いたいケースが今のところないので、必要になったらまた詳しく調べたいと思います。
思想と理想の果てに -- クリーンアーキテクチャのWEBフレームワークを作ろう（@nrslib）
[PHP Conference 2019]思想と理想の果てに――クリーンアーキテクチャのWEBフレームワークを作ろう │ nrslib
- 層は3つでも4つでもいい
- Controllerはアプリケーションが求めるデータに入力を変換する。
- ゲームのコントローラが電気信号で本体に入力データを送るのと同じ。
- 処理（InputPort）や出力（OutputPort）にinterfaceを使うことで、差し替えることができるからモックを刺して主導権をビジネスロジック側に出来る。
- 理想を追い求めると代償がある。
- 現代のMVC2 WebフレームワークだとOutputPortを使わない。
- 層の数に比例してclass/interfaceが多くなる。（めんどくさい）
- 理想を守るためにフレームワークを作ろう（！？）
- 情報はアウトプットする人のところに集まってくる。
- my favorite 車輪
- 10年前は早く開発できることが重要視していたけど、フレームワークは変わっていく。
- 「誰にも思い描く夢がある、その思想・理想を是非とも実現してほしい」
- 「思っていることがあるならやってみてほしい」
- 「世界をひっくり返すのはだれでもできる」
- 「次に世界をひっくりかえすのはみなさんです」
理想を追い求めるためのその熱量というものの凄さを垣間見ました。
一人で趣味でやっているのであれば理想を愚直に追い求めること自体は出来ますが、チーム開発だったりプロダクションだったりでは理想を追い求める代償が大きく、中途半端になって余計メンテしづらくなったり悲しい結果になるのだと思います。（今の現場でまれによく感じる）
それに対してプラグインだったり開発フレームワークだったりで「理想を追い求めた方が楽になる」という状況を作るのは有効なアプローチですよね。
5ヶ月でカバレッジを20%から90%にあげた話（@strtyuu）
5ヶ月でカバレッジを20%から90%にあげた話 - Speaker Deck
- 注：カバレッジは必ずしも品質に比例するわけではない
- 当時カバレッジ20%くらいのときに、存在しない未来の話で応募した。
- 採択されて「やらなきゃ」と追い込まれ、3ヶ月で18％から90%にした。（すごい）
- カバレッジを上げたかった理由
- 気軽にコードを修正したい。
- 依存が一方向だったら修正も楽だけど、循環すると難しい。
- フレームワークレイヤを改善したいけど影響が大きいからテストをしっかりとしたい。
- コードリーディングのコストを下げたい。
- 10年も続いてれば歴史的経緯のあるコードがある。小さな後悔が大きな後悔になるには十分な時間。
- 続けば続くほど関わる人が増えていくのでリーディングとかのコストに時間を払う人が多くなる。
- そのコストを下げた方がエンジニアにとって幸せなのではないだろうか。
- 気軽にコードを修正したい。
- 進め方を決めてからやった。
- テスト環境を整備した。
- 簡単にデータを作る仕組みを用意する。
- 完全コンストラクタなクラスでもActiveRecordでもどちらでも対応できるようにしないとしんどい。
- 状態に名前を付けてその状態を簡単に作れるようにしたい。
- 簡単に結合テストできる仕組みを用意する。
- テストの実行速度を早くする。
- めちゃくちゃPRを出すので早くCIが回ってくれた方がうれしい。
- pcovを採用。
- グローバルヘルパをモック可能にする。
- 簡単にデータを作る仕組みを用意する。
- 実際カバレッジを90%まであげてみて、それに見合った成果が出るかはわからない。
- でもPHP7.4にあげてみたら手動テストでは見つからなそうなバグ/非互換を発見することができた。
- カバレッジをあげることでリファクタリングをする土台が出来上がったので、ここからがスタート。
状態の抽象化ってテストするときには結構大事だと思っていて、状態の具体的なデータ状態に変更があった時にテストクラスへの影響が抑えられる仕掛けがあるとテストコードがちゃんとメンテされやすくなるのかなと思います。
カバレッジをあげるコストって後にならないと見合うかどうかはわからないので結構不安になるというか、他のことの方が優先度高いのでは…？って思うときはありますが、言語/パッケージのバージョンアップなど、欲しいときにカバレッジがちゃんとあるというのは心理的安全性的な意味合いでもコツコツ進めるべきなんでしょうね。
ちょっと自分がやろうとしているテスト環境の整備に対しての意欲を盛り上げていただきました。焼肉食べたいです。
「CPUとは何か」をPHPで考える（@tomzoh）
「CPUとは何か」をPHPで考える / What is a CPU? - Speaker Deck
- 削った箇所の供養としてのマイクテストと映像テスト（前座）
- CPUは「プログラム実行環境」「エミュレート対象」「電気回路」からの視点で見ることができる。
- 「TD4」という4ビットCPUを題材にする。
- 「プログラム実行環境」の視点で見ると、マシン語プログラムの実行環境であり、プログラムを実行してくれる存在。
- 自分の使う機能のみの理解でOK
- 「エミュレート対象」の視点で見ると、エミュレータのCPU部分であり、対象CPU用に書かれたすべてのプログラムを動作させる存在。
- CPU仕様を完全に理解しなければならない。
- 「電気回路」の視点で見ると、クロックに従って状態遷移する回路としてCPU命令を表現した存在。
- 仕様と物理のパズルを読み解かなければならない。
- プログラムカウンタは静的回路を処理装置化する存在。
- CPU自作は面白いよ！
前座で論理回路の基礎理論を久々に思い出しました。懐かしい…。
CPUの基本原理は中々知る必要に迫られることはないけど、知ってみると面白いですね。
「プログラム実行環境」として見てみるとそんなに難しくないけれど、「電気回路」として見てみると途端に難しい存在になるんですよね、CPUって。
だけどCPU自作はちょっとハードル高い…。
久々にObnizとかArduino周りを触りたくなりました。
感想
会場についたら「ここまで人が多いものか」と予想よりも大きい規模にびっくりしました。
いろいろ聞きたいお話はありましたが、後日Youtubeで見させていただきます！（配信残ってるのありがたいです）
LT枠は上級者ぞろいでした…！
4分枠に変更となっていたにも関わらず、言いたいことを詰め込んで伝えきれるというのはすごいです。
言いたいことを最初の方に持ってくるというのは言い切れないことに対する保険として、自分がやるときは参考にさせていただきます 🙇
様々なスポンサー企業様の展示ブースではお菓子や飲み物だけではなくモバイルバッテリー、電子メモパッド、SIMケースまでいただいて「え…こんなにもらっていいの…？」と不安になるレベルで頂きましたが、ありがたく使わせていただきます！🙏
頂いたものリスト（順不同）
- モバイルバッテリー 株式会社GameWith様
- タオル GMOインターネット株式会社様
- ティッシュ 株式会社リブセンス様
- ボディーシート 株式会社カオナビ様
- JetBrains IDE ディスカウントクーポン 株式会社サムライズム様
- 温泉の素 Hamee株式会社様
- ラムネ 株式会社ホワイトプラス様
- SIMカードケース 株式会社メルカリ様
- 電子メモパッド 株式会社PRECS様
- 茶っとわーく（煎茶） Chatwork株式会社様
- くるみ最中 BASE様
- 飴 エキサイト株式会社様
- チョコ
また、お声がけいただいた皆様、ありがとうございました！
テストだったり、DDDだったりと関心毎についてお話させていただけたので、参考になりました。
また来年のぺちこんでお会いしましょう！
