HTML5のdraggable属性とjavascriptを使用して自由にドラッグドロップできるようにしました。

下のコードを完コピしてもらえれば確認していただけると思いますが、

左側にドラッグ対象の要素(numberBox)が縦に20個並んでいるボックス(drop_back_box)があり、

右側には横長のボックス(dropBox)が縦に5個並んでいます。

numberBoxをdropBoxやdrop_back_boxにドラッグ・ドロップするのは簡単にできたのですが、

dropBoxに複数ドロップされたnumberBox間で左右にドラッグドロップできるようにするのに

かなり手こずってしまいました。

ドロップされたnumberBox間で左右にドラッグドロップするためにはnumberBox自体に

ondrop属性を持たせてjavascriptのinsertBeforeを使用することで簡単にできました。。。
こんな簡単なことをなぜすぐに気づかなかったのか。。。

HTML5のdraggable属性はドラッグした要素やドロップ先の要素の情報を取得できるのでかなり便利です。

コードは下記の通りです！

<style>
.left_box {
    width: 110px;
    height:700px;
    background:#fff;
    margin-right: 56px;
}

.drag_box {
    width: 100px;
    height: 30px;
    background: red;
    margin: 2px;
}

.right_box {
    background: #fff;
    height: 700px;
    width: 110px;
}

.drop_box {
    width:800px;
    height:38px;
    margin:2px;
    background:yellow;
    display: flex;
}
</style>

<!-- 左のボックス -->
<div style="display:flex;">
    <div class="left_box">
        <div class="drop_back_box" ondragover="dragover(event)" ondrop="dropBack(event)">
            <?php for ($i=1; $i < 21; $i++): ?>
                <div class="drag_box" id="numberBox<?php echo $i; ?>" draggable="true" ondragstart="f_dragstart(event)" ondrop="dropLR(event)">
                    ナンバー：<?php echo $i; ?>
                </div>
            <?php endfor; ?>
        </div>
    </div>


<!-- 右のボックス -->
    <div class="right_box">
        <?php $i=1; for($i=1; $i < 6; $i++): ?>
            <div id="dropBox<?php echo $i; ?>" class="drop_box" ondragover="dragover(event)" ondrop="drop(event)">
            </div>
        <?php endfor; ?>
    </div>

</div>

<script>
/***** ドラッグ開始時の処理 *****/
function f_dragstart(event){
    //ドラッグするデータのid名をDataTransferオブジェクトにセット
    event.dataTransfer.effectAllowed = 'move';
    event.dataTransfer.setData("text", event.target.id);
}

/***** ドラッグ要素がドロップ要素に重なっている間の処理 *****/
function dragover(event){
    event.dataTransfer.effectAllowed = 'move';
    //dragoverイベントをキャンセルして、ドロップ先の要素がドロップを受け付けるようにする
    event.preventDefault();
}

/***** 右のボックスにドロップ時の処理 *****/
function drop(event){
    // ドラッグされたデータのid名をDataTransferオブジェクトから取得
    const boxId = event.dataTransfer.getData("text");
    const numberBox = document.getElementById(boxId);
    const dropBox = event.currentTarget;
    dropBox.appendChild(numberBox);
    // エラー回避のため、ドロップ処理の最後にdropイベントをキャンセルしておく
    event.preventDefault();
};

function dropLR(event){
    // ドラッグされたデータのid名をDataTransferオブジェクトから取得
    const draggedEleId = event.dataTransfer.getData("text");
    // ドラッグされた要素を取得
    const draggedElement = document.getElementById(draggedEleId);
    // ドロップされた要素を取得
    const dropedElement = event.currentTarget;
    // ①ドロップ先の親要素のid名を取得
    const dropedParentId = event.currentTarget.parentNode.id;

    const dropBox = document.getElementById(dropedParentId);


    // 左のボックスに戻す時以外は要素間の左右にドロップできる処理
    dropBox.insertBefore(draggedElement, dropedElement)

    // エラー回避のため、ドロップ処理の最後にdropイベントをキャンセルしておく
    event.preventDefault();
    event.stopPropagation();
};


// 左のボックスにドロップする処理
function dropBack(event){
// エラー回避のため、ドロップ処理の最後にdropイベントをキャンセルしておく
    event.preventDefault();
}
</script>

まだまだ自分の応用力のなさを痛感してばかりですが、これからもプログラミング頑張ろうと思います！

EMOEMOはこちら

はじめに

こんにちはてらです！
簡単に自己紹介をするとごみくずプログラミング初学者です。(３ヶ月目)
現在個人開発中のWEBサービス（EMOEMO）をデプロイする予定だったのですが、想定外のバグが発生し、
デプロイはもう既にしているのですが公開できない状態に陥りました。やっと修正を終えたのでお披露目したいと思います。
では早速！

EMOEMO：↓LP部分

目次

• EMOEMOとは？別記事で紹介しています。こちらから
• 一番大変だった所
• 二番目に大変だった所
• 課題点
• 今後の予定

一番大変だった所　！加筆予定！

tweetを送信するだけじゃなく、画像も持たせることができたらより良いと思い実装しようと試みました。この機能の実装は闇が深く一番大変でした。どう大変だったのかについて書くとこれだけで、読みたくなくなるような分量になってしまいます。ですので、あとでコード等は使わずに図でこんなことしてるよ！っていうのを紹介がてらしてみようと思います。

二番目に大変だった所

自分のPC（ローカル）の中で、動かしている状態から実際にサーバー（heroku）にアップロード（デプロイ）をすると今まで使えていた便利機能（ライブラリ）が読み込まれなかったり、画面がうまく表示されなかったりして、滅茶苦茶大変でした。少し具体的に話すとtwitterキーを受け取れてはいるのですがそれをデータベースに保存できなくてコードを変更しました。

課題点

とにかく画面のデザイン（フロントエンド）がゴミカスレベルなのでまともになるように色々手を加えていこうと思っています。その間に皆さんに使ってもらって、こんな機能あったら良いなみたいな要望があったらQiitaのコメントでもtwitterのDMでも良いのでメッセージください！
使ってみてもらって感想までもらえたら僕は嬉しいです！

Twitterアカウント

今後の予定

• 見た目やボタンの配置（フロントエンド周り）の実装をする
• 皆さんの反応次第で機能の追加
  • 画像の削除機能の追加

この２点を主軸にして開発を進めていこうと思います。画像の削除機能については必須だと思うので実装します！

最後に！！！！！

もし最後まで読んでくださっている方がいたら良いねをお願いします！よろしくお願いします！
またね！

EMOEMOはこちら

この記事について

