MasaKu's BLOG

PHP多めでWeb関連技術の記事を書きます

新米パパエンジニア1年目の暮らし

年の瀬ですが、皆さん今年はどんな一年でしたでしょうか。 個人的に今年一番の出来事としては、今年の春に第一子が生まれたことです。めでたい!

新米パパエンジニアエントリー記事を何度か拝見したことがあったので、是非自分もと思い筆を取らせていただきました。

育児面とエンジニアとしての仕事面の2つについてまとめていきたいと思います。

育児について

生まれる直前

幸い、うちの妻の実家が比較的近くにあるということで、生まれる直前頃から里帰りしてもらっていました。 おかげさまで、比較的仕事の方も集中できたのではないかと思います。 特に、リリースが迫っている案件の対応などではどうしても帰宅が遅くなることもあったので、本当に感謝しかありません。

妻が臨月となってからは夜中に電話が来るのではないかと毎日ソワソワしていました。

生まれた直後

出産当日は本当にいろいろなことが起きてかなりの難産でしたが、母子ともに健康でした。 出産時のことについては本当にいろいろとあったので、書き始めるときりがないので割愛しますが、この世に生を受けるためには、本当にたくさんの奇跡とたくさんの人の協力が必要なんだなと思いました。 命がけの出産をやり遂げた妻に対する敬意と生まれてきた子供に対する感謝の気持ちで一杯になったことを覚えています。

ありがたいことに、うちの会社は比較的育休が取りやすい状況であったため、出産直後は妻の実家で里帰りしてもってから育休に入らせてもらいました。

初めての育児

トライアンドエラーの毎日のスタートです。 仕事では「何事も初めてのことは失敗するしその中から経験していくものだから大丈夫」のように楽観的に捉え、後輩などにもそのように伝えることが多かったのですが、新生児のお世話に関しては「一度の失敗が取り返しのつかないことになるのでは?」のようなプレッシャーがあり、首すわり前の沐浴などは、正直怖かったです。

育児に正解はないとは言いますが明らかな失敗だけはしないようにと、育児関連の記事を読んだりYouTubeで動画を見たりして知識を得ながら実践してみる、ということを通して何とか過ごしていました。

赤ちゃんのお世話で一番大変だと感じたのは泣き始めた際のあやし方についてです。 エンジニアという職業柄、再現性のある手法を見出すことに必死になっていましたが、赤ちゃんの機嫌を思うようにコントロールすることは簡単ではありません。というかほぼ不可能です。 昨日までは有効だったあやし方がなぜか全く効果がない!といった時は慌ててしまい余計に事態が悪化していく、ということも何度もありました。

赤ちゃんの機嫌を損ねる要因を思いつく限り洗い出して可能性の高いものから順番にチェックしていくのですが、どうしても原因がわからず、ほとほと手を尽くして意気消沈しているときにコロッと機嫌が直ったりと、PDCAを回す間もないほど忙しく大変な毎日でした。

それでも、一日を無事に乗り越えられたときには心地よい達成感があり、いい思い出がまた一つ増えたなという気持ちでした。

ある程度落ち着いてきて

生活のリズムができてくるようになると日々の変化に気づくようになりました。昨日できなかった◯◯が今日はできるようになっている!であったり、逆に昨日できていた□□ができなくなっていたりと、日々の変化を感じる余裕が出てくるようになりました。

知能という面だけでなく、身長・体重の増加といった外見の変化というわかりやすい形で日々成長していくので純粋に嬉しく楽しい気持ちでした。

月齢に合わせて生活習慣が変わってくるため、暦を感じる暇もなくあっという間に年末を迎えてしまいました。まだ年末の準備全然してない…。

エンジニアとしての日常について

日々の業務について

猛烈な激務に追われることもなく、家庭とうまくバランスを取りながら仕事ができているのかなと思います。これについては個人の努力ではどうすることもできないので、チームの管理をしてくれているマネージャーや優秀なチームのメンバーに支えられていることが一番の要因です。

