はてなブックマーク

Platform Week - The Cloudflare Blog この中から、個人的に気になったものたちをさっくりまとめ。つまりWorkersとかPagesとかに関連するものが多く、それ以外のStreamingとかWeb3系はスルーしてる。 The next chapter for Cloudflare Workers: open source The next chapter for Cloudflare Workers: open source CFWのランタイムのソースコードをオープンソースにするっていう発表 現時点でコードが見れるわけではなさそう これで`miniflare`と実環境の境界もなくせるねって言ってた https://twitter.com/_mrbbot/status/1523652262115278848 がんばれ〜 コードとして公開されたとして、誰しもが簡単

なんとなく察しはついてるけど、いちおう確かめておこうかと。 GitHub - leader22/workers-benchmark 詳細はこのリポジトリに。 Rustで書くには ドキュメントなどあらゆる情報は、Cloudflare公式のこのリポジトリにある内容がすべて。 GitHub - cloudflare/workers-rs: Write Cloudflare Workers in 100% Rust via WebAssembly Workerグローバルのコードがそれ用のcrateになってて、それを使ってRustでコードを書く。RequestやらKVやらだけでなく、いわゆるRouterやちょっとした便利関数まで実装されてた。 READMEにあるコード例をそのまま貼るとこんな雰囲気で。 use worker::*; #[event(fetch)] pub async fn main(

2022年現在に、Cloudflare Workersで（CDNエッジでWorkerで）SSRする方法は2つある。 Cloudflare Pages(w/ Functions) Cloudflare Workers(w/ Workers Sites) 静的サイトホスティングサービスであるPages + Functionsで動的な部分を追加するというアプローチか、動的なWorkers + 静的なアセットを配信するためのWorkers Sitesという機能を使うかの2択。 で、この記事で調べたいのは、どっちのアプローチでもいいけどこの動的な部分でいわゆるSSRができるフレームワークたち。 誰だってある日突然、エッジでSSRしたい気持ちに駆られることってあるじゃないですか。というわけで、独断と偏見で調べたものをまとめた。 SvelteKit Repo: https://github.com/sv

GitHub - BuilderIO/qwik: An Open-Source framework designed for best possible time to interactive, by focusing on resumability of server-side-rendering of HTML, and fine-grained lazy-loading of code. 去年から気になってて、調べたいなーと思ってたやつ。 昨今の覇権を握ってる系のJavaScript-firstなフレームワークたちとは違い、HTML-firstを謳うユニークなアプローチをしてるのが一番の特徴。 中の人による一連のシリーズもあって、そこも読んでまとめてみた記事です。 Qwik Series' Articles - DEV Community Qwikの特徴 遅いモバイル環境だとしても、

なんだかんだここ半年くらいずっとCloudflare Workersを触ってます。 で、CDNエッジでコードが動くことはわかった。制約があることも、それなりに速いこともわかった。 で、これをどう扱っていくのが人類にとって良いんかな〜？みたいなことをずっと考えてた折に、VercelやらRemixが「これからはエッジだ！」（意訳）みたいなメッセージを出してて、ふふ〜んってなった今日このごろ。 We believe the modern Web is at the Edge and embraces the open Web platform. https://vercel.com/blog/vercel-funding-series-d-and-valuation We leveraged distributed systems at the edge instead of static bu

Cloudflare社は、定期的に「なんたらWeek」って感じでまとめてアップデートを発表する取り組みをやってるっぽく、今回のテーマはフルスタック！ なんでもかんでもCloudflareでできるようにするよ！という強い意志を感じる発表たちだった。 Full Stack Week - The Cloudflare Blog 今回は実験的にTwitterでもまとめて流してたけど、やっぱりブログにまとめるほうがしっくりくるなってことで、改めて。 https://twitter.com/leader22/status/1460451057109127169 https://twitter.com/leader22/status/1460772775010791430 https://twitter.com/leader22/status/1461158193631936512 https://tw

我らがCloudflare社が、先日のブログで"Web3"なるものに言及してた。しかも3記事も続けざまに。 不勉強な身としては、ざっと読んだだけではふわっとしか理解できなかったので、もう少しちゃんと理解したいなーと思った。 というわけで、概要を訳しつつあれこれ調べてみたというメモです。 これは単に自分の視野が狭かったことに気付いたんですが、そもそも"Web3"という単語やそれを表すトレンドみたいなものは、2018年くらいのブロックチェーンな頃から既にあったんですね。 そういうわけなので、知ってる人にとっては何をいまさら？って話かもしれんし、それをこのタイミングでCloudflareが言及したことに、特別な意味を感じるのかも？とか。 Web 3.0とは Web3 — A vision for a decentralized web まずこの最初の記事をざっくり。 Web3とは、Web 3.0

