フロントエンドパフォーマンスのチェックリスト2021年版（PDF、Apple Pages、MS Word）-中編 | POSTD
目次＃ 前編 準備段階：計画と指標 パフォーマンスを重視する文化、Core Web Vitals、パフォーマンスのプロファイル、CrUX、Lighthouse、FID、TTI、CLS、端末。 現実的な目標の設定 パフォーマンスバジェット、パフォーマンス目標、RAILフレームワーク、170KB/30KBバジェット。 環境の定義 フレームワークの選択、パフォーマンスコストの基準設定、Webpack、依存関係、CDN、フロントエンドアーキテクチャ、CSR、SSR、CSR + SSR、静的レンダリング、プリレンダリング、PRPLパターン。 中編 アセットの最適化 Brotli、AVIF、WebP、レスポンシブ画像、AV1、アダプティブメディア読み込み、動画圧縮、Webフォント、Googleフォント。 ビルドの最適化 JavaScriptモジュール、モジュール/ノーモジュールのパターン、ツリーシェイ
Makefileを自己文書化する | POSTD
私たちのプロジェクトではいつも、非常に長い Makefile を使用して、インストールやビルド、テスト、デプロイメントの処理を自動化しています。ターゲット名はほとんど標準化されていますが（ make install 、 make deploy ）、中には説明が必要なものもあります（ make run-dev 、 make restart-api ）。そして、詳細なmakeターゲットを追加するほど、それらの処理内容をテキスト形式で大量に記載しなければなりません。私たちのプロジェクトでは通常、このような文書を README ファイルに書いています。 しかしCLI（コマンドラインインタフェース）を用いる場合は、主に自己文書化ツールを使っています。 make と打つだけで、利用可能なコマンドとその説明が一覧表示されたら便利だと思いませんか？ それを実現するのは、実はとても簡単です。まずは各ターゲッ
Amazon AWSでユーザ数1100万以上にスケーリングするためのビギナーズ・ガイド | POSTD
あるシステムを、1人のユーザから1100万人以上にスケーリングするにはどのようにすれば良いのでしょうか。Amazonのウェブサービスソリューションアーキテクトである Joel Williams が AWS re: Invent 2015 Scaling Up to Your First 10 Million Users でスケーリング方法について素晴らしいプレゼンをしています。 AWS上級者のユーザには適さないプレゼンですが、AWS初心者やクラウド初心者、Amazonが次々と送り出す新機能の流れについていけていない人が始めるには素晴らしい内容だと思います。 おおよその見当は付いていると思いますが、このプレゼンはAmazonによって提供されているため、どの問題についても解決策として提案されているものは全てAmazonのサービスになります。amazonのプラットフォームの役割は、印象深く、分か
ブロックチェ－ンを構築しながら学ぶ | POSTD
ブロックチェ－ンの仕組みを知るには構築するのが最短の方法 この記事を読んでいるということは、仮想通貨の拡大に興奮しているということですね。ブロックチェ－ンの仕組み、背後にある基本的なテクノロジーについて知りたいのでしょう。 しかしブロックチェ－ンを理解するのは簡単ではありません。少なくとも私にはそうでした。大量の動画の中をさまよい、抜けだらけのチュートリアルに従い、結局、実例が少なすぎてフラストレーションが大きくなりました。 私は手を動かして学ぶのが好きです。コードのレベルで内容を扱わざるを得なくなり、そうすることで身に付くからです。同じようにやってもらえば、この解説が終わる頃には、機能するブロックチェーンが出来上がり、どのように動くかがしっかりと把握できるようになるでしょう。 準備 ブロックチェ－ンとはブロックという名の 不変でシーケンシャルな 一連のレコードだということを覚えてください
モノリシックなバージョン管理の利点 | POSTD
以下は、私がよく交わす会話の一例です。 人物A：FacebookやGoogleは、巨大なモノリシックリポジトリ（モノレポ）を使っているんだってよ。 私：みたいだね。あれは本当に便利だと思う。 人物A：僕に言わせれば最悪の愚行さ。全てのコードを単一のリポジトリに入れるのがヒドイ考えだと、FacebookやGoogleはなぜ思わないんだろうか。 私：FacebookやGoogleのエンジニアたちも小さなリポジトリには精通しているだろうけど（ 濱野純（Junio Hamano） 氏はGoogle勤務だし）、単一の大きなリポジトリの方が、きっと”ある理由”で好みなんだよ。 人物A：なるほどね。僕としては、まだちょっと違和感はあるけど、モノレポが使われる理由は分かったような気がするよ。 “ある理由”はかなり長いので、同じ会話を何度も繰り返さなくていいように、ここに書き留めておこうと思います。 シンプ
V8エンジンでのJavaScriptの機能と最適化コードの書き方に関する5つのベストプラクティス | POSTD
数週間前に、JavaScriptが実際どのように動いているかを掘り下げて紹介する記事の連載を始めました。JavaScriptがどのような機能で構成されていてそれらがどのように組み合わさって機能していくのかを知ることによって、さらに良いコードやアプリケーションを作ることができるのではないかと思ったからです。 連載の1回目では 、エンジンやランタイム、コールスタックについての概要を紹介しました。2回目となる今回は、Google V8 JavaScriptエンジンについて細かく説明していきます。また、より良いJavaScriptコードの書き方、すなわち私たちの開発チーム SessionStack がプロダクトを開発する際に意識しているベストプラクティスについても併せて紹介します。 概要 JavaScriptエンジン とはJavaScriptコードを実行するプログラムまたはインタプリタのことです。
Angular 2/4が狭量で遅すぎる理由 | POSTD
(注：2017/08/30、いただいたフィードバックを元に翻訳を修正いたしました。) TL;DR — AngularJSのアイデアは、2012年には妥当と言えましたが、2017年においてはそうとは言えなくなっています。JSのエコシステムは、成熟度、柔軟性、および生産性の面で、あっという間にAngularの前を通り過ぎてしまいました。現在では、webpackやフロントエンドのNPM、成熟したツールとライブラリのエコシステムを背景として、 大型チームを有する企業であっても、 ReactやVueなどの軽量なJSライブラリを使用することで、大規模で柔軟性のあるSPAを、適切な設計で維持することが容易になっています。 加えて、Angular 2/4の問題が散見された3年の開発期間や議論の余地があるアーキテクチャの決定方針が、多くの企業にこの新しいフレームワークの採用を躊躇させているようです。 201
Kotlinの隠れたコストについてのベンチマーク | POSTD
@BladeCoder が書いた Kotlinの隠れたコストの調査 という一連のブログ記事は、ある Kotlin 構文にどのように隠れたコストがあるのかを説明しました。 実際の隠れたコストは、普通、不可視オブジェクトのインスタンス化やプリミティブ値のボクシング／アンボクシングに起因します。これらのコストは、Kotlinコンパイラがどのように上記の構文をJVMのバイトコードに変換するのかを理解していない開発者には特に見えづらいのです。 しかし、何らかの数字を示さずに隠れたコストの話をするだけでは、実際にどのくらいコストのことを心配すべきなのかという疑問が湧いてきます。コードベースのいたるところで、これらのコストを考慮すべきでしょうか？あるKotlin構文は単に全面的に禁止されるべきでしょうか？あるいは、最も範囲の狭い内部ループの中でだけ考慮されるべきでしょうか？ さらに挑発的な言い方をすれば
ファイルシステムよりも35％高速に | POSTD
1. 概要 SQLiteを使うと小さなBLOB（例：サムネイル画像など）を読み書きする場合、fread()やfwrite()を使って個別のファイル上に記録されたBLOBを読み書きするよりも35％も速く (*1) 読み書きができます。 さらに、10キロバイトのBLOBを扱うようなSQLiteデータベースを考えた場合、個別のファイルにそれぞれのBLOBを格納する場合に比べてディスク領域を約20％も節約可能です。 このようなパフォーマンスの差が生じる理由は、（私たちの考えでは）SQLiteデータベースの場合、open()やclose()システムコールが呼び出されるのが1回だけなのに対して、個別のファイルに格納されているBLOBを使用する場合は、open()やclose()がBLOBの数だけ呼び出されるためだと思われます。どうやらopen()とclose()を呼び出すオーバーヘッドは、データベース
JavaScript モジュールの現状 | POSTD
(注：2017/07/19、いただいたフィードバックを元に翻訳を修正いたしました。) ESM、CJS、UMD、AMD — どれを使うべき？ 最近、 Twitter では、 ESモジュール の現状、特に、 *.mjs をファイル拡張子として導入すると決めた Node.js の現状について大騒ぎになっています。この話題は複雑で、かなりの労力を費やしてそれに専念しないと議論について行けないので、 皆が恐れと不安を抱く のも無理はありません。 古き恐れ フロントエンド開発者なら、 JavaScriptの依存関係の管理に悩まされた日々 を憶えている人も多いでしょう。あの頃は、ライブラリをベンダーフォルダにコピー&ペーストし、グローバル変数に依存し、あらゆる物を正しい順序でconcatしようとしてもネームスペースの問題に対処する必要がありました。 何年もかかって、私たちは共通モジュール形式と中央集権
IRCは死んだ。IRCよ栄えよ。 | POSTD
IRC Internet Relay Chat が世に出たのは1988年だが、インターネットの言葉では、すでに古代だ。今なお世界で何十万ものユーザが使っているとはいえ、IRCの利用は劇的に減少してきている。 一時はこれほど広く使われた技術に多くのユーザが興味を失ったように思われるのはなぜか、IRCの開発者を含めた何人かと話をした。 IRCの起源 私たちはIRCの開発者、 Jarkko Oikarinen と連絡を取った。スウェーデンのGoogleに勤務する彼は、IRC誕生のストーリーを聞かせてくれた。 （初期のIRCサーバ。写真提供：Wikipedia.） Oikarinenによれば、彼は、1988年にフィンランドの University of Oulu で夏期インターンをしていた3か月か4か月の間にIRCを作った。 当時OikarinenはOuluBoxというローカルBBS（ 電子掲示板
マイクロサービスはもう十分 | プロダクト・サービス | POSTD
モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。要旨 モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。 – Martin Fowler 明確に構造化されたモノリスを構築できない時、なぜマイクロサービスがその答えだと思うのか。 Simon Brown 始めに マイクロサービスの利点と欠
GraphQLはWeb APIの次のフロンティアか？ | POSTD
RESTの規約。URLはリソースであり、CRUDはHTTP動詞にマップされる。 RESTの規約に1つ問題があるとすれば、規約が十分でないということでしょう。上記で”通常”、”多くの場合”、”時に”という表現を使ったのは、これらのやり方は仕様で推奨されているものの守られるとは限らないためです。実世界では、大抵のAPIはRESTishがせいぜいです。例えばStripeでは、リソース更新に PUT ではなく PATCH を使うべきですが、歴史的理由でそうはなっておらず、おそらく現時点では変更に値しないでしょう。いずれにしても開発者はドキュメントを読む必要があり、その時、 POST メソッドのユビキタスな使い方があることに気づくのです。 RESTには他の問題もあります。必要なものだけでなく全てが返ってくるため、リソースのペイロードが非常に大きくなることがあるのです。そして多くの場合、クライアントが
コーディングに対する考え方を変える6つのプログラミングパラダイム | POSTD
私は時折、コーディングに対する考え方を変えさせられるような、従来と非常に異なるプログラミング言語に出会います。本記事では、その中でも特に気に入っている発見をいくつかご紹介したいと思います。 これは、先賢による「関数型プログラミングは世界を変える！」的な投稿ではありません。本記事で挙げるのは、もっと「知る人ぞ知る」的なリストです。多くの読者の方にとって、以下の言語やパラダイムは聞いたことのないものが大半だと思いますので、私が経験したように、これらの新しい概念を学ぶ楽しさを感じていただければ幸いです。 注：私は以下の言語の多くに関して最低限の経験しかありません。その発想に引き込まれたのであって、専門的知識は持ち合わせていないため、訂正すべき点や誤りがあればどうぞご指摘ください。また、本記事で取り上げていない新しいパラダイムや概念に出会った方は、ぜひお知らせください。 最新情報：本記事が r/p
Webサイト開発にCSS in JavaScriptを使うのはやめよう | POSTD
9つのおとぎ話 CSSは迷走しています。JavaScriptでドキュメントをスタイリングしているプロジェクトでは、多くの場合誤った理由からその方式を選択しています。本稿では、よくある誤解（神話）を列挙し、そうした問題に対するCSSソリューションを紹介します。 本稿は、特定のプロジェクトや人物への攻撃を意図するものではありません。ここでは、“CSS in JavaScript”(CSS in JS)を styled-components を使用することと定義します。これは、Reactのコンポーネントをスタイリングする最近のトレンドとなっています。 styled-components の作者である Max Stoiber と Glen Maddern 、また彼らに協力した人々は皆、卓越したアイデアと善意にあふれる優秀な人々です。 完全な透明性のために断っておくと、私は react-css-mo
ReactのHigher Order Components詳解 : 実装の2つのパターンと、親Componentとの比較 | POSTD
ReactのHigher Order Components詳解 : 実装の2つのパターンと、親Componentとの比較 (編注：2016/7/27、いただいたフィードバックをもとに記事を修正いたしました。) 概要 この投稿は、HOCパターンを利用してみたいという 上級ユーザ 向けの記事です。もしReactが初めての方は、まず Reactのドキュメント を読むところから始めるとよいでしょう。 Higher Order Componentsは、さまざまなReactライブラリにとって価値があることがわかっている素晴らしいパターンです。この投稿で、HOCとは何か、できることは何か、制約は何か、どのように実装するのか……という点について詳細に見ていきます。 付録として、関連トピックについても見ていきます。それらは、HOCを学ぶ上での中核にはならないものの、カバーしておくべきだと私が思っているもので
200行のコードへのブロックチェーンの実装 | プログラミング | POSTD
ブロックチェーン の基本的な概念は非常にシンプルです。分散型データベースで、順序付けられたレコードのリストが連続的に増加していきます。しかしシンプルとは言え、ブロックチェーンやそれを使うことで解決しようとしている問題について話をする際に、頭を悩まされることがよくあります。これは、 ビットコイン や イーサリアム といった、一般にもよく知られているブロックチェーンベースのプロジェクトでよく聞かれる話です。「ブロックチェーン」は、 取引 や スマートコントラクト 、または 暗号通貨 といったコンセプトと強い結びつきがあります。 そのため、本来シンプルであるべきブロックチェーンの理解がより困難になってしまっています。抜け目のないソースコードであれば尚更です。 そこで、 NaiveChain という、200行のJavascripitに実装した、非常にシンプルなブロックチェーンを紹介したいと思います
Dockerの本番運用 | POSTD
以前に私が書いた「 Dockerの本番運用：失敗の歴史) 」という記事は、非常に多くの反響を呼びました。 その後、長い議論を交わして、何百件ものフィードバックや何千件ものコメントを読み、さまざまな人々や主要事業者とも顔を合わせました。Dockerでの試みが増えるほど、その失敗談は増えていきます。そうした現状を、今回アップデートしておきたいと思います。 この記事では、最近の交流や記事から得た教訓を紹介しますが、その前に簡単におさらいをして軽く背景を説明しましょう。 免責事項：対象読者 たくさんのコメントから、世の中には10種類の人々が存在するということが明らかになりました。 1) アマチュア 実際のユーザがいない試用版のプロジェクトやサイドプロジェクトを実行している人々です。Ubuntuのベータ版を使用するのが当然だと考えており、「安定したもの」は古いものと見なすようなタイプです。 注釈：書
Gitのスケーリング（と、その背景） | POSTD
数年前、Microsoftは、社内全体のエンジニアリングシステムを活性化させるため、数年間にわたる投資を行う決定をしました。私たちは山のような数のチームを抱える大企業です。チームはそれぞれ、担当のプロダクト、独自の優先順位、プロセス、ツールを持っています。”共通の”ツールもありますが、チームによって様々に異なる点も多く、内部で開発した単発のツールも数え切れないほどあります（「チーム」とは社の部門のようなもので、数千のエンジニアの集まりです）。 この状況にはたくさんのマイナス面があります。 似たようなツールを構築しているチームがいくつもあり、巨額の冗長な投資が生まれている 「クリティカルマス（損益分岐点を超える生産量、普及率）」に向けた設備投資ができない 皆がバラバラのツールやプロセスを用いているため、従業員が異動しにくい 組織の垣根を越えてのコード共有が難しい “MS限定”ツールの過多のた
Node.jsのパフォーマンス最適化を阻むものの見つけ方 | POSTD
皆さんは “Node.jsではコードが動的に最適化される” という記事を幾つか読んだことがあるかもしれません。本稿では、この文言が意味するところとコードが最適化される箇所の見つけ方について見ていきます。 Node.jsのパフォーマンス最適化を阻むものについて述べた本稿をご覧いただいたあとには、以下のことができるようになります。 関数の最適化がJavaScriptエンジン(V8)で行なわれているかの解明 最適化された関数が最適化戻し（De-optimization）されていないかの解明 関数が最適化できない理由の解明 このアジェンダは大げさですが、記事は至ってシンプルです。目指しているのは、上記の方法論を多くのNode.js開発者に役立てることです。 V8におけるNode.jsのパフォーマンス最適化についての簡単な概要 Node.jsを どの仮想マシン上でも使用可能にするという計画 はあるも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
