Core Web Vitals（CWV）は2020年5月に発表されました。Googleはこの発表の中で、「より良いWebのためにページエクスペリエンスを評価する」と述べています。特に重要なのは、この評価がGoogleの検索順位アルゴリズムの一部を構成することでした。つまり、高速なWebサイトは、同等の遅いWebサイトよりも順位が上になり、Google検索によるトラフィック（ほとんどのWebサイトにとってWebトラフィックの最も大きな部分を占める）が増えます。 Webパフォーマンスコミュニティは、Webパフォーマンスのビジネス上のメリットを売り込むことに関して、常にSEO業界に劣っていました。Webパフォーマンスがビジネスのパフォーマンスに直接影響を及ぼす証拠が数多く存在するにもかかわらずです。しかし、今やSEO業界全体がWebパフォーマンスを重視するようになり、企業もWebパフォーマンスに

数週間前に、JavaScriptが実際どのように動いているかを掘り下げて紹介する記事の連載を始めました。JavaScriptがどのような機能で構成されていてそれらがどのように組み合わさって機能していくのかを知ることによって、さらに良いコードやアプリケーションを作ることができるのではないかと思ったからです。 連載の1回目では 、エンジンやランタイム、コールスタックについての概要を紹介しました。2回目となる今回は、Google V8 JavaScriptエンジンについて細かく説明していきます。また、より良いJavaScriptコードの書き方、すなわち私たちの開発チーム SessionStack がプロダクトを開発する際に意識しているベストプラクティスについても併せて紹介します。 概要 JavaScriptエンジン とはJavaScriptコードを実行するプログラムまたはインタプリタのことです。

元記事の著者より：この記事は主に北米文化で私が見たことを反映しています。 誰かに職業をきかれたら、私は「フロントエンド開発者です」と答えます（答えは相手によって変わることもあります）。10年か20年前は、自分の仕事に必然的に伴うものが何なのかは、かなり明瞭でした。インタラクション用にHTMLやCSSを書き、JavaScriptも多少は書いていました。駆け出しの頃、PHPやMySQLの作業に職務の大半を費やしていたとはいえ、フロントエンド開発者として見られる方が好きです（これに関しては、後に詳しく説明します）。この状況は、2010年の初頭に変わり始めました。JavaScriptが、重要で、非常に大きな存在になってきたのです。昨年の初め頃から、たくさんのフロントエンド開発者に会うようになり、あることに気付きました。フロントエンド開発者は、もはや、私が以前から知っているフロントエンド開発者ではな

知っているUnixのコマンドで一番シンプルなものは何ですか？ 例えば echo という、stdoutに文字列を出力し true を返す – すなわち常に0の終了コードで終了するシンプルなコマンドがあります。 シンプルな、と言えば yes もそうでしょう。引数なしで実行すると、改行されたyが無限に出力され続けます。

以下は、私がよく交わす会話の一例です。 人物A：FacebookやGoogleは、巨大なモノリシックリポジトリ（モノレポ）を使っているんだってよ。 私：みたいだね。あれは本当に便利だと思う。 人物A：僕に言わせれば最悪の愚行さ。全てのコードを単一のリポジトリに入れるのがヒドイ考えだと、FacebookやGoogleはなぜ思わないんだろうか。 私：FacebookやGoogleのエンジニアたちも小さなリポジトリには精通しているだろうけど（ 濱野純（Junio Hamano） 氏はGoogle勤務だし）、単一の大きなリポジトリの方が、きっと”ある理由”で好みなんだよ。 人物A：なるほどね。僕としては、まだちょっと違和感はあるけど、モノレポが使われる理由は分かったような気がするよ。 “ある理由”はかなり長いので、同じ会話を何度も繰り返さなくていいように、ここに書き留めておこうと思います。 シンプ

