TAK TECH NOTE

サーバサイドエンジニアを目指し勉強した内容を発信するブログです。

Laravelのパスワードリセットなどでメール送信を行うとき

パスワードリセットが正常に機能していないと気づき、調べてみた。

どうやらLaravelアプリケーションからメールを送信するときは、".env"と"config/mail.php"の設定が必要のようである。

 

".env"

MAIL_DRIVER=smtp
MAIL_HOST=smtp.gmail.com
MAIL_PORT=465
MAIL_ENCRYPTION=ssl
MAIL_FROM_ADDRESS=q4mapp@gmail.com
MAIL_FROM_NAME=q4mapp
MAIL_USERNAME=q4mapp@gmail.com
MAIL_PASSWORD=tk435963
MAIL_PRETEND=false

 

"config/mail.php"

<?php
  
return [
    // Mail Driver
    'driver' => env('MAIL_DRIVER', 'smtp'),

    // SMTP Host Address
    'host' => env('MAIL_HOST', 'smtp.mailgun.org'),

    // SMTP Host Port
    'port' => env('MAIL_PORT', 587),

    // Global "From" Address
    'from' => [
        'address' => env('MAIL_FROM_ADDRESS', null),
        'name' => env('MAIL_FROM_NAME', null)
    ],

    // E-Mail Encryption Protocol
    'encryption' => env('MAIL_ENCRYPTION', null),

    // SMTP Server Username
    'username' => env('MAIL_USERNAME', null),
    
    // SMTP Server Password
    'password' => env('MAIL_PASSWORD', null),

    // Sendmail System Path
    'sendmail' => '/usr/sbin/sendmail -bs',

    // Mail "Pretend"
    'pretend' => env('MAIL_PRETEND', false),
];

 

これによってローカルではメール送信が成功したが、herokuでは成功しなかった。

herokuでは.envがpushされないため、別の方法で設定を流し込んでやる必要がある。

 

$ heroku config:set MAIL_DRIVER=smtp
Setting MAIL_DRIVER and restarting ⬢ q4m... done, v48
MAIL_DRIVER: smtp

 

上記のコマンドのようにしてローカルで設定した.envの中の変数をherokuアプリにも反映させることができる。

これでパスワードリセットのメール送信がうまくいった。

Gitのキホン

参考：https://qiita.com/gold-kou/items/7f6a3b46e2781b0dd4a0

 

上の記事を参考に、今まで曖昧な理解だったGitについて調べてみた。

発端はAWSで開発してHerokuにデプロイしていたアプリをMacにGitCloneしてから盛大にコケたからである。

 

 

ステージング・ローカルリポジトリ・リモートリポジトリ

Gitには作業の変更を記録する場所が３段階に別れている。

これらとは別に、ファイルの編集作業場所をワーキングツリーという。

ステージング環境

コミットするためのファイルを記録する場所。

ワーキングツリーの変更内容をaddコマンドでステージング環境へ記録する。

ローカルリポジトリ

リモートリポジトリにアップロードするためのコミット履歴とファイルを記録する場所。

インデックス上のファイルをcommitコマンドでローカルリポジトリにコミットする。

リモートリポジトリ

複数人で共有する場所。俗にいう本番環境である場合が多い。

ローカルコミットしたファイルをpushコマンドでリモートリポジトリにアップロードする。

 

ブランチ

ブランチとは作業履歴を枝分かれさせて記録していくものである。

リモートのmaster（幹の部分に当たる）と言うブランチから新たにブランチを切って作業を行っていくケースが多い。

ブランチを切る

新しく作業を始める時、ブランチを切ると言う。

ブランチの切り方についてみていく

 

1.リモートの最新の情報をローカルに取得する。

$ git fetch

2.どのブランチから切るか確認する。

$ git branch -a -v

3.2で選んだブランチから新しくブランチを切る。

$ git checkout -b 新たなブランチ名 切る元のブランチ

4.ブランチが正しくできたか確認

$ git branch

ex.ローカルにリモートの更新内容を反映する。

$ git fetch
$ git merge　ブランチ名

 

 

Herokuからのclone

散々コケたHerokuからのcloneは下記のコマンド１行で、cloneもリモートリポジトリの登録もしてくれるようである。

$ heroku git:clone -a APPNAME

リポジトリ名は"heroku"となるようである。

