オートローダー・DI・計算量

学習の記録

引き続きPHPでMVCモデルを作る学習を進めているが、オートローダーとDIに関しては理解に時間がかかった。

オートローダー

名前空間とディレクトリ構造について再認識する良い機会になった。名前空間についてはある程度理解していたつもりだったが、このおかげで理解がさらに1歩進んだ。またLaravelの学習を進めている中で一度だけautoloadに追記したことがあったが、その時の意味を理解することができた。自分で使いこなすレベルになるためにはまだ経験が足りないと思うので、その時のために頭に入れておく。Laravelのデフォルトのautolodaにはapp/しか記述がなかったが、その意味も理解した。OK。自分が今まで名前空間とディレクトリ構造を一致させるように書き込んでいたからだった。

DI

これちょいちょい調べていたが、やっぱりまだ個人的に納得のいくレベルまでは理解できていない。ただQiitaでDice機能を例にした記事

qiita.com

を改めてみたところ、以前より理解することができ、それがかなり役に立った。

前提としてDIはオアターンの1つであり、それを実現するフレームワークがDIコンテナ、Laravelではサービスコンテナである。

  1. Controllerの中に全部書く
  2. クラス化して mt_randの機能を切り離し、Controllerでインスタンス化する
  3. インスタンス化をControllerの外で行う（タイプヒントされた引数をfunctionに渡す）＝DI

またインジェクションには

  1. メソッドインジェクション
  2. セッターインジェクション
  3. コンストラクタインジェクション

の3種類存在することがわかった。ただこの3つの使い分けについてはまだ理解していない。Laravelのスキームに組み込まれたクラスは大体コンストラクタでインジェクションできるらしい。

DIのメリット qiita.com

はController側でインスタンス化しなくて済むので、修正の手間が少なく（呼び出し元を変えるだけでOKになることがる）テスト時にも便利で、DIコンテナのメリットはControllerの引数が少なくて済む

正直メリットをまだ実感することはできていないので、これから先の学習でその部分を補っていく。

計算量

エンジニア界隈のTwitterで流行りの100日漫画がある。そこで計算量について聞かれているシーンが話題になったので、改めて復習してみた。以下はステップ数表記で、計算量はO(n)のように記す

  • n
  • n2
  • log n
  • √n

それとステップ数の計算についても理解することができた。とてもわかりやすいQiitaの記事様様 qiita.com

である。

  • 確認としてnは反復

  • n2は反復2重またi<n*nが終了条件にある時

  • log nは実行するたびにiが累乗されてって問題のサイズが定数分の1になる時(例えば2の累乗だったら問題のサイズはどんどん1/2、半分になってく)

  • √nはi*i<nが終了条件にある時

日記の目的・現状の記録

はじめに

この日記の目的は、自分の学習を記録することである。後から見返して感傷に浸ったり、ちょっと役に立てばいいかなと思っている。

またエラーの対応も雑に記録しておくので、誰かのちょっとした助けになってくれても嬉しい。が、それは本日記のコアではないので本当に雑に記録しておく。雑ではない対応記録は余裕のある時にQiitaやZennに記載する。

以下は自身を取り巻く現状についてざっくばらんに言及していく。

現状

私は現在（2021_10_14）WEB開発者としてさらなる実力を身につけるべく、Laravelを用いたWEB開発の手法について勉強している。

またスクールのTAをやっていたり、MENTAのメンターもやっている。スクールのTAは自身の学習に専念するために明日で辞める。

これまでの過程として、AWS CLFの試験に夏合格しており、現在は来年度入社する会社での業務に備えてLaravelの学習を行っている。

来月からはPrAha Challenge3期が開始する予定であり、参加する1番の目的は実務に最低限必要なWEB開発における基礎的な知識（WEBの仕組み、開発手法、テスト）の深い理解にある（浅くは知っているつもりなのが現状）。

また、入社予定の会社に採用されることになった経緯として、人の縁も強く影響している。したがって両者にとってメリットのある、共に成長できる仲間を見つけることも期待している。もちろん自分が他者に対して与えられる人間に成長することが1番に意図していることである。

現状の優先度高めタスク 3項

  • WEB開発における基礎知識

特に DB・SQLについての知識が不足している。 PrAha Challengeの事前試験でもSQLについてだけ明確な回答を提示できなかった。 このことに関してはPrAha Challenge内で良いスタートダッシュを切れると考えている。

またHTTPリクエストやレスポンスに関する知識も不足していると感じている。 なぜならば今まで自分はget/post以外を意識して学習したことがないからである。 このとこに関してもPrAha Challenge内で良いスタートダッシュを切れると考えている。

  • Laravelについての深い理解をすること

題が抽象的なのでお察しだが、例えばService層やProvider層に関しての理解が薄いことが挙げられる。

このことに対し、現在PHPでMVCモデルを作る講座をUdemyで受講しているが、そこでDIについて説明を受け、自分でLaravelのDIについて調べてみたところ、理解が進んできている、気がする。

また最近ミライトデザイン社のYoutube動画を拝見した際に「技術書の読み方」という動画内で設計理論について触れていた。この内容によってDIの理解も以前より捗ったので、設計についての学習も並行して進めていきたい。

  • 設計理論についての学習

上述した通り現状DIの理解に役立っている。

しかし「設計についての学習」の本質とは異なった活用をしていると感じている。なぜなら、DIのための設計理論ではなく、設計理論を実現するための手法の一つとしてのDIだからだと私は認識しているからである。

したがって、実務でより高いパフォーマンスを発揮するために、この学習も進めていく。

  • AWS SAA取得 年内