1. 概要 SQLiteを使うと小さなBLOB（例：サムネイル画像など）を読み書きする場合、fread()やfwrite()を使って個別のファイル上に記録されたBLOBを読み書きするよりも35％も速く (*1) 読み書きができます。 さらに、10キロバイトのBLOBを扱うようなSQLiteデータベースを考えた場合、個別のファイルにそれぞれのBLOBを格納する場合に比べてディスク領域を約20％も節約可能です。 このようなパフォーマンスの差が生じる理由は、（私たちの考えでは）SQLiteデータベースの場合、open()やclose()システムコールが呼び出されるのが1回だけなのに対して、個別のファイルに格納されているBLOBを使用する場合は、open()やclose()がBLOBの数だけ呼び出されるためだと思われます。どうやらopen()とclose()を呼び出すオーバーヘッドは、データベース

(注：2017/07/19、いただいたフィードバックを元に翻訳を修正いたしました。) ESM、CJS、UMD、AMD 　—　どれを使うべき？ 最近、 Twitter では、 ESモジュール の現状、特に、 *.mjs をファイル拡張子として導入すると決めた Node.js の現状について大騒ぎになっています。この話題は複雑で、かなりの労力を費やしてそれに専念しないと議論について行けないので、 皆が恐れと不安を抱く のも無理はありません。 古き恐れ フロントエンド開発者なら、 JavaScriptの依存関係の管理に悩まされた日々 を憶えている人も多いでしょう。あの頃は、ライブラリをベンダーフォルダにコピー&ペーストし、グローバル変数に依存し、あらゆる物を正しい順序でconcatしようとしてもネームスペースの問題に対処する必要がありました。 何年もかかって、私たちは共通モジュール形式と中央集権

モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。要旨 モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。 – Martin Fowler 明確に構造化されたモノリスを構築できない時、なぜマイクロサービスがその答えだと思うのか。 Simon Brown 始めに マイクロサービスの利点と欠

9つのおとぎ話 CSSは迷走しています。JavaScriptでドキュメントをスタイリングしているプロジェクトでは、多くの場合誤った理由からその方式を選択しています。本稿では、よくある誤解（神話）を列挙し、そうした問題に対するCSSソリューションを紹介します。 本稿は、特定のプロジェクトや人物への攻撃を意図するものではありません。ここでは、“CSS in JavaScript”(CSS in JS)を styled-components を使用することと定義します。これは、Reactのコンポーネントをスタイリングする最近のトレンドとなっています。 styled-components の作者である Max Stoiber と Glen Maddern 、また彼らに協力した人々は皆、卓越したアイデアと善意にあふれる優秀な人々です。 完全な透明性のために断っておくと、私は react-css-mo

数ヵ月前、私はGoogleマップを、もっと正確に言うとGoogleストリートビューを利用しました。Googleストリートビューは子供の頃に思い描いた未来的なテレポートみたいで、とても気に入っています。私は、普段そうするように、その時もアドレスバーを見ました。2014年のいつ頃からか、パラメータは単なるクエリの文字列ではなくなり、その代わりに感嘆符で区切られた英数字の奇妙な寄せ集めになったようです。 難解で、現在のところ公開されたドキュメンテーションもなく、多くの人々に毎日使用され、リバースエンジニアリングが可能なプロトコル。こういうコードを目の前にすると、私は解読したくてウズウズしてきます。 私はブラウザのWebコンソールも見てみました。AJAX APIへのリクエストが同じようにエンコードされていただけではなく、もしレスポンスの一部が画像だった場合、その他のレスポンスは暗号を用いたバイナリ

以前書いた（C言語についての） メモリ安全性について定義した記事 について、型安全性について説明する記事も投稿してほしいというコメントがありました。型安全性についてはかなりよく知られてきていると思いますが、ズバリこうだと簡単に定義できるほどにはまだ理解が浸透していません。特に誰かが”Javaは型安全な言語だ”と言った場合、これは厳密に何を意味するのでしょう。全ての型安全な言語はある意味”同じ”と言えるでしょうか。ある特定の言語について、そして一般的な意味で、あなたを悩ませる型安全性とは何でしょうか。 実際のところ、型安全性が何を意味するのかは言語の型システムの定義によります。最もシンプルなケースでは、型安全性はプログラムの動作が正しく定義されるように保証します。もっと一般的な話をすると（この記事ではそのあたりをカバーするつもりですが）、言語の型システムはそのプログラムの正確さと安全性を推論

