概要 **以前作成したアプリ**に検索フォームを実装しました。 **vte.cxについて詳しく知りたい方はvte.cxのドキュメント**をご覧ください。 今回実装した検索フォームの仕様は以下になります。 検索した結果を一覧に表示する。 検索した結果でページネーションを行う。 入力した値を全文検索するフォームを作る 複数（最大すべて）の項目を入力し検索できるフォームを作る 実装 今回編集したファイルは一覧画面(ListProf)と新しく作った検索フォームファイル（SearchList）になります。 まずは検索フォームファイルの方から見ていきます。 検索フォーム(SearchList) import * as React from 'react' import { useState } from 'react' type SearchProps = Partial<{ getFeedLengt

概要 **前回作成したアプリにvte.cx**でページネーションの機能を実装しました。 **vte.cxについて詳しく知りたい方はvte.cxのドキュメント**をご覧ください。 今回実装したページネーションの仕様は以下になります。 初期表示は1ページ目 総件数を取得する 「次へ」ボタンを押すと、+1ページ目に移動する 「前へ」ボタンを押すと、-1ページ目に移動する 「最初」ボタンを押すと、1ページ目に移動する 「最後」ボタンを押すと、最後のページに移動する 現在のページを表示する ページの最終番号以降のリクエストが来た時にindexを追加で貼り直す 実装 今回ページネーションを実装したファイルは、前回作った一覧画面(ListProf)と、今回新しく作成したページネーション(Pagination)ファイルになります。 一覧画面(ListProf)。 import * as React fro

久しぶりにペラペラな思いつきを書き捨てて、寝ます。 2、3年前ぐらいにSIerやコンサルでTreasure Dataとか使ってマネージドDWH作ろうぜっていう風潮が流行って、今は運用フェーズに入ってどこも結構苦しんでるってのが僕のすごく狭い観測範囲での印象。 AWSのReadshiftしかり。 なぜ苦しんでるかっていうと、言うほどスケールしないからであり、言うほどマネージドじゃないから。 Treasure Dataは基本的に割当メモリが固定でオートスケールしないので、ピーク時に合わせて必要なメモリを確保しておかないといけない。そうなるとメモリ使用量とか負荷とかをモニタリングしないといけないわけだけど、Saasだから内部のアーキテクチャが隠蔽されていていちいちサポートに問い合わせないといけなかったりする。 Redshiftの場合はそもそも自前でクラスタ管理しなくちゃいけないのでそれが大変って