新しいモチベーションとしては、限られた時間を最大限有効に利用するための効率化を考えるようになったという点です。 これまでも時間は有限であるということは認識していたはずなのですが、何かあればテコ入れすれば何とかできるだろうといった気持ちは正直あったと思います。

ところが、家庭との両立を意識するようになってそれではいかんだろと気付き、短い時間でこれまでと変わらない成果を維持するためには何ができそうかを考えれるようになったかと思います。

業務外の学習について

恥ずかしながらかなり減少してしまっています・・・。 通勤中などの時間を利用して少しインプットすることはあるのですが、帰宅後や休みの日はあまり時間を取れていないのが現状です。

学習のモチベーションが下がっている、というわけではないのですが、帰宅後は休息、休日のまとまった時間は平日ワンオペで頑張ってくれている妻と育児をバトンタッチするなどして過ごすことが多いです。

完全に自分の考えを正当化するオレオレ持論ですが「チャンスは何度もやってくるがこの瞬間だけは二度と戻ってこない」と思い、今は家庭の時間を大切にできればと考えています。

また自分の時間に余裕を持てる状態になってきたら社外の勉強会などにも参加できればと考えています。

まとめ

子どもが生まれるまでは想像もしなかったような忙しさで毎日が過ぎていきますが、その分、一日一日の濃密さが今まで以上に増したようにも感じます。

これからも仕事面・プライベート面の両面で忙しくなるとは思いますが、自分なりのペースで肩の力を抜いて無理なく楽しみながらやっていけたらと思います。

【2023年版】個人的 Best PHPer's News

はじめに

この記事は ラクス Advent Calendar 2023 18日目 の記事です。

今年のアドベントカレンダーも、PHP TechCafe でコーナー化している「PHPer's News」で紹介されたニュースのうち個人的に印象に残っているものをまとめたいと思います。

PHP TechCafe とは

PHP TechCafe ロゴ

まずは、PHP TechCafe についてご説明いたします。

エンジニアと技術が交差する 憩いの場(カフェ)

月に1回開催 現在はオンラインで実施中

対象者:PHP入門後の初級エンジニア ~ シニアエンジニア

学びの場をつくり、エキスパートまでの自己成長を支援する

一緒に支援して頂ける エキスパート以上 の方も大歓迎!!

社内の運営メンバー数名とテーマ検討を行い、コンテンツ作りを分担しながら毎月開催しております。

イベント当日は運営メンバーと協力して作成したコンテンツを @YKanoh65 さんと、語り合う枠にてアウトプットしております。

2023年 開催履歴

  • 2023年12月開催:PHPerのための「2023年のアドベントカレンダーを読みあさる」(予定)
  • 2023年11月開催:PHPerのための「PHP系カンファレンスを語り合う」
  • 2023年10月開催:PHPerのための「PHPカンファレンス2023を振り返る」
  • 2023年9月開催:PHPerのための「PHPUnitの新バージョンを語り合う」
  • 2023年8月開催:PHPerのための「PHP8.3 の新機能について語り合う」
  • 2023年7月開催:PHPerのための「CakePHP」を語り合う 」
  • 2023年6月開催:PHPerのための「Symfony」を語り合う 」
  • 2023年5月開催:PHPerのための「PHPと型定義を語り合う」
  • 2023年4月開催:PHPerのための「PhpStormを語る」
  • 2023年3月開催:PHPerのための「PHPerKaigi2023」を振り返る
  • 2023年2月開催:PHPerのための「Laravel10の新機能」を語り合う
  • 2023年1月開催:PHPerのための「2022年アドベントカレンダー」を読み漁る

PHPer's News とは

PHP TechCafe にご参加いただいた方に何らかの情報をお持ち帰りいただきたく「社内のPHPエンジニアが気になったニュース」をご紹介しております。

2023年に開催した PHPer's News の中から特に気になった記事をピックアップさせていただき、今年一年の PHPer's News を振り返っていきたいと思います。

PHPUnit 10 リリース

phpunit.de