Laravel は Policy や FormRequest など、Controller を補佐するモジュールを多く提供しているので Fat Controller になりにくいとは思いますが、それでもときどき Fat Controller に出くわすことがありますので、それらを防ぐために使えるテクニックというか、Tips を5つばかり紹介したいと思います。

はじめに

Fat Controller とは？

簡潔にいえば、行数が多く（個人的には Controller だとひとつのメソッドが NCLOC で 50 行を超えると Fat 感を感じます、みなさんはいかがでしょうか）、行数が多いがために処理の流れを追うことが難しく、しばしば不具合の原因になるクラスのことをいうのだと思います。本記事では、ただ行数が多いというだけでなく、複数のメソッドで処理が重複していたり、メソッドの中で条件分岐が発生したりして、ひとつの変更が他の部分に及ぼす影響を検知しづらい状態にあるコントローラーを想定しています。

巨大なクラスであっても、そこに含まれるデータや関数が高凝集・低結合であれば問題ないと考えます。大事なのは「不具合の原因になる」ということであって、すべての巨大なクラスが悪である、ということではないと思っています。

Fat Controller の問題点

• 【長すぎるメソッド】ひとつひとつのメソッドが長く、処理の流れを追うことが難しい。それによって、局所的な変更が処理全体に影響することがあり、予期せぬ不具合が発生することがある
• 【処理の重複】Controller 間で処理が重複することによって、仕様変更によるコードの変更が漏れ、予期せぬ不具合が発生することがある
• 【単一責任原則違反】複数のパターンを同一の Controller で処理することによって、ひとつのパターンに関する変更が他のパターンへ影響することがあり、それによって予期せぬ不具合が発生することがある

Fat Controller になる主な要因として、Model 層が貧弱すぎる、ということが考えられます。本来 Model に書くべき処理を Controller に書いてしまっており、結果的に可読性が悪くなったり、ひとつのユースケースに対する変更が他のユースケースに影響を及ぼしたり、Controller 間でのコピペコードを量産したり、ということが起きます。

Fat Controller を防ぐ 5 つの Tips

1. リクエストのデータを処理する関数は FormRequest に書く
2. レスポンスのデータを処理する関数は ViewModel あるいは Resource に書く
3. シングルアクションコントローラーにする
4. 複数の Controller に分離する
5. UseCaseInteractor を使う

1. リクエストのデータを処理する関数は FormRequest に書く

public function search(Request $request) {
    if (isset($request->query('name'))) {
        $whereParams['name'] = $request->query('name');
    }
    return User::where($whereParams)->get();
}

みたいなリクエストパラメータの有無によって処理が分岐していくパターンです。上の例はひとつだけですが、これがずらっとあったり、if 文の中の条件が複雑になってくるとだいぶ読みにくくなってきます。

そこで、これらの処理は FormRequest 側へ移します。

// Controller
public function search(SearchUserRequest $request) {
    return User::where($request->filters())->get();
}

// FormRequest
public function filters(): array {
    $filters = [];
    if (isset($this->query('name'))) {
        $filters['name'] = $this->query('name');
    }
    return $filters;  
}

処理をただ他のクラスに移しただけじゃねーか、と思われるかもしれませんが、FormRequest へ移動することのメリットは、モデルに渡す入力パラメータの構築にのみ注力できる、ということで、たとえば、バリデーションルールは FormRequest に書いてあるでしょうから、入力パラメータが増えたりしたときに、FormRequest のみを変更すればよい状態にしておくと、変更漏れが起こりにくいんじゃないかと思います。また、複数のモデルに対して連続して処理するような変更が起こった場合にも、どれがどのモデルに関連するパラメータなのか、区別がつきやすくなると思います。

public function search(SearchUserRequest $request) {
    $users = User::where($request->userFilters())->get();
    $anotherModels = AnotherModels
        ::whereIn('user_id', $users->pluck('id'))
        ->where($request->anotherFilters())
        ->get();
    return ['users' => $users, 'anotherModels' => $anotherModels];
}

2. レスポンスのデータを処理する関数は ViewModel あるいは Resource に書く

public function index() {
    $users = User::where(...)->get();
    foreach ($users as $user) {
        $user->full_name = $user->family_name . ' ' . $user->given_name;
    }
    return view('user.index', compact('users'));
}

上の例はゲッターでやるほうがいいかなと思いますが、いい例を思いつかなかったのでご容赦を。

要は、Controller で受け取った Model からの戻り値を、View に渡す前に加工しなければならないケース、ということです。

// Controller
public function index() {
    $users = User::where(...)->get();
    $viewModel = new UsersViewModel($users);
    return view('user.index', ['users' => $viewModel->users()]);
}

// ViewModel
public function __construct(array $users) {
    $this->users = $users;
}
public function users(): array {
    return array_map([$this, 'transform'], $this->users);
}
private function transform(User $user): array {
    return [
        'id'   => $user->id,
        'name' => $user->family_name . ' ' . $user->given_name,
    ];
}

transform が返すのはオブジェクトにしてもいいでしょう。変換ロジックを書き換えたければ、 Controller 側で差し替えられるようにすると柔軟性が出ます。

// Controller
$viewModel = new UsersViewModel($users, new SummaryUserTransformer);

// ViewModel
public function __construct(array $users, UserTransformerInterface $transformer = null) {
    $this->users = $users;
    $this->transformer = $transformer ?? new DefaultUserTransformer;
}
public function users(): array {
    return array_map($this->transformer, $this->users);
}

// Transformer
public function __invoke(User $user) {
  return [
      // ...
  ];
}

3. シングルアクションコントローラーにする

シングルアクションコントローラーとは、 __invoke メソッドを持つ、特定のルーティングと対になる Controller クラスのことです。

ルーティングの書き方に特徴があります。

通常は Route::get('/', 'HomeController@index') のように @ の前にクラス名、後にメソッドを書きますが、シングルアクションコントローラーの場合は Route::get('/', 'HomeController') のようにクラス名のみ指定します（呼び出し時には自動的に __invoke が呼ばれます）。

いわゆる CRUD と呼ばれる処理は、 index/create/store/show/edit/update/delete の中から必要なメソッドを選択して使えばいいですが、それ以外のメソッドは、シングルアクションコントローラーにしておくと、クラスがスッキリすると思います。

4. 複数の Controller に分離する

複数の異なるユースケースを1つのアクションメソッドにまとめてしまうと、パターンによる条件分岐が必要になるため、Fat Controller になりがちです。

もし、Controller 内に、リクエストに応じて処理を分ける、みたいな条件分岐があるようであれば、複数の異なるユースケースをまとめてしまっている可能性があるので、分離できないか検討してみます。

