サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
zenn.dev/laiso
React Notes: MarkdownエディタのUIを作る 「React Notes」というReact Server Components(RSC)が発表された時期にReactチーム[1]やVercel[2]が公開していたブログ投稿デモサイトがあって、それをHotwireとHono/JSXで作ってみることでRSCなしに似たようなUXが作れるっていうのを示せるのではと思って、今クローンを作ってみています 現在はテキストエリアにMarkdownを入力するとプレビューをしてくれて、保存→更新の画面遷移がひととうりできるという部分のUIだけ先に試しに書いてみて以下にデプロイしました ソースコードがここにあります SSRな部分をHono/JSXのテンプレート処理系に寄せて クライアントサーバー通信と画面更新のコードはHotwire/Turboで簡略化 イベントハンドラな部分はHotwire/St
TL;DR Astro DBはDrizzle LibSQL(SQLite)互換 内部でAPIにSQLを送信している 仕組み上、Astroなしで無理矢理使うことができるがアンドキュメンテッドなのでお勧めしない Astro DBとは Astro DBはAstroが提供するフルマネージドなSQLデータベースです。Astro Studioというプラットフォームの一部で、Astroで構築するウェブサイトのバックエンドのDBとして利用できます。 ユースケースとしてはウェブサイトの問い合わせの保存先やコンテンツのマスターデータの管理などを想定していそうです 使い方は以下のドキュメントに載っています 静的なSSGでも動的なSSRでも使えます 以下のstudio-templatesリポジトリにサンプルプロジェクトがあります Astro DBのアーキテクチャ Astro DBはDrizzle ORMを拡張して
という構成を手軽に作れるようになっていて便利でした これを軸に素のReact APIを触って遊ぶ環境が作れそうです(Server APIもworkerdで動く範囲なら使えるかも?) とりあえず以下のソースコードでデプロイまでできるかを試しました プロジェクトのベースはnpm create hono@latestで作りました DEMO: https://hono-spa-react.pages.dev/ react react-dom @vitejs/plugin-react-swc をnpm installしています デバッグ しかしこの構成だと@hono/vite-dev-serverによるvite devは実行時エラーになり動きません(!) react-dom_client.js?v=f8955f15:11222 Uncaught Error: Objects are not vali
LLRT (Low Latency Runtime)はAWS Labsの人たちによって公開されたOSSで、 「v8やJSCよりミニマムなJavaScriptエンジン付けてLambdaにデプロイしたらめっちゃ速くなるんじゃない?」というようなコンセプトを持つ新しいJavaScriptコードのランタイムです QuickJS[1]というES2023準拠のJavaScriptエンジンとそのRustバインディングのrquickjsを使って全体的に構築されています(LLRTはES2020と明記されていますが) ECMAScript(ES)にはないNode.jsの標準API群が一部Rustを使って書かれています JavaScriptから呼び出せるモジュールを「LLRTからロードできるネイティブなESMモジュールを追加する」で示したとうり自作できるので、Web Standard APIs互換なウェブフレー
Cloudflare VectorizeはCloudflareがホストするVector database PineconeのようにHTTP経由で呼び出して使う Workers AIと組合せてllama-2とかでRAGを作ってくれという想定らしいけどホストされているText Embeddingsのモデルが英語用しかない 埋め込み表現に変換してVector databaseのAPIに投げるだけなので保存するデータはどのモデルを使っても問題はないのだけど、検索をする時にCloudflare Workersから使いたかったのでHTTP呼び出し可能なものにする 今回はOpenAIのtext-embedding-3の新モデルを試すことにした サンプルデータを登録してクエリで牽くという段階までは以下のドキュメントどうりに実行すると実現できるので省略する 今回は日本語検索をしたくてOpenAIのtext-
以下を満すようなツール (自分は)書き捨てHTMLを見やすく(pretty)する用途で使う ビルドツール不要 スタイル用にHTMLを修正しなくていい(class-less)
htmxの実装は4000行弱のJavaScriptファイルで、そんなに特殊なこともしていなかったので読みやすかった なんか懐しい感じがすると思ったけどjQuery世代の設計っぽい。変数がvarで定義されているし 全体 以下のようなDOMで考えてみる <body> <button hx-get="/clicked" hx-swap="outerHTML">Click Me</button> </body> ❯ curl http://127.0.0.1:8080/clicked <button hx-get="/clicked" hx-swap="outerHTML">Clicked!</button> querySelectorAll()でbody以下を探索してhx-*attributesが定義されたelementsにCustomEventhtmx:*のリスナーを追加 aタグやformタグ
$ git clone https://github.com/github/copilot.vim $ echo "console.lo" > sample.ts $ node getCompletionsCycling.mjs ./sample.ts Completions: { completions: [ { uuid: '3dcce22b-5656-46a3-bbe8-d204ad1c5259', text: 'console.log("Hello World");\n', range: [Object], displayText: 'g("Hello World");\n', position: [Object], docVersion: 0 }, { uuid: '94015891-20a7-4e84-a3b7-6ce0a44b5285', text: 'console.log
⚡️ 25x faster — Switch from npm install to bun install in any Node.js project to make your installations up to 25x faster. https://bun.sh/docs/cli/install という記述を見かけて直感的に、そうはならんやろと思ったものの実際にベンチマークをしているのでどういうことなのかを気になって調べた。 A global install cache. bun installを実行すると ~/.bun/install/cache/ 以下にnpmレジストリからダウンロードされたファイルの実体が展開されキャッシュされる(--cache-dirでパスを変更できる)。 キャッシュにはパッケージのバージョンごとのディレクトリとlatestのシンボリックリンクがある。こ
LiteFS+SQLiteでフルスタックNext.jsアプリケーションを作るから1年弱経過して、現在も1.0未満ですがいくつかの重要なアップデートがあったので共有します。 LiteFS Cloudの提供 2022年時点ではデプロイのタイミングなどでデータベースが吹き飛ばないようVolumeをアタッチして開発者が管理する必要がありましたが、Fly.ioによってLiteFS Cloudが提供されるようになり、バックアップ/リストアが自動化されました。 環境変数にLITEFS_CLOUD_TOKENをセットするだけで、LiteFSはFly.ioの外でセルフホストしつつバックアップにLiteFS Cloudを使うということも可能なようです。 内蔵HTTPプロキシ LiteFSは単一のプライマリノードのファイルシステムですべての更新操作を行うので、通常は複数ノードで動作する分散構成の場合はロードバラ
Function callingについて Chat Completions APIにFunction callingという機能が追加されて、入力テキストから実行する関数とパラメーターを生成できるようになった。 これによって開発者は Completions API(1回目)から返された関数とパラメーターを使って独自の処理を実行する 処理結果をCompletions API(2回目)にrole=functionにJSONでシリアライズして送信する APIからの応答テキストをユーザーに返す というフローが可能になる。 なので、ヘッドレスなChatGPT pluginsのように機能する(LangChainなどで連携方法を試行錯誤していた部分が一部取り込まれたともいえる)。 他の用途としては、「関数とパラメーターを生成」の部分のパラメーターをJSON Schemaとして指定できるので、プロンプトから
OpenAIのChat Completion APIでstream: trueに指定した時にSSEのレスポンスからコンテンツを逐次読み込みしてUIに反映させようとすると、意外に途中のパース処理に手間取ることが知られています。 JavaScript版openai-nodeモジュールのリポジトリにもissueがあるのですが、ユーザー間で試行錯誤しておりまだインターフェイスとして こなれていない印象です。 Cloudflare WorkersやVercel Edge FunctionのEdge Runtimeだとさらにややこしくて、openai-nodeはaxiosで作られたクライアントなのでそのまま動きません。 いろいろな回避策はあるのですが、今回は任意のモジュールを利用せずにAPIに直接リクエストを送信しつつストリーム形式のレスポンスに対応します。 Cloudflare Workers版 C
TLTR 実行時にNeon serverless driver(@neondatabase/serverlessモジュール)がnode-postgres(pgモジュール)内のSocketクラスをWebSocket実装に置き換える WebSocket接続を受けたneon.techサーバーがTCP接続に変換してPgBouncerに接続し応答する Neon serverless driverの解説記事が以下にあります。 Edge RuntimeでNode.jsのSocket APIがサポートされていない問題 Node.jsのORMライブラリはPostgreSQLへの接続にnode-postgresからSocket APIを呼び出しますが、Edge Runtimeは互換性の問題からそのままでは動作しません。 これに対して、各マネージドDBのプロバイダーは専用ライブラリを提供してHTTP経由でDBに
LangChainにContextual Compressionという抽象化が追加されました。概要は以下にあります。 Contextual Compressionは「インデックスするドキュメントのテキスト」と「プロンプトに含めるコンテキストとしてのテキスト」の性質が異る点に注目して、ドキュメント検索の後処理としてプロンプトに含めるテキストの内容に変換処理をかけて改善します。 前提知識 「LLMに質問の答えを生成してもらうためにコンテキストとして事前に検索したテキストをプロンプトに挿入する」という大枠の仕組みさえ知っていればokです。 最近読んだ以下のスライドが分かりやすかったです。 使うRetriever ドキュメント取得のRetrieverにはChatGPT Retriever PluginsをLangChainでデバッグするで作ったRetriverを利用します。 「最近話題になった英語
開発中にChat completion APIやEmbeddings APIを過渡に呼び出して課金されてしまうことを回避します。 また自動テスト内でOpenAI APIを呼び出す時も有効です。 OpenAI公式リポジトリにOpenAPI仕様書が公開されているのでStoplight Prismでモックサーバーを実行します。 > npm install -g @stoplight/prism-cli > prism mock https://raw.githubusercontent.com/openai/openai-openapi/master/openapi.yaml ❯ curl -X "POST" "http://127.0.0.1:4010/chat/completions" \ -H 'Content-Type: application/json; charset=utf-8'
Chat Plugins https://platform.openai.com/docs/plugins/introduction OpenAPI仕様書を公開しておくとGPTがそれを解釈してユーザーの入力からWebリクエストを作って処理してくれるすごいやつ プラグイン開発者は自分の作った各APIのdescriptionをちゃんと書いておけばあとはChatGPT側でよしなにやってくれる LangChainのOpenAPI Agentに仕組みは似ている Retrieval Plugin そのままフォークして使える検索用の知識を与えるプラグイン(APIサーバー)の雛形 こんな感じでAPI作れば動くよというリファレンス実装で、別にPython必須というわけではない 開発者は好きなベクトルDBを選んで自分で構築したインデックスを突っ込んでおけばOK ベクトルDBが必要な理由はテキストを入力してテキ
LangChainという人類のLLMsプロンプトエンジニアリングの英知の結晶みたいなライブラリが存在するのですがChatGPT関連の実装を読んでいたらStructuredOutputParserを実現するために興味深いことをしていた。 StructuredOutputParserは「ChatGPTから構造化書式を持ったデータ」を取得するために冒頭のプロンプトで「特定のJSONコードを埋め込んだmarkdownで出力しろ」と命令する。 The output should be a markdown code snippet formatted in the following schema: ```json { "answer": string // answer to the user's question "source": string // source used to answer
通称Tauri Mobileのアルファ版がリリースされたのでiOS/Androidアプリが開発できるようになった。(https://laiso.hatenablog.com/entry/tauri-on-mobile から半年) Tauriとは TauriはWeb技術でデスクトップアプリを構成するためのフレームワークで、Electronの代替ツール。アプリのUIをHTML+CSS+JavaScriptで開発し、その裏側のネイティブコードをRustで書いて呼び出すことができる。 TauriのアーキテクチャはシステムにあるWebViewを使ってHTML+CSS+JavaScriptを表示する。アプリ内にブラウザエンジンを含むアーキテクチャを取るElectronではApp StoreレギュレーションによりiOSアプリを開発できないので、Tauri MobileはiOS/Androidのネイティブ
これまでの問題 Next.jsのEdge RuntimeはAPI RoutesやMiddlewaresのような単純なリクエスト/レスポンス変換を行う用途で提供されていてReact Componentをレンダリングする(SSR)にはNode.jsランタイム(主にNodeのStreams API)が必要だった[1]。 その上でCloudflare Workersの実行環境でSSRを実現するにはFastly Compute@EdgeのコンポーネントのようにNode.js APIの互換性問題を解決しプラットフォームに適合したグルーコードを生成することが要求された(fastly/next-compute-jsの内部アーキテクチャを調べるを参照)。 なのでCloudflare WorkersにAPI単体をデプロイ+Cloudflare Pagesにエクスポート済みの静的サイトをデプロイしてSPAで動か
なぜLiteFS+SQLiteか 「個人開発のコストはDB次第」でサーバーレス環境でコンピューティングリソースを節約できたけどマネージドDBはまだ高いよ(要約)ということを言っていたら「本番環境でSQLiteを使うといいよ」と何人かの人に教えてもらってLitestreamのことを知った。 LitestreamはDBを読み書きするプロセスを1つにして利用するので、サーバーレス環境でsqliteファイルをパスで参照できて、複数箇所から掴まないように構築すれば条件は整えることができる(Cloud Runのように並行に呼び出してもインスタンスが共有されるサービス+最大サイズを1にしておく、とか)。 Litestreamのみでも便利に使えていたんだけど、プロジェクトをウォッチしていたらその後サーバーを複数台にしてそれぞれのインスタンスで同じ結果を得られたり、書き込み先を適切にハンドリングするデザイン
Cloudflareブログで興味深い記事が投稿されていたので読んだ。 趣旨としてはマイクロフロントエンドアーキテクチャのFragments組成をブラウザからではなくEdgeサーバーとSSRのレイヤーで実現する、というものだと思う。 マイクロサービスアーキテクチャのAPI Gateway / Backends for Frontendsパターンのうちブラウザアプリケーションに限定して拡張したものという理解をした。 Fragments組成 例えばこんな感じに画面の一部を描画するエンドポイントがある https://cloud-gallery-header.web-experiments.workers.dev/ https://cloud-gallery-footer.web-experiments.workers.dev/ これら1つ1つをCloudflare WorkersのService
でPrismaとDenoの人たちによって着々と進められていたプロジェクトが成就しついにDeno DeployでPrismaが使えるようになったのでFreshから試してみた。 環境 Deno Deployにデプロイする Prisma Data PlatformからDBサーバーに到達できる必要がある DBサーバーにはSupabase CloudのPostgreSQLを使う Prisma Data Platform PrismaのData Proxyという機能を利用するためのオフィシャルな方法。 Prisma ClientにDATABASE_URL="prisma://aws-us-east-1.prisma-data.com/?api_key=XXX"のような接続先を設定するとHTTP越しにクエリが実行される。 Denoにはpostgresドライバ がありDeno Deployでも利用できるが
Fastlyから新たなNext.jsインテグレーションツールがリリースされていたので調べてみた。 モチベーションとしてはServerless Nextjs Pluginに移植してCloudflare Workersでも動かしたい。 fastly/next-compute-jsとは Compute@Edge でNext.jsアプリケーションを動かしたい時に使うツール。 以下に解説がある 使い方 Next.jsプロジェクトを作成 npx @fastly/next-compute-js@latest init でサブディレクトリcompute-js以下にCompute@Edge固有の構成を追加する fastly compute serve でローカルで起動する fastly compute publish でデプロイする compute-jsに何ができるのか WebpackとFastly CLI
Firebase HostingがNext.jsのデプロイに対応した[1] と聞きつけ、Next.jsビルドツール好き[2] [3] なので様子を見てきました。 のリポジトリを中心に調べてみます。 Firebase CLI framework-awareness とは フレームワークサポートを付与するためのFirebase CLI のアドオン。 Firebaseプロジェクトの構成に応じて、Google Cloudのリソースを構築する。 現在Next, Nuxt2/3, AngularをサポートしていてCloud Functionsにこれからのフレームワーク機能をサポートするエンドポイントを自動でデプロイしてくれる。 内部アーキテクチャ next export で .next/ ディレクトリができる firebase-frameworks.build() がプロジェクト構造を解析してフレーム
CyberAgentのWeb Speed Hackathon 2022 の仕組みが素晴しいと思ったので(特にGitHub Actionsで自動化されたLeaderboardの部分)、自分の環境で遊ぶための方法を書きます。 Web Speed Hackathonとは たぶんフロントエンド版のISUCONのようなイベントです。 参加者は自分でHeroku等にデプロイしたURLを記載したGitHub Issueを投稿し、BOTが返すGoogle Lighthouseの結果を元に算出されたスコアを競います。 ウェブアプリケーションを遅くするための逆プラクティスがあてられているのはISUCONと同様で。 無料で使えるHerokuにデプロイできるかつ(インフラやバックエンド実装で工夫することも可能ですが)基本的にフロントエンドエンジニアのスキルの範囲内でスコアがアップするような設問になっているのが良い
「Nuxt3でのISR対応について調べる」や「Serverless FunctionsのCustom Runtimeを構築する」を経て、Vercelだいたい分かった状態になったため更に発展させてRailsでISRを動かす実験をしてみた。 条件 VercelのServerless Functionのruby27ランタイム(AWS Lambdaと同等)上で動かす a. Custom Runtimeで全部やるのはたいへんそうなので考えない Build Output API (v3) を使ってOn-Demand Incremental Static Regenerationする a. JavaScriptフレームワーク以外でもできるんじゃない? という部分を検証したい せっかくRailsアプリケーションなのでViewやARも使ってMVCしたい データベースはPlanetScaleのMySQL互換サ
LiteFSとは LiteFSはLitestreamの可用性に関する課題を解決するために同作者によって新しく作られたソフトウェア。 Live Read Replication の実験的な機能ではノード間のHTTP通信でリードレプレカを同期してプライマリで書き込んだデータをrestoreを通さずにレプリカから参照することができるようになる予定だった。 この時書き込みクエリをプライマリに振り分けるのはアプリケーションの責務になる。例: ただそもそも複数台でLitestreamを利用する用途の為にノード間のLive Replicationを実装したとしても、デプロイやフェイルオーバーでノードの入れ替わりが発生する時に、無停止でプライマリを別のノードに切り替えることも考慮したりと、当初のLitestreamのスコープになかった新しい問題も出てくる。 なので「サーバー内のsqlite3ファイルをS3
BunのランタイムにNextサーバーを起動するモードが用意されている。これが何なのか気になったので動作とソースコードを見比べて観察してみた。 bun devがHTTPサーバーを起動するためのコマンドになっている bun自体がもともとdev-serverを高速化する目的で作られたためだと思われる Nextを使うかどうかはbunfig.tomlの設定ファイルで指定されるが、bun --use next で明示もできる bun bun --use next で ./node_modules.bun, ./node_modules.server.bun の2つのバイナリを生成 bun devで これらの.bun を実行する。--bunfile, --server-bunfile で指定もできる 設定ファイルで指定せずオプションなしの bun dev だと routeが解決されず 404エラーになる
はじめに Zennのロードマップに本の全文検索はありますが、今のところタイトルやチャプターの一致検索しか対応していません Zenn Roadmap · zenn-dev/zenn-community なんとかして全文検索できるようにならないでしょうか? 原稿リポジトリを直接検索 Zennは投稿データをGitHubアカウントと接続することができます。 なので検索したい本の原稿がGitHub公開リポジトリである場合、GitHub上で全文検索することが可能です。 (「Chakra UIの歩き方 & Tips集」のリポジトリを検索している様子) しかし複数の本を横断して検索することはできませんし、GitHub連携されていない場合や公開リポジトリがない場合この方法も使えません。 今回私は複数の本を横断的に検索したかったため、替りの方法を求めました。 内部APIを使った本文データのクロール Zennの
次のページ
このページを最初にブックマークしてみませんか?
『laisoさんの記事一覧』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く