のんラボ

S3みたいなストレージサーバーっぽいものを自前で用意する④【RFC 7807 エラーレスポンス実装】

2022/03/26 2022/04/24

S3みたいなストレージサーバーっぽいものを自前で用意する④【RFC 7807 エラーレスポンス実装】こんにちは。のんです。前回に引き続き自前でストレージサーバーを開発していこうと思います。 S3みたいなストレージサーバーっぽいものを自前で用意する③【Digest認証実装】 | のんラボ S3みたいなストレージサーバーっぽいものを自前で用意する③【Digest認証実装】こんにちは。のんです。前回に引き続き自前でストレージサーバーを開発していこうと思います。 ... GitHubプロジェクトはこちら GitHub - nonz250/storage Contribute to nonz250/storage development by creating an account on GitHub. APIのエラーレスポンス標準化について APIのエラーレスポンスってサービスによって独自に決められたりしていてとても不便ですよね。そこでHTTP APIのエラーレスポンスにも規約が定められたりしています。それが RFC 7807 です。 RFC ft-ietf-appsawg-http-problem: Problem Details for HTTP APIs This document defines a "problem detail" as a way to carry machine- readable details of errors in a ... 日本語版はこちら https://tex2e.github.io/rfc-translater/html/rfc7807.html https://tex2e.github.io/rfc-translater/html/rfc7807.htmlを見る RFC 7807 の実装では、早速この規約に従って実装しよう。と思いましたが、まぁそれも面倒です。こういう標準化規約されているものは世界の優秀な方々がすでに作成していたりするものなのでこれに乗っかる形で実装してしまいましょう。俗に言う standing on the shoulders of Giants ですね。さくっと調べた結果、 Crell / ApiProblem GitHub - Crell/ApiProblem: A simple implementation of the api-problem specification. Includes PSR-15 support. A simple implementation of the api-problem specification. Includes PSR-15 support. - GitHub - Crell/... というものがありそうです。私も伝聞で知ったものなので信頼性などの調査は完璧ではありませんが、タダ乗りなので文句は言えないでしょう。こちらを採用します。書き味は Example にも書いてあるようにこのような感じ。 use Crell\ApiProblem\ApiProblem; $problem = new ApiProblem("You do not have enough credit.", "http://example.com/probs/out-of-credit"); // Defined properties in the API have their own setter methods. $problem ->setDetail("Your current balance is 30, but that costs 50.") ->setInstance("http://example.net/account/12345/msgs/abc"); // But you can also support any arbitrary extended properties! $problem['balance'] = 30; $problem['accounts'] = [ "http://example.net/account/12345", "http://example.net/account/67890" ]; $json_string = $problem->asJson(); // Now send that JSON string as a response along with the appropriate HTTP error // code and content type which is available via ApiProblem::CONTENT_TYPE_JSON. // Also check out asXml() and ApiProblem::CONTENT_TYPE_XML for the angle-bracket fans in the room. しかし、いくら便利でもこの実装を至るところに書くのは面倒ですし、設計上よくありません。そこで、 S3みたいなストレージサーバーっぽいものを自前で用意する②【ミドルウェア実装】 | のんラボ S3みたいなストレージサーバーっぽいものを自前で用意する②【ミドルウェア実装】こんにちは。のんです。前回に引き続き自前でストレージサーバーを開発していこうと思います。 ... で少し触れた、独自 HttpException が活きてきます。もちろん、設計の是非はあるとは思います。私なりの解釈を次の章で説明します。 HttpException に RFC 7807 のエラーレスポンスを実装するこのサービスでは HttpException にエラー時のHttpレスポンスを乗せることを想定しました。何かしらのエラーが発生したときは最終的に HttpException をスローし、それを Controller ないしは Middleware がレスポンスとして返す。という流れです。 Exception　に実装されている code と Http Status Code は別物なので、レスポンスの情報を乗せられるように実装します。まずは HttpExceptionInterface から <?php declare(strict_types=1); namespace Nonz250\Storage\App\Foundation\Exceptions; use Psr\Http\Message\ResponseInterface; interface HttpExceptionInterface { public function getStatusCode(): int; public function getApiProblemResponse(): ResponseInterface; } HttpExceptionInterface を実装する HttpException は必ず HttpStatusCode を取得できるようにしていなければなりません。なので、　getStatusCode を実装するように定義します。 getApiProblemResponse でエラーレスポンスを作成し取得します。そして肝心の HttpException の基盤例外クラスがこちら。 <?php declare(strict_types=1); namespace Nonz250\Storage\App\Foundation\Exceptions; use Crell\ApiProblem\ApiProblem; use Crell\ApiProblem\HttpConverter; use Fig\Http\Message\StatusCodeInterface; use Laminas\Diactoros\ResponseFactory; use Psr\Http\Message\ResponseInterface; use RuntimeException; use Throwable; class HttpException extends RuntimeException implements HttpExceptionInterface { private int $statusCode; private string $description; public function __construct( int $statusCode = StatusCodeInterface::STATUS_OK, $description = '', $message = '', $code = 0, Throwable $previous = null ) { parent::__construct($message, $code, $previous); $this->statusCode = $statusCode; $this->description = $description; } public function getStatusCode(): int { return $this->statusCode; } public function getApiProblemResponse(): ResponseInterface { $responseFactory = new ResponseFactory(); $converter = new HttpConverter($responseFactory, true); $problem = new ApiProblem($this->getMessage()); $problem ->setStatus($this->getStatusCode()) ->setDetail($this->description); return $converter->toJsonResponse($problem); } } この例外クラスは例外の主なメッセージ Http Status Code (4XX や 5XX を想定) 例外の詳細文を必要とし、これらの情報と Crell / ApiProblem を利用して ResponseInterface を実装した Httpレスポンスを返します。 $responseFactory = new ResponseFactory(); $converter = new HttpConverter($responseFactory, true); ResponseInterface を実装した HttpResponse を作成するために必要です。最終的には toJsonResponse でjson形式のレスポンスを返す関数を利用するために使います。 $problem = new ApiProblem($this->getMessage()); $problem ->setStatus($this->getStatusCode()) ->setDetail($this->description); 肝心の部分、 type は必須のためコンストラクタに例外の主なメッセージを渡しておきます。その後、必要に応じて status や detail を埋めるために setter で Http Status Code (4XX や 5XX を想定) や　例外の詳細文　を設定します。このあたりの詳細は RFC 7807 を参照していただければと思います。わかりやすいように引用しておくと、 o "type"（文字列）-問題のタイプを識別するURI参照 (RFC3986)。この仕様では、逆参照すると、問題の種類について人間が読める形式のドキュメントが提供されるようになります（たとえば、HTML (W3C.REC-html5-20141028)を使用）。このメンバーが存在しない場合、その値は "about：blank"であると見なされます。 o "title"（文字列）-人間が読める形式の問題タイプの概要。ローカリゼーションの目的を除いて、問題の発生ごとに変更するべきではありません（たとえば、事前対応型のコンテンツネゴシエーションを使用します。(RFC7231)、セクション3.4を参照）。 o "status"（number）-この問題の発生に対してオリジンサーバーによって生成されたHTTPステータスコード（(RFC7231)、セクション6）。 o "detail"（文字列）-この問題の発生に固有の、人間が読める説明。 o 「instance」（文字列）-問題の特定の発生を識別するURI参照。逆参照すると、詳細情報が得られる場合と得られない場合があります。エラーレスポンスの例としては For example, an HTTP response carrying JSON problem details: たとえば、JSON問題の詳細を含むHTTP応答： HTTP/1.1 403 Forbidden Content-Type: application/problem+json Content-Language: en { "type": "https://example.com/probs/out-of-credit", "title": "You do not have enough credit.", "detail": "Your current balance is 30, but that costs 50.", "instance": "/account/12345/msgs/abc", "balance": 30, "accounts": ["/account/12345", "/account/67890"] } と書いてありますね。最後に、この ApiProblem クラスを　toJsonResponse メソッドを使ってHttpレスポンスに変えます。 return $converter->toJsonResponse($problem); これが getApiProblemResponse の全容です。ちなみに、 HttpStatusCode の番号をマジックナンバーにしたくないため、 GitHub - php-fig/http-message-util Contribute to php-fig/http-message-util development by creating an account on GitHub. のライブラリを利用しています。 PSR-7 のHTTPに関する番号や数字をまとめて定義してくれている便利なライブラリです。独自 HttpException クラスの使い方何かしらの例外やエラーをキャッチしたときに、この HttpException を継承したクラスに詰め直して、スローするだけです。 try { $digests = $request->getHeader('Authorization') ?? []; if (count($digests) === 0) { throw new HttpUnauthorizedException('Please set `Authorization` header.'); } } catch (HttpUnauthorizedException $e) { $this->logger->error($e); return $e->getApiProblemResponse(); } 上記の用に HttpUnauthorizedException などを用意しておけば更に使いやすいはずです。 HttpUnauthorizedException の実装はこちら。ただのラッパーであることがわかるはずです。 <?php declare(strict_types=1); namespace Nonz250\Storage\App\Foundation\Exceptions; use Fig\Http\Message\StatusCodeInterface; use Throwable; class HttpUnauthorizedException extends HttpException { public function __construct($description = '', $message = 'Unauthorized.', $code = 0, Throwable $previous = null) { parent::__construct(StatusCodeInterface::STATUS_UNAUTHORIZED, $description, $message, $code, $previous); } } こうすることでとりあえずエラーが発生したときは HttpException を実装した例外クラスをスローしておけばなんとかなる。最終的にキャッチしたところで、 return $e->getApiProblemResponse() をすれば RFC 7807 を実装したHttpレスポンスとして返すことができるという便利な設計になりました。エラーレスポンスに関する責務も HttpException に封じ込めることができています。実際の動作実際に返ってくるレスポンスはこちら。 { "title": "BadRequest.", "type": "about:blank", "status": 400, "detail": "appName is required." } 最後にこのサービスは自分だけが利用することを想定しているので、APIエラー時に参照すべきドキュメントはありません。そのため type は全て about:blank ですが、外部に公開しているサービスならこの部分がドキュメントへのURLになるでしょう。とても親切な作りですね。ドキュメントを読む限り invalid-params を利用すれば複数のバリデーションエラーも含めることができそうなので、汎用性はとても高そう。 PHPフレームワークにも標準で実装しておいていただければ助かるものですが、まぁ、そう思うなら自分でプルリク出せという話ですね。どちらかというとプラグインとして用意してあげるのが良さそう？でもそれなら、この記事で紹介したライブラリで十分というものでしょう。という感じで RFC 7870 を実装してみました。次回は Repository の実装になりそうです。このときにDIについても話になるかもしれません。また記事にします。そのときはよしなに。 .