public function __invoke(SearchUserRequest $request) {
    if ($request->is_special) {
        $users = User::searchSpecial($request->specialFilters())->get();
    } else {
        $users = User::search($request->filters())->get();
    }
    // ...
}

これを2つの Controller に分離してしまいます。

// SpecialContext\SearchUserController
public function __invoke(SearchUserRequest $request) {
    $users = User::searchSpecial($request->filters())->get();
    // ...
}
// GenericContext\SearchUserController
public function __invoke(SearchUserRequest $request) {
    $users = User::search($request->filters())->get();
    // ...
}

必要なら Model も分けてしまってもいいかもしれません。

// SpecialContext\SearchUserController
// use SpecialContext\User
public function __invoke(SearchUserRequest $request) {
    $users = User::search($request->filters())->get();
    // ...
}
// GenericContext\SearchUserController
// use GenericContext\User
public function __invoke(SearchUserRequest $request) {
    $users = User::search($request->filters())->get();
    // ...
}

クラスは同じで「別のアクションメソッドに分離する」というのもオッケーですが、CRUD 以外はシングルアクションコントローラーにする、というルールにするなら、Controller を分けることになるでしょう。

5. UseCaseInteractor を使う

UseCaseInteractor はクリーンアーキテクチャの一部で、アプリケーションへの入力（リクエスト）を受け取って中核となる処理を行い、ビュー（あるいは API レスポンス）へのアウトプットを生成するクラスです。

参考）Laravelでクリーンアーキテクチャ - Qiita #UseCaseInteractor

上の例では UseCaseInteractor は値を戻さず、Middleware のプロパティに直接渡す方式を取っていますが、本記事ではそのまま戻すようにしています（名前も簡略化して UseCase としています）。

// Controller
public function __invoke(SearchUserUseCase $useCase, SearchUserRequest $request) {
    $users = $useCase->invoke($request->filters());
    $responder = new UsersResponder($users);
    return $responder->createResponse();
}
// UseCase
public function invoke(array $filters) {
    return User::where($filters)->get();
}
// Responder with Blade view
public function createResponse() {
    $viewModel = new UsersViewModel($this->users, new SummaryUserTransformer);
    return view('user.index', ['users' => $viewModel->users()]);
}
// Responder with API resource
public function createResponse() {
    return UserResource::collection($this->users);
}

UseCase 内に処理を閉じ込めることで、Controller をスリムに保つことができます。このクラスに渡すデータは、HTTP の世界の情報はプリミティブなデータ、あるいはドメインオブジェクトに変換しておくのがいいと思います。

おわりに

いかがでしたでしょうか。例がシンプルすぎていまいちピンとこないかもしれませんが、Fat Controller を解消したいとお悩みの方の一助になれば幸いです。

他にも Fat Controller 解消法をお持ちの方、コメント欄にて教えていただけると大変助かります

次回は「Laravel で Fat Model を防ぐ 5 つの Tips」をお送りしたいと思います。

2020-02-17 10:38 追記
大事なことが抜けていたので補遺を書きました。
Laravel で Fat Controller を防ぐもうひとつの Tip - Qiita
追記ここまで

はじめに

• こちらの記事の続きです
  • VSCodeのおすすめプラグイン（CakePHP開発用）
• ここでは、私がCakePHP開発時に設定しているVSCodeの設定（settings.json）を紹介します
• 設定はCakePHPのコード規約に沿うよう、なっております（たしか）

VSCode設定値

settings.json

{
    // ナビゲーション階層リンクを有効にする
    "breadcrumbs.enabled": true,
    // エディタの#editor.tabSize#と#editor.insertSpaces#の設定を強制する
    // 例）インデントがTABのファイルを開き編集した際に、TABキーでスペース4つの設定をしていたとしてもTABを入れる機能を無効
    "editor.detectIndentation": false,
    // 貼り付けた内容をエディタにより自動的にフォーマットする
    "editor.formatOnPaste": true,
    // エディタでアクティブなインデントのガイドを強調表示する
    "editor.highlightActiveIndentGuide": true,
    // Ctrlキーを押しながらマウスホイールを使用してエディタのフォントをズームする
    "editor.mouseWheelZoom": true,
    // マウスを使用して複数のカーソルを追加する時に使用する修飾キーをCtrlキーに割り当てる
    "editor.multiCursorModifier": "ctrlCmd",
    // エディタで制御文字を表示する
    "editor.renderControlCharacters": true,
    // エディタで単語間の単一のスペースを除く空白文字を表示する
    "editor.renderWhitespace": "boundary",
    // 80文字に垂直ルーラーを表示する
    "editor.rulers": [
        80
    ],
    // ドラッグアンドドロップを使用したファイルやフォルダーの移動時にエクスプローラーが確認を求めない
    "explorer.confirmDragAndDrop": false,
    // TABキーを押したときにEmmet省略記法を展開する
    "emmet.triggerExpansionOnTab": true,
    // Emmetのスペニットで使用される言語を日本語に指定する
    "emmet.variables": {
        "lang": "ja"
    },
    // エディタがフォーカスを失った時点で、ファイルを自動的に保存する
    "files.autoSave": "onFocusChange",
    // 規定の改行文字をLFにする
    "files.eol": "\n",
    // ファイルの保存時に最新の行を末尾に挿入する
    "files.insertFinalNewline": true,
    // ファイルの保存時に最終行以降の新しい行を削除する
    "files.trimFinalNewlines": true,
    // ファイルの保存時に末尾の空白を削除する
    "files.trimTrailingWhitespace": true,
    // 言語モードがMarkdownに対してファイルの保存時に末尾の空白を削除しない
    "[markdown]": {
        "files.trimTrailingWhitespace": false
    },
    // 現在のGitリポジトリの規定のリモートから自動的にコミットをフェッチする
    "git.autofetch": true,
    // Gitリポジトリを同期する前に確認しない
    "git.confirmSync": false,
    // プラグイン「PHP IntelliSense」用、PHP 7以降の実行可能ファイルへのパス
    "php.executablePath": "C:/xampp/php/php.exe",
    // プラグイン「phpcbf」用、phpcbfのパスを指定する
    "phpcbf.executablePath": "C:/Users/xxxxx/AppData/Roaming/Composer/vendor/bin/phpcbf.bat",
    // プラグイン「phpcbf」用、使用するコーディング標準をCakePHPにする
    "phpcbf.standard": "CakePHP",
    // プラグイン「phpcs」用、phpcsのパスを指定する
    "phpcs.executablePath": "C:/Users/xxxxx/AppData/Roaming/Composer/vendor/bin/phpcs.bat",
    // プラグイン「phpcs」用、診断メッセージにsniffのソースコードを表示する
    "phpcs.showSources": true,
    // プラグイン「phpcs」用、使用するコーディング標準をCakePHPにする
    "phpcs.standard": "CakePHP",
    // プラグイン「SQL Formatter」用、キーワードを大文字に変換する
    "sql-formatter.uppercase": true,
    // 代替的なDOMベースのレンダラーを使用する
    "terminal.integrated.rendererType": "dom",
    // ウィンドウのズームレベルを1に指定する
    "window.zoomLevel": 1,
    // プラグイン「One Dark Pro」用、ワークベンチで使用するカラーテーマを指定する
    "workbench.colorTheme": "One Dark Pro",
    // プラグイン「file-icons」用、ワークベンチで使用するアイコンのテーマを指定する
    "workbench.iconTheme": "file-icons"
}