本稿では、関数型プログラミングのコンセプトを実用的な方法でRubyのコードに盛り込む方法について紹介します。これは、私が「関数型プログラミングのスタイル」と呼んでいるものです。 私が言う「実用的」とは、関数型プログラミングのスタイルを取り入れた後もなお、コードの見た目や印象にRubyの特徴が残っていることを意味します。Rubyは、Haskellではありませんし、Haskellであるべきでもありません。考え方としては、この言語の性質を 利用しよう とするものであって、それに反することをするわけではないのです。出来上がったコードは、Rubyユーザにとって簡単に理解できるものであるべきです。うまくいけば、使い慣れているものよりも簡単と感じていただけるはずです。 では、可変性を回避する利点、方法、欠点、そして可変性の回避が適切ではないケースについて見ていきましょう。 なぜ可変性を回避するべきなのか

自社で構築した数エクサバイトのストレージシステム、 Magic Pocketを発表 して以来、多くの好意的なフィードバックをいただいています。この発表に続きまして、舞台裏からシステムの興味深い側面を見ていただくことができる技術ブログシリーズを投稿していこうと思います。保護の仕組み、運用ツール、ハードウェアとソフトウェアの境界線上の革新などです。しかし、まず、背景を説明する必要があるでしょう。本稿では、Magic Pocketのアーキテクチャ概略と設計で使われた基準についてお話しします。 紹介の投稿 で説明しましたように、Dropboxには、ファイルの内容と、ファイルやユーザについてのメタデータという2種類のデータが保存されます。Magic Pocketは、ファイルの内容を保存するのに使われるシステムです。保存するファイルは、ブロックに分割されて耐久性のためにレプリケーションされ、複数の地域

ReactのHigher Order Components詳解 : 実装の2つのパターンと、親Componentとの比較 (編注：2016/7/27、いただいたフィードバックをもとに記事を修正いたしました。) 概要 この投稿は、HOCパターンを利用してみたいという 上級ユーザ 向けの記事です。もしReactが初めての方は、まず Reactのドキュメント を読むところから始めるとよいでしょう。 Higher Order Componentsは、さまざまなReactライブラリにとって価値があることがわかっている素晴らしいパターンです。この投稿で、HOCとは何か、できることは何か、制約は何か、どのように実装するのか……という点について詳細に見ていきます。 付録として、関連トピックについても見ていきます。それらは、HOCを学ぶ上での中核にはならないものの、カバーしておくべきだと私が思っているもので

(訳注：2016/9/28、頂きましたフィードバックを元に記事を修正いたしました。) 何か新しいものが登場したと聞くと、人はそれに対する賛否を選ぶ傾向があります。TypeScriptが登場したときの私は、キーコンセプトのうち自分に合わないものをほんの幾つか取り上げて「否」の側を選んでしまいました。この記事では、私が当時どのように考えていたか、そして私がどのようにして「TypeScriptの背景には、大きな犠牲なしに利点を得る方法を知る人々による偉大な考えがあった」ことに気付いたかを説明しようと思います。 TypeScriptが登場したときの私の考え Anders Hejlsbergが何かに取り組んでいるときは、つい私はそちらに注意を完全に傾けてしまいます。彼はコンパイラの構築やプログラミング言語の設計を30年近く経験してきています。彼の様々なプログラミング言語に関する貢献については 彼のW