当時、「早急にPHPUnit10にアップデートしなければならないのか?」という話がありましたが、公式的にも急ぎの対応は不要であることが名言されておりました。PHPバージョンの最低条件をクリアすることなど、使用する上での要件がありますので無理にバージョンアップするのではなく、サービスが利用しているPHPバージョンに合わせて利用していくのが良いでしょう。

PHPフレームワーク「Laravel」のドキュメント翻訳者から広告ブロック使用自粛のお願い

opensource.srad.jp

OSS の存続のため広告のブロック機能を自粛してほしいという内容。OSSのメンテナンスに関する内容は少し前から話題になっていました。普段当たり前に利用させていただいているOSSですが、当たり前に使える状態になっているのはメンテナーが日々コストを払ってメンテナンスしている、ということをしっかりと再認識したいと思いました。

PHP Foundation にて諮問委員会が設立

thephp.foundation

PHP非営利団体PHP Foundation」の定期記事。発足初期に 10,000 ドルを寄付した企業には、2023 年 10 月まで主要スポンサーの地位と諮問委員会の席が提供されるという内容。 諮問委員会は、PHP Foundation 開発者が近い将来取り組む予定のタスクのリストを提供することができ、諮問委員会のメンバーは、チーム内でこれらの計画について話し合い、検討すべきと思われるフィードバックをPHP Foundation に提供することができます。 留意しておきたいこととしては、PHP の言語の開発方針を決定する権限は PHP Internals にあり、PHP Foundation にはありません。

ちなみに、弊社ラクスは PHP Foundation 設立当社に10,000 ドルを寄付させていただいておりましたので、諮問委員会の席を持っていました。

GitHubリポジトリを仮想地図としてマッピングしているサイト

anvaka.github.io

あのリポジトリってこの国だったんだ!とか、この国って結構コミットしてるんだなとかいうことが視覚的にわかって結構な時間つぶしになってしまいます。

PHPカンファレンス福岡開催

phpcon.fukuoka.jp

私は参加できなかったのですが、会場はかなり盛り上がっていたようです!イベント開催中にXにて「ラーソーメン」というメニューがたくさん流れて、今でも非常に気になっています。

みんなが幸せになれるPullRequestの作り方を考えてみた

qiita.com

プルリクエスト経由でのコミュニケーションに関する記事。この手の話題は定期的に上がっている印象ですが、今年は特に「レビュアーの意図が正しく伝わらず、適切なコミュニケーションができない」といった内容の話題が多かったように感じます。 文字ベースのコミュケーションって難しいですよね。リモートワークの普及などにも伴って文字ベースのコミュケーションの重要性がますます高まってきているように感じます。

