#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だったりと関心毎についてお話させていただけたので、参考になりました。
また来年のぺちこんでお会いしましょう！
「大改修！PHPレガシーコードビフォーアフター」に行ってきました
どんなイベント？
PHPer界隈のカンファレンスに参加したら一度はお世話になっているであろう「fortee」を題材に、PHPの匠による改善ビフォーアフターをお楽しみいただけるイベントです。
大改修！PHPレガシーコードビフォーアフター - connpass
セッション
メルカリ様セッション（@suzuki）
今回の会場はメルカリ様にご提供いただいており、更にドリンクまで提供いただきました！
森ビルは初で今後行くこともあまりないと思うので、レアな体験になりました…！
ありがとうございます！
- 価値を生み出しているレガシーコードを、「レジェンドコード」という。
- namespaceを使っていなかったり、Fat Controller/Modelだったりと負債があった。
- まずはテストがあったのでリファクタリングで対応していた。
- リファクタリングだけでは辛くなってきたのでマイクロサービス化に舵を切った。
- メルカリではマイクロサービスをテンプレート化することで簡単に立ち上げられるようになっている。
テストコードがあることの重要性っていうのがサービスが大規模になるにつれて効果を発揮していきますね。
テストコードがないと、「レジェンド」だからこそその生み出している価値を壊す可能性がある行為を取りづらくなってしまうので…。
独立したコアレイアパターンの適用（@shin1x1）
独立したコアレイヤパターンの適用 - fortee 編 - / fortee-meets-independent-core-layer-pattern - Speaker Deck
- Port&Adaptersは、USBのように刺さるものは何であっても大丈夫。
- 極力FWに依存しないようにコアの部分を独立させる。
- ただしFWに依存してもよいと自分で判断したなら依存させてもよい。(Carbonとか)
- PhpStormを使ったライブコーディング
- コントローラロジックをとりあえずそのままユースケースを切り出す。
- まずはユースケースに必要なものは引数で受け取り、Httpレスポンスに必要なものは戻り値にする。
- FWのExceptionは自分で定義しなおす。
- TestCaseもFWで拡張している基底クラスではなく素のPHPUnitを使うことでFW依存させなくする。
- Adapterはテスト用にテストコード内で無名クラスを作る方法もある。
- 「0 or 100」ではなく、漸進的にリファクタリングする。
- 適用する箇所を絞る。（副作用のある箇所だけなど）
PhpStormめちゃくちゃ便利そうで欲しくなりました。
単純なコンストラクタやGetterを作るのは人間のやる仕事じゃないというのはとてもわかりみが深いですね…。単純だけどミスりやすいっていうのもありますし。
PHP7.4のtyped propertyで会場が「おおーー！！」って盛り上がっていて面白かったです。
静的解析 （@tadsan）
「PHPプロジェクトに静的解析を新規導入する」 #phperkaigi｜tadsan｜pixivFANBOX
- 静的解析をすることでエラーとして顕在化していない「たまたま動いてるコード」の問題点を炙り出せる
- PHPStanならCIで差分を見れる。
- 「Phan Docker」で出てくるDockerImageは古いから使っちゃダメ。
- baselineを一度取って、その後に「これ以上増やさないでくれ」ということができる。
- issetの中などぱっと見エラーにならないところもある。
- 地道なものを地道に潰していくのが大切。
静的解析はやらねば…と思ってるけどまだやっていない。
「たまたま動いてるコード」の問題点を炙り出せるというのは、静的コンパイルが出来ないPHPで安全性をなるべく高めるためには必要だろうなと思う。
baselineを一度取って、その後に「これ以上増やさないでくれ」と制約をつけるのはあとから導入するときに周りの理解は得られやすそう。
Vaddyによる脆弱性分析（@cakephper）
- VAddyでは脆弱性診断対象サイトを登録して、ユーザがproxyを使った状態で当該サイトを巡回（クロール）することでシナリオを作成する。
- 自分で所有しているサイトのみ診断できる。海外ユーザがFacebookとかに診断かけようとしてるらしいけど、そういうのはNG。
- パラメータ毎にXSSやSQLインジェクションなどの検査を行う。
- forteeでは1件の脆弱性が見つかった。（本番は修正済み）
- ツールじゃ見つけにくい脆弱性（仕様なのか脆弱性なのか判断が必要なもの）もある。
- 認可の不備
- ログ出力不備
- 複雑な攻撃経路
- Mass Assignment
- 長谷川さん「僕も素人じゃないんでね」
脆弱性解析は、そういうツールがあるのは知っていたけど実際の利用イメージがなかったので参考になりました。
結構機械的な脆弱性検査って自分でやるにはコスパが悪く、結局試験項目としては上がらないものになりがち。
テストも人間が必要なところに関心を分離させて、ツールで見つけやすい脆弱性と見つけにくい脆弱性をそれぞれ分担を分けるのが良いんだろうなと思います。
レガシーなWebアプリケーションと向き合う（@blue_goheimochi）
- レガシーソフトウェア改善ガイドによれば、レガシーと言っても種類がある。
- レガシーコード
- レガシー基盤
- レガシーカルチャー
- レガシーコードへの対応はいくつかある。
- リファクタリング
- リアーキテクリング
- ビック・リライト
- 「レガシーさ」には、計測できるものとできないものがある。
- 計測できるレガシーさはコードの大きさや重複、循環的複雑度などがある。定量的に測れるのでアプリの健康診断的な感じ。
- 計測できないレガシーさは、
// ここのコードは変更しないことみたいなやつとか。 - コピペコードは必ずしも悪ではないが、phpcpdなどで検知したら目視確認をして判断する。
- 部分的にリファクタリングをしていく。一番重要なところを守るためにE2Eテストを書く。全部網羅するのはつらい。
コードの重複を検出したら、共通化していない理由とか他の人が判断できるようなコメントを書き残すとかがいいのかなと思いました。
コードを書いた人は「これは別の概念だからコードも別にして、重複してもやむなし」と考えていたのに、その思想が他の人に伝わらないと後で勝手にまとめられて事故ることも起きそうですよね。
コードの重複が可視化される弊害というか……。
ごへいもちさんはしずかなトーンで笑いを取っていくところがプロですね！
Forteeをバージョンアップしてみた（@yakitori009）
Forteeをバージョンアップしてみた - Speaker Deck
- 最初にバージョンアップ成功したか判断するためのユニットテスト/E2Eテストを作る。
- E2Eテストはコストがかかる。作って維持する覚悟があるか。
- まずはcomposer updateでマイナーバージョンを1つずつ上げていく→テストを動かす、というのを繰り返す。
- 自動アップデートツールは必ずしも簡単にアップデートできるというわけではない。まれによく事故る。
- PHPのバージョンアップの場合も同様にテストをしてアップデート結果を確認する。
- PHP7.4からcompactに未定義変数を渡すとE_NOTICEが出るようになったが、実は静的解析ですでに検出されていた。
- ランサーズのCM #採用やめよう で誤解されて採用しづらくなった。
滑らかなバージョンアップのためにはE2Eテストコードやらユニットテストやらないと確からしさは得られないから必要ですというのは再認識しました。
テストさえあれば一つずつ上げていけばどうにか出来るけど、テストがなければ上がったことの影響を一つ一つ手探りでやらなくちゃいけないのがつらいですよね…。（めちゃくちゃ心当たりがある）
compactってかなり事故起こりやすいですよね。
PHP7.4になって未定義変数の警告が出るようになったけど、それ以前は出なかったし、そもそも文字列で扱いにくいだとか……。
感想
最後の登壇者トークは、みなさんのトークスキルの高さが高く、参考になることがポンポンとでてきて面白かったです。
養殖物のコードよりも天然物のコード、例にするなら天然物の方が理解しやすいだとか、作ったからと言って無理して使い続ける必要はなくて、捨てるのも選択肢だとか。
次回開催の雰囲気もあったので、楽しみにしています！
余談
6階に喫煙所があると聞き、試しに特攻してみたのは私です。
一緒に行った方と「確か6階でしたよね？」「帰り18階って忘れないようにしないとですねー」みたいな話をしつつ、6階に到着。
降り立ってみれば左右にあからさまにロックがかかってそうなドアがあり、試しにドアノブをひねってみると開くようだった。
直感で「これ内側から開けられない扉なのでは？」と不安になり、同行してた他の方に一回ドアの外に出てもらい、外から開けられるか試したら開いたので安心してドアを通過した。
エレベーターホールから出てみると、右にはゲート。左にもゲート。道の先にはゲートしかなく、我々に進めない。
実は喫煙所に行くためにはビルカードが必要そうで、諦めて戻るかと思った矢先、さっきは開いたドアが開かない……。
さっき開いたのはドアを閉めてからロックされるまでの待機時間に被っていたらしく、エレベータも使えないため会場にも戻れないという詰んだ状態になったが、そこに救いの手を差し伸べてくださったのが警備員さんだった。
ちなみにエレベーターホールに戻れたとしても、エレベータ自体に認証機能があり戻れないのに変わりはなかったそうだ。 本当にありがとうございます🙏🙏
令和元年度 秋期 情報処理安全確保支援士 午前Ⅱ回答晒し
今日は令和元年度 秋期 情報処理安全確保支援士を受けてきたので、私の午前問題Ⅱの回答を晒します。
（午前Ⅰはまだ期限が残ってて免除できました）
回答内容と（間違ってるかもしれない）正答
問1
FIDO UAFについての問題です。
FIDOは生体認証をベースとした規格で、生体情報は認証サーバに送信しないため、「イ」が正解になると思われます。
「エ」と一瞬悩みましたが、指紋情報を直接サーバに送信しているのでNGです。
私の回答：イ
問2
サイドチャネル攻撃は物理特性を外部から調べて処理の内容を特定する攻撃手法です。
選択肢の中で物理的なものは電磁波のみなので、「イ」が正解になると思われます。
私の回答：イ
問3
VA（検証局）についての問題です。 VAはディジタル証明書の失効リスト（CRL）を管理している機関ですので、「ウ」が正解になると思われます。
私の回答：ウ
問4
よくでる過去問のXMLディジタル署名についての問題です。 正解は「ア」です。
私の回答：ア
問5
よく出る過去問のファイアウォールについての問題です。
正解は「ウ」です。
私の回答：ウ
問6
よく出る過去問のディジタル証明書の失効リスト（CRL）についての問題です。
正解は「エ」です。
私の回答：エ
問7
JIS Q 27014:2015（情報処理セキュリティガバナンス）についての問題です。
モニタとは経営陣が戦略的目的の達成を評価することを可能にするガバナンスプロセスを指すらしいので、「イ」が正解です。
JIS系の知識問題は苦手…。
私の回答：ウ（×）
問8
よく出る過去問のCRYPTRECについての問題です。
正解は「ウ」です。
私の回答：ウ
問9
情報システムの脆弱性評価についての問題です。
正解は「ア」です。
私の回答：ア
問10
BlueBorneについての問題です。
Bluetoothの脆弱性のいくつかを総称したものですので、正解は「ア」です。
関係ないけど「イ 感染したPCの画面の背景を青1色に表示させた～」っていうのめちゃくちゃブルースクリーンを連想した。
私の回答：ア
問11
よく出る過去問のCookieについての問題です。
CookieのSecure属性はhttps接続の場合のみCookieを送出するものですので、正解は「ウ」です。
私の回答：ウ
問12
よく出る過去問の電子メールの認証方法についての問題です。
正解は「ア」です。
正直DKIM自体を覚えてなくても名前からの連想と消去法でわかっちゃうやつ。
私の回答：ア
問13
マルチベクトル型DDoS攻撃についての問題です。
名前の通り、複数のベクトルで各OSI参照モデル層に攻撃をする手法ですので、正解は「イ」だと思われます。
私の回答：イ
問14
WebサイトにおけるSSL/TLSについての問題です。
常時SSL/TLS化することで得られる効果は暗号化であるため、正解は「エ」だと思われます。
私の回答：エ
問15
脆弱性攻撃ツールについての問題です。
複数のエクスプロイトコードをまとめたものがエクスプロイトキット（Exploit Kit）なので、正解は「ア」だと思われます。
私の回答：ア
問16
EAP-TLSについての問題です。
ディジタル署名を用いたクライアント・サーバの相互認証を行うので、正解は「ウ」です。
（若干問題文が過去問と変わってる？）
私の回答：ウ
問17
たまに出る過去問のSQLインジェクション対策についての問題です。
Webアプリケーションの実装で出来る対策はプレースホルダを利用することなので、正解は「エ」です。
私の回答：エ
問18
よく出る過去問のDNSSECについての問題です。
ディジタル署名を付加する仕様なので、正解は「エ」です。
私の回答：エ
問19
IPパケットの分割についての問題です。
IPパケットのフラグメンテーションは、ルータで分割処理が行われ、宛先ホストで再構築します。
そのため、正解は「ア」だと思われます。
ネットワークもうちょい勉強し解けばよかった。
私の回答：ウ（×）
問20
たまに出る過去問のTCPについての問題です。
TCPは一定時間経過しても応答がなければ再送するので、正解は「ウ」です。
私の回答：ウ
問21
JSON形式のデータ格納方法についての問題です。
項目数や内容は予測できないとのことなので、階層型、グラフ型、リレーショナルデータベースは不適切です。
そのため、正解は「ウ」だと思われます。
私の回答：ウ
問22
状態遷移図についての問題です。
仕様の中で唯一遷移図に記載されていないのは高速運転時のレディ以外の状態でStopボタンが押された場合、運転停止してレディに遷移する。なので、正解は「エ」だと思われます。
私の回答：エ
問23
よく出るマッシュアップについての問題です。
他のサイトが提供するサービスと組み合わせてサービスを機能させることなので、正解は「エ」です。
私の回答：エ
問24
よく出る過去問のフェールソフトについての問題です。
障害発生時の縮退運転を許容する考え方なので、正解は「ウ」です。
このへんの用語はよくわからなくなる…。
私の回答：イ（×）
問25
リスクコントロールの監査についての問題です。
移行自体が失敗することに対するリスクに対するチェックなので、正解は「エ」です。
私の回答：エ
感想
できれば全問正解したかったけど、似た単語が多いフェール〇〇系とかJIS〇〇系が苦手。
あとネットワークも浅くしかやっていないのでフラグメンテーションについては知らなかった。
え？午後問題？？ナニソレオイシイノ？？