S3みたいなストレージサーバーっぽいものを自前で用意する③【Digest認証実装】

2022/03/26 2022/04/10

S3みたいなストレージサーバーっぽいものを自前で用意する③【Digest認証実装】こんにちは。のんです。前回に引き続き自前でストレージサーバーを開発していこうと思います。 S3みたいなストレージサーバーっぽいものを自前で用意する②【ミドルウェア実装】 | のんラボ S3みたいなストレージサーバーっぽいものを自前で用意する②【ミドルウェア実装】こんにちは。のんです。前回に引き続き自前でストレージサーバーを開発していこうと思います。 ... GitHubプロジェクトはこちら GitHub - nonz250/storage Contribute to nonz250/storage development by creating an account on GitHub. 前回作成したAuthMiddleware にDigest認証を実装する Digest認証について Basic認証はBase64でエンコードされているとはいえ、パスワードを送ってしまうのでデコードされたらバレちゃう→ダメじゃんって流れからパスワードを含めた情報を md5 や sha256 でハッシュ化して送ろうと考案された。この辺は散々他のWEBサイトで解説されているので簡単に説明しました。 API認証でこのDigest認証を採用する可能性があった（仕事で使うかもしれない）から勉強するために採用しました。 Digest認証 - Wikipedia Digest認証 - Wikipediaを見る wikiによればクライアントは認証が必要なページをリクエストする。しかし、通常ここではユーザ名とパスワードを送っていない。なぜならばクライアントはそのページが認証を必要とするか否かを知らないためである。サーバは401レスポンスコードを返し、認証領域 (realm) や認証方式（Digest）に関する情報をクライアントに返す。このとき、ランダムな文字列（nonce）とサーバーがサポートしている qop (quality of protection) を示す引用符で囲まれた１つまたは複数のトークンも返される。それを受けたクライアントは、認証領域（通常は、アクセスしているサーバやシステムなどの簡単な説明）をユーザに提示して、ユーザ名とパスワードの入力を求める。ユーザはここでキャンセルすることもできる。ユーザによりユーザ名とパスワードが入力されると、クライアントはnonceとは別のランダムな文字列（cnonce）を生成する。そして、ユーザ名とパスワードとこれら2つのランダムな文字列などを使ってハッシュ文字列（response）を生成する。クライアントはサーバから送られた認証に関する情報(ユーザ名, realm, nc(nonce count), nonce, cnonce, qop)とともに、responseをサーバに送信する。サーバ側では、クライアントから送られてきたランダムな文字列（nonce、cnonce）などとサーバに格納されているハッシュ化されたパスワードから、正解のハッシュを計算する。この計算値とクライアントから送られてきたresponseとが一致する場合は、認証が成功し、サーバはコンテンツを返す。不一致の場合は再び401レスポンスコードが返され、それによりクライアントは再びユーザにユーザ名とパスワードの入力を求める。とある。 APIにはページが無い認証が必要であることが明示的にわかっているため、1, 2, 3の手順は必要ない。このため、 AuthMiddleware には4以降のクライアントから送信された入力情報を検証する処理のみを実装する。ざっくりとした実装と解説 <?php declare(strict_types=1); namespace Nonz250\Storage\App\Http\Auth; // 省略 class AuthMiddleware implements MiddlewareInterface { private DigestAuthInterface $digestAuth; public function __construct(DigestAuthInterface $digestAuth) { $this->digestAuth = $digestAuth; } public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface { try { $digests = $request->getHeader('Authorization') ?? []; if (count($digests) === 0) { throw new HttpUnauthorizedException('Please set `Authorization` header.'); } } catch (HttpUnauthorizedException $e) { // TODO: ログ記録 return $e->getApiProblemResponse(); } try { try { $input = new DigestAuthInput($digests[0], $request->getMethod(), App::env('DIGEST_NONCE')); $this->digestAuth->process($input); } catch (InvalidArgumentException | DataNotFoundException $e) { // TODO: ログ記録 throw new HttpBadRequestException($e->getMessage()); } catch (InvalidResponseException $e) { // TODO: ログ記録 throw new HttpUnauthorizedException('Please check user.'); } catch (Throwable $e) { // TODO: ログ記録 throw new HttpInternalErrorException($e->getMessage()); } } catch (HttpException $e) { // TODO: ログ記録 return $e->getApiProblemResponse(); } return $handler->handle($request); } } 以上が大まかな実装です。 TODO　コメントが多いのは実装途中だからですね。ロギングをしなければエラーを拾うことができなくなってしまいます。未実装なのでメモを残しています。それ以外のところを上から順に追っていきます。 try { $digests = $request->getHeader('Authorization') ?? []; if (count($digests) === 0) { throw new HttpUnauthorizedException('Please set `Authorization` header.'); } } catch (HttpUnauthorizedException $e) { // TODO: ログ記録 return $e->getApiProblemResponse(); } 特に難しいことはしていません。読めばわかると思います。 Authorization ヘッダがない場合にエラーレスポンスを返しています。 return $e->getApiProblemResponse(); の部分はまだ未解説の部分で、（たぶん）次回に解説するのでその時に。 Authorization ヘッダがない場合というのはクライアントは認証が必要なページをリクエストする。しかし、通常ここではユーザ名とパスワードを送っていない。なぜならばクライアントはそのページが認証を必要とするか否かを知らないためである。に反しているのでエラーを返しています。つまり、「このAPIは認証が必須ですよ。」ということをお知らせしています。次に実際にDigest認証をしているところを見てみます。下記のように、検証をしている箇所はUseCase層に封じ込めています。 try { try { $input = new DigestAuthInput($digests[0], $request->getMethod(), App::env('DIGEST_NONCE')); $this->digestAuth->process($input); } catch (InvalidArgumentException | DataNotFoundException $e) { // TODO: ログ記録 throw new HttpBadRequestException($e->getMessage()); } catch (InvalidResponseException $e) { // TODO: ログ記録 throw new HttpUnauthorizedException('Please check user.'); } catch (Throwable $e) { // TODO: ログ記録 throw new HttpInternalErrorException($e->getMessage()); } } catch (HttpException $e) { // TODO: ログ記録 return $e->getApiProblemResponse(); } ほとんどがエラーハンドリングのためのコードですが、実際に検証処理を呼び出している箇所は下記ですね。 $input = new DigestAuthInput($digests[0], $request->getMethod(), App::env('DIGEST_NONCE')); $this->digestAuth->process($input); Digest認証に関するコードはこちら。 Auth ├ ClientRepositoryInterface.php └ Command └─ DigestAuth ├─ DigestAuth.php ├─ DigestAuthInput.php ├─ DigestAuthInputPort.php └─ DigestAuthInterface.php DigestAuthInput クラスに Authorization ヘッダの値 HTTPリクエストメソッド nonce の値の認証に必要な3つの値を渡し、このInputクラスを利用してDigest認証の検証プロセスを発火します。ちなみに、 DigestAuthInput の実装はこちら。 <?php declare(strict_types=1); namespace Nonz250\Storage\App\Domain\Auth\Command\DigestAuth; class DigestAuthInput implements DigestAuthInputPort { private array $data = []; private string $method; private string $nonce; public function __construct(string $value, string $method, string $nonce) { $this->parse($value); $this->method = $method; $this->nonce = $nonce; } public function userName(): string { return $this->data['username'] ?? ''; } public function uri(): string { return $this->data['uri'] ?? ''; } public function qop(): string { return $this->data['qop'] ?? ''; } public function nc(): string { return $this->data['nc'] ?? ''; } public function cnonce(): string { return $this->data['cnonce'] ?? ''; } public function response(): string { return $this->data['response'] ?? ''; } public function method(): string { return $this->method; } private function parse(string $value): void { preg_match_all( '@(cnonce|nc|qop|response|username|uri)=(?:([\'"])([^\2]+?)\2|([^\s,]+))@', $value, $matches, PREG_SET_ORDER ); foreach ($matches as $match) { $this->data[$match[1]] = $match[3] ?: $match[4]; } } public function nonce(): string { return $this->nonce; } } 解説するべき点は1点のみです。 preg_match_all( '@(cnonce|nc|qop|response|username|uri)=(?:([\'"])([^\2]+?)\2|([^\s,]+))@', $value, $matches, PREG_SET_ORDER ); foreach ($matches as $match) { $this->data[$match[1]] = $match[3] ?: $match[4]; } Authorization ヘッダの中身（つまりクライアントから送信された入力内容）から、cnonce値, nc値 , qop値 , response値 , username値 , uri値を取得します。具体的な検証プロセスとその解説 DigestAuthInputPort が実装された入力内容を利用した検証プロセスはこちら。同様に上から追っていきます。 <?php declare(strict_types=1); namespace Nonz250\Storage\App\Domain\Auth\Command\DigestAuth; // 省略 class DigestAuth implements DigestAuthInterface { private const REALM = 'Secret Zone'; private const SHA_256 = 'sha256'; private ClientRepositoryInterface $clientRepository; public function __construct(ClientRepositoryInterface $clientRepository) { $this->clientRepository = $clientRepository; } public function process(DigestAuthInputPort $inputPort): void { $client = $this->clientRepository->findById(new ClientId($inputPort->userName())); $userName = (string)$client->clientId(); $password = (string)$client->clientSecret(); $nonce = $inputPort->nonce(); // @see https://tex2e.github.io/rfc-translater/html/rfc7616.html $A1 = hash(self::SHA_256, "$userName:" . self::REALM . ":$password"); $A2 = hash(self::SHA_256, "{$inputPort->method()}:{$inputPort->uri()}"); $validResponse = hash(self::SHA_256, "$A1:" . $nonce . ":{$inputPort->nc()}:{$inputPort->cnonce()}:{$inputPort->qop()}:$A2"); if ($validResponse !== $inputPort->response()) { throw new InvalidResponseException(); } } } 以外とシンプルにまとまっています。 $client = $this->clientRepository->findById(new ClientId($inputPort->userName())); まず、入力されたユーザー（クライアント）情報を取得します。このときにユーザーの存在チェックも行っています。 ClientRepogitory の実装については実際にGithubのコードを見てみてください。 storage/ClientRepository.php at main · nonz250/storage Contribute to nonz250/storage development by creating an account on GitHub. とは言ってもただのSQL実行機ですが...複雑なクエリを必要としないので、ORMやクエリビルダなどのツールは用意していません。（これもそのうち記事にしたいと思います。）ともかく、 Repogitory からユーザー情報を取得できたので、リクエストで入手した情報とサーバーにある情報を比べて比較していきます。 $userName = (string)$client->clientId(); $password = (string)$client->clientSecret(); $nonce = $inputPort->nonce(); 見てわかるように、今後の処理が追いやすいように変数に格納しているだけです。次のコードに行きます。 @see でも書かれているように、Digest認証は RFC 7616 で決められています。下のサイトは日本語訳されているサイトなので比較的読みやすいと思います。 https://tex2e.github.io/rfc-translater/html/rfc7616.html https://tex2e.github.io/rfc-translater/html/rfc7616.htmlを見るただ、もちろん RFC ft-ietf-httpauth-digest: HTTP Digest Access Authentication The Hypertext Transfer Protocol (HTTP) provides a simple challenge- response authentication mechanis... こちらのサイトの確認も推奨します。さて、具体的な実装については 3.4.1章に書かれていそうです。前提として、このAPIのDigest認証は下記の仕様に従うものとします。 qop 値が auth であることハッシュ化アルゴリズムは SHA256 であることとすると、 If the algorithm parameter's value is "", e.g., "SHA-256", then A1 is: A1 = unq(username) ":" unq(realm) ":" passwd where passwd = < user's password > と実装されるようです。上記を参考にして、まず A1 から $A1 = hash(self::SHA_256, "$userName:" . self::REALM . ":$password"); ユーザー名、 realm値、パスワードを : で結合したものを MD5 や SHA256 でハッシュ化します。次に A2 です。 If the qop parameter's value is "auth" or is unspecified, then A2 is: A2 = Method ":" request-uri If the qop value is "auth-int", then A2 is: A2 = Method ":" request-uri ":" H(entity-body) auth を想定していますので、 A2 = Method ":" request-uri ですね。 $A2 = hash(self::SHA_256, "{$inputPort->method()}:{$inputPort->uri()}"); HttpリクエストメソッドとリクエストUri を : で結合したものを MD5 や SHA256 でハッシュ化します。最後に A1 と A2 からレスポンス値の生成します。このレスポンス値がクライアントで生成されたと同じであれば認証成功となります。 If the qop value is "auth" or "auth-int": response = <"> < KD ( H(A1), unq(nonce) ":" nc ":" unq(cnonce) ":" unq(qop) ":" H(A2) ) <"> See below for the definitions for A1 and A2. 日本語の文法的に最後になってしまいました。これまで作成した A1 と A2 からレスポンス値の生成方法は、 A1 、 nonce値、 nc値、 cnonce値、 qop値（ここではauth）と A2 を : で結合して MD5 や SHA256 でハッシュ化します。 $validResponse = hash(self::SHA_256, "$A1:" . $nonce . ":{$inputPort->nc()}:{$inputPort->cnonce()}:{$inputPort->qop()}:$A2"); こうすることで、クライアント側で生成された response値と同じものが作成できたはずです。それを実際に検証し、成功すればOK。失敗すれば例外をスローします。 if ($validResponse !== $inputPort->response()) { throw new InvalidResponseException(); } これで検証プロセスの実装が完了しました。まとめクライアント側でユーザー情報など各種値と、決められた手順でハッシュ化された response値を Authorization ヘッダにセットサーバーに送信。サーバー側でユーザー情報の有無確認クライアントとは違うリソース（重要: クライアントから取得した情報を利用しても意味がない。DBなどで保存されているクライアントとは別のリソース）を使い、同じ手順で response値を生成 response値の比較という手順。おまけ: エラーハンドリングについて ValueObjectなど引数のエラー BadRequest ユーザー情報の有無や認証エラー Unauthorized その他 InternalServerError という感じ。最後にぶっちゃけこのコードもまだまだ改善点はありますね。 qop は auth のみを前提にしていますし、ハッシュ化のアルゴリズムも <algorithm> -sess の考慮がされていません。想定されていないことなら、それをエラーレスポンスとしてユーザーに教えてあげる必要がありますよね。でもそれがない。というのが今後の課題になりそうです。とはいえ、結局自分しか使わないサービスになりそうなのでその辺は...実装するかな？ｗ次回は予定通り RFC 7807 について記事にしたいと思います。 APIを実装する上でエラーレスポンスをどう返すかというのをルール化したものですね。この話はどちらかというと採用したライブラリや、独自例外クラスの記事になりそうです。賛否あるかと思いますが、温かい目で見ていただければ幸いです。また記事にします。その時はよしなに。 .