また、以下のコマンドでリポジトリ名"heroku"に任意のアプリのgitURIを紐づけることができるので、複数のherokuアプリを管理する場合に有効である。

$ heroku git:remote -a APPNAME

 

 

まとめ

今回はリポジトリやブランチについて、herokuとのgitのやりとりについてまとめた。

新しい機能追加やバグ修正を行うなど作業を行うときはmasterブランチではなく別のブランチを切って行うようにする。

git cloneでハマったのでメモ

awsでLaravelのアプリケーションを作っていて、無料期間終わった後にローカルにも成果物があったほうが良いとなり、gitの練習も兼ねてローカルにも開発環境を用意しようとしていきなりハマったのでメモ。

何も考えずgit cloneすると・・・

$ git clone https://git.heroku.com/hoge.git
Cloning into 'hoge'...
remote: !	Your account hoge@yahoo.co.jp does not have access to hoge.
fatal: unable to access 'https://git.heroku.com/hoge.git/': The requested URL returned error: 403

となった。awsでgit config -l するとメールアドレスにgmailの方を使っていた。

git configの設定方法を調べ、システム全体の設定(git config --system:/etc/config)と該当ユーザの全リポジトリ(git config --global:~/.gitconfig)と該当リポジトリ(git config:repository/.git/config)があることがわかり、システム全体以外（最初から設定が無かった）の設定を行った。

gitの設定だけではまたも・・・

git cloneするとまたも同じエラー。

ここであることに気づく。「herokuからgit cloneしようとしてるよな、herokuのログイン設定が違うんじゃね。」

heroku loginしてみたらうまくいった。どうやらherokuの認証でコケていたようである。

まとめ

herokuからgit cloneするときはheroku のログインも忘れずに。

リファクタリングとは

先だって公開した記事でも述べた通り、私はその場の思いつきでアプリを作成してきたので、自分のコードを見直してこなかった。

機能を追加するために見直すことはあったが本当の意味で「見直す」ではなく「過去の自分（他人）が書いたコードの意味を再解釈する」という無駄な行為だったように思う。

今まで自分が実装してきた機能をどのようにして実装したのかを振り返るためにもコードの見直しを行いたいと思う。

どうやらエンジニアの中では「リファクタリング」という行為があるらしい。

早速調べてまとめてみる。

 

 

まずはきれいなコードから

そもそもきれいなコードとは何か。

読みやすくて、修正しやすいコードである。

他人（過去の自分）がみてもすぐにどんな処理をしようとしているか理解できるコードのことではないだろうか。

コードが難解だと時間というリソースを消費するし、不具合の温床にもなる。

ではきれいなコードの条件とは何か。

・同じ処理はまとめる

同じ処理が繰り返し書かれていると、コードが読みづらく修正時に修正箇所が多くなってしまう。

ロジックに変更が生じた場合に、多くの既存コードを修正することになり、その分修正漏れが生じる可能性が高くなる。

ミスを減らすにはコードを書かない方が良い（※有名著リーダブルコードより）のでまとまった処理はメソッドとして抽出し、処理部で呼び出す方が良い。

・ネストは浅くする

if文などでネストが複雑に組み合わさっているとネストが深くなって、条件が理解しづらくなってしまう。

修正時の閉じ括弧や閉じタグの漏れにも繋がる。

必要であればメソッド化するなどして、読みやすい条件にするべきである。

変数名・関数名をわかりやすくする

名前だけでどんな変数or関数なのか想像できるようなネーミングにすること。

名前で役割や処理がわからないような名前は、その後の処理もわかりづらくしてしまう可能性がある。

 

 

リファクタリングとは

読みづらいコード、わかりづらいコードをきれいなコードに修正すること。

機能の追加やバグ修正をするわけではなく、内部的な機能は変えずに、理解や修正が簡単になるようにコードのみを修正する。

タイミングは開発中に見直した時でも、時間をとって見直した時でも良いが、もっとわかりやすく短く書けないか（短くてもわかりづらくては意味がない）を考えながら、問題のありそうな箇所を見つけ、わかりやすいコードに変更する。

 

 

実際にリファクタリングしてみた

直近で開発していたPHPアプリケーションで実際にリファクタリングを行ってみた。

以下はデータベースのcategoriesというテーブルの行数と、categoriesテーブル内のidとnameカラムの内容をコレクションとしてそれぞれ変数へ代入するという処理である。