おわりに

• VSCodeに設定を追加してコード修正して保存した際に、コード差分に想定していなかった変更が現れるのは あるあるだと思います
  （スペースのみの行がスペース消えてるみたいな）
• この記事が他のエンジニアの参考になれば幸いです

参考

• Visual Studio Code – コード エディター | Microsoft Azure

はじめに

• VSCode（version:1.42.1）でCakePHP3の開発をするにあたり、いろいろ試してみて私が採用しているプラグインをざっくり紹介します（n番煎じ）
• 詳細な設定は、各プラグイン名にVSCodeのマーケットプレイスのリンクを張っておりますので、そちらからご覧ください
• 環境はWindows 10を想定しています
• VSCodeのオススメ設定（settings.json）については別記事で紹介しようと思います （未着手）
  • ⇒　VSCodeのおすすめ設定（CakePHP開発用）

ざっくりプラグイン紹介

1. Auto Rename Tag
   • 言語モード（右下の右から3番目くらいの項目）がHTMLの時、タグを変更すると閉じタグも同時に変更してくれる
2. Bookmarks
   • Ctrl+Alt+kでコード行にブックマーク
   • Ctrl+Alt+lでファイル内のブックマーク行にジャンプ
   • ソースを追うのに便利
3. Brancket Pair Colorizer
   • カッコのペアは同色、別カッコは別色で表示するため、if文の複数の条件等で間違えにくい
4. Code Spell Checker
   • 英語のスペル誤りを下線（波線）で表示してくれるため、正しい命名ができる
5. Color Highlight
   • HTMLカラーコードの記述（#00008b等）で、文字背景をその色で表示するため、すぐ色の確認ができる
6. Docker
   • PowerShell等でコマンドを入力しなくても、右クリックでコンテナに入ったりログを確認したり、いろいろできる
     ※Docker for Windowsのインストールが必要
7. Excel to Markdown table
   • 言語モードがMarkdownの時、Excelのセルコピーを、Shift+Alt+VでMarkdownのテーブル形式で貼り付ける
   • 簡単にREADME.mdやRedmine、Backlogで表を作成できる
8. file-icons
   • サイドバーのファイルツリーのファイル名の横に、ファイルに対応するアイコンを表示する
   • 何のファイルかが直感的にわかる
   • setting.jsonに以下を追加する
     • "workbench.iconTheme": "file-icons",
9. gettext
   • 翻訳ファイル.po、.potのシンタックスハイライトをしてくれる
10. Git History
    • Gitのコミット履歴の一覧や、コミットログの検索が、コマンドを入力することなくVSCodeのGUI上でできる
      ※Gitのインストールが必要
11. GitLens
    • コードをクリックすると、その行をいつ、誰が、何のコミットメッセージをしたのかを表示する
    • 戦犯がすぐわかる（つらい）
      ※Gitのインストールが必要
12. Japanese Language Pack for Visual Studio Code
    • VSCodeが日本語で表示される
13. Japanese Word Handler
    • 日本語の選択時（Ctrl+Shift+矢印）に、日本語の単語単位で移動できる
14. Log File Highlighter
    • 言語モードがLogの時、カラー表示する
    • 内容が見えやすくなる
15. Markdown All in One
    • 言語モードがMarkdownの時、編集時に入力補完してくれる
    • Ctrl+bでBold体にする等のショートカットキーもある
    • 今の記事作成にも役立っている
16. Markdownlint
    • 言語モードがMarkdownの時、編集時にスタイルチェックをしてくれる
    • ルールに適さない入力は下線（波線）で表示される
    • 箇条書きのスペース4つは下線が出るが、私は無視している（backlogのリスト表示が正しくできないので）
17. nginx.conf
    • nginxの設定ファイル（.conf）をシンタックスハイライトしてくれる
18. One Dark Pro
    • Atomエディタと同様のテーマ（背景色やシンタックスハイライト色）を反映する
    • テキスト選択すると一致箇所を強調してハイライトしてくれるところがGood
    • setting.jsonに以下を追加する
      • "workbench.colorTheme": "One Dark Pro",
19. Output Colorizer
    • VSCodeが出力するログをカラー表示する
20. Path Autocomplete
    • ディレクトリパスの補完をしてくれる
    • パス記述誤りが減る
21. PHP Debug
    • PHPファイルのコードにブレークポイントを設定し、デバッグを行える
      ※PHPのインストール、XDebugのインストールが必要
22. PHP DocBlocker
    • メソッドコメントを補完してくれる
23. PHP import checker
    • インポートしている未使用のクラスを強調表示してくれる
    • 自分が追加した覚えのあるクラス（use Xxx/Yyy;）のみを削除するようにしている
24. PHP IntelliSense
    • PHPのコード補完やメソッドの引数のヘルプをホバー表示する等、いろいろしてくれる
      ※PHPのインストールが必要
    • setting.jsonに以下を追加する
      • "php.executablePath": "C:/xampp/php/php.exe", // php.exeへのパス
25. phpcbf
    • PHPのコード静的解析を行ってくれる
    • Shift+Alt+Fでコードを自動できれいにしてくれる
      ※Composer、Composerを利用してphpcsのインストールが必要
    • setting.jsonに以下を追加する
      • "phpcbf.executablePath": "C:/Users/xxxxx/AppData/Roaming/Composer/vendor/bin/phpcbf.bat", // phpcbf.batへのパス
      • "phpcbf.standard": "CakePHP",
26. phpcs
    • PHPのコード静的解析を行ってくれる
    • インデントずれている、スペースがない、等の箇所に下線（波線）を表示する
      ※Composer、Composerを利用してphpcsのインストールが必要
    • setting.jsonに以下を追加する
      • "phpcs.executablePath": "C:/Users/xxxxx/AppData/Roaming/Composer/vendor/bin/phpcs.bat", // phpcs.batへのパス
      • "phpcs.standard": "CakePHP",