S3みたいなストレージサーバーっぽいものを自前で用意する②【ミドルウェア実装】

2022/03/26 2022/03/26

S3みたいなストレージサーバーっぽいものを自前で用意する②【ミドルウェア実装】こんにちは。のんです。前回に引き続き自前でストレージサーバーを開発していこうと思います。 S3みたいなストレージサーバーっぽいものを自前で用意する①【ルーティング初期設定】 | のんラボ S3みたいなストレージサーバーっぽいものを自前で用意するこんにちは。のんです。実はちょっと前からのんラボのリプレースを考えていまして、ブログに載せる画像のアップロード先について考えていました。これまで... GitHubプロジェクトはこちら GitHub - nonz250/storage Contribute to nonz250/storage development by creating an account on GitHub. ミドルウェアを実装する league/route　の MiddlewareInterface https://route.thephpleague.com/ https://route.thephpleague.com/を見る league/route は PSR-15 準拠のミドルウェア実装に対応しているので、 https://www.php-fig.org/psr/psr-15/#22-psrhttpservermiddlewareinterface https://www.php-fig.org/psr/psr-15/#22-psrhttpservermiddlewareinterfaceを見るにあるように、 The following interface MUST be implemented by compatible middleware components. namespace Psr\Http\Server; use Psr\Http\Message\ResponseInterface; use Psr\Http\Message\ServerRequestInterface; /** * Participant in processing a server request and response. * * An HTTP middleware component participates in processing an HTTP message: * by acting on the request, generating the response, or forwarding the * request to a subsequent middleware and possibly acting on its response. */ interface MiddlewareInterface { /** * Process an incoming server request. * * Processes an incoming server request in order to produce a response. * If unable to produce the response itself, it may delegate to the provided * request handler to do so. */ public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface; } を実装するようにします。 process の引数である ServerRequestInterface は PSR-7 、RequestHandlerInterface は PSR-15 準拠です。 ServerRequestInterface （※ 長いので省略） https://www.php-fig.org/psr/psr-7/#321-psrhttpmessageserverrequestinterface https://www.php-fig.org/psr/psr-7/#321-psrhttpmessageserverrequestinterfaceを見る RequestHandlerInterface https://www.php-fig.org/psr/psr-15/#22-psrhttpservermiddlewareinterface https://www.php-fig.org/psr/psr-15/#22-psrhttpservermiddlewareinterfaceを見る The following interface MUST be implemented by request handlers. namespace Psr\Http\Server; use Psr\Http\Message\ResponseInterface; use Psr\Http\Message\ServerRequestInterface; /** * Handles a server request and produces a response. * * An HTTP request handler process an HTTP request in order to produce an * HTTP response. */ interface RequestHandlerInterface { /** * Handles a request and produces a response. * * May call other collaborating code to generate the response. */ public function handle(ServerRequestInterface $request): ResponseInterface; } ミドルウェアはよくドーナツ型の図で表現されます前処理や後処理では、実際にControllersやActionに行く前にしておきたい共通処理を書くことが多いですね。ログの書き込み認証チェック共通データの取得などなど。もちろん上図のように、ドーナツは二重三重にすることができます。実際に作成した AuthMiddleware がこちら。 <?php declare(strict_types=1); namespace Nonz250\Storage\App\Http\Auth; use Psr\Http\Message\ResponseInterface; use Psr\Http\Message\ServerRequestInterface; use Psr\Http\Server\MiddlewareInterface; use Psr\Http\Server\RequestHandlerInterface; class AuthMiddleware implements MiddlewareInterface { public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface { // ミドルウェアでしたい処理。ここではDigest認証を行います。 return $handler->handle($request); } } と言っても、まだDigest認証の実装はしていません。この実装については次回の記事で書こうと思います。前回作成したルートにこの AuthMiddleware を設定します。 $router = new League\Route\Router(); $router ->group('/', static function (League\Route\RouteGroup $router) { // 認証が必要なアクションをここに登録します。 }) ->middleware(new Nonz250\Storage\App\Http\Auth\AuthMiddleware); これで $router->group() で登録したアクションを実行するときに必ず AuthMiddleware が発火します。認証エラーの場合は例外をスローする実装にしておけばアクションまでは実行されないという寸法です。ついでにRequestBodyをParseするMiddlewareを作成するフルスタックなフレームワークを利用していないので、 Content-Type が application/json の状態でアクションからRequestBodyを取得するとStringで取得してします。 <?php declare(strict_types=1); namespace Nonz250\Storage\App\Http\Test; use Laminas\Diactoros\Response; use Psr\Http\Message\ResponseInterface; use Psr\Http\Message\ServerRequestInterface; class TestAction { /** * @param ServerRequestInterface $request * @return ResponseInterface */ public function __invoke(ServerRequestInterface $request): ResponseInterface { $response = new Response(); // ここで取得できる$contentsがjson。つまりStringのまま。 $contents = $request->getBody()->getContents(); $response->getBody()->write($contents); return $response; } } Laravelなどのフレームワークなら自動的に配列に変換されていたり、プロパティとして取得できるのですが、それができていません。これだと非常に不便なので、同じようにMiddlewareを用意してその中でRequestBodyをjsonから配列に変換する処理を行います。 ServerRequestInterface には withParsedBody と getParsedBody という関数が実装されていますので、これを利用します。実際に作成した ParseRequestMiddleware はこちら <?php declare(strict_types=1); namespace Nonz250\Storage\App\Http\ParseRequest; use JsonException; use Nonz250\Storage\App\Foundation\Exceptions\HttpBadRequestException; use Psr\Http\Message\ResponseInterface; use Psr\Http\Message\ServerRequestInterface; use Psr\Http\Server\MiddlewareInterface; use Psr\Http\Server\RequestHandlerInterface; class ParseRequestMiddleware implements MiddlewareInterface { public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface { try { try { $contentTypes = $request->getHeader('Content-Type'); if (count($contentTypes) === 0) { throw new EmptyContentTypeException(); } $contentType = $contentTypes[0]; if ($contentType !== 'application/json') { throw new InvalidContentTypeException(); } $contents = $request->getBody()->getContents(); $parsedBody = json_decode($contents, true, 512, JSON_THROW_ON_ERROR); } catch (EmptyContentTypeException|InvalidContentTypeException $e) { // TODO: ログ記録 throw new HttpBadRequestException($e->getMessage()); } catch (JsonException $e) { // TODO: ログ記録 throw new HttpBadRequestException('Json syntax error.'); } } catch (HttpBadRequestException $e) { return $e->getApiProblemResponse(); } $request = $request->withParsedBody($parsedBody); return $handler->handle($request); } } 一つずつ説明していきます。 $contentTypes = $request->getHeader('Content-Type'); if (count($contentTypes) === 0) { throw new EmptyContentTypeException(); } このコードでRequestHeaderから Content-Type の値を取得します。取得できない場合は Content-Type が無い旨を示す例外をスローします。独自に作成した HttpException と HttpExceptionInterface を継承した例外です。 return $e->getApiProblemResponse(); にある RFC 7807 に従ったエラーレスポンスを返す関数を用意しています。実は league/route にも HttpException は実装されていますが、上記のような独自処理を実装したかったし、 league に依存しすぎるのもどうかと思ったので自前で用意したという流れです。この件についてもいずれ記事にしたいと思います。次のコードです。 $contentType = $contentTypes[0]; if ($contentType !== 'application/json') { throw new InvalidContentTypeException(); } このコードは Content-Type の内容が取得できたらその値が application/json かどうかを確認します。違ったら不適切な Content-Type であることを示す例外をスローします。 $contents = $request->getBody()->getContents(); $parsedBody = json_decode($contents, true, 512, JSON_THROW_ON_ERROR); バリデーションが終了したら実際にRequestBodyを取得します。 json_encode を利用して連想配列へ変換します。このとき、Parseでエラーが発生したら JsonException をスローするように設定しているので、それを catch したらその旨を HttpBadRequestException として投げ直しています。無事、 $parsedBody を取得できたら、 withParsedBody でRequestクラスに保存しておきます。 $request = $request->withParsedBody($parsedBody); こうすることで、 $contents = $request->getParsedBody(); で連想配列形式で取得できるようになります。このMiddlewareをRouterに登録しておきます。 $router = new League\Route\Router(); // AuthMiddlewareと違い、全てのルートでONにしておく $router->middleware(new Nonz250\Storage\App\Http\ParseRequest\ParseRequestMiddleware); $router ->group('/', static function (League\Route\RouteGroup $router) { // 認証が必要なアクションをここに登録します。 }) ->middleware(new Nonz250\Storage\App\Http\Auth\AuthMiddleware); 最後に今回はMiddleware、特に前処理を利用して、認証やRequestBodyの加工の実装を行いました。連想配列を返すっていうのもまた微妙に使いづらいですが、ひとまずここで良しとしておきましょう。必要がある場合はまた自前で拡張してプロパティから取得できるように実装すればいいでしょう。...が、その場合は素直にフレームワークを利用したほうが安心できるかもしれませんね。次回はDigest認証の実装について記事を書こうと思います。その後に RFC 7807 について記事にする予定です。そのときはよしなに。 .