調べたのでメモ。 TypedArray TypedArray - JavaScript | MDN いわゆる型付き配列。 通常の配列と違って型が固定できる分、内部的に最適化がしやすいとか諸々で住み分けられてる。 そういう意味で一般的なフロントエンドのJavaScriptコードで出てくることはそうそうない。 たとえばWebAudioとか、CanvasとかWebGLとか、いわゆるバイナリに近い処理をブラウザでやる場合に必要になるAPIたち。 Node.jsだと、`Buffer`っていうそれ用のクラスがあったりする。 種類 Int8Array Uint8Array Uint8ClampedArray Int16Array Uint16Array Int32Array Uint32Array Float32Array Float64Array BigInt64Array BigUint64Arra

Your shopping website is not an SPA. I repeat: your shopping website is not an SPA. Stop trying to sculpt David with a JS chainsaw and get yourself an HTML/CSS chisel.— Alex Russell (@slightlylate) 2021年8月10日 この主張、界隈（少なくとも自分の観測範囲）では割とよく見かけるし、なんか定期的に話題になるトピックなのかなーと。 まあ持論としてもコレには概ね同意しており、会社のスタンスとも相まって、常日頃からぼんやり考えてたりすることでもある。 で、そんな折にこのツイートを発見して、さらにそれに言及してる人々を見て、ふと自分でも現状を整理しておきたいなーという気持ちになったので筆を執った次第。

https://github.com/mrbbot/miniflare Cloudflare Workers（以下、CFW）相当の実行環境をローカルで再現できるアレです。 そんなんは公式が出してほしいな〜と思い続けてはや1年弱、いつまで経っても出てこない！ というわけで、コード読んでみたシリーズです。 そもそも、なぜローカルで動かしたいのか これはひとえに、現状のCFWはローカルで開発できないから。 いちおう本家のCLIに`wrangler dev`という開発用のコマンドはあるけど、インターネットにプライベートなやつがデプロイされてそれを`localhost`にトンネルするだけで、実質ローカルではない。 そのうえ、 （インターネットに上げるからか）動作も速くない そしてとにかくクラッシュする 変更も反映されたりされなかったり謎 そのくせしっかり課金対象（無料枠の圧迫） という感じで、あまり

というアプローチを紹介してる記事があって、なるほど？と思ったのでまとめてみる。 元記事はこちら。 Leveraging Web Workers to Safely Store Access Tokens – The New Stack 毎度のことながら、今にはじまったことではない。 元記事いわく WebWorkerであれば、メインスレッドで実行されるであろうXSSや3rdのコードから触れないので安全！ 設計としては、 メイン: まず`Worker`をロード メイン: 初期化のメッセージを`postMessage()` クレデンシャルがあるならそれを渡す ワーカー: アクセストークンの準備 受け取ったやつ or そこで`fetch()`して、オンメモリに保存 （これで準備OK） メイン: APIにリクエストしてほしいと`postMessage()` ワーカー: APIに向けてアクセストークン

Cloudflare Workers docs 巷で話題のエッジワーカーというやつ。 お仕事で使えるかもしれないというわけで、Docsを一通り読んでみて、ちょっとしたコードをデプロイしてみたところまでの感想。 Docsを読んでの学び コールドスタートがない AWSやらGCPのそれと違って、ランタイムごとにコンテナを〜という構造ではないから。 V8のIsolateなる機能を使って、基本的に立ちっぱのホストの上で、ランタイムだけを起動できるとのこと。 How Workers works · Cloudflare Workers docs なので、たまーに動かすコードでも実行が速いというわけ。 リージョン: 地球 普通にそう書いてあってカッコいい・・ってなった。 実行時間の制限がない 時間に関する制限は、CPU時間だけ。 Limits · Cloudflare Workers docs Netl

達人プログラマーを読んだせいか、最近よく考えてることでもあるので、この際なのでポエムにしてみた。 受託の会社バイアスはあるかもしれないけど、基本的にコードを書くエンジニアには通ずるところがあるはず。 設計に時間をかける これは、「いきなりエディタに向かってコードを書き始めない」ということ。 フォーマットはなんでもいいけど、 まずどういうものを実装しようとしていて 愚直にやるならこうする それによって既存のコードに影響がないか 過去のコードと一貫しているか 他の要件とぶつからないか etc.. などなど一通り思案して、必要ならメモを書いて、頭の中でコードをイメージする作業を先にやる。 そしてイメージできたものを、ガッとエディタに打ち込んで動くコードにしていく。 もちろん書いてみてはじめて気づく落とし穴もあったりするけど、その時はまたエディタから離れる。 コードを見てコードを治そうとすると、あ

久しぶりに物理本を読んだけど、やっぱ物理はええな・・かさばるとこ以外。 せっかくなので読書感想文と、特に印象に残った部分を、章ごとに書いておく。 第1章: 達人の哲学 この本を読んでいくにあたって、そもそも達人とはなんぞやという話がメイン。 プログラマーというより、いわゆる社会人としてこうあれみたいなテーマで書かれてて、なんかみんな読んだらいいのではと思いました。 物事をうまく進捗させるために、 まず何を言いたくて その結果どうしたいのかまで考えて 相手の状況やタイミングを見計らって コミュニケーションを実行する・されると、あれこれスムーズにいきますよっていう。 このテクは中々に便利で、日常生活でもそれこそ夫婦間とかのコミュニケーションでも使える話かなーと思ってて。 ただ自分の場合はこれをやりすぎて、質問してるはずが誘導尋問みたいになっちゃうときがたまにある・・。 第2章: 達人のアプロー