27. Rainbow CSV
    • 言語モードがCSVの時、要素の位置ごとに色が決められて表示するため、同列の値が直感的にわかりやすい
28. Regex Previewer
    • 入力している正規表現の一致を、適当な文字列と並べて確認できる
    • 正規表現が正しく書けているかリアルタイムでテストできる
    • 確認時に正規表現の後ろにgmをつけることを忘れない（/正規表現/gm）
29. Sort lines
    • 文字列の羅列を右クリックでソートできる
    • Excelを使うまでもない、簡単なソートがしたい時に利用
30. SQL Formatter
    • 言語モードがSQLの時、SQL文を貼り付けると、きれいにフォーマットして表示してくれる
    • 長くて複雑なSQLも見やすくできる
    • ログに出力されているSQLの解読に便利
31. TODO Highlight
    • TODO:を強調表示してくれる
    • 別作業で時間を開けてしまう時に「TODO: 内容」と記載しておくことで忘れにくい
32. zenkaku
    • 全角スペースを強調表示してくれる
    • 全角スペースで動かないSQLやプログラムに、悩まされずに済む
33. テキスト校正くん
    • 日本語の文章をチェックしてくれる
    • ですます調・だである調の混在や、同じ助詞の繰り返し等があると、下線（波線）を表示する
    • 和文に半角文字や外来語カタカナ表記には伸ばし棒（マスター等）で下線が出るが、私は無視している（マスタを伸ばすのは好みではないので）

おわりに

• プラグインの利用にあたっては、本当にたくさんの記事を参考にさせていただきましたので、ここで感謝いたします
  （昔参考にしていた記事が見つからなかった…）
• 開発言語が変わっても、コード静的解析、コード自動補完、デバッグ系以外のプラグインは流用が利くことを改めて気づきました
• この記事が他のエンジニアの参考になれば幸いです

引用URL元

• Extensions for Visual Studio family of products | Visual Studio Marketplace

本文

PostgreSQLを支持する議論

Martin Langhoff が PostgreSQLを支持すると主張（出典：Moodle over webct および LNLS at Athabasca University？フォーラムの投稿）

Postgresを使用する理由

Postgres を使用する理由はいくつかありますが、概要を簡単に説明します。 Catalystではさまざまな RDBMS を実行しており、Oracle、Postgres、MySQL、Progress、その他いくつかの社内経験があります。また、レプリケートされたデータベース、クラスタリング、およびその他のトリックの経験もあります。これらは、.nzルートドメインサーバーのバックエンドと、他のいくつかのミッションクリティカルなシステムに使用します。

パフォーマンスの面では、Postgres は MySQL よりも少し前もって設定する必要があります。適切に調整されたPostgresは、小さなデータベースでの MySQL の SELECT パフォーマンスにかなり近いものです。大きなテーブルでは、MySQL のパフォーマンスにいくつかの悪い問題があり、Postgres のパフォーマンスははるかに優れています。

書き込みパフォーマンスも MySQL の問題です。大量のトラフィックがあるため、同時書き込みに深刻な問題があります。負荷が高い場合、Postgres のパフォーマンスはたいへん優れています。

しかし、実を言うと、Postgres を選択する本当の理由は信頼性です。多くのデータベースを維持しており、Postgres は堅実で信頼性が高く、ACID の正確性に重点を置いています：コミットから戻ったとき、データはディスク上に安全にあり、失われません-実際のディスクの問題はありません RAID-1 を使用してオフセットします。

どんなに一生懸命試してみても、使用頻度の高い MySQL データベースには繰り返しインデックス破損の問題があります。ほとんどの Linux ディストリビューションで MySQL のスタートアップスクリプトを見ると、すべてのスタートアップでデータ破損をチェックします。これは、頻繁に発生するという事実を隠すためです。

また、これはデータがミッションクリティカルではない小規模なインストールではまずまずですが、そのようなアプローチをどれだけ信頼できるかを考慮する必要があります。また、大規模なデータセットでは、isamchk/myisamchkの実行に数時間かかる場合があります。

MySQLのクラスタリングソリューションは大々的に宣伝されており、私はそれが人を惑わす情報だと思います。私の主な懸念は、「非同期」に書き込むことです。つまり、データが安全にディスク上にあるという保証はありません。いつかディスクに到達します。それは slave に届きます...いつか。うーん。

MySQLクラスターが非同期書き込みを使用していることを考えると、マスターとスレーブの間で読み取り/書き込みを分割すると、データを書き込み、すぐに（または直後に）読み取ることができます。そして、これはかなりの数の場所で起こります。

また、非同期書き込みを使用することでパフォーマンスが向上することも考慮する必要があります。スタンドアロンのPostgres または MySQL に非同期書き込みを使用するように指示すると、スケーラビリティが大幅に向上します（最大 3〜4 倍の同時書き込みを処理できるはずです）。これを実行すると、MySQL クラスターのパフォーマンス上の利点はほとんどなくなります。マスターがダウンした場合でも、セミホットテイクオーバーが行われますが、PostgresはSlony を使用してそれを行うことができ、スレーブ内のデータの一貫性をより良く保証します。

簡単に言えば、MySQL は、理論的にはデータが保存されていることを保証していても、データをディスク上に安全に保存することに関しては、通常あまり堅固ではありません。また、MySQL Clusterは、保証はもうないということを前もって言っています。そーですよー。ウィンク。

マイケルは UPS について話しています。車サイズの UPS と、自動起動するコンテナサイズのオンサイト発電機があります。それでも、大規模なインストールでの DB の一貫性については、これに依存しません。電力以外の多くの事柄が失敗する可能性があります（実際にそうなっています）。プロセスにデータの保存に問題がある場合、正しいことはそれをユーザーに伝えることです。非同期書き込みでは、まだ保存されていないデータのキューが作成されますが、既にユーザーにそのことを伝えています。

これは、データベースが行うべきことではありません。

現在、livejournal や slashdot で使用されているものと同様のテクニックをいくつか検討しています。 DB の負荷を約50％削減することで、Moodle のスケーラビリティを向上できるはずです。これは、より緊急なプロジェクト間のギャップでゆっくりと起こっています。あなたがそのトラックに興味があるなら、リチャードまたは私に ping を送ってください。

Open University は Postgres を使っている

Moodle のハードウェアパフォーマンスフォーラム への Tim Huntの投稿では、Open University はそれが最高のデータベースであるために、Postgres を使っています。

関連項目

Installing Postgres on Ubuntu(Debian)
MySQL vs. Postgres in Mahara (Mahara is a webapp built in a very similar manner to Moodle, all the arguments there apply to Moodle too).