S3みたいなストレージサーバーっぽいものを自前で用意する①【ルーティング初期設定】

2022/03/13 2022/03/13

S3みたいなストレージサーバーっぽいものを自前で用意するこんにちは。のんです。実はちょっと前からのんラボのリプレースを考えていまして、ブログに載せる画像のアップロード先について考えていました。これまではLaravelのデフォルト設定であるプロジェクト内のStorageディレクトリ内に保存していました。ただ、リプレースする際にこれがかなりのネックになっていて、頭を抱えています。新しいプロジェクトではキチンとストレージサーバーを用意してそこにアップロードするようにしようと思いました。 S3を検討していたのですが、S3使うだけじゃ何のインプットもアウトプットもできないので自前でストレージサーバーを用意しようと思い立ったのがこの記事を書くキッカケです。今回からそのためのプロジェクトについて記事にしていきます。一応、連載記事にしようと思っていますが、他にも書きたい内容（Rustとかチームビルディングとか）があるので、とびとびになるかも。 GitHubプロジェクトはこちら GitHub - nonz250/storage Contribute to nonz250/storage development by creating an account on GitHub. できるだけフルスタックなフレームワークは使わない Laravel CakePHP Symfony Slim などは利用しません。しかし、自前で用意した生のPHPだけで書くという意味ではなく、laminasのコンポーネントや、leagueのコンポーネントを利用していきます。 https://getlaminas.org/ https://getlaminas.org/を見る The League of Extraordinary Packages The League of Extraordinary Packagesを見るここでの狙いは、 PSR7やPSR15、RFC 7807やRFC 7807などの仕様、動作の勉強となります。何を組み合わせればいいのか。どのような実装になっているのか。 LaravelやCakePHPのドキュメントやAPIリファレンスを読んでいるだけでは得ることができない習慣を習得するためです。では、早速始めましょう。（今回は触りだけですが...）まずはディレクトリ構成から storage/backendが前提です。 . ├── app │ ├── Adapter │ ├── Domain │ ├── Http │ ├── Provider │ └── Strategy ├── bin ├── tests └── vendor app/Adapter 主にRepository層の具象クラスをまとめる。他のユースケース層で書きたくないものを逃がす場としても利用するかも。ちょっと考え方ガバいけども、今の考え方で大丈夫そう。 app/Domain 主にUseCase層をまとめる。他にはEntities/ValueObjectをまとめます。つまり、レイヤードアーキテクチャでいうDomain層も含んでいるということ。 app/Http 主にHttpControllerをまとめる。MVCモデルのCです。 bin 独自コマンドを実行できるようにする予定。リッチなMigration機能は求めていないので、単純なSQLを実行するためのコマンドや、定期的にファイルを調整するコマンドを用意するつもり。と、だらだら書いたけども... 兎にも角にもRoutingとHttp Requestを捌きたい自前のストレージサーバーと言ってもアップロード用のAPIを公開して受け付けるくらいの機能しかないです。この辺がFW（フレームワーク）を利用しない理由でもあります。 league/route https://route.thephpleague.com/ https://route.thephpleague.com/を見る Route is a fast PSR-7 routing/dispatcher package including PSR-15 middleware implementation that enables you to build well designed performant web apps. です。この仕様にあるライブラリを探すことになるのですが、このページで書いてある2つのライブラリを利用します。 laminas/laminas-diactoros GitHub - laminas/laminas-diactoros: PSR HTTP Message implementations PSR HTTP Message implementations. Contribute to laminas/laminas-diactoros development by creating an... If you use Laminas Diactoros project you will also need composer require laminas/laminas-httphandlerrunner とあるので、 laminas-httphandlerrunner GitHub - laminas/laminas-httphandlerrunner: Execute PSR-15 RequestHandlerInterface instances and emit responses they generate. Execute PSR-15 RequestHandlerInterface instances and emit responses they generate. - GitHub - lamina... も入れます。これらを利用してテスト用のアクションを用意する <?php declare(strict_types=1); include_once 'vendor/autoload.php'; /** * Load dotenv. */ $dotenv = Dotenv\Dotenv::createImmutable(__DIR__); $dotenv->load(); /** * Load environment. */ $env = new Nonz250\Storage\App\Shared\ValueObject\Environment($_ENV['APP_ENV']); /** * Create request. */ $request = Laminas\Diactoros\ServerRequestFactory::fromGlobals( $_SERVER, $_GET, $_POST, $_COOKIE, $_FILES, ); /** * Setting router. */ $responseFactory = new Laminas\Diactoros\ResponseFactory(); $strategy = new League\Route\Strategy\JsonStrategy($responseFactory); $router = new League\Route\Router(); if (Nonz250\Storage\App\Foundation\App::environment(Nonz250\Storage\App\Shared\ValueObject\Environment::LOCAL)) { $router ->group('test', static function (League\Route\RouteGroup $router) use ($strategy) { $router->get('/', static function (): array { return [ 'message' => 'test', ]; })->setStrategy($strategy); $router->get('/hello', static function (): Psr\Http\Message\ResponseInterface { $response = new Laminas\Diactoros\Response(); $response->getBody()->write('<h1>Hello, World!</h1>'); return $response; }); $router->get('/action', Nonz250\Storage\App\Http\Test\TestAction::class); }); } $response = $router->dispatch($request); (new Laminas\HttpHandlerRunner\Emitter\SapiEmitter)->emit($response); 最後に次回はPSR15を参照して、Middlewareを実装した内容を記事にします。自分のためのAPIなので、認証が必要です。 Basic / Digestなどが一般的ですが、今回はDigest認証をAPI認証として利用します。 OAuth2の実装までやってみようと思いましたが、流石に時間かかりすぎるなと思ったのでやめました。 AuthMiddlewareについてはまた記事にしたいと思います。そのときはよしなに。 .

