記事:2024/4/22-
ルールなど
とりあえず全部開く
2,3分で読めそうなやつはすぐ読んじゃう
その他はgptに要約してもらってからメモ取りながら読む
土曜日中に読めなかったものは諦めるか、読みたければ繰り越す
繰越
ふーむ…命名は確かにこうやってある程度機械的に決めたい。
命名は大事なので時間をかけたいので、時間をかけなくていいところは予め決めておきたい。
JSRいまいちよくわからん…
ts/esmがデフォの世界?
Node.js、Bun、Cloudflareなどにも対応
ts/esmで書けば、いろんなランタイムでつかえるよーってことか?ライブラリ開発者が楽になる?
app.use((req, res, next) => {
// post である場合は origin と sec-fetch-site をチェック
if (req.method === "post") {
// origin は必ずチェック
if (req.headers.origin !== "https://sns.example") {
return res.send(400)
}
// sec-fetch-site は、存在した場合だけチェック
if (req.headers.secFetchSite && req.headers.secFetchSite !== "same-origin") {
return res.send(400)
}
}
return next()
})
// デフォルトに頼らず Cookie に Lax を明示
// 理想は read と write に cookie を分け write を Strict にする
app.use(session("Lax"))
// 副作用のある API は必ず POST にする
app.post("/post", async (req, res) => {
await createPost(req.body)
// ...
})
まず最初に気をつけなければならないことは「TypeScriptのモジュール記法はESMではない」ということだ。
TypeScriptのプロジェクトを運用していると、依存ライブラリをバージョンアップしたらアプリケーションが動かなくなったというケースに遭遇したことがある人もいるだろう。 それはこのサンプルのように、依存ライブラリがESMで記述されるようになったがtsconfig.jsonの設定でCommonJSのファイルが吐き出されるため、CommonJS -> ESMの読み込みとなってエラーになったというパターンがある。
ああ、そうか、tsって厳密にはesmではないのか…トランスパイル時に設定によって変換されるのね。
package.jsonのtype && compilerOptions.module
"type": "commonjs" && compilerOptions.module: "commonjs" -> CommonJSが生成される
"type": "commonjs" && compilerOptions.module: "NodeNext" -> CommonJSが生成される
"type": "module" && compilerOptions.module: "commonjs" -> CommonJSが生成される
"type": "module" && compilerOptions.module: "NodeNext" -> ESMが生成される
拡張子
.ts -> .js が生成される
.mts -> .mjs が生成される
.cts -> .cjs が生成される
なるほど。
Webとスマホアプリ一括で作れるってこと?
React Native for Webの後継みたいなこと…?
そもそもReact Native for Webを知らなんだ。
Non-Async Blocking API: One significant drawback is that js localStorage operates as a non-async blocking API. This means that any operations performed on localStorage can potentially block the main thread, leading to slower application performance and a less responsive user experience.
Limited Data Structure: Unlike more advanced databases, localStorage is limited to a simple key-value store. This restriction makes it unsuitable for storing complex data structures or managing relationships between data elements.
Stringification Overhead: Storing JSON data in localStorage requires stringifying the data before storage and parsing it when retrieved. This process introduces performance overhead, potentially slowing down operations by up to 10 times.
Lack of Indexing: localStorage lacks indexing capabilities, making it challenging to perform efficient searches or iterate over data based on specific criteria. This limitation can hinder applications that rely on complex data retrieval.
Tab Blocking: In a multi-tab environment, one tab's localStorage operations can impact the performance of other tabs by monopolizing CPU resources. You can reproduce this behavior by opening this test file in two browser windows and trigger localstorage inserts in one of them. You will observe that the indication spinner will stuck in both windows.
Storage Limit: Browsers typically impose a storage limit of around 5 MiB for each origin's localStorage.
“Code monkeys” will continue to lose value and struggle to find employment. And really good engineers, the problem-solvers, will continue to be in high demand with diminishing supply.
Learn at least one new language every year.
Read a technical book each month.
9 - IF YOU CAN’T GIVE IT A GOOD NAME, IT’S DOING TOO MUCH
Section 1: Assessing if your problem is worth solving
Section 2: Finding a problem that matters
Section 3: Discovering the best solution
#17: Am I the best person to solve this?