-        $numrecord = DB::table('categories')->count();
-        $categories = DB::table('categories')->pluck('id', 'name');
+        $cat_record_count = DB::table('categories')->count();
+        $cat_id_name = DB::table('categories')->pluck('id', 'name');

git log の出力であるため、行頭の"-"が変更前、"+"が変更後である。

変更前はnumrecord、categoriesといった抽象的で、変数の中身を推測しづらい名前だったため、処理のわかりやすさという点を意識して変数名を変更した。

まだまだ筆者のセンス不足を感じる点もあると思うが、変更前よりはわかりやすくなった。

他のコードも含めてまだまだ改善の余地があると思うので今後もリファクタリングは気付いた時に随時行って、未来の自分が見て即時に理解できるコードを書くようにしていきたい。

 

WEBアプリケーションの設計方法について調べてみた【フロント編】

Laravelで自作WEBアプリを作ってみて、その場その場の思いつきでアプリ開発を進めていることに気がついた。

DBの設計をメモ書き程度ではあるがやっていたにも関わらず、ビューやコントローラについては命名規則も、役割分担も無く完全にその場の思いつきで機能追加を行なっていた。

そもそも学生時代からアプリの設計などやったことがなかったし、思いつきもしなかった。

ここで、アプリケーション開発の設計方法について調べてみたので自分用にまとめていきたい。

 

1. ワイヤーフレームを書く

WEBサイトの画面レイアウトを記載した図面。「どこ」に、「何」を配置するのか記載する。レイアウトの詳細は以下のページへ。

 

websae.net

 

 

ex1. ディレクトリマップ

webサイトを構成するページを、階層ごとにまとめたもの。

どのページがどのページにぶら下がっているのかを明示して階層をわかりやすくし、URLやタイトルを記載する。

ワイヤーフレームとは別に用意するのが望ましい。 

 

 

2.ワイヤーフレームの作り方

実際のワイヤーフレームの作り方についてまとめていく。

盛り込むべき情報を精査し、その後にレイアウト作業に入っていくという順で作成する。

2-1.ピックアップ

ピックアップとはそのサイトに載せるべき情報をひたすら上げていくことである。

「電話番号」、「バナー画像」、「広告」など、そのサイトに必要な情報を列挙していく。

あとで整理するため、ここでまとまっている必要はない。

2-2.グルーピング

ピックアップで列挙した項目で似た内容のものをグループ化していく。

「電話番号」と「住所」は「連絡先グループ」や、「会社名」と「会社ロゴ」は「会社情報グループ」などのまとまりでグループ化していき、

情報の分散に留意してグループ化を行う。

2-3.ランキング

グループ化した項目に優先順位をつける。

webサイトの目的に沿って優先順位をつけ、そのサイトの前面に出したい情報を精査する。

例えば、コーポレートサイトであれば、会社名や会社ロゴなどの情報をもつ「会社情報グループ」に高い順位をつけ、 コミュニティサイトなどの場合は会社情報は目立たない方が好ましいので低い順位とするなど。

 

 

3.情報をレイアウトする

ランキングまでに精査した情報を元に、webサイトの目的や機能性を意識してレイアウトを確定していく。

レイアウトはその時代ごとのトレンドなどにも留意する必要がある。

以下からレイアウトに関する用語についてまとめていく。

3-1.ヘッダー

webサイトを訪れた人が最初に目にする画面である。

メインとなるビジュアルやロゴを配置する場合が多い。

3-2.フッター

サイトの最下部のことである。

ここには規約や会社情報など、よく使わないにしろ重要な項目を置く。

3-3.グローバルナビゲーションバー（ナビバー）

webサイトのどのページにも配置される、よく使うメニューを配置するバーである。

3-4.サイドバー

メインコンテンツの横に表示されるバー。

ブログサイトなどでよく用いられる関連記事、最新情報やプロフィールページなどへのリンクを配置する。

 

 

4.まとめ

今回はフロントエンドにおけるwebサイトの設計についてまとめた。

ワイヤーフレームや、ディレクトリマップはwebアプリケーション設計において、後からこのページが必要だった！となることを防いだり、事前にレイアウトを提示して打ち合わせで活用する手段となる。

今後は自主制作においても活用して実務で対応できるよう備えていきたい。