Next.jsのGetServerSidePropsの挙動について

2022/02/11 2022/02/11

Next.jsのGetServerSidePropsの挙動についてこんにちは。のんです。 Reactは書いたことあるのですが、Next.jsは触ったこと無かったので入門しました。今回はそこで発見したわかりにくい仕様について備忘録ついでに記事にしたいと思います。メモ程度で終わってしまいますがご了承ください。 Next.jsのSSGとSSR。前置き。 Next.jsはPreRenderingとServerSideRenderingの2つをサポートしています。クローラーBotのことなどを考えると、SSR一択かもしれんな。と公式からの回答もあるようにSSR推奨気味ではあるものの、それをどのように動作確認すれば良いものやら試行錯誤していました。自分的には右クリックからでる「ページのソースを確認」でHTMLの内容が表示されていればSSRできていると考えています。デフォルトの設定だとSSRできていないようで、どこで切り替えられるのかと調査していました。 Nuxt.jsとは違い設定にSSRモードのフラグ管理も無いようなので、発見時にはなるほど〜といった感想です。 GetServerSidePropsの挙動について結論としてはGetServerSidePropsの関数をexportしてやる必要がありました。 SSRの処理がない場合でも宣言することでSSRできるようになります。ここが重要なようで、別段SSR時に特別なfetch処理がない場合でもこいつを宣言することでSSRが可能になるようです。こんな感じ。（省略とかしてない本当のコード） import {GetServerSideProps, NextPage} from "next"; import {useRouter} from "next/router"; const Article: NextPage = () => { const router = useRouter(); const { id } = router.query; return ( <div> <p>articles</p> <p>{id}</p> </div> ); }; export const getServerSideProps: GetServerSideProps = async (context) => { return { props: {}, }; }; export default Article; このgetServerSidePropsの部分。処理もしていないし、propsも渡していませんが、このページをSSRするために宣言しています。いや、そんなことする必要あるの？という話ですが、jsでレンダリングされる以上クローラーに検知され易くするためには必要な処置だと考えています。具体的な例を書くとこのようになります。 import {GetServerSideProps, NextPage} from "next"; import {useRouter} from "next/router"; const Article: NextPage = () => { const router = useRouter(); const { id } = router.query; return ( <div> <p>articles</p> <p>{id}</p> </div> ); }; // SSRされないようにコメントアウト // export const getServerSideProps: GetServerSideProps = async (context) => { // return { // props: {}, // }; // }; export default Article; とすると、 const router = useRouter(); const { id } = router.query; で取得した <p>{id}</p> の部分がSSRされません。このコメントアウトをもとに戻すと......SSRされます。これは const router = useRouter(); const { id } = router.query; がjsの処理であり、PreRenderingされているためソースレベルではhtmlとして出力されていないからだと考えます。なので、全てをしっかりクローラーに判断してもらうためには、何も処理がなくてもいいので export const getServerSideProps: GetServerSideProps = async (context) => { return { props: {}, }; }; を書いておこうということを発見しました。最後に正直、普段触っている方からしたら「何を今更。」という話かもしれませんが、Nuxt.jsユーザーからすると結構珍しいことだったのでメモ程度に記事にさせていただきました。この「のんラボ」もそろそろ一新するタイミングかなぁ〜と考えています。そのときにはNext.jsを使って一新したいです。あと、技術記事にするときに「わからなかったこと」や「わかりにくいこと」を中心に記事にしてきましたが、ブログのネタに困ることが多くなってきたので、垂れ流し形式変更しようかなと思い始めています。まぁこのへんはゆるく考えます。また記事を書きますので、その時はよしなに。 .

