Windows11（22H2）の格安PC買ってやったこと
何か月か前に話題になっていたIntel N100の中華ミニPCにひかれて、5年以上ぶりに自宅の端末を入れ替えた。Intel N100+メモリ16GB+SSD256GB程+Win11pro付きでお値段2万円強という、信じがたいコスパ。 必ずしも優れているとは言えないスペックでWin11を快適に使うために、買ってから最小限やった設定を書いておく。 ・前提端末OSには粛々とHWの管理だけをしてもらい、「こんな素敵な＆便利なWeb機能もあるよ！」的な導線はいらない。TeamsもOutlookも職場で嫌ってほど使っているが、自宅では金輪際使う予定なし。タスクバーのウィジェットもBingへの導線も全部要らない！という人向け。 ※本当はhttps://anond.hatelabo.jp/20191116220232さんのWindows11版の記事が出てればそれで事足りたのだけど、見つけられなかったので投
Node.jsコンテナイメージを極限まで軽量化! サイズを1/10以下に｜SHIFT Group 技術ブログ
はじめにSHIFT DAAE の shinagawa です。表題の通りNode.jsで作成したコンテナのイメージサイズの軽量化に挑戦しました。 背景近年の多様化・高速化するビジネスに対応するITシステムの構築を実現する「クラウドネイティブ」の構成要素の一つとして 「コンテナ」という仮想化技術が存在し、当部門でも活用を進めております。 このコンテナイメージを作成するにはアプリケーションコードやライブラリ・モジュールなどの依存物、ランタイム等を1つのイメージとして組み立てて作成しますが、 この構成要素が増えるとイメージサイズが肥大化し保管時のストレージのコストの増加やイメージの転送、環境への展開に時間がかかることになります。 従ってイメージのサイズを削減することは、これらの点を改善することにつながります。 ここではネット上で紹介されている、あらゆる打ち手を組み合わせてコンテナイメージの軽量化に
git statusが43秒かかっていたのを1秒に高速化する大規模Gitリポジトリの操作を高速化するためのscalarを紹介 | Act as Professional
Git 2.38がリリースされました。 このバージョンから大規模Gitリポジトリの操作を高速化するscalarが同梱されるようになりました。 今回はこのscalarによって、どれぐらいGitの操作が高速化されるのかを簡単に検証します。 結論から言うとgit statusが約43秒かかっていたのが約1秒で操作できるようになります。 Install Git 2.38Git 2.38からscalarが同梱されましたので、各自の環境にあわせてInstallなりVersionUpなりをしてください。 $ git --version git version 2.38.0 Before大規模Gitリポジトリとしてchromiumを利用しました。 普通にgit cloneしてきて、git statusを実施すると約37秒かかります。 ❯ time git status On branch main You
Next.jsのスタンドアロンモードでビルドしたイメージを Cloud Run へデプロイする
module.exports = { - experimental: { - outputStandalone: true, - }, + output: 'standalone', } Next.js の experimental features のひとつに、スタンドアロンモードがあります。 通常モードでは、本番リリース可能なビルドを用意する場合、yarn build による .next/ ディレクトリとあわせて node_modules も含めます。依存関係を解決するために必要ですね。一方スタンドアロンモードを有効にした上で yarn build するとビルド結果が異なります。.next/ディレクトリが作られる点は同じですが、そこにstandaloneディレクトリが追加されます。ここにはアプリを動かすためのファイルが依存関係も含めてすべて入っていて、.next/standalone/
保守性の高いReact hooksコードの指針
前提 本記事は保守性の高いReact hooksコードの指針を記述します。指針はtipsに近いものから原則に近いものまで雑多に含まれます。総じてReact hooksの標準的なAPIを上手く扱う方法が多めです。 これらは保守性の低いコードを反面教師とした私的な経験則に基づきます。（思い出し次第随時追加していきます） ご留意ください。 解消したい痛み 再現が困難な不具合の発生 容易に無限ループが発生しうる 不具合発生箇所の特定が手間 分岐が多くコードリーディングに手間がかかる 解消する手法 useEffectは１ページに１つ useEffectにdeps自動補完除外コメントを入れる stateはプリミティブにする propsにフラグがある場合はコンポーネントを分ける useEffectは１ページに１つ 悪例: ユーザーイベントの処理 const [foo, setFoo] = useStat
結局useMemoはいつ使えばいいの？ 僕の決定版 - Qiita
皆さんこんにちは。筆者の以前の記事では、ReactのuseMemoを無駄に使うことによるレンダリング速度のオーバーヘッドがどれくらいかをベンチマークによって示しました。 それによれば、スマートフォンを想定したとしても、useMemoだけで描画に目に見える影響を与える（16msくらいの遅延を発生させる）には万のオーダーのuseMemoが必要なことが分かります。 速度ではなくuseMemoを使うことによるメモリ消費量の増加を気にする声も聞かれましたが、すみませんが筆者はそこまでメモリクリティカルなアプリをReactで書いたことがなく知見に乏しいため、今回はこの記事の対象外となります。 この結果が出たことでuseMemoをいつ使うのかなどという議論には終止符が打たれたかと思いきや、上記の記事の感想などを見ているとまだ喧々囂々です。 そこで、この記事では筆者の考えを皆さんに共有し、いよいよもってこ
React Suspenseで不要な描画処理をなくす
function ProfileDetails() { const user = resource.user.read(); // throw promise here return <h1>{user.name}</h1>; } この仕様自体、それだけで記事になるほど面白いです。（ここでは割愛します。） React Freeze React Freezeは、そんなSuspenseを利用したライブラリです。 元々React側は、データ取得の際に使うことが主なユースケースと言っていたのに対して、このライブラリの目的は、ある瞬間にユーザーに表示されていないアプリの部分について、不要な再レンダリングを避けることとなっています。 どうやって実現しているのでしょうか？ 実は、ライブラリの実装もシンプルで興味深いです。 // ref: https://github.com/software-mansi
React 18に備えるにはどうすればいいの？ 5分で理解する - Qiita
React 18はReactの次期メジャーバージョンで、2021年の6月にalpha版が、11月にbeta版が出ました。また、Next.js 12でもReact 18のサポートが実験的機能として追加されました。React 18の足音がだんだんと我々に近づき、アーリーアダプターではない皆さんの視界にもいよいよReact 18が入ってきたところです。 特に、React 18ではServer-Side Rendering (SSR) のストリーミングサポートが追加されます。現在ReactでSSRを行いたい人の強い味方としてNext.jsが存在しているわけですが、Next.js 12でもReact 18を通してストリーミングの恩恵を受けることができます（Next.jsではSSR Streamingと呼んでいるようです）。また、厳密にはReact 18とは別ですが、React Server Comp
JestでTypeScriptを高速化する | miyauci.me
JestでTypeScriptを高速化するJestでテストの高速化させる方法を紹介します。トランスフォーマーとしてesbuildやswcを紹介し、TypeScriptで遅くなりがちなトランスパイルを高速化させることで、テストを自体を高速化します。 はじめにesbuild の登場により、フロントエンドの世界は、開発環境により速度を求めるようになりました。vite の隆盛はその最たるものといってもいいでしょう。 esbuild や swc は高速な Go や Rust によって書かれ、更に多くの場合、Typescript の型チェックを省略しています。 tsc の型チェックは、大抵 IDE やワークフローで行われているので、これらを削ぎ落とすことで、純粋なコンパイラとして JavaScript への変換に特化しているということですね。 さて、Typescript コードをテストする際、多くの場
Emacs の起動時間を”“詰める””
Author: zk-phi Published: 2020-09-07 Last Modified: 2020-09-07 GitHub Source: md Emacs はプラグインを増やしていくと起動に何秒もかかって重い、という話をみることがあります。 しかし、考えてみれば Emacs には 1000 以上の Emacs Lisp ファイルが初めから同梱されているわけで、そこに数十のプラグインを足しただけで爆裂に遅くなるのは、なにか設定にも問題がある気がします。 この記事では、 Emacs の起動時間を詰めるために今までに試してきた、小技や大技たちを紹介します。 自分用にメンテしているフレームワーク setup.el で活用しているテクニックが主なので、そちらを試してみて欲しい気持ちもありますが、それぞれの Tips 単体でも価値があると思うので記事にもまとめてみることにしました。
JavaScript が読み込まれる前でもWeb Applicationを動かす - from scratch
今回は最近取り組んでいる、 JavaScript が読み込まれる前であっても「ちゃんと」 Web Application が動作するように作る話をします。 Server Side Rendering における注意点と対策 BFFを使ってServer Side Rendering をすることに数年前から取り組んでいます。 まずはSSRをやる上での注意点と対策について紹介します。 SSRをすることはSEOのためだと思われがちですが、個人的にはSEOのためにしているわけではなく、 First View を向上するため（特に First Meaningful Paint を向上するため）にやっています。 First View SEOとSSRに関しては Google が最近出したこの記事の SEO Considerations 節が詳しいです。ここでは説明しません。 SSRをしない、Client S
nextjsのISRを使うときのfallback指定について理解するまでの話
next.jsのISRを使おうとして「なんか全然うまく行かない」ってなってたのがやっと理解出来たのでメモ 問題編 とりあえず見様見真似でISRはrevalidateとfallbackつければ良いんだな？とやってみたところ、どうもpropsが空Objectになってしまうようで悩んでいた。 例えば下記のような場合、エラーが起きる // pages/greeting/[name].js const Page = (props) => { // ↓ここでエラー return <div>Hello {props.name.toUpperCase()}</div> } export const getStaticProps = async (req) => { return { props: { name: req.params.name }, revalidate: 100 } } export c
ネイティブコンパイルEmacsの登場
日本時間の2021年4月26日午前3時6分、Emacsのmasterブランチにfeature/native-compブランチがマージされました（コミット：Merge branch ‘feature/native-comp’ into into trunk）。これにより、HEADのEmacsをビルドすると、Native compilation機能を兼ね備えたネイティブコンパイルEmacs、通称Gcc Emacsが使えるようになりました。 ネイティブコンパイルEmacsの機能 # ネイティブコンパイルEmacs（以下、Gcc Emacsと呼びます）は、Andrea Corallo、Luca Nassi、Nicola Mancaの3名によるBringing GNU Emacs to Native Code という論文で詳細が説明されています。 簡単に説明すると、これまでのEmacsは、Elisp
Webフォント読み込み戦略（2021年） - MOL
Preload web fonts 前回、といっても2年前だが、display=swapとはなにかで、Google Fontsを読み込むときはURLパラメータに display=swap をつけるといいよと言った。というわけで、それ以降、『目標をセンターに入れて、display=swap…』と盲目的に考えるようになってた。 おさらいとして display=swap では、まず代替フォントを表示し、Webフォントをダウンロードしたら、随時スワップするという挙動になる。この場合、代替フォントからWebフォントへ切り替わる FOUT (flash of unstyled text) が起こってしまう。こんな感じ↓ 出典：font-face descriptor playground まぁ何も表示されないよりかは良いかと思うわけだが、時は流れ、最近ではWebの指標として、Web Vitalsという
Debug performance in the field | Articles | web.dev
Debug performance in the field Stay organized with collections Save and categorize content based on your preferences. Learn how to attribute your performance data with debug information to help you identify and fix real-user issues with analytics Google provides two categories of tools to measure and debug performance: Lab tools: Tools such as Lighthouse, where your page is loaded in a simulated e
10分で理解するGrafana
Grafana とは Grafana は Grafana Labs が公開しているログ・データ可視化のためのツールです 可視化ツールとしては kibana とほぼ同じようなものです Grafana も kibana も、DB に保存されたログに対してリアルタイムにクエリを投げてデータを表示することができ、 表示する期間の長さや時間帯を変えたり、パーツ毎に特定のノードだけのデータを表示したりインタラクティブに可視化を操作することができます Grafana は複数のデータベースに対応しており現時点では以下に対応しています - Graphite - Prometheus - Elasticsearch - InfluxDB - OpenTSDB - MySQL - AWS Cloudwatch kibana は elasticsearch のみ対応しています UI の機能は kibana の方が
Next.jsのISRで動的コンテンツをキャッシュするときの戦略
最近Next.jsのISR（Incremental Static Regeneration）を耳にする機会が増えてきました。Zennでも2021/3/17時点で記事や本などの一部のページでISRを採用しています。 ISRとは何か ISRを使うことで、動的なコンテンツを含むページも静的ページとしてCDNにキャッシュすることが可能になります。Next.jsのISRはドキュメントに書かれているようにstale-while-revalidateという考え方でキャッシュが行われます。 具体的には、リクエスト時にページのキャッシュを作成し、次のアクセスではキャッシュされた古いデータを返します。その裏で次のアクセスに向けてキャッシュが再生成されるというイメージです。 これによりユーザー投稿コンテンツであってもCDNにキャッシュしやすくなるというわけです。 Next.jsでのISRの実装 デプロイ先がVe
Before You memo() — overreacted
There are many articles written about React performance optimizations. In general, if some state update is slow, you need to: Verify you’re running a production build. (Development builds are intentionally slower, in extreme cases even by an order of magnitude.) Verify that you didn’t put the state higher in the tree than necessary. (For example, putting input state in a centralized store might no
Web FontによるCore Web Vitalsへの影響と使い続ける方法｜平大志朗
だれかWebのチョットワカル人、 「(日本語など大容量の)Web FontのCore Web Vitalsへの影響 使い続ける方法とその是非」 を記事に書いてほしい。。。 preload頼りでいいんだろうか。どのくらい失敗するんだろうか…… — 辻正浩 | Masahiro Tsuji (@tsuj) January 20, 2021 私自身も、WebフォントがどれくらいCore Web Vitals影響するのか、影響を回避しながらWebフォントを使う方法がハッキリ分かっていなかったので、調査してみました。 本投稿はWEB上から入手できる情報源をもとに内容をまとめています。情報の正確性には留意していますが、私の独自の解釈・予想も含まれています。以上から、本情報はいち見解として捉えていただきますようお願い致します。WebフォントによるCore Web Vitalsへの影響とはCore Web
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
より速い WEB を目指す Next.js / nextjs-make-the-web-faster