( ´∀`) < モナーがechoしてくれる monacoって言うコマンドを作りました

qiita.com

モナーがしゃべっているように見えるツールの紹介。こういうの大好きです!! イベント中は「モナー、何それ?っていう人増えてきたんじゃないか?」と危惧していましたが実際どうなんでしょう・・・。

PhpStorm にてAIアシスタントが利用可能に

blog.jetbrains.com

今年はLLMが各IDEにもAIアシスタントとして取り入れられた一年でした。PhpStormにも追加され、今後はAIアシスタントを使いこなして開発していくことが求められてくると思われます。

RFC投票権限を持っていない我々一般ユーザも各種RFCに対して賛成反対を示せるサイト

rfc.stitcher.io

これまで、RFCの投票結果を見るだけになっていたので、ユーザ目線でどういった意見があるのかということは各種SNS等に散らばっている意見を集めてくるしかなかった印象ですのでとても便利なサイトだと思います。

AIに「深呼吸しよう」といった人間っぽい言葉をかけると問題の正答率が上昇するという研究結果

gigazine.net

AIに対して質問する際のテクニック。AIの学習元データは人間か書いた文章であるため、人間の話し言葉のような質問の仕方をしてみるのもあり。 あまりにも自然なコミュケーションができてしまうので、かなり抽象的な聞き方をしたり、回答が終わった際に「ありがとうございます!」のようなメッセージを送ってしまうこともあります。

curl にて重大度HIGHの脆弱性が発見される

daniel.haxx.se

皆さんお世話になっているかと思われます、大人気ライブラリ「curl」にて重大度HIGHの脆弱性が見つかりました。 このバグを発見した奨励金として、4,660米ドルが支払われたとのことです(これまでに支払われたcurlのバグ報奨金としては最大のもの)。

PHP 8.0 系がEOLに

www.php.net

PHP 8.0 系って最近リリースされたように感じますがもうEOLなんですね・・・。 緩やかな比較の仕様変更による影響でヒーヒー言ってたのが懐かしいですね。 時が過ぎるスピードが速すぎて恐ろしい・・・。

おわりに

2023年もたくさんのニュースがありましたね。 他にも「こんなニュースがあったよ!」といったお声もお待ちしております。

来年も社内のPHPエンジニアが気になったニュースを PHP TechCafe を通して発信していければと思いますので今後ともどうぞよろしくお願いいたします。

参考サイト

【2022年版】個人的 Best PHPer’s News

はじめに

この記事は ラクス Advent Calendar 2022 4日目 の記事です。

全国的に急激な気温の低下がみられますが、皆様におかれましては寒暖差で体調を崩されておりませんでしょうか。 私の方は、寒さ対策としまして、まずは足先を温めるべく暖かそうな靴下を購入しました。

今年のアドベントカレンダーは、私が毎月参加させていただいているイベント PHP TechCafe でコーナー化している PHPer's News について一年間のまとめ記事を書きたいと思います。

PHP TechCafe について

PHP TechCafe ロゴ

まずは、PHP TechCafe についてご説明いたします。

エンジニアと技術が交差する 憩いの場(カフェ)

月に1回開催 現在はオンラインで実施中

対象者:PHP入門後の初級エンジニア ~ シニアエンジニア

学びの場をつくり、エキスパートまでの自己成長を支援する

一緒に支援して頂ける エキスパート以上 の方も大歓迎!!

社内の運営メンバー数名とテーマ検討を行い、コンテンツ作りを分担しながら毎月開催しております。

イベント当日は運営メンバーと協力して作成したコンテンツを @YKanoh65 さんと、語り合う枠にてアウトプットしております。

12月も開催を予定しており、テーマは「PHP8.2」についてです。PHPer の皆様、ご興味あれば是非ご参加のほどよろしくお願いいたします。

rakus.connpass.com

2022年 開催履歴

  • 12月開催予定:「PHPerのための「PHP8.2のリリース」を祝い合う」
  • 11月開催:「PHPerのための「PHPフレームワーク」を語り合う」
  • 10月開催:「PHPerのための「PHPのリーダブルなコード」を語り合う」
  • 9月開催:「PHPerのための「PHPカンファレンス2022」を語り合う」
  • 8月開催:「PHPerのための「PHP8.2の新機能」を語り合う」
  • 7月開催:「PHPerのための「PHPDoc相談会」」
  • 6月開催:「PHPerのための「Composer」を語り合う」
  • 5月開催:「PHPerのための「静的解析」を語り合う」
  • 4月開催:「PHPer Kaigi 2022 を振り返る」
  • 3月開催:「Laravel 9 について語る」
  • 2月開催:「PHPerのための「Xdebugの活用方法」を語る」
  • 1月開催:「2021年のPHP/Laravel振り返り+2022年」を語る」

PHPer's News

PHP TechCafe にご参加いただいた方に何らかの情報をお持ち帰りいただくこととを期待して、PHP TechCafe では毎月「社内のPHPエンジニアが気になったニュース」をご紹介しております。

せっかくですので、今回は、2022年に開催した PHPer's News の中から特に気になった記事をピックアップさせていただき、今年一年の PHPer's News を振り返っていきたいと思います。

【PHP8.1】PHP8.1はPHP7.4より20%高速化している

qiita.com

PHP は PHP5 から PHP7 の間でかなりのパフォーマンス改善が見られ、PHP7.4 では PreLoading が導入。さらに、PHP8 では JIT の登場とパフォーマンス改善の進化が止まりません。

そんな中、PHP8.1 のパフォーマンスはさらに向上しているという内容の記事。どこまでも改善されていくPHPの今後に目が離せません。

なお、PHP7系は既にセキュリティサポートが終了しておりますので、PHP8 系へのアップデートが急がれます・・・。

www.php.net

オープンソース開発者が広く使われているライブラリを改ざん、大量のプロジェクトに影響

hisubway.online

faker.js とcolors.js の作者が意図的にソースコードを破壊したという内容の記事。

OSSの開発には当然コストが発生しているわけですが、それが製作者に還元されることは少なく、時には急ぎの不具合の修正を求められることもあるようで、製作者としては複雑な気持ちになることもあるかと思います。

とはいえ、行き過ぎた行動に対するコメントも多かったようで「いったんリリースした道義的責任をないがしろにするのもおかしい」や「『OSS開発者にお金を払う』ではなく『OSSを使うのをやめる』につながるのではないか」といった意見もあった模様です。

OSS を利用している側としてはいろいろと考えさせられるニュースでした。

なお、faker.js については既に Faker というプロジェクトで開始しており、プロジェクトへの経済的支援については、今後はOpen Collectiveと協業し、メンテナーではなくプロジェクトに紐づくようにする模様です。

mag.osdn.jp

GitHubでMermaidが使えるようになった

zenn.dev

Mermaid 記法はグラフやチャートを描ける記法で、システム開発でよく利用されるガントチャートフローチャートを表現することができます。

GitHubでは、READMEにマークダウン記法が利用できましたが、この度新しくMermaid 記法も利用できるようになったとのことでした。

記法にはある程度の慣れが必要な部分もあるかと思いますが、エクセル等で作成した図を切り貼りしたりする必要がなくなり、かつ、キレイな図を書けるようになるのは嬉しいです。

【PHP9】ついに未定義変数が使えなくなる

qiita.com

PHP9 系の重大な下位互換性のない変更の一つです。

現在、未定義変数を利用した際は警告を出力されるようになっているため、今のうちが少しずつ対応していくしかないです。後回しにせず気づいたところから少しずつ修正していく必要がありそうです。

PHPerKaigi 2022への参加をきっかけにPHPStan本体にPRを出した

muno-92.hatenablog.com

PHPerKaigi 2022 にて @t_wada さんが コンストラクタは1回以上呼べる ということを発されたことから始まったPR。

speakerdeck.com

当時、PHPerKaigi 公式の Discord チャンネルで状況をウォッチするだけの人になっておりましたが、実際に PR が承認された際は歴史的瞬間に立ち会えたような気持になりました。

PR を出すまでに必要な作業について全くの未知でしたが、こうして流れで整理していただき大変勉強になりました。

GitHub、コードエディター「Atom」の開発を終了 ~年内にアーカイブ

forest.watch.impress.co.jp

入社前から利用していたエディタが開発終了となってしまうニュース。確かに、入社後は PhpStorm か VisualStudioCode しか使わなくなってしまっていたな・・・、という気持ちがありましたが、やはり開発終了となってしまうと悲しいものです。

今後は Visual Studio CodeGitHub Codespaces による、クラウドでのソフトウェア開発の信頼性向上に集中するとのこと。

Internet Explorer 11 のサポートは 2022 年 6 月 15 日に終了しました

support.microsoft.com

世間的にも利用者数が減少傾向にあった IE ですが、Microsoft 側もサポートを終了する運びとなりました。

Microsoft Edge にて IE モード なるモードが存在するため、IE専用のサイトに関しては、こちらのモードを利用することになりそうです。

開発者目線としましては、サポートブラウザを一つ減らす方向で調整できるようになったのは開発速度アップにも繋がる大きなニュースかと思いました。

GitLabがVisual Studio CodeベースのWebIDEへ移行すると発表

www.publickey1.jp

GitLab は Web 画面上からもソースコードを修正することができましたが、この度、コードエディタは Visual Studio Code ベースに置き換えになるとのことです。

Visual Studio Codeマルチプラットフォーム対応していることや Web ブラウザ上でも利用できるようにするなど、ユーザ獲得のための取り組みが盛んです。

前述した Atomの開発終了の件 もあり、来年も Visual Studio Code の進化が期待されます。

code.visualstudio.com

PHPのコア開発者が決定!

qiita.com

PHP Foundation による PHP コア開発者が決定しました。PHPはこれでオープンソースプログラミング言語として一部のOSS開発者によりメンテナンスされてきましたが、Open Collective を通して寄付を募り、PHPに関わる人全員で運営していこうという方針になりました。

  • Arnaud Le Blanc
  • Derick Rethans
  • George Peter Banyard
  • Ilija Tovilo
  • Jakub Zelenka
  • Máté Kocsis

thephp.foundation

AWSが「Docker Desktop」代替となり得る「Finch」をオープンソースで公開 ローカルマシンに仮想環境・ビルドツールなど一式を導入

www.itmedia.co.jp

Docker Desktop に代わるツール「Finch」の紹介です。今のところ「IntelプロセッサもしくはAppleシリコン搭載のMacにのみ対応」とのこと。

Docker Desktop は 10月27日より突然の値上げとなり、Team プランを100人以上で利用している場合は Business プランへの変更が求められ、これまでの30% 程の価格アップとなりました。

www.itmedia.co.jp

おわりに

いかがでしたでしょうか。 2022年もたくさんのニュースがありこの場では語りつくせないほどたくさんのニュースがありました。

他にも「こんなニュースがあったよ!」といったお声もお待ちしております。

来年も社内のPHPエンジニアが気になったニュースを PHP TechCafe を通して発信していければと思いますので今後ともどうぞよろしくお願いいたします。

参考資料

PHPerKaigi 2021 二日目 参加メモ

はじめに

PHPerKaigi 2021 に参加しました。

1日目はあいにく別件の用事があり参加できませんでしたが、タイムシフトで後日参加いたします。

2日目の参加メモを公開します。

※個人的なメモですので、支離滅裂かと思いますがご了承くださいませ

聴講セッション

  • 無駄な物をなるべく作らないリプレイス戦略
    • 11:50 Track B
  • 今こそ理解するDI(Dependency Injection)
    • 14:10 Track A
  • DNSを制する者はインターネットを制す!DNS世界
    • 14:50 Track B

無駄な物をなるべく作らないリプレイス戦略

  • ママリ
    • 記事の管理
    • 記事のCMS
  • 技術スタック
  • リファクタリング
    • コードの最適化
  • リライト
    • 設計から1から作りなおす
  • リプレイス
    • 置き換えること
  • 完全な書き直し(リライト)は最終手段
    • 大きなリスクがあるため
      • リライトして何年も立つがまだ終われない
      • リライトしたあとの方が性能が悪い
      • 想像していなかった仕様や機能の漏れがあった
    • 記事サービスの場合、複数の機能があるため、リライトは現実的ではない
  • そのためリファクタリングの方針とした
    • リライトまでの経緯
      • コーディング規約
      • Linter
      • 静的解析ツール
      • テストの充実バレッジの計算
      • 開発環境のコンテナ化
      • 不要なコードの削除
        • 一番の問題は解決されない
    • アーキテクチャとしての課題を明らかにする
      • イケてないことを放置しない
        • コードを修正する
        • 直せなくても同じミスをしなければ良い
            • オブジェクトではなく配列がた多用される
            • 責務の大きすぎるクラス
            • Viewに漏れ出すロジック
      • モダンなプラクティスを使えば課題の多くを解決できる
  • リライトにすることになりました
    • 無駄なものをなるべく作らないりプレイス戦略とは
      • 必要なものから少しずつ作っていく
        • ログインログアウトだけできても意味はなく、それに付随する必須機能を組み合わせて進めていく
  • 必要なものを作る戦略
    • 知るところから始める
    • とにかく対話する
      • 実際に使っているユーザと対話する
      • 現状のサービスの使われ方を明らかにしていく
        • プロダクトとして何らかの課題を解決できる最小単位
      • ユーザインタビューを行う
        • インタビュー中の発言やメモなど
    • 共通理解を持つ
      • 実際に作ってみたら思っていたものと違ったを防ぐ
      • 狩りで決めたスコープに抜け漏れがないか、関係者で認識にずれはないかを検証する
        • ユーザストーリーを前提として設計する
          • ユーザの操作のストーリーを書き出す
            • 作成して、プレビューして・・・・。
    • まずはリファクタリング、リライトは最終手段
      • 無駄なものは作らないはキホン

今こそ理解するDI(Dependency Injection)

  • DIとは方法論
    • 保守性の高いコードを書くことを目的としたソフトウェエア設計原則とパターンのセット
    • 粗結合の実現を目的としたデザインパターン
  • 制御の逆転
    • 呼び出す側と呼び出される側が逆転する
    • 必要になったら呼ぶ
      • フレームワークを利用したアプリケーション開発に当てはまる
        • アプリケーション側から呼ぶことはほぼない
        • 呼ばれるタイミングはフレームワーク側で実施している
    • ユニットテスト
      • setUP
      • tearDown
    • IoCとDIの関係
      • IoCは制御の逆転
        • Inversion of Controll
      • DIは依存関係に対する制御の逆転と表現
    • メールを送信するメソッドを例にする
      • init で設定を行っている
        • しかし、この中でAWSのメール送信オブジェクトを利用している場合、AWSに依存していることになる
        • つまり、オブジェクトを関数内で作ってしまうとそのオブジェクトに依存している状態になってしまう
    • テストを支援するのが目的ではなく、
      • オブジェクトがそ結合になることでテストしやすくなっているだけ
    • DIコンテナラは必須ではない
      • フレームワークはDIコンテナを利用している前提になっているだけで、必須ではない
      • 依存関係をコンテナに定義しておくだけで、コンテナ側オブジェクトの依存関係を解決してくれる
      • サービスロケーターではない
    • サービスロケーターについて

DNSを制する者はインターネットを制す!DNS世界

  • ドメイン名ハイジャックは恐ろしい
    • 悪意あるユーザが名前解決先のIPを書き換える
      • レジストラ経由で変更されてしまうため気づきにくい
      • MXが変更されるとメールが乗っ取られる
      • クラウドサービスのパスワードリセット
    • 悪意あるWebサーバへ誘導される
      • HTTPSもOKになってしまう
        • 徐々にやられていくと気づきにくい
          • 10人に1人だけなど
  • 過去あった自称
  • レジストラの問題が起点となるため、防ぎようがない
    • なるべく早く気づいて対策を実施する
  • NSchecker
    • TLD権威サーバに登録されているNS情報をチェック
    • 改ざんを検知するとコマンドが異常終了
    • コマンドの結果からメール通知やほかの連携も可能
      • Slack通知機能
  • DNSプロトコル
    • 30年以上の歴史がある
    • UDP上の512バイトいないのデータ
      • TCPフォールバック有り
    • 1ビット単位でフォーマットが決まっている
      • dig コマンドでDNSのデータが出せる
      • DNSのレスポンス
        • 名前はラベルで区切られている
        • vaddy.net -, 5vaddyy3net\0
      • 同じ文字データは圧縮される
        • オフセットでデータ量を無駄にしない
      • 子供が 20 時を過ぎててもYouTubeを見ている
        • YouTubeだけを止めたい
          • DNSCOP
            • DNSパッケットをフルリゾルバに転送
              • 転送時にメインをチェックしてコントロール
          • 子供がPCでアクセスするドメインが全て丸見えに(プライバシー上の問題)
      • 私たちのDNSクエリ
        • フルリゾルバにはこう見える
          • あるIPの利用者はXX時に example.cam をよく見てる
        • 暗号化されていない
          • 自分がどういうDNS結果が見られている
      • DNS結果の汚染防御
      • 経路の暗号化
    • フルリゾルバ(キャッシュサーバ)には誰が何のIPを知りたいかは防げない
      • ODoH
        • DNSメッセージを暗号化してDNSプロキシに送信
          • そのまま、DNSプロキシがフルリゾルバに転送