RustでMVC・クリーンアーキテクチャっぽく書いてみた

2022/01/29 2022/01/29

RustでMVC & クリーンアーキテクチャっぽく書いてみたこんにちは。のんです。久しぶりにRustの記事更新です。何もしていなかったわけではなく、ブログにできるレベルの成果物ができていなかっただけですｗ。成果物 ※masterブランチで作業しているので、既に色々更新されている可能性があることにご注意ください。 GitHub - nonz250/rust-sample Contribute to nonz250/rust-sample development by creating an account on GitHub. 個人的悩みポイント mod.rsについて Rustはmoduleの考え方あので、modを定義する必要があるのですが、クリーンアーキテクチャを適用するとどうしてもファイル数が多くなります。その際、 mod.rs というファイルをたくさん作ることになるのですが、これをどうにかスマートに書く方法がないものかなやんでしまいました。結局、 mod.rs を作りまくるこで対応しましたが、もう少しいい感じに書く方法はありそう。。今後に期待。エラーについて Rustをやるにあたって一番最初に躓くところだそうです。特に私はPHPerなので、例外ガンガン書くタイプのプログラマーでした。 Golangなども普段業務で触っているわけではないので、例外がないプログラミング言語をどのように書けばいいのかめっちゃ困りました。 DBアクセスができなかった...とか、データが存在しないとか、ランタイム系のエラーはWEBアプリには付き物なので、通る前提でコーディングできないのが辛いところです。例外を投げるというより、エラー型？（ Result 型）を返すという方がニュアンスとして合っていそうなのでそのように実装していますが、エラーのバケツリレーが始まった感出ていてありゃ〜という感じこの問題もどうにかしてスマートに書く方法はありそう。現在は泥臭くエラー返しています。。。がこの方法も悪くはないのでは？とブログ書きながら考えていたりもします。 PostRepository の実装部分であるこことか fn find_by_id(id: PostIdentifier) -> Result<Post, String> { let connection = establish_connection(); let post = match posts_schema::dsl::posts .find(id.to_string()) .first::<PostModel>(&connection) { Ok(ret) => ret, Err(_err) => return Err("Post not found".to_string()) }; return Ok(Post::new( PostIdentifier { identifier: Ulid::from_string(&post.id).unwrap() }, PostTitle::new(post.title).unwrap() )) } それを呼び出すユースケース、こことかの話。 impl UpdatePost { pub fn process(input: UpdatePostInput) -> Result<(), String> { let mut post = match PostMySqlRepository::find_by_id(input.identifier) { Ok(post) => post, Err(err) => return Err(err) }; post.change_title(input.title); PostMySqlRepository::save(post); return Ok(()); } } ぜーんぶResult返すようになっちゃいました。ここまででRustいいなって思ったところ強力な安全性これはRustに限ったことではありませんが、やっぱり強力な型安全、処理安全なところですね。 ValueObject は採用していますが、これ書く意味ある？（いや、当然書く意味はあるのですが。）と感じてしまうくらい、Rustの仕様を信じてコーディングできるのはすごいなと思いました。あと、エラー周りも最初は戸惑いましたが、エラーを投げるということすらも「これくらいのエラーは想定しておけよ」と言われているようで、ストイックな言語であるということがヒシヒシと伝わってきます。私は好感持てました。 CQRSでReadModelを実装したときはほぼほぼRustの仕様に乗っからせてもらっています。 #[derive(Serialize)] pub struct PostReadModel { identifier: String, title: String } そのほかの実装部分 pub struct GetPostMySqlQuery {} pub struct GetPostMockQuery {} pub trait GetPostQuery { fn get_post() -> Vec<PostReadModel>; } impl GetPostQuery for GetPostMySqlQuery { fn get_post() -> Vec<PostReadModel> { let connection = establish_connection(); let results = posts_schema::dsl::posts .load::<Post>(&connection) .expect("Error loading posts"); let mut posts = Vec::new(); for result in results { posts.push(PostReadModel { identifier: result.id, title: result.title }) } return posts; } } impl GetPostQuery for GetPostMockQuery { fn get_post() -> Vec<PostReadModel> { return Vec::from([PostReadModel { identifier: Ulid::new().to_string(), title: "mock".to_string() }]); } } serde = { version = "1.0", features = ["derive"] } ただの構造体をReadModelとして定義して、jsonにシリアライズできるようにしています。これだけストイックなら、コードを短く書こうと書いている側も頑張るはずこれは個人の感想ですが、ここまでストイックな言語ですと、書けば書くほどエラーに直面します。冗長なコードがだらだら書くとエラーに当たりやすくなるので、短く簡潔に必要なものだけを書くように方向性を矯正させられるとも考えました。とりあえず動けば良かろうをすると、大変な目に合いますねｗ最後にとはいえ、まだまだ基礎中の基礎しか実装てきていないので、このリポジトリで色々勉強していきたいと思います。そのほかにUlidのライブラリを導入したりしていましたが、この辺は書くまでもないことなので割愛しています。多分ここまでくればシンプルなWEBアプリは書けるようになっているはずですが、メールの送信とか、 curl の実行くらいは勉強しておきたい。「rocket使え」ってのはなしでｗ FW使うと勉強の意味無くなってしまいますから。また進捗あれば記事にします。そのときはよしなに。 .

