狛ログ

オフィス狛 技術部のJoeです。
先日、担当しているJavaのプロジェクトでMavenのビルドを行ったところ、下記のエラーが発生しました。

[ERROR] Failed to execute goal on project web: Could not resolve dependencies for project [プロジェクト]: Failed to collect dependencies at [アーティファクトID]: Failed to read artifact descriptor for [アーティファクトID]: Could not transfer artifact org.springframework.boot:spring-boot-dependencies:pom:1.5.4.RELEASE from/to central (http://repo1.maven.org/maven2/): Failed to transfer http://repo1.maven.org/maven2/org/springframework/boot/spring-boot-dependencies/1.5.4.RELEASE/spring-boot-dependencies-1.5.4.RELEASE.pom. Error code 501, HTTPS Required

Maven Central リポジトリからアーティファクトをダウンロードできずに、「501」でエラーとなっています。

原因は、2020年1月15日から、Maven の Central リポジトリ へのHTTP経由による接続のサポートが終了し、HTTPS経由での接続が必須となりました。（ちょっと古い情報ですが）
そのため、このままですと、Central リポジトリ への接続が拒否され、ビルドが失敗します。

解決方法を調査してみると、いくつか対応策が出てきますが、私が解決できた方法をご紹介します。

【環境】
・Spring Tool Suite（Windows）：4.15.3
・Maven：3.8.4

※環境の状態によっては、下記のエラーが発生する場合もありますが、同じ対応で解決できました

[ERROR] Failed to execute goal on project web: Could not resolve dependencies for project [プロジェクト]: Failed to collect dependencies at [アーティファクトID]: Failed to read artifact descriptor for [アーティファクトID]: org.springframework.boot:spring-boot-dependencies:pom:1.5.4.RELEASE was not found in https://oss.sonatype.org/content/repositories/snapshots during a previous attempt. This failure was cached in the local repository and resolution is not reattempted until the update interval of sonatype-snapshots has elapsed or updates are forced

① エラーとなったアーティファクトのバージョンを最新版に上げる

私の利用していたアーティファクト「doma-spring-boot-starter」は、バージョンを最新版（1.1.1 → 1.6.0）にすることでエラーが解消し、アーティファクトをダウンロードできました。
※アーティファクトによっては、最新バージョンとしても今回の事象が解消されていない可能性もあるかと思います

バージョンの上げ方は、Central リポジトリで、ご利用のアーティファクトを検索、最新バージョンを確認いただき、pom.xmlファイルで、対象のアーティファクトの「<version>タグ」で指定下さい。

② Maven Central リポジトリのURLを指定する

①でエラーが解消されない場合や、事情によりバージョンを変更できない場合は、pom.xmlファイルに、下記のとおり、Maven Central リポジトリのURLを明示的に指定することで、エラーを解消することが出来ました。

    <repositories>
        <repository>
            <id>maven</id>
            <name>Maven Central</name>
            <url>https://repo.maven.apache.org/maven2/</url>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
        </repository>
    </repositories>

※調査してみると、「<id>タグ」と「<name>タグ」には、下記を指定することで解消できるとの情報もありましたが、私の環境ではエラーを解消できませんでした。

            <id>central</id>
            <name>Central Repository</name>

①、②でpom.xmlファイルを編集し、ビルドしてもエラーが解消されない場合は、プロジェクトの更新（プロジェクトを右クリック ＞ Maven ＞ プロジェクトの更新）し、再度ビルドすることもお試しください。

以上です。
同じエラーが発生した場合に、お役に立てば幸いです。

オフィス狛 技術部のKoma（Twitterアカウントの中の人＆CEO）です。

今回は画面遷移前に表示する下図のような確認ダイアログ風のポップアップ（以降、確認ポップアップ）を作成していこうと思います。

１からこのような仕組みを作るのは大変なので、「Simple Modal Module」（ngx-simple-modal）というプラグインを使いたいと思います。

※「Simple Modal Module」のインストールや使い方の細かい説明は、弊社メンバーの記事（【Angular・【Simple Modal Module】モーダルを手軽に実装する。）をご覧ください。

当記事では、以前の記事で使用した「アカウント登録機能」に実装する形で、実践的な説明をしようと思います。
と言うことで、是非、以前の記事も参照ください

参照１：【Angular】独自エラーチェック（カスタムバリデーション）を作成する。
参照２：【Angular】コンポーネントの設計（画面ごとの設計）について。
参照３：【Angular】エラーメッセージの管理について考える。

（１）どのコンポーネントでポップアップを呼び出すべきか

まず、どのコンポーネントでポップアップを呼び出すべきか考えてみます。
親（Container）なのか、子（Presentation）なのか・・・・
以前の記事で、こんな定義をしたかと思います。

「Container」として分類するもの

• 画画面の状態保持に関すること（NgRxのStore操作など）
• 画面に入力した値の業務チェック（API呼び出しが必要なもの、など）
• API（バックエンド処理）の呼び出し
• 画面遷移

「Presentation」として分類するもの

• 画面表示、及び表示内容の制御（エラー時など）
• 画面に入力した値のバリデーションチェック
• 画面に入力した値の関連チェック、及び業務チェック

という事で、ちょっと悩みどころではあるのですが、呼び出しは「子（Presentation）」の方が良いと思います。
確認ポップアップの「OKボタン＝画面遷移する」、「キャンセルボタン＝画面遷移しない」と考えると、確認ポップアップとしての動きは、あくまで「画面遷移するかどうかの関連チェック」に過ぎない、というのが理由です。
他にも、「キャンセルを押された時に画面の表示を変えたい」という要件があった場合、確認ポップアップを親（Container）で呼び出すと、かなり複雑になってしまうから、というのも理由の１つです。（今回はそのような要件はないですが）

（２）確認ポップアップの作成

呼び出す場所は決まりましたので、呼び出す「確認ポップアップ」用のコンポーネントを作成しようと思います。
弊社のプロジェクトでは、「app」配下に「shared」と言うディレクトリを作り、その中にプロジェクトで共通的に使うものを配置しています。

今回は、以下のように作成します。

src/
└ app/
    └ shared/
        └ modal/
            └ containers/
                └ confirmation-dialog/
                    └ confirmation-dialog.component.html
                    └ confirmation-dialog.component.ts

では、それぞれ実装を見ていきましょう。まずは、テンプレート（View）から。
[confirmation-dialog.component.html]

<div class="message">
  <div class="modal-dialog modal-content">
    <div class="modal-header">
      <div class="modal-title"></div>
      <button type="button" class="close" aria-label="閉じる" (click)="onClickCancel()">
        <span aria-hidden="true">×</span></button>
    </div>
    <div class="modal-body">
      <p class="text-center">{{ message }}</p>
    </div>
    <div class="modal-footer p-0">
      <button class="btn btn2" (click)="onClickCancel()">キャンセル</button>
      <button class="btn btn1 btn-block" type="submit" (click)="onClickOk()">OK</button>
    </div>
  </div>
</div>

特筆すべきところは特に無いですが、このコンポーネントを汎用的に利用する為に、表示するメッセージは「{{ message }}」で変数を展開する形にしています。

続いて、コンポーネントの実装です。
[rconfirmation-dialog.component.ts]

import { Component, OnInit, ChangeDetectionStrategy } from '@angular/core';
import { SimpleModalComponent } from 'ngx-simple-modal';

export interface ConfirmModel {
  message: string;
}

@Component({
  selector: 'koma-confirmation-dialog',
  templateUrl: './confirmation-dialog.component.html',
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class ConfirmationDialogComponent
  extends SimpleModalComponent<ConfirmModel, boolean>
  implements ConfirmModel, OnInit {
 
  message: string;

  constructor() {
    super();
  }

  ngOnInit() {}

  onClickCancel() {
    this.result = false;
    this.close();
  }

  onClickOk() {
    this.result = true;
    this.close();
  }
}

少し詳細を説明しています。
まず、下記の記載でポップアップに表示するメッセージを呼び出し元で設定出来るようにしています。

export interface ConfirmModel {
  message: string;
}

あと重要なのは、「ngx-simple-modal」のクラス（SimpleModalComponent）を継承し、先程作った「ConfirmModel」を実装する、と言う事です。

export class ConfirmationDialogComponent
  extends SimpleModalComponent<ConfirmModel, boolean>
  implements ConfirmModel, OnInit, OnDestroy {

「OKが押されたか、キャンセルが押されたか」は、「result」にTrue、Falseを設定することで、呼び出し側へ知らせます。

  onClickCancel() {
    this.result = false;
    this.close();
  }

  onClickOk() {
    this.result = true;
    this.close();
  }

これで確認ポップアップが作成できました。次はこの確認ポップアップを呼び出してみましょう。

（３）確認ポップアップの呼び出し

では早速、先程作成した確認ポップアップの呼び出しを実装して行きます。
まずは、呼び出し側の子のテンプレート（View）を実装します。

[register.component.html]（form部分のみ抜粋）

    <form [formGroup]="formRegister" (ngSubmit)="onSubmit()" (keydown.enter)="$event.preventDefault()">
      <div class="form-input">
        <div>
          <label>携帯電話番号<span>必須</span></label>
          <input formControlName="mobilePhoneNumber" type="tel" inputmode="numeric" class="form-control" placeholder="携帯電話番号を入力"
            [ngClass]="{'alert-danger' : v.mobilePhoneNumberInvalid}" autofocus>
          <ng-container *ngIf="v.mobilePhoneNumberInvalid">
            <p *ngIf="v.mobilePhoneNumberHasErrorRequired" class="error-message">{{ message('msg_error_field_required', '携帯電話番号') }}</p>
            <p *ngIf="v.mobilePhoneNumberHasErrorMaxLength" class="error-message">{{ message('msg_error_field_max', '携帯電話番号', mobilePhoneNumberMaxLength) }}</p>
            <p *ngIf="v.mobilePhoneNumberHasErrorFormat" class="error-message">{{ message('msg_error_cellphone_number') }}</p>
          </ng-container>
        </div>
        <div>
          <label>お名前</label>
          <input formControlName="name" type="text" class="form-control" placeholder="お名前を入力（任意）"
            [ngClass]="{'alert-danger' : v.nameInvalid}">
          <ng-container *ngIf="v.nameInvalid">
            <p class="error-message">{{ message('msg_error_field_max', 'お名前', nameMaxLength)}}</p>
          </ng-container>
        </div>
      </div>
      <footer class="footer fixed-bottom d-flex">
        <button type="button" (click)="onClickPrev()">戻る</button>
        <button [disabled]="formRegister.invalid" type="submit">確認</button>
      </footer>
    </form>

特筆すべき部分は特になく、単純に下記の部分を追加しているだけです。

<button type="button" (click)="onClickPrev()">戻る</button>

これは単純ですね、「戻る」ボタンを追加しただけ、になります。

では、次は子コンポーネントに戻るボタンを押した時のアクションを実装して行きます。
[register.component.ts]

import { Component, OnInit, Input, Output, OnDestroy, EventEmitter } from '@angular/core';
import { FormBuilder, FormGroup, Validators } from '@angular/forms';
import { Observable, Subscription } from 'rxjs';
import { CustomValidators } from '@app/shared/validator/custom-validators';
import { RegisterValidator } from './register.validator';
import { AccountViewSaveModel } from '../../models/account';
import { getMessage } from '@app/shared/message/error-messages';
import { SimpleModalService } from 'ngx-simple-modal';
import { ConfirmationDialogComponent } from '@app/shared/modal/containers/confirmation-dialog/confirmation-dialog.component';

@Component({
  selector: 'koma-register',
  templateUrl: './register.component.html',
})
export class RegisterComponent implements OnInit, OnDestroy {
  // Input・Outputの定義。
  @Input() accountViewSave$: Observable<AccountViewSaveModel>;
  @Output() formBack = new EventEmitter();
  @Output() formSubmit = new EventEmitter<AccountViewSaveModel>();

  mobilePhoneNumberMaxLength = 11;
  nameMaxLength = 20;

  registerSubscription: Subscription = new Subscription();

  formRegister: FormGroup = this.formBuilder.group({
    mobilePhoneNumber: [
      '',
      [
        Validators.required,
        Validators.maxLength(this.mobilePhoneNumberMaxLength),
        CustomValidators.mobilePhoneNumberValidator,
      ],
    ],
    name: ['', [Validators.maxLength(this.nameMaxLength)]],
  });

  constructor(
    private formBuilder: FormBuilder,
    public v: RegisterValidator,
    private simpleModalService: SimpleModalService,
  ) {}

  ngOnInit(): void {
    // バリデーション設定
    this.v.formGroup = this.formRegister;

    this.registerSubscription.add(
      // 画面初期値設定
      this.accountViewSave$.subscribe(value => {
        if (value) {
          this.formRegister.controls.mobilePhoneNumber.setValue(
            value.mobilePhoneNumber,
          );
          this.formRegister.controls.name.setValue(value.name);
        }
      }),
    );
  }

  ngOnDestroy(): void {
    // ダイアログ削除
    this.simpleModalService.removeAll();
    // サブスクリプション解除
    this.registerSubscription.unsubscribe();
  }

  onClickPrev(): void {
    // 確認ダイアログの表示
    this.simpleModalService
      .addModal(ConfirmationDialogComponent, {
        message: getMessage('msg_confirm_screen_transition'),
      })
      .subscribe(result => {
        if (result) {
          this.formBack.emit();
        }
      });
  }

  // 画面でSubmitが発生した時の処理
  onSubmit(): void {
    if (this.formRegister.valid) {
      // バリデーションエラーが発生していない場合
      const formModel = {
        mobilePhoneNumber: this.formRegister.controls.mobilePhoneNumber.value,
        name: this.formRegister.controls.name.value,
      } as AccountViewSaveModel;
      this.formSubmit.emit(formModel);
    }
  }

  message(messageId: string, ...args: any[]): string {
    return getMessage(messageId, ...args);
  }
}

中身を細かく見ていきましょう。
まずは、「ngx-simple-modalのSimpleModalService」と、先程作成した確認ポップアップをインポートしています。

import { SimpleModalService } from 'ngx-simple-modal';
import { ConfirmationDialogComponent } from '@app/shared/modal/containers/confirmation-dialog/confirmation-dialog.component';

戻るボタンを押された場合の画面遷移の制御は、親コンポーネント側で行うので、親コンポーネントへのイベント登録（定義）も行います。

@Output() formBack = new EventEmitter();

そして、インポートした「SimpleModalService」はDIする必要があります。

  constructor(
    private formBuilder: FormBuilder,
    public v: RegisterValidator,
    private simpleModalService: SimpleModalService,
  ) {}

次に「戻るボタン」を押した時の処理です。ここで確認ポップアップを表示します。

  onClickPrev(): void {
    // 確認ダイアログの表示
    this.simpleModalService
      .addModal(ConfirmationDialogComponent, {
        message: getMessage('msg_confirm_screen_transition'),
      })
      .subscribe(result => {
        if (result) {
          this.formBack.emit();
        }
      });
  }

ざっくり説明すると、

• SimpleModalServiceのaddModalに自作コンポーネントを指定して、さらに自作コンポーネントのmessageに、表示用の文言を設定している
• ポップアップの戻りは、subscribeで受け取り設定する（resultにTrue、Falseが設定されて戻ってくる）

と言う感じですね。
Trueの場合（確認ポップアップで「OK」が押された場合）、親画面へイベントを委譲しています。

（４）親コンポーネントの実装

確認ポップアップの表示とは直接関係ないですが、親コンポーネントも実装しておきましょう。
まずはテンプレート（View）に、子のOutput（formBack）と親のイベント（onClickBack）の紐付けを追加します。

[account-register.component.html]

<koma-register
  (formBack)="onClickBack()"
  (formSubmit)="onSubmit($event)"
  [accountViewSave$]="accountViewSave$"
></koma-register>

続いて、コンポーネント側の実装です。
[account-register.component.ts]

import { Component, OnInit } from '@angular/core';
import { Store, select } from '@ngrx/store';
import { Router } from '@angular/router';
import { AccountViewSaveModel } from '../../models/account';
import * as fromAccount from '../../store/reducers';
import * as AccountActions from '../../store/actions/account.actions';

@Component({
  selector: 'koma-account-register',
  templateUrl: './account-register.component.html',
})
export class AccountRegisterComponent implements OnInit {

  // Storeから入力情報を取得する（確認画面から戻ってきた場合には値が入っている）
  // 取得値の型はObservableになるので、変数の末尾に「$」を付ける（お約束みたいなもの）
  accountViewSave$ = this.store.pipe(select(fromAccount.getDataRegisterPost));

  constructor(public store: Store<fromAccount.State>, private router: Router) {}

  ngOnInit(): void {}

  onClickBack(): void {
    // ホーム画面に遷移する（戻る）
    this.router.navigateByUrl('/home/top');
  }

  onSubmit(formModel: AccountViewSaveModel): void {
    // 入力情報をStoreに格納して（＝引き継ぎ情報として）、遷移後の画面でも使えるようにする。
    this.store.dispatch(
      AccountActions.setRegisterPostData({ data: formModel }),
    );
    // 確認画面へ遷移する
    this.router.navigateByUrl('/account/register-confirm');
  }
}

「NgRxのStore」などが使われていますが、ここは一旦スルーしてください。（いずれ、NgRxの実装方法も記事にしようと思います。）
ここでは、画面で入力された値はStore（と言う場所）に格納されている、ぐらいの理解でOKです。
（重要なのは、「データ保存方式」ではなく、あくまで「戻るボタンの制御」なので）

と言う事で、中身を見ていくと・・・・先程、子側と紐付けたイベント（onClickBack）が実装されていますね。
画面遷移するだけの処理ですが、URLがそのまま固定文字列で記載されているのが気になります。
こちらも今回の記事の本質では無いですが、URLの固定文字列も定数化しちゃいましょう。

（２）でも説明したように、「app」配下に「shared」と言うディレクトリを作り、その中にプロジェクトで共通的に使うものを配置します。
今回は、以下のように作成します。

src/
└ app/
    └ shared/
        └ constant/
            └ page-constants.ts

実装は下記のようになります。
[page-constants.ts]

export namespace url {
  export const HOME_TOP = '/home/top';
  export const ACCOUNT_REGISTER_CONFIRM = '/account/register-confirm';
}

では、先程の固定文字列を定数に変更してみます。
下記が、最終的な親のコンポーネントとなります。
[account-register.component.ts]

import { Component, OnInit } from '@angular/core';
import { Store, select } from '@ngrx/store';
import { Router } from '@angular/router';
import * as PageConstants from '@app/shared/constant/page-constants';
import { AccountViewSaveModel } from '../../models/account';
import * as fromAccount from '../../store/reducers';
import * as AccountActions from '../../store/actions/account.actions';

@Component({
  selector: 'koma-account-register',
  templateUrl: './account-register.component.html',
})
export class AccountRegisterComponent implements OnInit {

  // Storeから入力情報を取得する（確認画面から戻ってきた場合には値が入っている）
  // 取得値の型はObservableになるので、変数の末尾に「$」を付ける（お約束みたいなもの）
  accountViewSave$ = this.store.pipe(select(fromAccount.getDataRegisterPost));

  constructor(public store: Store<fromAccount.State>, private router: Router) {}

  ngOnInit(): void {}

  onClickBack(): void {
    // ホーム画面に遷移する（戻る）
    this.router.navigateByUrl(PageConstants.url.HOME_TOP);
  }

  onSubmit(formModel: AccountViewSaveModel): void {
    // 入力情報をStoreに格納して（＝引き継ぎ情報として）、遷移後の画面でも使えるようにする。
    this.store.dispatch(
      AccountActions.setRegisterPostData({ data: formModel }),
    );
    // 確認画面へ遷移する
    this.router.navigateByUrl(PageConstants.url.ACCOUNT_REGISTER_CONFIRM);
  }
}

（５）メッセージを追加する

最後に確認ポップアップに送る為のメッセージ定義もしておきましょう。

[error-messages.ts]

export const errorMessages: { [key: string]: string } = {
  msg_error_field_required: '{0}は必ず入力してください。',
  msg_error_field_max: '{0}は{1}文字以内で入力してください。',
  msg_confirm_screen_transition:
    '現在の入力中の情報は破棄されます。前の画面に戻りますか？',
};

function formatMessage(msg: string, ...args: any[]): string {
  return msg.replace(/\{(\d+)\}/g, (m, k) => {
    return args[k];
  });
}

export function getMessage(messageId: string, ...args: any[]): string {
  return formatMessage(errorMessages[messageId], ...args);
}

これで、全ての実装が完了しました。
この応用（むしろ、今回の方が応用ですが）で、「アラート表示ポップアップ」や、「完了メッセージ表示ポップアップ」など、色々作れると思います。

ぜひ、色々カスタマイズしてみてください！

オフィス狛 技術部のJoeです。
担当のプロジェクトで、AWSのプライベートサブネット内のLambda関数で、環境変数の複合化を行うため、AWS KMSを利用する必要がありました。
インターネットゲートウェイとルーティングできないプライベートサブネット内のLambda関数が、VPC外のサービスであるAWS KMSを利用するためには、２つの方法があります。

方法と設定

１．NAT Gatewayを作成する

パブリックサブネットにNAT Gatewayを作成し、インターネット経由でKMSに接続します。

【NAT Gatewayの設定手順】
　※NAT Gateway 以外は、既に構築済みの前提として、手順は省略させていただきます

① VPCのサービスから、NAT Gateway を作成します。

② プライベートサブネットのルートテーブルのルートに、①で作成したNAT Gateway を指定します。

■注意点
・Elastic IP アドレスは、AWS アカウントごとに各リージョンで 5 つのデフォルト制限がありますので、既に５つ割り当てている場合、制限の増加をリクエストする必要があります。

２．エンドポイントを作成する（PrivateLink）

KMS用のエンドポイント（インターフェイスエンドポイント）を作成し、プライベートリンクでKMSに接続します。

【エンドポイントの設定手順】
　※エンドポイント以外は、既に構築済みの前提として、手順は省略させていただきます

① VPCのサービスからエンドポイントを作成します。

■注意点
・エンドポイントに設定するセキュリティグループは、インバウンドルールに「HTTPS」を許可する必要があります。

NAT Gatewayとエンドポイントのどちらを利用したほうが良いのか

ご利用に環境による場合もあるかもしれませんが、今回のように、新たにプライベートサブネット内のLambdaやEC2から、AWSのサービス（KMS、S3など）を利用する場合は、 下記の理由などから、エンドポイントを作成し、プライベートリンクで接続が良さそうです。

ただし、対象の AWS サービスで VPC エンドポイントが利用できない場合もありますので、こちらで事前にご確認ください。
AWS PrivateLink と統合できる AWS のサービス

１．セキュリティ

NAT Gatewayは、インターネット経由で接続しますが、プライベートリンクを利用すると、トラフィックをインターネットに公開することなく、AWS のサービスに接続できます。
そのため、ブルートフォース攻撃やDDos攻撃、その他の脅威に晒される危険が軽減されます。
また、セキュリティグループを関連付けることで、アクセス制御も可能です。

２．料金

料金については、AWS アーキテクチャ ブログを見ますと、エンドポイント（インターフェイスエンドポイント）は、「インターネット ゲートウェイへのトラフィックを回避し、NAT ゲートウェイ、NAT インスタンス、またはファイアウォールの維持に関連するコストが発生するのを回避することで、ネットワーク パスを最適化できます。」との記載があります。
また、NAT Gatewayと「１つ当たりの料金」と「処理データ 1 GB あたりの料金」を比較すると、料金は約6分の1で、AWSのコストを削減できる可能性があります。
NAT Gatewayの料金
エンドポイントの料金

３．管理

管理については、エンドポイントは設定手順が少なく、構成も分かり易いため、個人的には管理し易いと思いました。


以上です。
今回は、インターフェイスエンドポイント（プライベートリンク）についてご紹介しましたが、エンドポイントは他にも「ゲートウェイロードバランサーのエンドポイント」、「ゲートウェイエンドポイント」がありますので、機会があればご紹介したいと思います。

こんにちは、オフィス狛 技術部のmmm（むー）です。

以前、Laravelのプロジェクトで、日付のフォーマットを編集したかったのですが、レスポンスの項目名がcreated_at の場合、うまく変換できず少しはまりました。

その時、調べたことについて記事に残します。

前提条件

$ php artisan -V
Laravel Framework 8.27.0

SELECT @@VERSION;
Microsoft SQL Server 2017 (RTM-CU30) (KB5013756) - 14.0.3451.2 (X64)  	Jun 22 2022 18:20:15  	Copyright (C) 2017 Microsoft Corporation 	Developer Edition (64-bit) on Linux (Ubuntu 18.04.6 LTS)

1. したかったこと

当初、SQLでフォーマットを指定して、created_at カラムの値をレスポンスしたかったのですが、期待した形の値が取得できませんでした。
※コードは必要な箇所以外、簡易化して記載します。
※127は「ISO 8601 (タイム ゾーン Z)」となります。

class ConditionsController extends Controller
{
    public function index(Request $request)
    {

			$conditions = Condition::select(
			            DB::raw("CONVERT(VARCHAR, created_at, 127) as created_at")
			        )->get()->first();

			return response()->json($conditions);
    }
}

/*
■結果
{
    "created_at": "2022-09-07T02:48:46.947000Z"
}
*/

本来、「2022-09-07T11:48:46.947」のようなフォーマットになる想定でしたが、
created_atの値は「2022-09-07T02:48:46.947000Z」でした。

一方、下記は全く同じ書き方ですが、取得するカラム名が created_at ではない場合、期待通りにフォーマットを変換することができました。

class ConditionsController extends Controller
{
    public function index(Request $request)
    {

			$conditions = Condition::select(
			            DB::raw("CONVERT(VARCHAR, created_at, 127) as test") // 別名でtestを設定
			        )->get()->first();

			return response()->json($conditions);
    }
}

/*
■結果
{
    "test": "2022-09-07T11:48:46.947"
}
*/

created_atカラムに、testという別名を付けると、値は「2022-09-07T11:48:46.947」でした。

2. 原因と解決策

調査した結果、created_atとupdated_atはデフォルトの場合、EloquentがCarbonインスタンスへ変換していることがわかりました。
Modelから返ってきた値をCarbonのフォーマットを使用して編集するように修正しました。

class ConditionsController extends Controller
{
    public function index(Request $request)
    {

			$conditions = Condition::select(
			            DB::raw("CONVERT(VARCHAR, created_at, 127) as created_at")
			        )->get()->first();
			$response['created_at'] = $conditions['created_at']->toIso8601String(); // 変換処理を追記

			return response()->json($response);
    }
}

/*
■結果
{
    "created_at": "2022-09-07T11:48:46+09:00"
}
*/

今回は toIso8601String() を使用しましたが、基本的なフォーマットは下記ページに用意されています。
参考：https://carbon.nesbot.com/docs/#api-conversion

3. 補足

今回はControllerでフォーマットの修正を行いましたが、Modelで下記のように、属性を指定してフォーマットを指定することもできます。

protected $casts = [
    'created_at' => 'datetime:Y/m/d',
];

さらに、Laravelで get...Attribute （...は加工したい項目名）と記載して、フォーマットを指定することも可能です。

public function getCreatedAtAttribute($value)
{
    return Carbon::parse($value)->format('Y/m/d');
}

上記は一例となります。Laravelでは様々な機能が用意されているので、もっといろんな方法があると思います。

参考になりましたら、幸いです。

こんにちは。オフィス狛 技術部のmmm（むー）です。

担当しているプロジェクトで、Laravelのコマンドラインで実行するバッチ処理がいくつかあるのですが、ユーザー数が日に日に増えていき実行時間が長くなっていきました。

普段は自動で実行しているので特に問題ないのですが、先日テストのため手動でバッチを実行しないといけないことがあり、

（この処理いつ終わるんだろう・・・・）

となってしまいました😖

処理を実行して放置すれば良いとしても、目安もわからず、都度確認するのは大変だと思いますので、今回はコマンド実行の処理とプログレスバーの作成方法をご紹介いたします。

前提条件

$ php artisan -V
Laravel Framework 8.27.0

1. コマンドを作成する

コマンドを作成します。今回は例として、ランキング作成の処理としました。

# php artisan make:command [コマンド名]

$ php artisan make:command CreateRankingCommand

自動で作成されたファイルを確認すると下記のようになっています。

// app/Console/Commands/CreateRankingCommand.php

<?php
namespace App\Console\Commands;

use Illuminate\Console\Command;

class CreateRankingCommand extends Command
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'command:name';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'Command description';

    /**
     * Create a new command instance.
     *
     * @return void
     */
    public function __construct()
    {
        parent::__construct();
    }

    /**
     * Execute the console command.
     *
     * @return int
     */
    public function handle()
    {
        return 0;
    }
}

まず、２つの項目を設定します。
1. $signatureに、コマンド名を設定します。ここに設定した名前を使用して、コマンドラインで処理を実行することになります。
2. $description に、このコマンドの説明を記載します。

修正すると、以下のようになりました。

    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'command:create_ranking'; // 修正しました

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'ランキングを作成します。'; // 修正しました
    

次に、コマンドが実行できるか確認します。

処理内容はhandle()内に本来記載しますが、初期状態から何も修正していないので、特にエラー等が表示されなければ問題ありません。

# php artisan command:[コマンド名]

$ php artisan command:create_ranking

また、以下のようにコマンドが作成できているか確認することもできます。

$ php artisan list | grep command:
  command:create_ranking                  ランキングを作成します。

2. プログレスバーを作成する

コマンドが実行できることは確認できたので、処理とプログレスバーを作成します。

処理内容は、handle()メソッドの中に記載します。
大変簡素ですが、今回はただループするだけの処理を作成します。

public function handle()
    {
        $count = 10;

        for ($i = 1; $i <= $count; $i++) {
            // 本来、ここで何か処理を行います
        }

        return 0;
    }

ここにプログレスバーを表示する処理を追記していきます。
コードの説明としては、下記①②③のコメントに記載した通りです。

public function handle()
    {
        $count = 10;

        // ①処理の総ステップ数を指定します
        $progressBar = $this->output->createProgressBar($count);

        for ($i = 1; $i <= $count; $i++) {
            // 本来、ここで何か処理を行います

            // ②プログレスバーの表示を１つ分進めます
            $progressBar->advance();
        }

        // ③プログレスバーの表示を完了状態にします
        $progressBar->finish();

        return 0;
    }

処理を実行すると下記のようになります。
※この処理は中身がないため、すぐ終わります。

$ php artisan command:create_ranking
10/10 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%

とても簡単に処理の進捗度を表示できるようになりました！

以上となります。
参考にして頂ければ幸いです。

技術部のyuckieee(ゆっきー)です。
今回は、PythonのFlaskフレームワークを使用し、Webシステム構築をした際にハマった事象について、解決策と合わせて、ご紹介しようと思います。

■Webシステム概要

発生事象の説明をする前に、まずは今回開発を行ったWebシステムの概要について共有しておきます。超ザックリとした概要ではありますが、以下のような構成・仕様となっていました。

【システム構成】
・ALB(ロードバランサー）
・EC2(Web/APサーバ)
　- OS：RedHatLinux8.x(EC2)
　- Web/AP：Apache 2.4.xx(mod_wsgiでFlaskと連携)
　- 言語：Python 3.8
　- フレームワーク：Flask
・通信プロトコル
　- クライアント⇔ALB：HTTPS(TCP/443※)
　　※HTTPで接続された場合でもALB側でHTTPSに変換して、リクエスト自体は受け付ける
　- ALB⇔EC2：HTTP(TCP/80)

(構成イメージ)
【Webシステムの仕様】
　・BASIC認証を使用して、ログイン認証を行う
　・ログイン認証後、トップページでユーザ情報をセッションに格納して他ページで使用する
　・他ページはユーザ情報必須のため、トップページ以外へのダイレクトアクセス※は非許可
　　※ブラウザにURLを直接入力したり、お気に入りからアクセスした場合など
　・ダイレクトアクセス検知時は、トップページに強制遷移させ、必ずトップページ経由とさせる

(画面遷移イメージ)

■発生した事象

Webシステム開発が完了し、システム構成で説明した通りの通信経路となるよう、Webシステムにアクセスする際のURLを以下のように変更しました。（URLはイメージです）

【開発時】http://websystem.com/
※Webシステムのあるサーバに直接アクセスするために設定されたWebシステムのURL
　　↓
【開発完了後】https://alb.websystem.com/
※AWSのALBを介してアクセスするために設定されたWebシステムのURL

そして、動作確認をしようと【開発完了後】のURLにアクセスしたのですが、通常アクセス時のとおりトップページから他ページに遷移しようとしても、トップページへの強制遷移が発生し、他ページに遷移ができない状態に陥りました。
明日からユーザ側で試験利用と言っているのに、軽くパニックです（笑）

(画面遷移イメージ)

■直接原因

Webシステムの仕様から考えると、ダイレクトアクセス検知によってトップページに強制転送されているのだろうと感じていました。 そして、その直感は当たっており、この仕様に絡んで以下２つの仕組みにより起こった問題であることが分かりました。

① 相対URLでの画面遷移

Webシステムのページ遷移に使用するURLは、Flaskのurl_forというメソッドを使用しており、このメソッドで生成されるURLは相対URLがデフォルトとなっており、このWebシステムでもデフォルト指定にて使用していました。
今回の場合、直前のアクセス元であるALBがhttps → httpに書き換えてリクエストを投げてきているため、受け取ったhttp://~から始まる絶対パスを元に、相対指定でURLが作成されて画面遷移されることになりました。

② HTTPSサイトからHTTPサイト遷移によるリファラ削除

突然何だ？！と思うかもしれませんが、このWebシステムではダイレクトアクセスの検知を、リクエストヘッダ内にあるリファラ(遷移元URL情報)の存在チェックで行っていました。
想定では、ダイレクトアクセスの場合、リファラには遷移元URLが入っていないため、ここをチェックすることでダイレクトアクセスの判定が可能と考えていたためです。
ですが、①の画面遷移を受け付けたブラウザは「HTTPSサイト(安全)」から「HTTPサイト(非安全)」への遷移が発生したと検知し、セキュリティリスク回避のためリファラの内容を削除してリクエストしていました。

その結果、リクエストを受け取ったWebシステムは、リファラなし（＝ダイレクトアクセス）と判断し、トップページに強制転送していた訳ですね。

リファラという用語がピンとこない方は、公式ページを参照してみてください。
Referer - HTTP - MDN Web Docs

■根本原因

ここまで、実際に事象を引き起こした仕組みについて説明してきました。
ですが、そもそもAWSのALBを経由しなければ、正常に動作していたわけです。なのに、なぜこの事象が発生したのでしょうか？

それは、AWSのALBを経由したことでリクエスト情報が書き換わったためです。

今回でいうと、ALBからEC2(Web/APサーバ)への転送時に通信プロトコルをhttps → httpに書き換えており、転送リクエストを受け取ったEC2(Web/APサーバ）から見るとリクエスト元はALBなので何も間違ってはいませんし、そういう仕様なのです。
そのため、開発者は、プロキシ経由が発生すると分かった時点で、クライアントのリクエスト情報を正確に取得できるよう設計考慮が必要でした。

■解決方法

それでは、実際に根本原因に対処していきましょう。
今回は、クライアントの情報をちゃんと取得できれば解決するわけです。
でも、リクエスト情報が書き換えられてるのにどうすれば？

ご安心ください！

今回使用したALBの場合、経由前のリクエスト情報が別のヘッダーに退避されています。
それが「X-Forwarded-xxx」ヘッダーです。
「X-Forwarded-xxx」ヘッダーには、いくつか種類があり、通信プロトコルが格納されているヘッダーは「X-Fowarded-Proto」となります。

ヘッダー名	説明
X-Forwarded-For	プロキシ経由時、クライアントのIPアドレスが格納されます。複数プロキシ経由時はカンマ区切りで表記され、プロキシ経由ごとに右端にIPアドレスが追加されていきます。
X-Forwarded-Host	リクエストヘッダー内でクライアントから要求された元のホストを特定するための事実上の標準となっているヘッダーです。
X-Forwarded-Proto	プロキシまたはロードバランサーへ接続するのに使っていたクライアントの通信プロトコル (HTTP または HTTPS) を特定するために事実上の標準となっているヘッダーです。

ただし、これらのヘッダーは標準化されたものでなく、書き換え容易且つ、経由するプロキシ（今回はALB）によって挙動が異なる可能性もあるので、ご注意ください。ALBの仕様については以下に記載がありました。
HTTP ヘッダーと Application Load Balancer

なお、「X-Forwarded-xxx」ヘッダーに関する詳細は以下を参照して確認してみてください。
※「X-Fowarded-xxx」は、現状「X-Forwarded」ヘッダに移行されるようなので「X-Fowarded」ヘッダーに関するリンクも張っておきます。
X-Forwarded-Proto - HTTP - MDN Web Docs
Forwarded - HTTP - MDN Web Docs - Mozilla
RFC 7239 Forwarded HTTP Extension

ここまでの説明から、この事象を解決するには「X-Fowarded-xxx」ヘッダーにあるプロトコル情報を使えば良い。というのが、ふんわり頭に浮かんだのではないかと思います。
それでは、このWebシステムでは、どのように「X-Forwarded-Proto」ヘッダーの値で書き換えればよいのでしょうか？
自分でゴリゴリ実装することも可能ですが、今回使用したPythonのフレームワークであるFlaskでは、既に対応するミドルウェアが提供されていました。
それが「X-Forwarded-For Proxy Fix」というミドルウェアです。

X-Forwarded-For Proxy Fix - Werkzeug

このミドルウェアを使用することで、経由(信頼）するプロキシ数に応じてリクエスト元情報の補正を行うことが可能です。 使用方法などの詳細は、上記公式ページを参照して、確認してみてください。
具体的な実装例は以下となります。

from werkzeug.middleware.proxy_fix import ProxyFix

def app():
~略~
    app = Flask(__name__)
    app.wsgi_app = ProxyFix(app.wsgi_app, x_proto=1)
~略~

インスタンス作成時に今回問題となった「X-Forwareded-Proto」ヘッダの値を使用して、通信プロトコル情報が補正されるように設定します。 公式を参照すると、「X-Fowareded-Proto」ヘッダーを補正したい場合は、引数にx_proto=(信頼する)プロキシ経由数の形式で指定すれば良いようです。
ヘッダーごとに引数が異なるようなので、詳細は公式参照ください。

上記を設定することで、無事問題は解決することが出来ました。

＜おまけ＞
対処方法を色々と探していたのですが、他の方法もあるようでした。
プロキシによっては「X-Forwarded-xxx」ヘッダーが設定されていないなどもあると思うので、参考までに紹介しておきます。 ただし、ヘッダーが取得可能な時は、わざわざ手間を増やしたり、セキュリティリスク高める必要はないと思うので、推奨は致しません。

・直接原因① Flaskが認識するリクエスト元プロトコルを"HTTPS"固定に変更する
Flaskのインスタンス生成時、リクエスト元のプロトコル情報を直接"HTTPS"(固定)に書き換えることで対処する方法です。以下、実装例です。

def create_app():
...省略...
    class SchemeFix:
        def __init__(self, app):
            self.app = app

        def __call__(self, environ, start_response):
            environ['wsgi.url_scheme'] = 'https'
            return self.app(environ, start_response)

    app = Flask(__name__)
    app.wsgi_app = SchemeFix(app.wsgi_app)
    
    return app

・直接原因② リファラが削除されないように設定を変更する
直接原因②はリファラが削除されるのが問題なので、削除されないようにすればいいじゃん！という対策です。対象のWebページ（HTML)に対して、以下のようなメタ情報を定義してリファラの送信制限を緩和させます。

<meta name="referrer" content="origin-when-crossorigin">

上記content="origin-when-crossorigin"の記載が該当箇所になります。
この設定の場合、同一のプロトコル水準 (HTTP→HTTP, HTTPS→HTTPS) で同一オリジンのリクエストを行う場合はオリジン、パス、クエリー文字列が送信され、オリジン間リクエストや安全性の低下する移動先 (HTTPS→HTTP) ではオリジンのみを送信します。
今回のダイレクトアクセスチェックでは、リファラの値有無を確認しているため、オリジンのみでも値があれば事象は解消可能となります。
全ての情報が必要な場合はcontent="unsafe-url"を設定することでリファラを取得可能ですが、安全性の面から非推奨となっているため、使用は回避するべきだと思います。

Referrer-Policy - HTTP - MDN Web Docs

■まとめ

Webシステムだけでなく、インフラも含めた全体的な視点でシステム構築をすることの難しさと面白さを知りました。
徐々に仕組みを理解し、謎が解けた時は本当に楽しいですね。
今後も幅広い領域の経験を積みながら、レベルアップしていければと思います。

オフィス狛 技術部のHammarです。

先日Visual StudioでIIS Expressからデバッグ時に、急に「ID XXXXXのプロセスは実行されていません」と表示されるようになり、全くデバッグが出来なくなりました。
いろいろ先人の復帰方法を見ながら試してみても、どうもうまくいかず軽くハマっていたんですが、意外と簡単な方法で復帰したので、お知らせしたいと思います。

実行環境

---

• Windows10
• Visual Studio 2017
      - IIS Express(Google Chrome)よりデバッグ

事象

---

先日までは普通にデバッグ開始ボタンよりデバッグできていて、ある日同じようにデバッグ開始したところ、起動してブラウザは開くんですが、「このサイトにアクセスできません」のエラーが発生して、上手く接続できていない状態になっていました。
その時、Visual Studioもデバッグモードになっているものの、設定したデバッグポイントが、「ブレークポイントは、現在の設定ではヒットしません。このドキュメントのシンボルが読み込まれていません。」と表示されてしまっていました。
なので、一旦デバッグを停止し、もう一度デバッグを開始したところ、下記のように「ID XXXXXのプロセスは実行されていません」が表示され、以降はデバッグをやり直しても、Visual Studioを起動しなおしても同エラーが出続けてしまう状態に陥ってしまいました。

解消方法

---

調べていくと、似たような状態になっている記事をいくつか見つけたので、手っ取り早くできる方法を２つ３つやってみたのですが、どうも解決しませんでした。
（「IIS Expressサーバーを起動できません。」というエラーと一緒に発生している記事の内容を主に試してみたので、ちょっと今回の事象とは微妙に違ったのかもしれません）
で、調べをすすめていくと、簡単に解消できた方法が以下の内容です。

■csprojファイルの下記3行を削除する

<DevelopmentServerPort>xxxxx</DevelopmentServerPort> 
<DevelopmentServerVPath></DevelopmentServerVPath>
<IISUrl>http://localhost:xxxxx/</IISUrl>

上記はデバッグ時に起動するIIS ExpressのURLや、仮想開発サーバーのポート、パスを設定している部分なのですが、こちら3行を削除して、プロジェクトをリロードすれば、なんとあっさりデバッグが正常にできるようになりました。
ちなみに、上記を削除しても、再度デバッグ実行したタイミングで、記述が自動的に再作成されるので、特に問題は無いようです。

また本エラーの解消方法調べていくと、結構対応方法が多様でバラバラなので、もしかしたら一概に、この方法で解決します！とはならないかもしれないのですが、とりあえず簡単に試せる方法ではあるので、もし同様のエラーに陥った方は、まずは一旦試していただければと思います。