フロントエンドパフォーマンスのチェックリスト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モジュール、モジュール/ノーモジュールのパターン、ツリーシェイ
カオステストでHTTP/2の問題を見つけ出す | POSTD
(注：2017/04/20、いただいたフィードバックを元に翻訳を修正いたしました。修正内容については、 こちら を参照ください。) 要約 HTTP/2 にはHTTP/1.xに比べて多数の改良点がありますが、 カオステスト を行ったところ、HTTP/2のパフォーマンスがHTTP/1より劣る状況があることが分かりました。 ネットワーク上にパケット損失がある場合、TCP層での輻輳制御によって、少数のTCPコネクションの中に多重化されているHTTP/2ストリームがスロットリングされます。さらに、TCPリトライのロジックにより、リトライが行われている間、1つのTCPコネクションに影響しているパケット損失が、いくつかのHTTP/2ストリームに同時に強い影響を与えます。言い換えれば、ヘッドオブラインブロッキングが事実上、ネットワーク階層の レイヤ7 から レイヤ4 へ移動したということです。 背景とサー
DockerでのNodeアプリ構築で学んだこと | POSTD
以下に紹介するのは、 Docker を使って node.js 用のWebアプリケーションを開発、およびデプロイする際に、私が四苦八苦しながら学んだ秘訣やコツです。 このチュートリアル記事では、Dockerで socket.ioのチャットサンプル を白紙の状態から本番状態へとセットアップしていきます。このプロセスを通じて、そうした秘訣などを簡単に習得していただければ幸いです。特に、以下のような内容について見ていきます。 実際にDockerでNodeアプリケーションを起動する。 すべてをrootとして実行させない（悪いやり方です）。 開発時のテスト-編集-リロードサイクルを短くするため、バインドを使用する。 再構築を高速にするため、 node_modules をコンテナで管理する（これには秘訣があります）。 npm shrinkwrap で、ビルドを反復可能にする。 開発環境と本番環境で Do
2017年JavaScriptのテスト概論 | POSTD
本稿は、JavaScriptのテストについて最も重要な根拠、用語、ツール、アプローチなどの知識を身に着けることを目的とした簡略版ガイドブックです。本稿で検討する数々の側面に関する最新の秀逸な記事も紹介しつつ、私たちが経験的に得たことも多少付け加えたいと思います。 Facebookによるテスト用フレームワークであるJestのロゴをご覧ください。 見てお分かりのように、このフレームワークは「苦痛のない」JavaScriptのテストをスローガンに掲げています。しかし、 “次のように言う人” もいます。 苦痛のないテストなんてあり得ない。 実際、Facebookはこのスローガンを掲げるだけの素晴らしい理由があります。一般的にJSのデベロッパは Webサイトのテストにあまり満足していません 。JSのテストには制限があり、実装が難しく、低速である傾向があります。 一方、正しい戦略を立てて適切にツールを
Webデベロッパのためのセキュリティ・チェックリスト | POSTD
安全で堅牢なWebアプリケーションをクラウドで開発するのは 非常に困難 です。それを簡単だと思っているような人は、例えばとんでもない頭脳をお持ちというなら別ですが、遠からず痛い目を見ることになるでしょう。 もし MVP（Minimal Viable Product：必要最低限の機能を備えた製品） のコンセプトを鵜呑みにして、有益かつ安全な製品を1ヶ月で作成できると考えているようなら、プロトタイプを立ち上げる前に一度考え直した方がいいと思います。以下に挙げたチェックリストをご覧いただければ、セキュリティに関するクリティカルな問題の多くをスキップしていることが分かるはずです。あるいは少なくとも、潜在的なユーザに対しては 誠実 であるように心がけ、製品が完全ではないこと、そしてセキュリティが不十分な製品を提供していることを伝えるようにしてください。 このチェックリストはシンプルなもので、決して完
ReactでTDD（テスト駆動開発）を始めよう : 環境構築からテスト作成、機能実装までの詳解ガイド | POSTD
最小限の設定のTDD手法を使い、「何をテストすべきか？」から、よくある落とし穴の避け方まで、Reactコンポーネントをテストする方法を学びましょう。 導入 まず、 React を触ったことがあり、更にはいくつかのテストも書いた経験があるとしましょう。それでも、コンポーネントをどうテストするのが最善なのか、よく分からないかもしれません。どこから始めるのでしょう。具体的には何をテストすればよいのでしょうか。 いくつかのReactコンポーネントは簡潔過ぎて、そもそもテストが必要なのかすらはっきりしません。 AngularからReactに乗り換えた 人なら、テストには愛憎のような思いがあるかもしれません。 確かに Angular にはテストを支援するツールがたくさんありますが、同時にテストを書くのが難しくなる可能性があります。冗長ながら省略できない定型コードが多々ある上、 $digest の呼び出
そのJavaScriptの関数は本当に純粋関数？ | POSTD
(2016/12/11、いただいたフィードバックをもとに翻訳を修正いたしました。) JavaScriptにおいて”純粋関数”とはどういう意味でしょうか？ 一般的なプログラムの用語では、純粋性というのは”参照透過性”として知られています。カッコよく言うと、「 式や関数の呼び出しをその結果と置き換えたとしても、プログラムの振る舞いが決して変わらない 」こと、また別の言い方をするなら、「 同じ入力値を渡すたび、決まって同じ出力値が得られる 」ということです。 これなら直感的に理解できそうに聞こえますし、 x => x * 10 などの関数は純粋に見えます。これに数字の 3 を引数として渡したら必ず、出力値として 30 が得られますからね。では、ある関数が純粋で別の関数が純粋でないと、どうしたら分かるのでしょう？ コードを読むだけで十分でしょうか？ 一般的にどう思われているかを見てみましょう。昨日
あまり知られていないCSSの12の事実(続編) | POSTD
1年以上前に、私は最初の 12 Little-known CSS Facts（あまり知られていないCSSの12の事実） を発表しました。SitePointで最も人気の高い記事となりました。この記事を書いた後も、私はCSSのアドバイスやちょっとした情報の収集を続けました。だって、大ヒット映画も必ず続編を制作するじゃないですか。 注釈 SitePoint/ Natalia Balska によるイラスト それでは、早速今年も開発のヒントになる12の事実について話しましょう。もちろん、中にはもうすでにご存じのこともあると思いますが、この中で初めて知ったという事実がありましたら、コメントでお知らせください。 1. border-radius プロパティに”スラッシュ”シンタックスを使用できる事実 このプロパティについてはSitePointに4年以上 前に書いた のですが、この機能が存在することを、未
CSSコーディングテクニック : 詳細度、単位、flexbox、mixin | POSTD
(2016/7/15、記事を修正いたしました。) 最近、ビギナーからベテランのデベロッパに至るまで、CSSに手を焼く人を多く見かけます。そうした人たちの中には、CSSの機能を好まず、別の言語を使った方がいいのではないかと考えている人もいます。もともと、CSSのプロセッサもこうした考え方から生まれました。書くべきコードを少なくできることを期待して（ 以前の記事で ご紹介しているとおり、普通はそうではありません）CSSのフレームワークを使う人もいれば、CSSを完全に見限り、スタイルの指定にJavaScriptを使うという人もいます。 しかし、あなたが取り組んでいるパイプラインにCSSプロセッサをいつも取り入れる必要があるとは限りません。どんなプロジェクトであれ、開始の時点から、膨れ上がったフレームワークをデフォルトに取り込む必要はありません。また、CSSを使うところで、代わりにJavaScri
Reactを使ったモジュラーCSS : CSS-in-JSとCSS Module | POSTD
Buffer のメンバーはReactが大好きで、フロントエンドの多くのコードベースを徐々にReactに移行させています。ReactにFluxを加えると、モジュラー形式の小さなアプリでできた複雑なプロダクトを構築するための、とても健全な方法になると思います。そこで、１つ１つの新しい小さなアプリと機能を、大規模な構造体に追加される、Reactの新しいブロックと考えます。 私は最近、このような新機能の１つに取り組んでいますが、React＋Fluxのアプリケーションを作るのがいかに簡単であるかと、その理由について、さらに夢中になってしまいました。Reactを使うと有意味なコンポーネントを集めてUIを宣言的に構築するのが楽になり、Fluxはその混成体に妥当なデータフローをもたらします。 複雑なアプリケーションを作るときに発生する課題について多くの考察がなされましたが、React＋Fluxの組み合わせ
Reactを用いたアプリケーションアーキテクチャ：Fluxを再考する | POSTD
他のフレームワークやライブラリから React に乗り換える人たちは、「ReactはUIのレンダリングに関する問題しか解決しておらず、状態管理とアプリケーションアーキテクチャの選択は開発者に委ねられているのだから、どうやってアプリケーションの状態を管理したらいいのか？」 と疑問に思う傾向があります。FacebookはReactのレンダリングモデルに適している、 Flux と呼ばれるアーキテクチャを勧めています。 この記事では、UIレイヤとしてReactを用いてJavaScriptのアプリケーションの状態を管理する方法を探り、 Om のような ClojureScript ライブラリのアイデアを用いてFacebookのFluxの抽象的なフレームワークを作り変えてみたいと思います。 Fluxの核となる考えは、 データは一方通行で流れるべき というものです。これによってアプリケーションの論証が簡単
CSSモジュール ― 明るい未来へようこそ | POSTD
ここ最近、CSSに対する考え方が広がりを見せています。皆さんの中には、その転換点を見つけようと、Christopher Chedeauの”CSS in JS”という講演を聞いた方もいるでしょう。2014年11月にNationJSで行われたこの講演は、CSSにおける重大な分岐点となりました。まるで高エネルギー粒子が衝突した後のように、それを機に、数ある多様な考え方が、各々の方向へ渦を描くように広がったのです。その例として、 React Style と jsxstyle 、 Radium を挙げましょう。これら3つは、Reactのスタイリングにおける最新かつ最良、そして最も実行しやすいアプローチに含まれており、 各々のプロジェクトのReadmeファイルでも、 そのように言及しています。もし”発明”が、 adjacent possible（一歩先にある可能性） を探ることの一例であるのなら、Ch
リレーショナルデータベースの仕組み (1/3) | POSTD
リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術（ビッグデータ、NoSQL、JavaScriptなど）を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか？ 私は開発者として、理解していないものを
Webページレンダリングについて知っておくべきこと: ピクセルは高コスト | POSTD
Web開発者として、ユーザの画面表示にピクセルがどのように関わるのかということは知っておくべきでしょう。知ることが目的なわけではなく、効率性のため画面表示を最適化する際にその知識が必要となってくるからです。 先日、「 フロントエンド開発者がWebページレンダリングで知っておくべきこと 」を読んだのですが、重要なポイントを外してしまっている印象を受けました。その記事で強調されていたのは、CSSセレクタのマッチング、レイアウト（FirefoxのようなGeckoベースのブラウザではリフロー）、そして レイアウトスラッシング という名でも知られる強制同期レイアウトに注意することです。確かに、これらは気をつけたほうがいいことだとは思いますが、私としては、ページレンダリングについて開発者が知っておくべきことをその記事ですべてカバーしていたとは思えません。大抵の場合、Web開発者は60fpsの表示を目指
@extendを使うべき時、@mixinを使うべき時 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) 私がクライアントからよく受ける質問に 「@mixinと@extend、それぞれどのような時に使うべき？」 というものがあります。 “引数を使わない@mixinは悪である”。 これは以前からある経験則です。同じコードを2つのインスタンスで重複させるだけの@mixinは不快でさえあります。しかし、@extendを使うべき時、@mixinを使うべき時、これらを見極めることにはもっと深い意味があるのです。 それでは詳しく考察していくことにしましょう。 私は普段、@extendは決して使わないようにとアドバイスしています。@extendには、一見したところ魅力的な特徴がたくさんあるのですが、注意しなければいけない点はそれ以上にあります。言ってしまえば 見かけ倒し だということです。 それでも@extendを使い
JavaScriptのデバッグ方法 – JSを嫌いにならないためのTips | POSTD
この記事のオリジナルは voxxed に投稿されたものです。 JavaScript関連の問題を抱えるチームをサポートする仕事を通じて、いくつか共通の問題点があることに気づきました。もしあなたもJavaScriptに対するイライラを感じているのであれば、この記事は何らかの助けになるかもしれません。おことわり：私がお教えするヒントはすでにご存知のものもあるとは思いますが、うまくいけば、多少なりとも有用な情報があるかもしれません。特にエンタープライズアプリケーションやCMSソリューションを構築する際に有効なヒントです。チームの誰もが話したがらないCMSのコードについてお話しします。いずれも必要に応じて採用できるものです。 debuggerステートメント 大半のブラウザでサポートされているにもかかわらず、JavaScriptを書く際に最も活用しきれていない機能の1つです。debuggerステートメ
リーダブル・コードを書く | POSTD
ここ数年間をプログラミング的な観点で見ると、私が望んでいたほどには面白みがなかったと言わざるを得ません。このことは、恐らく他のプログラマの皆さんも同意見かと思います。そこで、私はこの期間をある意味、充電期間と捉えて、自分の開発ツールの強化に取り組んできました。そして土曜日になると、Bashを使って ワークスペース 作りに精を出していたのです。 最後にシェルを使って真剣にプログラミングに取り組んだのは、かれこれ恐竜がまだ地球を支配していた頃だったでしょうか。何年も触れていなかった言語を改めて取り上げ、その昔に自分が書いたコードを見直してみると、いかに自分が成長したかということを実感できて、なかなかに面白いものです。 14年前、私は”コンパクトなコードは優れている”という考えに随分と傾倒していました。コードが少なければ、そしてDon’t Repeat Yourself（DRY）に従えば、バグも
すべてのプログラマが読むべき記事10選 | POSTD
Javaプログラマやソフトウェア開発者として、私は「プログラマが知っておくべき…」というタイトルが付く記事から、多くのことを学びました。そういった記事は、特定のトピックに関する有益かつ詳細な情報を数多く与えてくれましたが、探し出すのが非常に困難でもあったのです。知識を探求する中でとても役に立つ記事を見つけたら、参考として何度も読み返せるようにブックマークしてきました。こういった記事を読むことは、どのプログラマにとっても有益になると思うので、私が集めた「 すべてのプログラマが知っておくべきこと 」を皆さんと共有する為にこれを書きました。 ここで紹介する記事は私が個人的にブックマークしたものです。「メモリ」、「Unicode」、「浮動小数点演算」、「ネットワーキング」、「オブジェクト指向設計」、「時刻」、「URLエンコード」、「文字列」などといった代表的なトピックについて載っています。このリス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