2022年の抱負

2022/01/07 2022/01/07

2022年の抱負明けましておめでとうございます。今年もよろしくお願いいたします。のんです。遅ればせながら、今年の抱負記事を書いてみました。自分の作成した今年の抱負メーカーを利用して画像も作成しました！よかったら使ってみてください！今年の抱負メーカー | ツイッターで今年の抱負をつぶやこう！今年の抱負メーカー | ツイッターで今年の抱負をつぶやこう！時間をフル活用個人アプリを次のステップへ去年はちょっと色々なことに手を出しすぎてグダってしまったというか、本当にやりたいことに対して時間を割くことができなかったなという反省がありました。そこで、今年はやりたいことにしっかりと時間を割けるように意識していきたいと思います！個人開発したアプリの面倒をあまり見れていなくて、去年のうちにやっておきたかったことも他のすべきことで時間を使ってしまい、未達となってしまいました。個人開発のアプリに時間をたくさん使って、たくさんの人に使ってもらえるように頑張りたい。常日頃からそのように思っているので、今年はしっかりと個人アプリに対して時間を使ってあげたいと思っています。 Rust / Golangの勉強今まで個人アプリをPHPで書いていましたが、ある程度成熟したアプリについてはRustやGoで書き直してみようかなと思っています。特にこのブログはおかげさまで色々な方に見ていただけているので「もっと早く描画できるようにしたいな」と結構前から思っていたところです。パフォーマンス的にどのくらい改善されるかはわかりませんが、勉強がてらやってみるのもいいかも。実は少しずつRustの勉強を初めていたのですが、他のブログなどを見るとGoの勉強から始めてみるのもいいかもとあるのでGoで実装してみようかなと考えを改めて見ようとしているところ。あとWEBでRustはオーバースペックっぽい？仕事ではGoが主流のよう。実際にどうなるかはわかりませんが、ひとまずRustでMVCっぽいことをできるようになったのでGoでそれをできるようにしたいと思います。最後に今回は今年の抱負記事でした。数を絞ることで目標を見失わない作戦は果たしてうまくいくでしょうか？仕事も頑張りつつ、自分のための一年にできたらと思います！また記事書きます。そのときはよしなに。 .

2021年の振り返り

2021/12/26 2021/12/26

