TypeScript 関数型スタイルでバックエンド開発のリアル
TSKaigi 2024 のスライドです
TSKaigi 2024 のスライドです
WebAssembly所感
WebAssemblyをちょっといじってみて思ったところをまとめてみます。 設計思想 WebAssembly/designに設計文書がまとまっています。特にHighLevelGoals.mdから読み取れるポイントは以下の4点です。 サンドボックス化された環境であること。 移植性があること。つまり、特定の実CPUアーキテクチャ等に依存しないこと。 少なくともC/C++の(十分に高速な)コンパイルターゲットとして機能すること。 安定した仕様を持つこと。 サンドボックスという観点からは、先行技術として以下のようなものが特筆に値します。 Webサンドボックス JavaScript および asm.js Javaアプレット Flash (ActionScript) NaCl, PNaCl Web以外のサンドボックス OSのユーザーランド、特にLinux userland これらのサンドボックスとの比
この記事はTSKaigi2024での以下の私の発表内容を書き下ろしたものです。 なぜAPIに型をつけたいのか 現代のWebのシステム開発において、クライアント・サーバーともに型のある言語で開発されることが増えてきました。静的な型検査はコードの堅牢性やよりよいメンテナンス性の向上をもたらします。 プログラミング内部だけで型検査をするだけでも十分メリットはありますが、外部I/Oに対する型付けが不十分だとそのメリットを最大限に発揮してるとは言えません。外部I/Oとは、例えばWebフロントエンドだとLocalStorageやDOMからの入力値、それからネットワーク通信（今回はこれをAPIと呼びます[1]）などですね。サーバー側でいうとAPIからの入力・レスポンスやデータベースへの読み書きが該当します。 個人的な経験から言うと、Webシステムの開発におけるエラーの多くはAPIやデータベースとのやり取
目次 目次 「戻り値型の後置記法」って何？ 何が嬉しいの？ 問題点 「戻り値型の後置記法」って何？ C++11から導入された言語仕様です。 タイトルの呼び方は自分が勝手に使っているだけで、英語圏だと「trailing-return-type」がよく使われるらしい。 cpprefjp.github.io この仕様を使うと例えば以下のようなコードが int Add(int a, int b) { return a + b; } このようになります。 auto Add(int a, int b) -> int { return a + b; } 何が嬉しいの？ この仕様はC++のメタプログラミングで戻り値型の推論を簡単に行う目的で使用されます。 なんだ、そんなC++上級者のための機能なんて下々の人間には関係ないじゃん、とお思いかもしれませんが、この機能にはもう一つわかりやすい大きなメリットがある
Result 型 (類似するものとして Either Monad の方が有名かもしれません) を導入する場合、アプリケーション全体の設計を変えたり、全箇所を書き換える必要はありません。 neverthrow は部分的に使用でき影響範囲も閉じるので、局所的に使い始めることができます。 (Rust のような) Result 型 とは ざっくり言うと関数の処理の結果と成否を 1 つの型 Result<T, E> で表したものです。(T は期待する結果の型、 E はエラーを表現する型) 筆者は詳しくはないのですが、 Haskell 等にある Either<L, R> とは厳密には違うようです(Either は両方の値が使用可能であることを前提としている？) 参考: Rust ではなぜ、Either 型ではなく Result 型を採用しているのか neverthrow とは TypeScript で
neverthrow の全機能リファレンス
JavaScript/TypeScript で try/catch を使わないエラーハンドリングに利用できるライブラリとしてはそこそこ有名だと思う neverthrow ですがあまり解説された記事が少なく、関数型と手続き型の書き方をいい感じにミックスできるいいライブラリで情報の少なさから選択されないのも勿体なく感じました。ちょうど GitHub のドキュメントを読みながら意訳してまとめた手元の技術メモがありますのでその一助になればと公開します。 neverthrow とは supermacro/neverthrow: Type-Safe Errors for JS & TypeScript プログラムのエラーハンドリングを try - catch ではなく関数型プログラミング由来の Result 型や Either 型と呼ばれる方法で実現する機能を提供するライブラリです。具体的には Res
Tagged Type(Branded Type)を使って飛行機の不時着や人工衛星紛失を防ごう / Scala 3ではTagged Typeを簡単に作れる - Lambdaカクテル
Tagged Type というテクニックがある（TypeScript界隈などではBranded Typeと呼ばれているようだ）。実行時の型としては同じだが、型システム上はこれを区別して別物として扱い、混同できなくする仕組みを作るためのものだ。 AIくん！サムネイラスト作って！と頼んで作ってもらった画像 Tagged Type 単位の取り違えによる事故は後を絶たない。世の中には、キログラムとポンドを混同して飛行機があわや墜落しかけたり、メートルとヤードを混同して人工衛星がどっかに行ったりしている。尊い人命や国民の血税と比べるといささか霞むかもしれないが、ユーザIDとペイロードを間違えて送信したり、金額と口座番号を取り違えて送金したり、秘密鍵と公開鍵を間違えて表示したりしてしまえば、プログラマが大変な苦労をするか、会社そのものが傾くだろう。 しかしながら、データとしてはどちらも同じDouble
TSKaigiにて使用した資料です。 https://tskaigi.org/talks/ytaisei_ Reactを用いたSPA開発においてフレームワークの採用は時にtoo muchになります。 しかし、Next.jsやRemixのFiled-Basedなルーティングは開発体験が良いです。 私たちはSPA開発においても型安全でFile-Basedなルーティングを求めています。 今回はそのような状況においてTanStack Routerが有力な候補になることを、その特徴とメリットに触れながら解説します。 次の特徴を紹介します。 - 型安全でシンプルなルーティング - File-Basedなルート生成 - バンドルサイズを軽減するCode Splitting - Search Paramsによる状態管理
今回の話 以前、Visitorパターンで型によるswitchやif判定を消すという記事を書きました。前回のやり方に従えばVisitorパターンを使えばswitch文を消せて型安全にすることができました。 ただ、「じゃあ実際使いやすいのか？」というと正直なところ微妙でした。 そういうわけで今回は「妥協をしてできるだけ安全にしながら使い勝手を保つ」方法を紹介します。 前回のおさらい 問題としたコード Visitorパターンで型によるswitchやif判定を消すで紹介したコードのおさらいです。 何を重視していたかというと「型の網羅性を保証したい」でした。あるデータ構造群を他のデータ構造に変換するときなど、switchを使ったパータンマッチングで記述することができます。 using System; namespace Visitors.Samples { public static class C
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TypeScriptとGraphQLで実現する型安全なAPI実装
C++erは全員戻り値型の後置記法を使おう - ペイントソフト開発日誌
neverthrow で局所的に Result 型を使い、 try-catch より安全に記述する
TanStack Routerで型安全かつ効率的なルーティングを実現
【C#】 拡張メソッドで型によるswitchやif判定をできるだけ消す - Qiita