Python + VSCode の環境構築 20240604
作業メモ。モダン Python 速習。 AI 周りのツールを動かしていたら TypeScript だけでやるには無理が出てきたので、久しぶりに Python の環境構築をする。 具体的には TestGen LLM を動かしたい。 Python はたまに触るけど、基本 2.x 時代の知識しかない。 基本的にこの記事を読みながら、細かいアレンジをしている。 追記 rye が ruff と pytest を同梱してるので rye fmt, rye check, rye test で良かった uvicorn を叩くより、 fastapi-cli を使って起動したほうが良さそうので変更 基本方針: Rye に全部任せる 良く出来てると噂に聞いたので、 rye に任せる。 自分が Python が苦手な点は pip を下手に使うと環境が汚れていく点で、基本的に rye で閉じて管理させる。システムの
WebAssembly は次世代のコンテナ技術になれるか？
色々あって WebAssembly の component model を調べていたら、未来が見えた気がしたのでここに書いておきます。 「今の WebAssembly」 とは何か WebAssembly の Web の部分は忘れてください。これは単に JVM version 20xx です。ポータブルなバイナリ仕様です。 実行にあたっては今はホスト言語として JS が使われていますが、実際にはホストがJSである必要すらなく、なんならホストが不要なスタンドアロン環境すらあります。(wasmtime/wasmer) じゃあ WebAssembly は何かというと、サンドボックスで実行される VM の仕様です。比較的高水準なバイナリで、 V8 や Spider Monkey に付属する WebAssembly Runtime や、 Wasmtime や Wasmer といった WebAssemb
MoonBit が WebAssembly 時代の理想(の原型)だった
最近 moonbit という言語を知ったのですが、これが調べれば調べるほど好きになる言語だったので、紹介させてください。 文法的には GC 付きの Rust で、 WebAssembly にコンパイルされます。とくに CDN Edge Worker 上での実行を想定しているようです。もう好き。 注意: まだ若い言語なので、これから言語仕様がガンガン変わっていくと思われます。あくまで現時点での情報です。 tl;dr Pros だいたい GC あり Rust と捉えていい 文法面のキャッチアップが容易 ライフタイムの難しさを考えなくていい すでに vscode 拡張やパッケージマネージャ等のエコシステムが整っている Cons まだ安定していない / しばらくはソースコードが公開されない 現時点では学習リソースやパッケージ数が足りず、書き手の腕力が求められる はじめに: JS/TS/Rust へ
Markdown のコードブロックでLSPを動かす VSCode 拡張を作った
これができる拡張を作った。 TypeScript と HTML と CSS の LSP を動かせるようにしたので、 markdown 内部で補完が走る。 TypeScript に関しては補完だけではなく型診断の結果を表示している。 .md だけではなく .mdx にも対応している。 インストールと設定 インストールした上で .vscode/settings.json に次の設定を書く。 { "markdown-code-features.enable": true, // to enable completion in markdown "[markdown]": { "editor.quickSuggestions": { "comments": true, "strings": true, "other": true } } } 基本的に、markdown-code-features.
「理論上は最強」の Qwik/QwikCity を、フロントエンドの共通基盤にできないか
Qwik をマイクロフロントエンド基盤として使えないか検討していて思いついた色々。副産物で色々作った。 tl;dr Qwik は理論上は最強。だが難しい qwik-react を使えば選択的に Qwik/React を切り替えられるので、 Astro と同じメタフレームワークとして使えそう React 以外もその気になれば対応できるはず => qwik-svelte と qwik-vue を実装した 最終的な問題は Qwik が流行るかどうか Qwik/QwikCity とは何か Qwik は SSR First なUIライブラリで、 .tsx の React 方言からコンポーネントを生成する。 import { component$, useSignal } from '@builder.io/qwik'; export default component$(() => { return
星取表のアンチパターン
これだけみると LibC がよく見えますね。 オープンソースのライブラリ比較や、エンタープライズな SaaS が競合に対する優位を見せたいときに星取表が使われることが多いです。 中立な立場でライブラリを選定する過程として出てくることがあります。 自分はこれに全く意味がなく、むしろ競争的な立場では出した側が負けるものと認識しています。 星取表を作る側の意図 よく見かけるパターンがこれです。 開発自体は長いため機能が豊富だが性能に劣る先発が、後発を貶めている 恣意的な項目選定で、そもそも負けている そもそも比較対象としての土俵が違う(全部入りのフレームワークと単機能なライブラリの比較) 特に 1 と 2 の組み合わせが多く、この裏では非機能要件で圧倒的に負けていることが多いです。例えば A は機能は豊富だけどビルドに 30秒で、Bは機能は足りないけど3秒だといった場合、多くの場合ではまず B
Cloudflare Workers を活かしきるスタックを考えた(remix+d1 on pages-functions) + 残タスク
Cloudflare Workers を活かしきるスタックを考えた(remix+d1 on pages-functions) + 残タスク このスクラップ で試行錯誤していたまとめ。 最終形はここにアップロードした。 docs の下に、このリポジトリを生成した手順、セットアップ方法、リリース方法を書いてある。 (remix-validated-form や vitest のテストの追加でもうちょっといじるとは思う) なぜ cloudflare-workers + d1 のポテンシャルは最強で、近い未来、開発者|個人開発者の銀の弾丸になると思っているのだが、それを活かす開発スタックが知られていない(要出典)。この記事では GW の間に自分で周辺ライブラリを使い倒しながら選定していった。 2021年 は Fullstack Next.js 元年なので、有望な Next.js 系フレームワークを
フロントエンドとSPA職人の目指したものの歴史と概略
年末年始にフロントエンド論みたいな記事をいくつか見たが、僕ら古のSPA職人がやってきたフロントエンドという職域と目指していたものが失伝しかけている気がするので、ここに時代ごとに何を考えていたか、雑に書き殴る。 注意点として、 2004から始まるが、自分がプログラミングを始めたのが2010, 業務としてコードを書き始めたのが 2012 なので、解像度が高いのはそれ以降になる。 tl;dr 2004: 動き出す HTML 2011: 構造化のはじまり 2015: 贅沢品としてのSPAとコミュニティ分化 2017: 貧者のSPA 2019: 守破離としてのパフォーマンス 2004: 動きだす HTML AJAX の時代。要は XMLHTTPRequest で取得したコンテンツに応じて、動的書き換えをDOM書き換えを行うこと。今では名付けるほどでもない操作だが、HTMLが静的なものをやめたことは、
プログラミング学習の通過儀礼
プログラミング学習とはそもそも何なのか プログラミング初学者やITに関わる人が最初に知るべきこととして、プログラミングとは「あなたが問題を解決するのに用いたい手段を、あなたが思っているようにコンピュータに入力すること」ではない。 実際には、プログラミング学習はコンピュータに可能な(非常に限定された)処理セットを学ぶことであり、その応用の先に当初のゴールが含まれるかは、プログラミングを学んでその特性を学ばないと、判断すらできない。 例えば、手段 A によってゴール X を達成したいとしよう。非プログラマ/プログラミング初学者の発想は、よほど目の付け所がいいのではない限り、次のいずれかに分類される。 A には同じゴール X を解決する簡易な代替手段 B があり筋が悪い。 A で実現するほどの価値がない A は現状の人類の既存のソフトウェアの応用では実現できない。あるいは非常に困難。無理に実現し
Cloudflare D1 がヤバい
まだ検証足りないけど、マジで想像通りのブツなら魂震えるかもしれん…。 Announcing D1: our first SQL database Cloudflare D1 = Edge SQLite Cloudflare D1 は Cloudflare Worker で、つまり CDN Network 上で sqlite が動きます。これだけなら普通の sqlite ホスティングなんですが、もちろん Cloudflare が出すからにはそれだけではなく、CDN Edge 上に Read Replica がバラ撒かれた sqlite になります。ヤバくないですか？ 僕はヤバいと思いました。 このヤバさを知るために、Cloudflare が開発した基盤についていくつか抑えておく必要があります。 Durable Objects は CDN 上の Actor モデルを構築できます。この Acto
Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか
Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか https://d.potato4d.me/entry/20220405-nodejs/ へのアンサーソング。 プログラミング言語としての JavaScript の話をする。 2010年頃、Python 2 でプログラミングを学習した自分にとっては Node.js + CoffeeScript が Better Python だった。 CoffeeScript は当時の JS(ES3~5) に足りない機能を補ってくれて、Python と同じく空白制御のオフサイドルールなのが気に入った。見た目が少しだけ Ruby っぽいので当時全盛だった Rails の人間に訴求するにも有利だった。 Node.js のモジュールシステムである Commonjs は Pytho
実行環境依存のコードに対してテストを書く考え方
社内用の啓発記事ですが、閉じる理由がないのでここに投げます。 ブラウザにべったりなコードを書いてると、ブラウザや node.js 固有の環境をインラインで記述してしまうことが多々あると思います。 あえてダメダメなブラウザ向けのエントリポイントの例を書きます。 // main.ts let id = localStorage.get('id'); if (!id) { id = `${navigator.userAgent}-${Math.random()}`; localStorage.set('id', id); fetch('/auth', { method: 'POST', credentials: 'include', body: JSON.stringify({ id, at: Date.now(), }), headers: {'Content-Type': 'applicat
React で展開された HTML 要素から vscode の生成元コードに飛ぶ 方法
自分が欲しかったから作ったシリーズ 説明しづらいので下記の動画を見たほうが速いです。 Shift を押している間だけオーバレイが有効になり、要素名をクリックすると vscode の該当行に飛びます。 今のところ vite + react のみの対応ですが、仕組み上、あらゆる UI フレームワークに適応可能です。 何が起きているか TypeScript transformer の仕組みで *.tsx の jsx 要素に data-sj-path="vscode://file/..." を付与する TypeScript AST は sourcemap 用の情報を持っている Node の parent を探索し、直近の関数コンポーネント名を探す Shift を押している間、 マウスでホバーされた要素が data-sj-path を持っているならオーバレイを表示 オーバレイ中の要素名をクリックした
typeorm + absurd-sql on Browser のロマン構成
ロマン構成が動いたので紹介します。 コード: https://github.com/mizchi/absurd-sql-example-with-typeorm デモ: https://heuristic-perlman-94f8f4.netlify.app tldr Steam の某クリッカーゲームをやってたら放置ゲーでも作りたい気分になってきた。 複雑なデータを管理するならブラウザ内に本物の sqlite を持ってきたい sqlite は持ってこれたけど TS の中で 生 SQL 書くのがだるかった(補完支援がない)ので ORM でラップしたい Typeorm + absurd-sql の構成を試したら色々大変だったけど動いた つまりブラウザでこのコードが動く。 // ... @Entity() class User { @PrimaryGeneratedColumn() id: nu
Swdev 0.4.0 の新機能、ローカルファイルの読み書き機能とその制限
swdev 0.4.0 のリリースをしました。面白機能をいっぱい足しました。 swdev@0.4.0 | Deno Swdev とは何か: おさらい No Bundle Frontend を目指して、 service worker ですべてをコンパイルすることを目標としています。ブラウザ内で完結してることが他にない優位で、効率的なホットリロードなどを実現できる基盤を作ろうとしています。 インストール $ deno install -qAf --unstable https://deno.land/x/swdev/swdev.ts $ swdev init myapp $ cd myapp $ swdev serve #=> localhost:7777 No Assets！ swdev init xxx で生成したプロジェクトが、ローカルに swdev 用のアセットを生成しないようにしまし
Swdev: 真の No bundle frontend
みなさん、ブラウザ内で TypeScript が直接動いてくれたらいいなぁ、と思ったことはありませんか？ しました。 これができます。 どのようにうごいてるか Service Worker は合法 MITM とも言えて、 fetch 時のリクエストを好きに書き換えることができます。 開発時 初回インストール時に Service Worker をインストール コンパイラを内蔵した Service Worker がリクエストの拡張子に応じて js に書き換える Content-Type: text/javascript として SW でキャッシュして返却 TypeScript(.ts, .tsx) と Svelte(.svelte + preprocess) に対応 WebSocket サーバーを起動。ファイル変更を監視して、変更されたファイル名をブラウザに通知 変更されたファイルを Serv
Svelte + TypeScript のベストプラクティスを考える
自分で Svelte + TypeScript を色々と書いてみたが、情報がまとまってなかったので、ここでまとめていく。 なぜ Svelte + TypeScript か Svelte + TypeScript はセマンティクスが単純で型が付く軽量な Vue として気に入っている。ビルドが軽量で他と混ぜやすいのが特に気に入っていて、React や Vue の他のシステムに対しても、末端のコンポーネントとして混ぜやすい。Vue は歴史的経緯でデータバインディングの仕様が混沌としているが、Svelte はESM First で構文解析時の処理に仕様を寄せてるので、とてもシンプル。 webcomponents として配布するモードがあるのも気に入っている。Vue React は単体のビルドサイズが大きすぎて webcomponents の末端にするのは難しい。 やりたいこと <script la
Native ESM 時代のフロントエンドビルドツールの動向
No Bundle ツールの流行: vite / snowpack モダンブラウザは Native ESM を備えているので、開発時は高速な localhost アクセスを頼って直接 import する、外部ライブラリだけ事前にコンパイルしておく、という手法が流行ってきている。プロダクション用は今まで通りビルドする。 webpack はすべてを一つにバンドルするためにメモリ上にファイルの実体と依存グラフを持っているが、これによりメモリと CPU を圧迫する問題があった。特に巨大なリポジトリではそれが顕著になる。 No bundle ツールの実装として vite と snowpack がある。 https://github.com/vitejs/vite https://www.snowpack.dev/ vite は使ってみた限り、更新時の差分ビルドが爆速で、明らかに体感が良い。 Vue
現代のオブジェクト指向の class の割れ窓化と宣言的プログラミング
オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだの Hatena の件。基本的には同意。ただちょっと切り口が違うので自分の意見を言っておく。ただ、このテーマで何度か書こうとして失敗していて、今回も成功しているとはいえない。 宣言的プログラミングの時代 現代の主流は「宣言的プログラミング」であると思っている。これはリソースの宣言と、その状態遷移の手続きや振る舞いの付与が中心にある。 宣言型プログラミング - Wikipedia その代表的な例がフロントエンドの React と、バックエンドの k8s で、どちらも時系列に基づいた状態の宣言と、フレームワーク側による状態遷移処理、 Reconcillation(調停) が基礎にある。 フロントエンドとバックエンドという両極端な世界で、この変化が起きたのがこの時代を反映したものであると思う。 例えば、jQuer
サードパーティスクリプトの極限環境向け Svelte
この記事は、 Svelte Advent Calendar 2020 - Qiita の 22 日目です。 昨今では、フロントエンドの JS を減らす圧が強くなってきています。とくに来年 4 月に導入される Core WebVital は SEO に関わるため、 マーケティング文脈でもフロントエンドの改善施策として、パフォーマンスを上げる圧が強くなっています。 Google の UX 指標「Core Web Vitals（コアウェブバイタル）」とは？LCP・FID・CLS を解説｜ ferret JavaScript よ。文明を捨て、自然に還れ。 ::ハブろぐ で、ユーザー体験を遅くするものとしてやり玉に上げられるのが、サードパーティスクリプトという、サイト外から読み込まれる第三者の script です。代表的なものが Google Tag Manager や Twitter や Face
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