アクセスするとメガ単位でたくさんの画像を読み込むサービスがありまして・・。 リファクタによって、動的に必要な画像だけを読み込むように改修はしたけど、それでも回遊するとサイズがすごいことになる。 これをなんとかするならServiceWorkerしかない！というわけで。 Workbox 最初は0から手書きしようかと思ったけど、ちょっとやり始めただけであれこれ面倒なことがわかったので、先人に頼ることにした。 Workbox  |  Google Developers ご丁寧に、こういうことがやりたいんじゃろ？っていうのがガイドの中にあって、そうそうこれこれ〜って感じだった。 事前キャッシュではなく、あくまでランタイムでのキャッシュがしたかったので、これ。 import { CacheableResponsePlugin } from "workbox-cacheable-response"; i

について、Vue Composition APIのDocsに記載があったので、自分用にメモ。 Composition API RFC | Vue Composition API このRFCが出たのは2019年の7月なので、ぜんっぜん目新しい情報はないです。 React Hooksとの比較 Composition APIで関数ベースでロジックを記述できるようになる ロジックを合成できるという書き味は、React Hooksと同等であろう ただし、大きな違いもいくつかある まず`setup()`は、本当に1度しか呼ばれない これはつまり より直感的にJavaScriptを記述できる 呼び出し順序も、条件分岐も気にしなくてよい 呼ばれる回数が減るのでGCにも優しい `useCallback()`を使ったインラインハンドラーの最適化などが不要 `useEffect()`や`useMemo()`に正

https://sveltesummit.com/ https://www.youtube.com/watch?v=vHHLLJA0b70 JST夜中スタートだとリアルタイムで見れない...😴 というわけで、気になるトークだけまとめました。 The Zen of Svelte (Morgan Williams) https://www.youtube.com/watch?v=vHHLLJA0b70&t=683s Svelteはフレームワークである そして学びやすいのが特徴 Pythonのように、Zenの心得がある https://github.com/feltcoop/why-svelte#easy-to-learn 作者のRich氏もこう言ってる Frameworks are not tools for organizing your code, They are tools for

https://www.netlify.com/pdf/oreilly-modern-web-development-on-the-jamstack.pdf Netlify社が2019年に公開した本？PDFです。 せっかくJamstackの会社に入ったので、読んでおかないといけない気がして。 あとJamstackは人によって解釈が違ったりするとし、Jamstackの真髄について知っておきたいですよね？と思い。 ただこれなんと127ページもあるんですよね〜。 全編もちろん英語なので、読むのも中々に大変ですよね〜。 てなわけで、ざっくり訳してまとめまておきました。（それでも長いけど） はじめに ここ最近のWebの進化はすさまじい ブラウザもJavaScriptもパワフルになった その分ユーザーの要求も増える やることが増えると処理は遅くなる 遅いページは見向きもされないモバイル当たり前の世界だ

（SSR不要論者のはしくれとして）今までこれっぽっちも気にしてなかった、あのNext.jsです。 ここでいうSSRは、クライアントのリクエストに応じてSSRしてレスポンスを返すこと。 ただ最近仕事で使ったり、副業でも使ってたりする機会があって、一部認識を改めたところがあるのでそれをメモっておく。 静的サイトジェネレータとしてのNext.js それは、「元来のサーバーレンダリング用ミドルウェアとしてではなく、SSGを目的としたプリレンダリング用ツール」として見れば、実は結構よいのでは？というもの。 コマンドでいうところの`next build && next export`だけを使う前提。 プリレンダリングで最適化した静的なサイトにしたい けど、それぞれのページにはJSを使った処理がある 前者だけの場合は、だいたい`11ty`みたいないわゆる静的サイトジェネレータが検討されるけど、各ページで

気になるもののコードは読むべし、ということで。 ちなみにコードを読み始めた時点でのバージョンは、`v3.23.2`です。 自分のコードリーディング用のメモ記事なので、他の人が読んでわかりやすいかは保証できません！ 読みすすめ方 GitHub - sveltejs/svelte: Cybernetically enhanced web apps Svelteには、`runtime`と`compiler`のコードがある。 いずれはどっちにも目を通すつもりでいるけど、まずは`compiler`から読んでいく。 ただ`compiler`のコードをそのまま使うことはほぼないと思うので、実際にモジュールとしてどういう使われ方をするのかが知りたい場合は、Rollupなどバンドラーのプラグインのコードも見ることになりそう。 この記事ではコードの中身を1行ずつ（もちろん端折るけど）読んでいく。 svelte