カテゴリ:管理者｜Performance（翻訳準備中）｜ Open University（翻訳準備中）
メインページ

原文

Ajax marking block

AJAX marking block はあなたの全てのマーキングをあなたがいるページを去ることなしに見てグレードすることができるものです。あなたが教えている全てのコースの木構造においてあなたがマークすべき全ての ungraded work とともにそれぞれのコースと評価アイテムにそれがいくつあるかという数を表示します。アイテムをクリックすることで grading がポップアップし、それをした時に木は自身をアップデートしますので、あなたは何が残っているかを追跡することができます。

内容

1 自分に合った方法で marking を優先する
1.1 特定のクラスのために全ての work をマークする
1.2 もっとも緊急な work をマークする
1.3 一つの質問に迅速に連続して全てに答えることでより速くクイズをマークする
2 あなたが必要とするものだけをマークしその他を隱す
2.1 あなたがマークしなければいけない活動のための work のみを表示する
2.2 あなた自身の teaching groups のための work のみを表示する
3 インストール
3.1 Zip ファイル
3.2 Git
4 トラブルシューティング
5 サポートされるタイプ
6 関連項目

1 自分に合った方法で marking を優先する

1.1 特定のクラスのために全ての work をマークする

ブロックは、ワークフローを考慮して構築されています。クラスが予定されており、マーキングを完了する必要がある場合は、コホートタブを使用して、コース全体のすべての作業を確認します。コホートを使用していない場合は、設定タブを使用するか、表示されているアイテムを右クリックして、興味のあるコースまたはアクティビティを「グループノードの表示」に設定します。これにより、作業が各グループの個別のノードに分割され、それらだけをマークできます。

1.2 もっとも緊急な work をマークする

各コース、アクティビティ、グループなどには、マークされていない作業のカウントが添付されています。これは、最近（過去4日以内）、中期（4〜10日）、期限切れ（> 10日）の3つの数値に分けられます。最も古い work がどこにあるかをすばやく確認し、それらに最初に注意を払うことができます。マーキングは、関連性を維持するために2週間以上かかることはありません。したがって、マーキングを見逃すことはありません。

1.3 一つの質問に迅速に連続して全てに答えることでより速くクイズをマークする

ブロックは、クイズを個別の質問に分解してからすべての生徒の回答を表示するため、特定の質問に対するすべての回答をすばやく実行して、同じことに集中することができます。

2 あなたが必要とするものだけをマークしその他を隱す

ブロックは、設定タブと右クリックコンテキストメニューを介して設定を提供します。ツリーは、変更が行われるとすぐに更新されるため、何が起こっているのかを確認できます。

2.1 あなたがマークしなければいけない活動のための work のみを表示する

時々、あなたが何もするべきではないアクティビティでマーキングされるのを待っている仕事があります。これらのアクティビティは、設定タブで見つけて表示/非表示アイコンをクリックするか、メインコースツリーのアイテムを右クリックすることで非表示にできます。もちろんこれを行うと、そのコース内のすべてのアイテムがその設定を継承するように設定されます。その後、オプションで個々のアクティビティのコースのデフォルトをオーバーライドできますが、コースレベルの設定を停止すると、それらのオーバーライドがすべて消去されます。

2.2 あなた自身の teaching groups のための work のみを表示する

時々、いくつかのグループが活動をしていますが、あなたはそれらのいくつかを教えるだけです。同じ Moodle コースのアクティビティとリソースが複数の教師とクラスで共有されている場合。この場合、構成タブを使用するか、表示/非表示設定に関してコースツリーを右クリックして、個々のグループをそのアクティビティに対して表示または非表示に設定できます。デフォルトは、表示/非表示の場合と同じ方法で、アクティビティレベルをオーバーライドしてコースレベルで設定されます。グループを「個別のグループ」に設定している場合、上記のように、メンバーであるグループの生徒の work のみが自動的に表示されます。

3 インストール

ファイルを blocks/ajax_marking ディレクトリにファイルをコピーしたならば、通知スクリーン（フロントページ -> サイト管理 -> 通知）に行き正しく設定されたメッセージがあることを確認してください。

ファイルの入手方法：

3.1 Zip ファイル

正しい zip ファイルを ここ からダウンロードしてください。/blocks/ フォルダにコピーしてそこで unzip してください。

3.2 Git

github のリポジトリは ここ です。あなたのシステム上で最新のバージョンを得るために次のコマンドを使用してください。
（訳者注：バージョンが古い記述になっているようですので注意してください。）

 cd /path/to/your/moodle/blocks
 git clone https://github.com/mattgibson/moodle-block_ajax_marking.git ajax_marking
 cd ajax_marking
 git checkout MOODLE_22_STABLE

4 トラブルシューティング

あなたがすべきと思う仕事を見ることができない場合、これにはいくつかの理由があります。以下を試してください：

• あなたは管理者であり、あなたが見ているコースには work がありますが、あなたはそれらの教師として登録されていません。これは、サイト管理者が何千ものアイテムを不必要に見るのを防ぐためです。自分をカテゴリの教師として追加すると、そのカテゴリ内のコースで機能しますが、サイトレベルでは機能しません。

• コースまたはアクティビティが「個別のグループ」に設定されており、自分の work を見ることができない生徒と同じグループに属していない。多くの人がこの手法を使用して、教えていない教師からクラスを隠すため、これを尊重するようにブロックを設定しました。コースのすべてのグループに参加すると、大丈夫です。

• AJAXマーキングブロックの設定タブを使用して、一部の項目を「非表示」に設定したり、一部のグループを「非表示」に設定したりしています。設定をリセットするには、次のようなSQLクエリを実行します：DELETE FROM mdl_block_ajax_marking where userid = または、[構成]タブを確認して、コースレベルのすべての項目を非表示および再設定します。コースレベルの設定を変更すると、アクティビティレベルでのオーバーライドがすべて破棄されるため、これは機能します。どのグループでも同じことを忘れないでください。

• 探している作業は、サポートされていない（まだ）モジュールからのものです。リストは以下のとおりです。私が念頭に置いているコアブロック機能を完了したら、すべてのモジュールをサポートすることを目指しています。うまくいけば、2012年6月の初めまでにこれが行われ、マークできるすべてのモジュールが表示されるようになります。

5 サポートされるタイプ

• 宿題
• フォーラム（ratings が有効な場合のみ）
• ワークショップ
• クイズ（エッセイの質問のみ）

6 関連項目

カテゴリ:Contributed code（翻訳準備中）｜Teacher（翻訳準備中）｜ 管理者
メインページ

local.ERROR: Expected response code 354 but got code "554", with message "554 5.5.1 Error: no valid recipients

