はてなブックマーク

ネットで定義を調べてみると... データベース設計において、マスタテーブルとトランザクションテーブルという２つの分け方をもとに考えることがある。しかし、あらためてマスタとトランザクションとは何なのか、調べてもいまいちピンとこない。 ネットで調べると以下のような説明が出てくる。 マスタテーブル ユーザーが変更できないデータ あらかじめ登録しておくデータ トランザクションを記録するさいにポチポチ選択する系データ あまり変更することの無いデータ 顧客データや商品データなど ヒトやモノとか トランザクションテーブル ユーザーが登録するデータ 作成してから1週間くらいは高頻度な変更が発生する可能性がある 日報データや売上や活動履歴とか コトやイベント系とか なんとなく、マスタが初回に作成するリードオンリーっぽい情報を管理するもので、トランザクションが作業時に発生するデータであることがわかる。しかし、

useRefとは 公式サイトによれば、 useRef は、.current プロパティが渡された引数 (initialValue) に初期化されているミュータブルな ref オブジェクトを返します。返されるオブジェクトはコンポーネントの存在期間全体にわたって存在し続けます。 まずは ref のことを DOM にアクセスする手段として理解しているかもしれません。<div ref={myRef} /> のようにして React に ref オブジェクトを渡した場合、React は DOM ノードに変更があるたびに .current プロパティをその DOM ノードに設定します。 しかしながら useRef() は ref 属性で使うだけではなく、より便利に使えます。これはクラスでインスタンス変数を使うのと同様にして、あらゆる書き換え可能な値を保持しておくのに便利です。 と書いています。useR

