Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
セーフティ・JavaScript・プログラミング
Search
e_ntyo
May 26, 2018
Programming
0
220
セーフティ・JavaScript・プログラミング
https://hojiro-lt.connpass.com/event/88352/
e_ntyo
May 26, 2018
Tweet
Share
More Decks by e_ntyo
See All by e_ntyo
論文紹介 "My Mouse, My Rules - Privacy Issues of Behavioral User Profiling via Mouse Tracking"
e_ntyo
1
140
論文紹介 - Towards Memorable Information Retrieval (ICTIR ‘20)
e_ntyo
0
50
Introducing Type Providers
e_ntyo
0
17k
slamdata/purescript-halogen の紹介
e_ntyo
0
97
Other Decks in Programming
See All in Programming
非ブラウザランタイムとWeb標準 / Non-Browser Runtimes and Web Standards
petamoriken
0
430
どうして手を動かすよりもチーム内のコードレビューを優先するべきなのか
okashoi
3
870
令和7年版 あなたが使ってよいフロントエンド機能とは
mugi_uno
10
5.2k
いりゃあせ、PHPカンファレンス名古屋2025 / Welcome to PHP Conference Nagoya 2025
ttskch
1
180
サーバーゆる勉強会 DBMS の仕組み編
kj455
1
300
.NETでOBS Studio操作してみたけど…… / Operating OBS Studio by .NET
skasweb
0
120
return文におけるstd::moveについて
onihusube
1
1.4k
rails newと同時に型を書く
aki19035vc
5
710
Alba: Why, How and What's So Interesting
okuramasafumi
0
210
QA環境で誰でも自由自在に現在時刻を操って検証できるようにした話
kalibora
1
140
Оптимизируем производительность блока Казначейство
lamodatech
0
960
盆栽転じて家具となる / Bonsai and Furnitures
aereal
0
1.9k
Featured
See All Featured
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.1k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
127
18k
Bash Introduction
62gerente
610
210k
RailsConf 2023
tenderlove
29
970
The Cost Of JavaScript in 2023
addyosmani
46
7.2k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.5k
Designing on Purpose - Digital PM Summit 2013
jponch
116
7.1k
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
Mobile First: as difficult as doing things right
swwweet
222
9k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.2k
Transcript
None
はなすこと 1. @e_ntyoとは 2. なぜJavaScriptなのか 3. 何をもって”安全”とするのか 4. 安全にJavaScriptを書くために ◦
関数型プログラミング ◦ 静的型 ◦ fp-tsの紹介 5. まとめ
1. @e_ntyoとは • オタク(アイドル, アニメ, バンド) • 走る異常性癖 •
普段はTypeScriptを書いている ◦ 最近はHaskell, GraphQLに興味
2. なぜJavaScriptなのか • 活躍する機会が豊富 ◦ web browser, v8 engine, mobile,
etc… ▪ メディアプログラミングの環境としても優秀 ◦ Webアプリケーション開発における莫大な資産(ドキュメント, ライブラリ, FW, 知見) • 特になし
2. なぜJavaScriptなのか • そもそも出来ることならJavaScriptなんて書きたくない ◦ AltJSを使おう(後述) ◦ もうすぐwasmの時代がやってくるらしい
• それでも今は、書かなくてはならない ◦ 今、本格的なWebアプリケーションを開発・運用するなら、JSからは逃げられない ▪ 既存の手法を利用し、早く作って早く公開する必要に駆られることは多い ◦ あなたの大好きなプログラミング言語のコードを読める人は会社に何人いるか
3. 何をもって”安全”とするのか • プログラミング言語の文脈での”安全” ◦ メモリ安全性, 型安全性, null安全, etc… ◦
使うプログラミング言語に依存するところが大きい • “安全な言語とはプログラミングの最中にうっかり自分の足を撃つことが不可能 な言語” - Benjamin C. Pierce 著/住井英二郎 監訳/遠藤侑介・酒井政裕・今井敬吾・黒木裕介・今井宜洋・才川隆文・今井健男 訳 『型システム入門 プログラミング言語と型の理論』 (オーム社、978-4-274-06911-6、2013年) ◦ うっかり”危険”な操作をしないよう、適切な抽象を提供する ▪ スコープ違反 ▪ nullを含む型エラー ▪ セグメント違反, 配列の無効なアクセス
3. 何をもって”安全”とするのか • 型安全 != 実行前に危険な/誤った箇所がわかる ◦ 実行時にエラーで教えてくれるタイプ == 動的型付け言語
◦ 環境(使用する言語やツール)に依存 ◦ 静的型の表現力にも限界はある ▪ どこまで実行前にチェックするか ▪ 依存型やモナドで表現力を高めていく • 今回扱う”安全”は、”TypeScriptで担保される安全”`
4. 安全にJavaScript を書くために • JavaScriptでの”危険”とは何か ◦ Null, undefinedの扱い ◦
等価性判定 ◦ var, letで宣言した変数への 再代入 ◦ 存在しないプロパティへの アクセス・代入 ◦ etc… TypeScriptでこれらの”危険”は回避できるのか?
4. 安全にJavaScript を書くために • JavaScriptでの”危険”とは何か ◦ Null, undefinedの扱い ◦
等価性判定 ◦ var, letで宣言した変数への 再代入 ◦ 存在しないプロパティへの アクセス・代入 ◦ etc…
4. 安全にJavaScript を書くために • JavaScriptでの”危険”とは何か ◦ Null, undefinedの扱い ◦
等価性判定 ◦ var, letで宣言した変数への 再代入 ◦ 存在しないプロパティへの アクセス・代入 ◦ etc…
4. 安全にJavaScript を書くために • JavaScriptでの”危険”とは何か ◦ Null, undefinedの扱い ◦
等価性判定 ◦ var, letで宣言した変数への 再代入 ◦ 存在しないプロパティへの アクセス・代入 ◦ etc…
4. 安全にJavaScript を書くために • JavaScriptでの”危険”とは何か ◦ Null, undefinedの扱い ◦
等価性判定 ◦ var, letで宣言した変数への 再代入 ◦ 存在しないプロパティへの アクセス・代入 ◦ etc…
4. 安全にJavaScript を書くために • JavaScriptでの”危険”とは何か ◦ Null, undefinedの扱い ◦
等価性判定 ◦ var, letで宣言した変数への 再代入 ◦ 存在しないプロパティへの アクセス・代入 ◦ etc… transpile
4. 安全にJavaScript を書くために • JavaScriptでの”危険”とは何か ◦ Null, undefinedの扱い ◦
等価性判定 ◦ var, letで宣言した変数への 再代入 ◦ 存在しないプロパティへの アクセス・代入 ◦ etc…
4. 安全にJavaScript を書くために • JavaScriptでの”危険”とは何か ◦ Null, undefinedの扱い ◦
等価性判定 ◦ var, letで宣言した変数への 再代入 ◦ 存在しないプロパティへの アクセス・代入 ◦ etc…
4. 安全にJavaScript を書くために • JavaScriptでの”危険”とは何か ◦ Null, undefinedの扱い ◦
等価性判定 ◦ var, letで宣言した変数への 再代入 ◦ 存在しないプロパティへの アクセス・代入 ◦ etc… • with, eval ◦ やめようね! ◦ neverを使うとマシに • dead code ◦ 論理的に到達不可能なコードは 検出される • if, switchの条件分岐の漏れ ◦ if, caseブロック内で 値を返す関数の場合、 それは網羅的でないといけない ▪ もちろん検出される
4. 安全にJavaScriptを書くために • でもお高いんでしょう? ◦ “Your TypeScript is JavaScript”
▪ 既存のJSのコードをそのままtscを噛ませると、エラーが出ても必ず出力される ▪ TSの導入にコストはかからない • 安全性以外の特典 ◦ 型がコードのドキュメントのようにはたらく ◦ 最新のECMAScriptの機能が使える ▪ babelいらず ◦ 既存のたくさんのJSライブラリの型ヒント ▪ 補完だけ欲しい人にも
4. 安全にJavaScriptを書くために • さらに”安全”にやっていくために ◦ 副作用のないコード ▪ いちいち関数の返した値を変数に束縛したくない
◦ テスタブルで再利用性の高いコード ▪ well-testedな関数の組み合わせで書けばバグりにくいはず ◦ 文脈を型で表現したい ▪ Option<T>くんはどこ…?
4. 安全にJavaScriptを書くために • さらに”安全”にやっていくために ◦ 副作用のないコード ▪ いちいち関数の返した値を変数に束縛したくない
◦ テスタブルで再利用性の高いコード ▪ well-testedな関数の組み合わせで書けばバグりにくいはず ◦ 文脈を型で表現したい ▪ Option<T>くんはどこ…?
4. 安全にJavaScriptを書くために • いつものパターン ◦ fp ▪ むやみにグローバルな状態を作らない ▪
副作用を出さない • ケースによってはReactive Extensionsもアリかと ▪ 複雑な機能はwell-testedな小さな関数の組み合わせで実現 ▪ カリー化 ▪ 高階関数 ▪ 関数合成 ▪ オライリーから本が出ているが古い • Webのドキュメントを漁ったほうが良い
4. 安全にJavaScriptを書くために • モテない男が気休めに使うみじめな道具 ◦ モナドライブラリ(TypeScript) ▪ Option<T>, Either<T>,
Writer<T>, etc… ▪ monapt, TSMonad, fp-ts
4. 安全にJavaScriptを書くために • gcanti/fp-ts ◦ 最近出てきたさいつよモナドライブラリ ▪ さいつよ: Star,
機能数, 更新頻度 ◦ PureScript, fantasy-land, static-land, Scalaにインスパイアされた ◦ 最新のTypeScriptの機能を取り入れている ◦ interfaceで高階型を表現し、Applicative, Monadを提供 ◦ Option<T>, Either<T>, Reader<T>, Writer<T>, State<T>, Task<T>, Debug.Trace(), etc… ◦ この前記事を書いたので読んでください
4. 安全にJavaScript を書くために • gcanti/fp-ts ◦ Either<L, R> ▪ 失敗系と成功系を
型で表現 ▪ Promiseとの親和性
4. 安全にJavaScript を書くために • gcanti/fp-ts ◦ Option<T> ▪ Nullableな型 •
T | null ▪ 他のモナドと 組み合わせられる
5. まとめ • プログラミング言語の安全性の定義は難しい ◦ 言語により様々な”危険”があるため • もしJSを書くときは、TSやfpを使い、JSの”危険”なコードを握り潰そう ◦
fp-tsを使うと便利である