2021年の振り返りこんにちは。のんです。今回は2021年の振り返り記事になります。今年も色々イベントがありまして、楽しい年になりました！ということで振り返っていきます。会社の業務以外の活動（副業）をたくさんした年中には途中で止まってしまっているものもありますが多めに見てくださいｗやはりいちばん最初に挙げられるのは副業ですね。副業（プログラム開発支援）たまたまとあるサイトで出会った方に「開発の手伝いをしてくれないか」とお声がけいただき、丁度私も探していたところでしたので、協力させていただきました。その方がとても良心的な方で、技術的にも仕事的にも大変良い思いをさせていただいております。このブログを見ているかはわかりませんが、本年は大変お世話になりました。引き続き変わらぬお付き合いをさせていただきたいと思っております。これ以外にも他の方から、ちょっとしたお手伝いに誘っていただくことも多く、大変ありがたいことに本格的に始動した今年から、嬉しい悲鳴をあげさせていただきました🙇 副業（プログラミングレクチャー）こちらは結構前から活動していました。最初は友達やその知り合いのレクチャーや相談といった感じでしたが、こちらも今年をきっかけに色々な方からお声がけいただき、いつも予約パンパンの状態にさせていただいております。本当はお断りしている方々にもレクチャーしたいと思っているのですが、本業との兼ね合いで最大同時に2名までと決めているのです。本当に申し訳ない🙇 機会があればまたお声がけいただければと思います。プログラミングレクチャー系の動画投稿こちらは完全に止まっていますね... なんとか投稿していきたいですが、動画の作成に時間がかかりすぎる。中途半端なものを出すのもアレなので、一度STOPしているというのが現状です。このあたりはキチンと解決して動画を出していきたい。私は学生向けに投稿していきたいので、簡単なものを短期間で成果が出るような内容で投稿するつもりです。来年どうなるかは...まだわからない。名刺代わりのサイトを作りましたこういうこともあり、自分のことを紹介することが多くなりました。ということで、 https://nozomi.bike/ を作成。こちらから私の情報にアクセスできます。コンタクトのとり方はまだメールオンリーですが、追々増やしていくつもりです。よかったらTwitterも覗いてみてください。このサイトに掲載しています。お仕事も頑張った年去年ももちろん頑張ってましたが、今年はベクトルを変え、社外の方々に会社のことを知ってもらうために、自分のTwitterで社内のことをつぶやき始めた年でもあります。 TwitterのDMから何回かアプローチが届くこともありましたし、そこそこ貢献できているでは？あとは自分のプロダクト絡みで、顔と名前だして動画を投稿したりもしました。作るのを頑張ったというより、知ってもらう努力をした年。という感じですね。バイク乗り換えたこれは比較的最近の話ですが、５年ほど乗ったバイクを乗り換えました。これは感慨深かった... 愛車を手放すのがこんなに喪失感あるとは... まぁその代わりバルカンSという新しい相棒に出会えたわけですけどもね！ｗ来年も乗って乗って乗りまくります！！最後にこう見ると割と仕事人間なのかもしれん。でもPCの前に居るか、バイクに跨っているかとどちらかなので、間違っていないかｗついに確定申告が必要な規模になったので、戦々恐々としています。来年は一発目は今年の抱負メーカーを利用したつぶやきにしたいなという思いです。またお会いしましょう！その時はよしなに。 .

バルカンSを納車しました！

2021/12/12 2021/12/12

バルカンSを納車しました！こんにちは！のんです！！バルカンSを納車しました！前々から気になっていたクルーザータイプのバイクです！株式会社カワサキモータースジャパン株式会社カワサキモータースジャパンのオフィシャルウェブサイトです。モーターサイクル、ジェットスキー、ドリームプラス、汎用ガソリンエンジンなど、カワサキブランド製品の製品情報、購入サポート情報をご紹介し... 実は結構前から乗り換えは検討していた。やっぱり、２５０ccは軽い。高速ではおもちゃみたいにどっかすっ飛んでいきそうで怖かったのです。もちろんZ250はいいバイクで街乗りや峠のツーリングはとても楽しいです。でもそろそろ大排気量のバイクも乗ってみたいなでもリッターバイクはでかすぎるし乗らなくなってしまいそう。ということでZ650やZ900を候補にあげていました。しかしまたタイプの似ているバイクはどうなのか。。。ということで。。。↓ 前乗っていたZ250とは全く別のタイプを選択しましたこれまでのZ250 前乗っていたのはZ250。ストリートファイターという見た目が尖っているスポーツタイプのバイクといったところです。こんな感じです。結構尖っているバイクかと思います。でも見た目の割に軽量で取り回しが簡単なので、女性人気が高いバイクでもあります。あと、めちゃくちゃコアなファンが多いことでも有名ですｗ新しく納車したバルカンS めちゃくちゃマッシブ。クルーザータイプではありますが、バルカンS（このSはSportのSだそうです）と呼ばれるだけあり取り回しがスポーティーな味付けです。ドコドコというエンジン音も控えめなので、ライトにアメリカンタイプのバイクに乗りたい方にはオススメかもしれません。足つきも抜群。何ならZ250よりもいいまであります。まぁクルーザーですし。重心が低いので人馬一体のような乗り方はとても難しい。ニーグリップもできない（いや、できるんだけど、するとダサいｗ）のでコーナーは要注意ですね。しかし、その分ロングツーリングでは力を発揮します。優れた安定性にパワーもあるし、乗り心地も最高です。積載性能は相変わらずなしですが、サイドバック装備を前提にしているので思ったより載ります。スポーツタイプから乗り換えるために装備も一新したどうですかね？乗り心地の違いやっぱり重い押し歩きは考えたくないですね。重心が低いのもあって押して歩くと転けそうです。転びそうなときに復帰するのも大変そう。。。重さのおかげで高速巡航が快適。ちょっとした風や衝撃で車体が揺れません。どっしりと走れるのはとても快適です！足を投げ出すタイプ足が真下に下ろすのではなく、前に投げ出すタイプなのでバイクで立つことができません。注意して乗らないと結構、腰に来るバイクかもしれませんｗそれでも他のバイクよりはふかふかなのは嬉しい。前傾姿勢というより前屈姿勢。ポジションの調整は必要になるかも。体が硬い人は試乗してみてください。背もたれをつけるとめちゃくちゃ違いそうｗ今度試してレビューしてみます。最後にとまぁこんな感じで全然違うタイプのバイクに乗ってみる。。というのもいいですね。この週末は完全に体調不良で死んでました。2日も寝込んだのいつぶりだろうか。口の中が風邪の味がするｗ次回は今年の振り返り記事、その後に今年の抱負記事になりそうですね。また書きます。そのときはよしなに。 .

自己紹介ページ（ポートフォリオサイト）を一新した話

2021/11/28 2021/11/28

自己紹介ページ（ポートフォリオサイト）を一新した話こんにちは。のんです。今回は自分のポートフォリオサイトを一新した話です。今回作成したポートフォリオサイト Nozomi Hosaka https://nozomi.bike 結構前からポートフォリオサイトは用意していた。それがこちら https://portfolio.nozomi.bike/ こちらは完全に自作のhtmlとjsとCSSのみ。モーダルなども全て自作となっていますが、機能重視で正直ダサかったので、一新しようと思っていました。新しいサイトはどのような構成か？ NuxtでSSGしています。やっぱりポートフォリオサイトは静的なもので十分なので、SSRに対応できるように作成していたり、環境もDockerのコンテナで起動できるように調整済みですが、インフラ周りはそこまで用意せず、ただ単にSSGで生成したものを配置しているだけです（手抜き）このブログもサーバーやバックエンド（PHPではなく違う言語など、）丸ごと変えたいと思っているので、そのタイミングで、このポートフォリオサイトも構成が変わることでしょう。ひとまず、サイトとしてやりたいことはできているので及第点としたい。地味に自分の名刺代わりになるサイトが存在しなかったので、年内のうちに用意できたのは大きいなぁと感じています。新しいサイトでやりたかったことせっかくドメイン登録している（nozomi.bike）のに、このドメインにふさわしいサイトが無かった。これまでの制作物のまとめが全然できていなかったので、そのピックアップとその見せ方を整えたかった。自分の名前や顔を公開してもいいと思った。お仕事の受付ページを作りたかった。この辺を静的サイトではできないので、今後改善予定といった感じでしょうか？ポートフォリオというと初学者の面接対策のように考えられがちですが、イチプログラマーとして名刺のように使用したいという側面が強いですね。最後に現状はただの１枚のページですが、ここに書ききれない成果を上げられるようにがんばります。 Nozomi Hosaka https://nozomi.bike よかったら見てください。あと、ブログの更新や今年の抱負メーカーの更新もしなきゃなと思っています。また記事にするので、そのときはよしなに。 .