追記 Docker上で開発するパターンを紹介していましたが、一番いいのはDocker上で開発しないことだなと感じました。nodejs自体環境ごとの差分が少なく(macでは動くけどwindowsでは動かないみたいなあれ)、Docker上で開発すると遅いです。あくまでDockerはコンテナデプロイ用と割り切ったほうがいいかもしれません。 2年間育ててきたDockerfileがいい感じになってきたのでノウハウ共有します。サンプルコードはNestJSを利用していますが、Expressなどの他のフレームワークでも参考になると思います(NestJSの前はExpressで運用していたので)。あとprisma初めて使ったので書き方違うかもです。その時は指摘ください。 サンプルコード この記事がカバーしているのは ローカルで Docker for Desktop を使って開発をする。 CIサーバー(GitH

参考資料 NodeJSにおけるテストのベストプラクティス テストピラミッド テストトロフィー テストに関する考え方 テストにはグラデーションがあります。１つのクラスや関数しかテストしないユニットテストから、複数のクラスや関数の組み合わせをテストするインテグレーションテスト、そしてすべてをまとめてテストするE2Eテストまでです。これらをよくテストピラミッドやテストトロフィーを使って、どれくらいのテスト量があると理想だよと教えられます。 ユニットテストとインテグレーションテストの違い 複数のクラスや関数を１つのテストでチェックできるなら、ユニットテストをせずに、インテグレーションテストだけ(あるいはE2Eテストだけ)でいいじゃないかと思うかもしれません。ユニットテストの有効性について説明します。 クラスAがクラスBとクラスCを利用しているとします。 テストのパターンとしては クラスCoreをユ

もくもく会で話している中で、「技術書を読んでも頭に入ってこないし、プログラミングスキルが上がらない」という話になり、そのよさげな説明を思いついたので共有します。 具体的な話としては「本を読んでもスキルアップした感じがしない。それで本をよむモチベがわかない。」というものでした。これは僕もとても共感します。バックエンドエンジニアでいくつか有名な本があり(例えばPoEAAやDDD本)、読まないといけないと思い手を出しました。しかし、何を言っているかわからずひたすらに苦痛で、読み切ることができませんでした。結局これらを読み終えることができたのは、業務経験を4年ほど積んだあとでした。 なぜ、本を読んでも苦痛なのか、頭に入ってこないかを、今振り返ってみると、「全体感」と「土地勘」という例えで説明できるのではと思いました。 まず、前提としてあなたが新しい土地に引っ越してきたとします。その地域のことは全然

現代のベンチャー開発は大きく３の分野が影響しています。 UX リーンスタートアップ(とデザインシンキング) アジャイル開発手法とウォーターフォール開発手法 ただ残念ながらエンジニアの観点でこれらをいい感じにまとめたものは無かったため、僕の観点からまとめてみました。今後起業する人やベンチャーに入るエンジニアの参考になればと思います。 前提知識編 何を作るかとどう作るのか まずは何を始めるにしても「何を作るのか」を決めるフェーズと「どう作るのか」を決めるフェーズを分割したほうがよいです。「何を作るのか」とは、「何を作るのが正解か」と言い換えてもいいかもしれません。多くのプロジェクトには目的があり、その目的を達成するために「何を作るのか」を探るフェーズです。対して、「どう作るのか」は作るものが決まっており、それをどのような手段で作るのかを決めるフェーズです。 なぜ、「何を作るのか」と「どう作るの

こんにちはハトです。色々の記事をあさっているうちに、ファイルアップロードのやり方の知見がたまったので共有します。 基本 以下のようにinputタグにfileを指定すれば、ファイルエクスプローラー(もしくはファインダー)が開きます。選択したファイルはonChangeコールバックの引数に渡されます。

jestのモックの基本 モック関数と引数や呼ばれた回数の記録(sinonで言うところのspy機能) 基本はモック関数であるjest.fn を利用する。 jest.fn() の返り値自体にmock というプロパティがあり、それにアクセスすることで、何回呼ばれたとか、引数の値はなんだったのかとかわかる。 const mockCallback = jest.fn(x => 42 + x); forEach([0, 1], mockCallback); // The mock function is called twice expect(mockCallback.mock.calls.length).toBe(2); // The first argument of the first call to the function was 0 expect(mockCallback.mock.cal

追記: こちらの記事も書きました！ ディレクトリ構造いろいろ ディレクトリ構造って結構悩みますよね。NestJSに限らずいくつかパターンを上げてみたいと思います。 Rails型 僕が最初に学んだディレクトリ構造です。 ├── controllers │ ├── userController.ts │ └── chatController.ts ├── services │ ├── userService.ts │ └── chatService.ts ├── models │ ├── user.ts │ └── chat.ts └── configs ├── presentations │ ├── userController.ts │ └── chatController.ts ├── usecases │ ├── userService.ts │ └── chatService.ts

NestJSとJWT認証で調べて出てくるのは、JWTを自分たちで発行しているやつが多く、Cognitoなど外部がトークン発行してくれる系の認証サンプルが少なかったので、共有します。 公式サイトでは認証に関するページは以下のリンクです。 目標 以下のようにappコントローラーにjwt認証を追加します。このコントローラーにリクエストを送っても、有効なJWTをAuthenticationヘッダに付与しなければ、401エラーで弾かれる仕様です。 @UseGuards(JwtGuard) @Controller() export class AppController { @Get('hello') testGet(): string { return 'Hello!'; } }

バックエンドアプリケーションがやってること 以前こんな記事を見かけました。 そこではアプリケーションのやっている内容を簡潔にまとめており、とても理解が深まった覚えがあります。これを僕の視点と経験からさらに解説してみようと思います。 バックエンドアプリケーションのやっている内容は 権限チェック インプット(request body, query, params)のバリデーション ドメインルールチェック CRUDアクション レスポンスをフォーマットし返却 の5つにまとめられます。 class コントローラー { 更新系メソッド(リクエスト){ // 1. 権限チェック if(リクエスト.ユーザー.権限 !== 'アドミン') throw '権限エラー!'; // 2. インプット(request body, query, params)のバリデーション if(!リクエスト.ボディ.ユーザーID

以下の記事を投稿して1年が経ちました。ノウハウが溜まってきたので、現時点で僕が理解している範囲で共有したいと思います。バックエンド向けの記事です。 ここで言うところの権限とは、誰がこの機能を使えるか決めることです。認可と意味は一緒なのかな？ 権限パターン 以下のような４つの機能があったとき、 取得 作成 更新 削除 権限管理は以下のパターンがあります。 ユーザーに直接機能を紐付ける(例: ユーザーAは取得のみ可能、Bは作成更新のみ可能)。 機能と権限識別記号を紐付ける(例: permissionがADMINであれば全機能可能。USERであれば取得のみ可能など) ユーザーの属性に応じて機能を紐付ける(例: ユーザーが北海道出身で25歳以下のとき、削除が可能) ユーザーに直接機能を紐付ける 各ユーザーごとに細かく機能を割り当てたいときに便利です。細かく権限管理したくない場合は、今後扱う項目が増

nodejsを例に解説します。nodejsでは環境変数はprocess.env.環境変数名でとりだせます。また、開発環境・テスト環境・本番環境をそれぞれNODE_ENVという環境変数にdevelopment test productionと入れる文化があります。 アプリケーションコードに自分が今いる環境(開発|ステージング|本番)を意識させない これはつまり、コード内で環境識別変数(今回で言うところのNODE_ENV)によってif分岐を作らないという意味です。各環境にどのような設定が入るかはアプリケーションコード外にその種類分作成しましょう！ bad if(開発環境){ const logger = new Logger({ level: 'debug' }); } else if (ステージング環境){ const logger = new Logger({ level: 'info }

Authまわり知見貯まるまでは結構むずいので僕のわかる範囲で解説していきます。 公式リファレンス Authライブラリはamazon-cognito-identity-jsのラッパーライブラリ Authライブラリはamazon-cognito-identity-jsのラッパーライブラリです。こちらの機能をamplify向けにインターフェース変えたものです。と解説しようと思ったのですが、GitHubのレポジトリはamplify-jsに統合したみたいですね... フロントエンド用のAPIとバックエンド用のAPI amplifyの他にAWS SDKにはCognitoライブラリが提供されています。以下のドキュメントと先ほどあげた公式リファレンスを比べてみてください。 同じ内容が書いてあることに気づきましたでしょうか？違いといえばAWS SDKのCognitoライブラリのほうには、admin???とい

2022/05/13 追記 記事の下の方で実現している解決方法について、最近うまく動いていないことを確認しました。サポートに連絡したところ、UpdateUserAttributesの完了のタイミングによってはこちらのコードはうまく動作しないことがわかりました。もしこちらの問題を現時点で解決したい場合はこちらの記事のように、独自でメールアドレス検証機構を作成するのが安定してよさそうです。 ユーザーロックされる こんにちはハトです。cognitoで詰まったので共有。 cognitoでメールアドレス変更機能を実装していた。すると以下のことに気づく。 新しいメールアドレスを申請して、メールで検証をする前にその新しいメールでログインできてしまう 逆に検証が成功していないのに古いメールアドレスでログインできない つまり間違ったメールアドレスをリクエストするとその時点で詰む(ユーザーロックというらしい)

こんにちはハトです。業務でwebアプリにWebSocketを導入し、半年たったので知見を共有したいと思います。間違ったことを言っている可能性がありますご了承ください(指摘などwelcomeです) ぶっちゃけリアルタイム通信ってそこまで必要ない 後述しますが、WebSocketを導入すると同時に複雑さも入り込みます。WebSocketは必要ないのであれば入れないほうが良いと思います。自身のサービスの要件を考えたときにリアルタイム通信が本当に必要なのかどうか考えましょう。 WebSocketを導入するとスケールアウト時に、クライアントが接続しているサーバー間をまたぐ通信にRedisなどを導入する必要があります。 WebSocketとsocket.ioの違い 最新のブラウザはWebSocket通信に対応しています。しかしWebSocketについて調べると有名なsocket.ioというライブラリが

こんにちは、ハトです。いままでサーバーを通じでS3にアップロードさせてたのですが、直接アップロードさせたほうが、作りやすいことに気づいて移行しました。以下知見の共有です。 流れ STEP: ブラウザからファイルをアップロード。ファイルのtypeとnameをバックエンドに送信。 バックエンドはS3のsdkをもとに署名付きURLをS3サービスにリクエストする。このときBucket名やファイル名(Key)とファイルタイプをパラメータとして送る バックエンドはsdkから署名付きURLを受け取り、フロントエンドにわたす フロントエンドはもらったURLに直接ファイルをPUTする。 フロントエンドのコード ファイルを何らかの方法で取得した前提です(inputタグからとか)。 // step1: 署名付きurlを取得 const resSignedUrl = await axios.get(`/uploa

こんにちは、ハトです。 いろいろ時間をかけて調査した結果、使わないことになったので供養します(ち〜ん) 長いリストのパフォーマンスを向上させる Reactで長いリストをレンダリングするときに、初期のレンダリング時にコストをすべて払います。これを画面が表示される部分だけレンダリングさせるようにしたライブラリがreact-windowです。React公式サイトのパフォーマンス向上ライブラリの１つとして紹介されています。 こちらを調査する機会があったので、それをまとめてみました。react-windowはgridの機能もあるのですが、今回はリストのみ調査対象です。 サイト 概要 実際にリストをすべてレンダリングするのではなく、画面に表示されている領域のみをレンダリングする技術。それによって、リストをすべてレンダリングするコストを回避しています。 ライブラリ内部に仮想のリストを保持してあり、リスト

画面ローディング時にhtmlの一番下までスクロールしたい こんちには、ハトです。業務で自動スクロールが必要になったので、いくつか方法を考えました。 react-scrollでuseEffect(useLayoutEffect)ないでscrollToBottom()する react-windowというリストライブラリを使ってuseEffect時に一番下のアイテムまでscrollToItem()する リストの最後にdivタグをおき、refを取得。useLayoutEffect内で、ref.current.scrollIntoView()をする useRefに関してはこちらの記事もご参考ください。 結論。refでscrollIntoViewをするのがよい ミニマム const List = () => { const scrollBottomRef = useRef<HTMLDivElement

こんにちはハトです。業務でcognitoを利用していたのですがかなり躓いたので共有します。 つまづきポイント多すぎ まずAWSを利用している方でSPAで認証を実現しようとしてネットをあさるといろいろ情報があることに気づく cognitoの利用 Amplify の auth の利用 わけわかめとなる。次にAmplifyを調べる cliがあるよ cliでコマンド打てばGraphQLとか使えるよ Amplify Consoleあるよ。静的ホスティングが自動化できるよ ん？認証だけ使いたいのになんでGraphQLいれるの？みたいになる。 とりあえず、僕がつまずいたポイントや知見を共有しようと思います。 前提 すでにcreate-react-appなどで、何かしらのreactプロジェクトを作ってある。 AWSでconigtoを使うだけならamplifyはいらないけど、amplifyライブラリは便利だ

このユーザーはこの機能が使える、みたいなあれをどう実現するか 新しい記事公開しました！ 結論 DBで実現するかアプリケーション側でライブラリで実現する。casbinが強そうだぞ。 はじめに ユーザーテーブルにisAdminというカラムを使って、アドミンかそうでないかで、アクセスコントロールを分けていたが、サービスが大きくなり、もう少し細かくコントロールする必要になった。そこで、情報収集してえた見識をまとめておく。 アクセスコントロールという考え方を知る だれがこのファイルを操作できるのかみたいなやつ。おおきく4つのパターンがあるみたい。 DAC RBAC MAC ABAC DACとRBACとMAC この３つはまとめて図で理解したほうが覚えやすいと思う。 DAC(任意アクセス制御)はユーザー側が任意にこの機能を誰が使えるか設定する。例えばgoogleでファイル共有するときに誰までが閲覧可能か