これは自分のためでもあるし、他人のためのタスクでもある。

  1. 自分のメリットとして、クラウドインフラの知識を身につけることで、より高いパフォーマンスを実務で発揮できると考えている。なぜならば「サービスが全体でどの様に動いているか」を自分が理解していれば、全体を意識した開発を行うことができ、より良いものを開発することに自分が貢献できる、という考えを持っているからである。現状はLaravelを用いたバックエンド開発について学んでいるが、バックエンドはサーバーとの通信を行っており、自分が働きたいと思っている企業はクラウドインフラを活用している事例が多いので、フロントではなくクラウドインフラに対する学習を進めている。

  2. 他人のためとしたのは、自分が一番お世話になっているエンジニアがAWSエンジニアとして活躍しており、現在社内ワンオペでクラウドを担当しており、私もちょっとした作業を頼まれるからである。私は現状この方の役に立って少しでも恩返しがしたい気持ちがある。

以上2点の理由により、AWS SAAの取得のため学習を進めている。

やりたいこと

  • 個人開発物で収益を上げたい

まず収益なしで、モバイルアプリだったら実現できそうな便利なアプリが思い浮かぶが、WEBだと中々思い浮かばない。

それって結局モバイルアプリで実現した方がユーザーにとっては便利じゃない？といつも頭に思い浮かんでしまう。

この原因として、自分が収益を上げるWEBアプリケーションに対する理解の低さ、またモバイルアプリケーションについて知らなさすぎるが故の安直な考えの2点が原因だと考えられる。

したがって「ユーザーがWEBアプリケーションとして存在していたら金銭的価値を感じるもの」(買い切り、サブスクとして利用したいもの)についてより考え、挑戦していきたい。

  • 決済機能の実装に関する知見

個人開発で収益を上げる際に、決済機能を搭載させたいと考えているから。

感じている不安

  • 自分が惹かれる企業にはPHPではなくRubyを採用している企業が多い。

このままPHPを扱い続けて自分の満足のいくキャリアを送ることができるか不安である。が、それはPHPやRubyの実情を知らないだけだからと考えることもできる。また比較記事を読んだ感じ、両者にそこまで大きな壁はなさそうだった。兎にも角にもまずは実務に携わってみてから。

  • PHPはAWS Lambdaに対応していないため、AWS Lambdaを扱うことには直接的にPHPの知見を活用することができない

これはPrAha Challengeでnodeを触るので大丈夫そう。GASでも活用することができる。

結局は自分がPHPerとして稼げるか不安なのである。そんれならPHPでもRubyでもNode.jsでもなんでも、仕事としての収入はとりあえずPHPから始め、優先度を適切に管理した上で好きに触れば良い。

さいごに

やってることが頭に入ってこなかったため、今日の記録をつけようと思っていた時にふと思いついて書き始めたが、結構な文量になった。ただ自分の中で「なぜやるのか」が整理できタスクの優先度も再認識することができた。

また、現状自分が感じている不安は「PHPerとして金銭的価値を他者から受けることができるか」ということに起因していることを認識することができた。結局いまからRubyやNode.jsの学習を始めても、来年度の春には中途半端な人間が出来上がる気がする。まずはPHPの知見を深めてから考えていきたい。1つの言語を極めれば他の言語の理解もすんなりいくって誰かも言ってたよ！大丈夫！

DockerでbuildしたユーザーイメージのURLにアクセスしても「見つからない」

前回のエラーを解決し、ようやく環境構築が終わる！と思っていたが、最後の最後でうまくいかなかった。どうして・・・

 

## 実際のエラー

ChromeのURLに該当するURLを入力しても「ページが見つかりません」となってしまう。一応Docker Desktopから覗いたらIndex Ofにはアクセスできていた。

 

## 解決

hostsファイルに対応するURLを記述する。

私はmacを使用しているので

```

sudo vim /private/etc/hosts

####

~~

127.0.0.1 hoge

~~

####

```

という様に追記したら解決した。

 

## 収穫

hostsファイルの存在は知っていたが、実際にこの様な状況で追記する必要があるのだと体験することができた。

ただ、経験上大抵のこの問題はプロジェクト内のルーティングミスが原因であることが多かったので、Dockerだと必要になるシチュエーションが出てくるのかなぁという認識になっている。類似する問題が出てきたときに、すぐhostsファイルを指摘できるかは現状自信がないので、引き続き学習を進めていく。

Docker build時にcomposer-setup.phpが見つからないエラー

社内でDockerを使ったので、より深掘りするためにDockerによる環境構築の勉強をUdemyで行っていたところ、Docker build時にエラーが発生してしまった。

実際のエラー

 => ERROR [15/16] RUN php composer-setup.php     
------
 > [15/16] RUN php composer-setup.php:
#19 0.234 Could not open input file: composer-setup.php
------
executor failed running [/bin/sh -c php composer-setup.php]: exit code: 1
ERROR: Service 'php' failed to build : Build failed

正直エラー文は出てこないで欲しいものだが、エラーを解決した時に他では得難い達成感を得られるのも事実。 大人しく解決方法を探る。

解決

Dockerfileに記載されてある、composerのインストールに関するコマンドが正しいものではなかった。 まず、エラー文中にもあるとおり、この問題はcomposerのsetupに関するものである。 そこで該当するDockerfileの記述を確認してみると、composerのバージョンアップデートによるハッシュ値の変更が原因だった。これは動画投稿時と私の学習時に時間的な開きがあるので、当然生じるエラーであった。

収穫

composerのアップデートはハッシュ値の変更が伴うので、必ずと言っていいほどコマンド内容の変更が発生する。 初手脳死でエラー文貼り付けて検索することよりも、エラー箇所の特定を先にしたほうが検索の質も上がって結果的に良い結果になる。