TypeScriptの型と値とバリデーション
TypeScript は本質的に自分に型が付与されていると思っているだけの JavaScript です。 いくら型を付与しようが、それが実行時に影響を与えることはありません。 コードレビューをしているとここを誤解している人が本当に多いです。何度も解説しているのですが、なかなか浸透しないので、TypeScript におけるバリデーションという視点で記事を書くことにしました。 あと TS でバリデータ使って色々作ろうとしている友人と、プログラミング始めたてで zod と openapi を使っいる友人がいたので、彼らが想定読者です。 型と値の名前空間 TypeScript 上での名前空間(スコープ)は2つに分類できます。 値: 実行時にランタイム上のメモリに存在するもの 型: 静的解析時にのみ参照可能なもの。コンパイル時に完全に消滅する。 TypeScript は基本的に JavaScript
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 で閉じて管理させる。システムの
プログラマ視点での生成AIとの付き合い方
プログラミングについて、最近考えてることについてのポエム。 基本的に、 GPT-4 と Claude-3-Opus を使った経験を念頭に置いて話をする。機械学習エンジニアではないので、あくまで利用者に徹した視点での話。仕事で生成AIを使ったパイプラインを作ったりはしている。 生成AIの進化速度を予測しておく 今大事なことは、今AIがどの程度の性能かという定点の話ではなく、その進化の速度を認識すること。 コード生成というタスクにおいて、生成AIモデルを人間に当てはめると、こんな感じの人物像を自分は持っている。 GPT-4: プログラミング経験2年目の大学2年生 Claude-3-Opus: プログラミング経験3年目の大学3年生 ここでいうn年目は、業務経験ではなく、プログラミングの単位がある大学での、教育課程としての経験年数。今のひたすら学習量を増やす方式だと、単に1年に1年分ぐらい賢くなっ
WebAssembly は次世代のコンテナ技術になれるか？
色々あって WebAssembly の component model を調べていたら、未来が見えた気がしたのでここに書いておきます。 「今の WebAssembly」 とは何か WebAssembly の Web の部分は忘れてください。これは単に JVM version 20xx です。ポータブルなバイナリ仕様です。 実行にあたっては今はホスト言語として JS が使われていますが、実際にはホストがJSである必要すらなく、なんならホストが不要なスタンドアロン環境すらあります。(wasmtime/wasmer) じゃあ WebAssembly は何かというと、サンドボックスで実行される VM の仕様です。比較的高水準なバイナリで、 V8 や Spider Monkey に付属する WebAssembly Runtime や、 Wasmtime や Wasmer といった WebAssemb
AI 時代のコードの書き方, あるいは Copilot に優しくするプロンプターになる方法
Copilot をオープンベータ直後から長く使っていて、また補助的に ChatGPT も使いながらコードを書いていて、なんとなくコツがわかるようになってきた。 自分は生成モデルのことは表面的な理解しかしてない。雑にバックプロパゲーションの実装の写経したり、Transformer の解説とかは読んだが、にわかの域を出ていない。 あくまで利用者として生成モデルから吸い出したプラクティスになる。 基本的に TypeScript と Rust での経験が元になっているが、他の言語にも適用できる話ではあると思う。自分は TypeScript はかなり得意だが、 Rust はあんまり書けるわけではなく、Rust の学習で ChatGPT を頼ろうとして失敗しているというステージ。 Copilot / ChatGPT とどう付き合うか まず、前提として ChatGPT も Copilot も、コード生成
TypeScript 本体のコードを読んでみよう
みんなお世話になっている TypeScript のコードを読みたいと思ったことはないだろうか。読んだ。 一週間ぐらいかかった。完全に読み切ったとは言えないが、概要は掴んだ。 なかなかに複雑でドメイン知識を得るのが難しかったので、これから読む人向けに、登場人物や概念を整理して紹介したい。 読んだのは 2023/6/8 時点で git clone したコード。 最初に: 自分のゴール設定 複数ファイルにまたがった参照を、 TypeScript の Language Service が提供する findReferences() や findRenameLocations(), goToDefinitions() を使って、インクリメンタルに書き換えたかった。 Terser を使うと、今触ってるオブジェクトが何で、何のメンバを書き換えたかの情報が残らない。これを TypeScript のレイヤーで
星取表のアンチパターン
これだけみると LibC がよく見えますね。 オープンソースのライブラリ比較や、エンタープライズな SaaS が競合に対する優位を見せたいときに星取表が使われることが多いです。 中立な立場でライブラリを選定する過程として出てくることがあります。 自分はこれに全く意味がなく、むしろ競争的な立場では出した側が負けるものと認識しています。 星取表を作る側の意図 よく見かけるパターンがこれです。 開発自体は長いため機能が豊富だが性能に劣る先発が、後発を貶めている 恣意的な項目選定で、そもそも負けている そもそも比較対象としての土俵が違う(全部入りのフレームワークと単機能なライブラリの比較) 特に 1 と 2 の組み合わせが多く、この裏では非機能要件で圧倒的に負けていることが多いです。例えば A は機能は豊富だけどビルドに 30秒で、Bは機能は足りないけど3秒だといった場合、多くの場合ではまず B
フロントエンドとSPA職人の目指したものの歴史と概略
年末年始にフロントエンド論みたいな記事をいくつか見たが、僕ら古のSPA職人がやってきたフロントエンドという職域と目指していたものが失伝しかけている気がするので、ここに時代ごとに何を考えていたか、雑に書き殴る。 注意点として、 2004から始まるが、自分がプログラミングを始めたのが2010, 業務としてコードを書き始めたのが 2012 なので、解像度が高いのはそれ以降になる。 tl;dr 2004: 動き出す HTML 2011: 構造化のはじまり 2015: 贅沢品としてのSPAとコミュニティ分化 2017: 貧者のSPA 2019: 守破離としてのパフォーマンス 2004: 動きだす HTML AJAX の時代。要は XMLHTTPRequest で取得したコンテンツに応じて、動的書き換えをDOM書き換えを行うこと。今では名付けるほどでもない操作だが、HTMLが静的なものをやめたことは、
プロを目指す人のためのTypeScript 本の感想 #ブルーベリー本
自分も教える事が多いので、読み手にどういう風に学んでほしいか、自分がどういう風に伝えるべきか、という視点で読んだ。 1章・イントロダクション そもそもTypeScript とはなにかみたいな話。 コンパイルエラーが出ている状態ではプログラムが完成したとは言えません。 力強い コンパイルエラーをただ避けるのではなく、利用する気持ち で TypeScript プログラミングに臨みましょう。 初心者に型違反の向き合い方を諭す話。IDEの補助になるとか。 TS年表で取り上げてるのが特徴的。exactOptionalProperty を取り上げてたり。 TSの型はランタイムに影響しない、という話を何度も解説している。これは初心者の誤解がとても多いので、必要だと思う。何度いっても、伝わって欲しい人に伝わらないのだが… enum や namespace については意図的に解説しない。過去のTS独自路線だ
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
(自分の) JavaScript のユニットテストの書き方
(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事
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 を持っているならオーバレイを表示 オーバレイ中の要素名をクリックした
webcontainer とは
stackblitz が提唱して実装している node.js が動くブラウザ環境。container といってるが、 Docker 等とは関係ない。 stackblitz/webcontainer-core このコンテナはブラウザ内で node.js (らしきもの)が動くことがターゲットで、現在デモとして next.js をビルドしてプレビューできている。これによって node.js + webpack + next.js cli が動いていることがわかる。 デモはここで試せる。 まだ OSS ではないので、この記事の大部分は想像によって書かれている。 webcontainer 概要 (自分の理解なので話半分に) ブラウザサンドボックスでも electron なしでも動かせるようになってきた。しかし現在 node.js を動かすには色々と欠けている部分があるので、それらを総称して webc
Re: Rails を主戦場としている自分が今後学ぶべき技術について
この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io
プログラミング初心者のための JavaScript と Node.js の歴史、それを踏まえた勉強方法
プログラミング初心者のための JavaScript と Node.js の歴史、それを踏まえた勉強方法 2020年でJavaScript学ぶならきっとブラウザ向けJSガン無視していきなり初手node.js（ただし暫く何も足さない）がいいんじゃないかというメモ - min.t (ミント) Node.js を教えることについて、自分は賛成なんですが、その学習パスが整理されてないなと思っていたのと、学習パスがなぜ整理されていないかについて書きます。 はじめに 問題意識として、今のプログラミングスクールや独学勢が Ruby on Rails に偏っていて、 Node.js の人間としては、歯がゆく感じているんですが、実際 Node.js を教えるとしても問題も多いと認識しています。 歴史の話は、当時の実情や政治を省いて結果だけを書きます。具体的には第一次ブラウザ戦争、第二次ブラウザ戦争を言及しませ
blitz-js prisma rails 倒し方
この記事の内容 blitz-js が生まれた背景 prisma の紹介 blitz で簡単なブログを作ってみる blitz を vercel にデプロイしてみる tldr blitz-js は next.js + prisma で rails を再現しようとしているフレームワーク Prisma ORM それ自体が良い。blitz の理解のためにも、まず Prisma を学べ blitz-js 自体はまだ α 品質だけど、今から注目しておく価値はある。デファクトになるかは不明。思想は継承されそう。 はじめに next.js はとても良いフレームワークだが、永続層を持たない。なのでフロントエンドとフロントサーバーに閉じている。 永続層、つまり DB を持たないので、初学者や流行りのプログラミングスクールの教材に選ばれない。また、JavaScript の学習資料が散らばっている。 要は Rail
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