これに遭遇した時は、メールアドレスを別のサーバで取得したメールアドレスのSMTP設定をして試してみて下さい。

取り立てドメイン、作り立てのメールアドレスだからいけないのかわかりません。
別サーバのメールアドレス変えたら、送信が出来ました。
システム側のバグではないです。バグの原因を調べる時間が喰われるのって本当やだよね。

でわ、また。

初めてMacにLarabel入れようとしたら普通に詰まったので共有します。

経緯

・Homebrewにて、MacにPHPをインストールした。
・ComposerをMacに入れてパスを通した
・以下のコマンドを入力したところで問題発生

composer global require laravel/installer

問題

エラーコード

まずはこんなエラーコードが出ました。

mbp:~ 【ユーザーネーム】$ composer global require laravel/installer
Changed current directory to /Users/【ユーザーネーム】/.composer

Using version ^3.0 for laravel/installer
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - laravel/installer v3.0.1 requires ext-zip * -> the requested PHP extension zip is missing from your system.
    - laravel/installer v3.0.0 requires ext-zip * -> the requested PHP extension zip is missing from your system.
    - Installation request for laravel/installer ^3.0 -> satisfiable by laravel/installer[v3.0.0, v3.0.1].

行なった対処１

まずはLarabelをインストールするときに、どこのPHPを見ているのか確認

コマンド：which php
結果：/usr/bin/php

ここからわかること

・パスがMac標準PHPのものになっているらしい。
・どうやら標準PHPには「zip」らしきものが無いっぽい。
・/usr/bin/phpではなく、/usr/local/opt/phpを見て欲しいのに。

行なった対処2

コマンド：brew install php@7.3
結果：
Warning: php@7.3 7.3.14 is already installed and up-to-date
To reinstall 7.3.14, run `brew reinstall php@7.3`

ここからわかること

・もうすでにhomebrewでのPHPインストールは終わっている。

行なった対処３

コマンド：brew install php@7.3

【結果】
==> Reinstalling php@7.3 
==> Downloading https://homebrew.bintray.com/bottles/php@7.3-7.3.14.catalina.bottle.tar.gz
Already downloaded: /Users/【ユーザーネーム】/Library/Caches/Homebrew/downloads/42f5213d06a0456cf231786c8bf93b8fe340b153e0467babad9e5a0ca2935832--php@7.3-7.3.14.catalina.bottle.tar.gz
==> Pouring php@7.3-7.3.14.catalina.bottle.tar.gz
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set php_ini /usr/local/etc/php/7.3/php.ini syst
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set php_dir /usr/local/share/pear@7.3 system
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set doc_dir /usr/local/share/pear@7.3/doc syste
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set ext_dir /usr/local/lib/php/pecl/20180731 sy
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set bin_dir /usr/local/opt/php@7.3/bin system
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set data_dir /usr/local/share/pear@7.3/data sys
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set cfg_dir /usr/local/share/pear@7.3/cfg syste
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set www_dir /usr/local/share/pear@7.3/htdocs sy
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set man_dir /usr/local/share/man system
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set test_dir /usr/local/share/pear@7.3/test sys
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set php_bin /usr/local/opt/php@7.3/bin/php syst
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear update-channels
==> Caveats
To enable PHP in Apache add the following to httpd.conf and restart Apache:
    LoadModule php7_module /usr/local/opt/php@7.3/lib/httpd/modules/libphp7.so

    <FilesMatch \.php$>
        SetHandler application/x-httpd-php
    </FilesMatch>

Finally, check DirectoryIndex includes index.php
    DirectoryIndex index.php index.html

The php.ini and php-fpm.ini file can be found in:
    /usr/local/etc/php/7.3/

php@7.3 is keg-only, which means it was not symlinked into /usr/local,
because this is an alternate version of another formula.

If you need to have php@7.3 first in your PATH run:
  echo 'export PATH="/usr/local/opt/php@7.3/bin:$PATH"' >> ~/.bash_profile
  echo 'export PATH="/usr/local/opt/php@7.3/sbin:$PATH"' >> ~/.bash_profile

For compilers to find php@7.3 you may need to set:
  export LDFLAGS="-L/usr/local/opt/php@7.3/lib"
  export CPPFLAGS="-I/usr/local/opt/php@7.3/include"


To have launchd start php@7.3 now and restart at login:
  brew services start php@7.3
Or, if you don't want/need a background service you can just run:
  php-fpm
==> Summary
?  /usr/local/Cellar/php@7.3/7.3.14: 521 files, 77MB

ここからわかること

・インストールは完了している。
よく見ると・・・。

php@7.3 is keg-only, which means it was not symlinked into /usr/local,
because this is an alternate version of another formula.

If you need to have php@7.3 first in your PATH run:
  echo 'export PATH="/usr/local/opt/php@7.3/bin:$PATH"' >> ~/.bash_profile
  echo 'export PATH="/usr/local/opt/php@7.3/sbin:$PATH"' >> ~/.bash_profile

For compilers to find php@7.3 you may need to set:
  export LDFLAGS="-L/usr/local/opt/php@7.3/lib"
  export CPPFLAGS="-I/usr/local/opt/php@7.3/include"

解決策

※このコマンドをこのまま入力しても良いですが、記事が古くなっている可能性があるので上記コマンドを入力しつつ自分の環境で何が起こっているのかを確認してください。

  echo 'export PATH="/usr/local/opt/php@7.3/bin:$PATH"' >> ~/.bash_profile
  echo 'export PATH="/usr/local/opt/php@7.3/sbin:$PATH"' >> ~/.bash_profile

  export LDFLAGS="-L/usr/local/opt/php@7.3/lib"
  export CPPFLAGS="-I/usr/local/opt/php@7.3/include"

この4つのコマンドを記入後、

$ source ~/.bash_profile

このコマンドを入力したら、無事Larabelインストールが出来るようになりました。
めでたし！

初めてMacにLaravel入れようとしたら普通に詰まったので共有します。

経緯

・Homebrewにて、MacにPHPをインストールした。
・ComposerをMacに入れてパスを通した
・以下のコマンドを入力したところで問題発生

composer global require laravel/installer

問題

エラーコード

まずはこんなエラーコードが出ました。

mbp:~ 【ユーザーネーム】$ composer global require laravel/installer
Changed current directory to /Users/【ユーザーネーム】/.composer

Using version ^3.0 for laravel/installer
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - laravel/installer v3.0.1 requires ext-zip * -> the requested PHP extension zip is missing from your system.
    - laravel/installer v3.0.0 requires ext-zip * -> the requested PHP extension zip is missing from your system.
    - Installation request for laravel/installer ^3.0 -> satisfiable by laravel/installer[v3.0.0, v3.0.1].