1983年に発売されたNintendo Entertainment System（NES、日本での商品名は「ファミリーコンピューター」、以下「ファミコン」）は安価なのに高性能だったため、大ヒット商品となりました。独自設計のピクチャー･プロセシング･ユニット（PPU）を使うことで、当時としては驚きの映像を生み出すことができました。そして、今でも特定の環境で視聴すればとてもきれいな映像が楽しめます。一番の業績はメモリの利用効率です。グラフィックスを最小限のバイト数で作成することに成功しました。それと同時にファミコンは、開発者に便利で使いやすいツールを提供しました。その点でも、それまでのテレビゲーム機とは一線を画した製品でした。ファミコンのグラフィックスの生成方式を理解すれば、システムの技術的な優れた能力のありがたみが分かるはずです。そして、現代のゲーム製作者が現在のマシンではどれだけ簡単に作業

新人の開発者が繰り返し突き当たるテーマがあります。プログラム言語を1～2種類勉強するのに時間を費やしたり、プログラミングの演習を行ったりすることに関して問題はないと感じていても、学んだことをどう応用していいのか分からずにいるのです。このことは、次のようなフレーズとしてよく耳にします。「プログラムの書き方は知っているが、何をプログラムしていいのか分からない」と。これに対する答えは、一般的に、「プログラミングの課題を行いなさい」、「オープンソースプロジェクトに貢献しなさい」、または、「ゲームを作りなさい」というようなものです。 プログラミングの課題を行うことは、知的ないい訓練にはなります。しかし新しいプログラムの開発方法を学ぶのにはあまり役立ちません。オープンソースプロジェクトに貢献するのは確かにステップアップになります。実際のプロジェクトがどのように構成されているか学び、プログラム言語の技術

本記事はRubyについて書かれたものではありますが、Python、JavaScript、Javaなど、全ての言語コミュニティに当てはまる事実を述べたものです。依存関係が引き起こす負の連鎖は誰のためにもなりません。 上の図は、私がこれまでに使用した全てのRailsアプリの依存関係を可視化したものです。以下の例はいずれも、どこかで聞いたことのあるものではないでしょうか。 何百ものエントリを含むGemfile 本番環境で読み込まれるテスト用Gem 数百メガバイトもRAMを食うRailsのプロセス Rubygemsシステムは、それを再利用する誰もが容易にRubyのパッケージを作ることができるという点で、賞賛に値するものです。しかし、その便利さが意味するところは、そうしたGemと他のGemを非常に安易に結び付け、さらにそれが、「インターネットでダウンロード」され、数百もの依存関係を持つRailsアプ

(編注：2016/7/29、頂いたフィードバックを元に記事を修正いたしました。) APIをデザインするということは、科学であり技術でもあります。多くの頭の良い人たちが失敗を重ねてきました。成功している人たちは、APIの主な目的を念頭においてデザインしているのです。その目的とは、「開発者たちをウンザリさせる」ということです。 親愛なる仲間たち、その崇高っぽい追求を称えるべく、「APIデザインにおける七つの大厄介」を共に数え上げようではありませんか（私がしたことを見てください）。 リスティクル（箇条書き形式の記事） を書くつもりはないのですが、少なくともタイトルは 教養ある宗教的文献が参照元 です。 まず、ルールを決めましょう。ここでは、成功し、きちんと機能しているAPIを取り上げます。ですから、「動かない」とか、「大量のセキュリティホールがある」といったことは厄介ごとに数えません。「致命的」

(訳注：2016/3/2、いただいた翻訳フィードバックをもとに記事を修正いたしました。) (訳注：著者のMattより、「本文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング領域では、対象とするシステムに応じた(例： 8-bitの組み込みシステム、10年前のコンパイラ、多くの異なるCPUアーキテクチャで動く必要のあるアプリケーション、Win/Linuxでのビルド互換性など)特有のアドバイスが必要」との補足を頂いております。) 以下の文章は2015年の始めに書いたドラフトで、今まで公開していませんでした。私のドラフト用フォルダの中で誰の目も引かなかったため、大部分が書いた時のままです。公開するにあたり、単純に2015年を2016年に変更しました。 必要な修正、改善、苦情があり