Laravelをインストールするときに、どこのPHPを見ているのか確認

コマンド：which php
結果：/usr/bin/php

ここからわかること

・パスがMac標準PHPのものになっているらしい。
・どうやら標準PHPには「zip」らしきものが無いっぽい。
・/usr/bin/phpではなく、/usr/local/opt/phpを見て欲しいのに。

HomebrewでPHPをインストール出来ているかを確認

コマンド：brew install php@7.3
結果：
Warning: php@7.3 7.3.14 is already installed and up-to-date
To reinstall 7.3.14, run `brew reinstall php@7.3`

ここからわかること

・もうすでにhomebrewでのPHPインストールは終わっている。

PHPを念のため再インストール

コマンド：brew reinstall php@7.3

【結果】
==> Reinstalling php@7.3 
==> Downloading https://homebrew.bintray.com/bottles/php@7.3-7.3.14.catalina.bottle.tar.gz
Already downloaded: /Users/【ユーザーネーム】/Library/Caches/Homebrew/downloads/42f5213d06a0456cf231786c8bf93b8fe340b153e0467babad9e5a0ca2935832--php@7.3-7.3.14.catalina.bottle.tar.gz
==> Pouring php@7.3-7.3.14.catalina.bottle.tar.gz
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set php_ini /usr/local/etc/php/7.3/php.ini syst
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set php_dir /usr/local/share/pear@7.3 system
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set doc_dir /usr/local/share/pear@7.3/doc syste
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set ext_dir /usr/local/lib/php/pecl/20180731 sy
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set bin_dir /usr/local/opt/php@7.3/bin system
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set data_dir /usr/local/share/pear@7.3/data sys
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set cfg_dir /usr/local/share/pear@7.3/cfg syste
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set www_dir /usr/local/share/pear@7.3/htdocs sy
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set man_dir /usr/local/share/man system
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set test_dir /usr/local/share/pear@7.3/test sys
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear config-set php_bin /usr/local/opt/php@7.3/bin/php syst
==> /usr/local/Cellar/php@7.3/7.3.14/bin/pear update-channels
==> Caveats
To enable PHP in Apache add the following to httpd.conf and restart Apache:
    LoadModule php7_module /usr/local/opt/php@7.3/lib/httpd/modules/libphp7.so

    <FilesMatch \.php$>
        SetHandler application/x-httpd-php
    </FilesMatch>

Finally, check DirectoryIndex includes index.php
    DirectoryIndex index.php index.html

The php.ini and php-fpm.ini file can be found in:
    /usr/local/etc/php/7.3/

php@7.3 is keg-only, which means it was not symlinked into /usr/local,
because this is an alternate version of another formula.

If you need to have php@7.3 first in your PATH run:
  echo 'export PATH="/usr/local/opt/php@7.3/bin:$PATH"' >> ~/.bash_profile
  echo 'export PATH="/usr/local/opt/php@7.3/sbin:$PATH"' >> ~/.bash_profile

For compilers to find php@7.3 you may need to set:
  export LDFLAGS="-L/usr/local/opt/php@7.3/lib"
  export CPPFLAGS="-I/usr/local/opt/php@7.3/include"


To have launchd start php@7.3 now and restart at login:
  brew services start php@7.3
Or, if you don't want/need a background service you can just run:
  php-fpm
==> Summary
?  /usr/local/Cellar/php@7.3/7.3.14: 521 files, 77MB

ここからわかること

・インストールは完了している。
よく見ると・・・。

php@7.3 is keg-only, which means it was not symlinked into /usr/local,
because this is an alternate version of another formula.

If you need to have php@7.3 first in your PATH run:
  echo 'export PATH="/usr/local/opt/php@7.3/bin:$PATH"' >> ~/.bash_profile
  echo 'export PATH="/usr/local/opt/php@7.3/sbin:$PATH"' >> ~/.bash_profile

For compilers to find php@7.3 you may need to set:
  export LDFLAGS="-L/usr/local/opt/php@7.3/lib"
  export CPPFLAGS="-I/usr/local/opt/php@7.3/include"

解決策

※このコマンドをこのまま入力しても良いですが、記事が古くなっている可能性があるので上記コマンドを入力しつつ自分の環境で何が起こっているのかを確認してください。

  echo 'export PATH="/usr/local/opt/php@7.3/bin:$PATH"' >> ~/.bash_profile
  echo 'export PATH="/usr/local/opt/php@7.3/sbin:$PATH"' >> ~/.bash_profile

  export LDFLAGS="-L/usr/local/opt/php@7.3/lib"
  export CPPFLAGS="-I/usr/local/opt/php@7.3/include"

この4つのコマンドを記入後、

$ source ~/.bash_profile

このコマンドを入力したら、無事Laravelインストールが出来るようになりました。
めでたし！

EMOEMOはこちら

はじめに

初めまして！てらって呼んでください
簡単に自己紹介をするとごみくずプログラミング初学者です。(３ヶ月目)
現在個人開発中のWEBサービス（EMOEMO）をデプロイする予定だったのですが、想定外のバグが発生し、
デプロイはもう既にしているのですが公開できない状態です。現状のバグと今後の対策案について考えてみましたので、報告できればと思います。

現状のバグ＆対策案

• 全てのログインしているユーザーがツイートを送信しても僕のアカウントにツイートされてしまう。

どうやらtwitter認証周りのコードが悪さをしているような気がするので、その辺りから攻めてみようかと思っております。苦しい戦いになりそうです。

嘆き

画像の投稿関連の実装にもかなり時間をかけていて結構ギリギリでも実装できたのでこの勢いでと思ったのですが、
やはり、簡単にはいかないようです。引き続きどうにか頑張って、修正して使えるようにして見せるので待っていてください！

EMOEMOの新規実装機能

• 画像投稿機能
• 一覧ソート表示機能

ソート機能は大した事はなかったのですが、画像を投稿する実装がめちゃくちゃ大変でした。4日くらいかかりました。
具体的にどのような感じの実装になったかというと↓のような感じです。投稿するのが難しく、できても編集できるようにする機能の実装が滅茶苦茶大変でした。最終的に投稿した画像を編集できるようにするためのコード200行くらいになりました。汗

フロントは全然いじってないのですが基本的な機能を実装し終えて、デプロイし、皆さんに使ってもらっている間に手を入れようと思っています。

引き続きEMOEMOをよろしくお願いします。(まだデプロイして無いですが...)

最後に

もし最後まで読んでくれた方がいたら、いいね！をおねがします！

EMOEMOはこちら