フロントエンドテストにおける知見の宝庫を発見！「javascript-testing-best-practices」JavaScriptテストフロントエンド はじめに JavaScriptにおけるテストのベストプラクティスをまとめた「javascript-testing-best-practices」というGitHubレポジトリが大変勉強になったため、特に参考になった内容をまとめて共有したいと思います。 （補足）本レポジトリにはfrontendのみならずbackendのテストに関する情報もありますが、今回はfrontendに焦点を当てて共有します。そのため扱うSectionは以下の4つです。 Section 0: The Golden Rule Section 1: The Test Anatomy Section 3: Frontend Section 4: Measuring Test

年末年始にフロントエンド論みたいな記事をいくつか見たが、僕ら古のSPA職人がやってきたフロントエンドという職域と目指していたものが失伝しかけている気がするので、ここに時代ごとに何を考えていたか、雑に書き殴る。 注意点として、 2004から始まるが、自分がプログラミングを始めたのが2010, 業務としてコードを書き始めたのが 2012 なので、解像度が高いのはそれ以降になる。 tl;dr 2004: 動き出す HTML 2011: 構造化のはじまり 2015: 贅沢品としてのSPAとコミュニティ分化 2017: 貧者のSPA 2019: 守破離としてのパフォーマンス 2004: 動きだす HTML AJAX の時代。要は XMLHTTPRequest で取得したコンテンツに応じて、動的書き換えをDOM書き換えを行うこと。今では名付けるほどでもない操作だが、HTMLが静的なものをやめたことは、

kubeadm では、kubeadm join コマンドの実行で、新しいノードの追加がかんたんにできます。 このとき何が行われているのかを調べてみました。 ノード追加のワークフロー The join workflow kubeadm join では次のようなステップが行われる。 API Server から必要となるクラスターの情報をダウンロードする Bootstrap token と CA key hash を使ってデータの信頼性を検証する クラスターの情報が取得できたら kubelet は TLS bootstrapping プロセスを開始できる TLS Bootstrap では shared token を使用して Kubernetes API Server で一時的に認証をし、証明書署名要求 (CSR) を送信する コントロール プレーンは既定でこの CSR リクエストに自動的に署名

Intro Fetch API の実装が広まり、 IE もリタイアを迎えたことで、今後忘れ去られていくことになるだろう XMLHttpRequest について。 どのように始まり、どのように広まり、どのように使われなくなっていくのか。その間に残した多大な功績を残す。 XMLHttpRequest の始まり この名前は非常に長いため、通常 XHR と略される。 この API は、現在の Web API のように W3C/WHATWG による標準化を経て策定された API ではない。 Microsoft によるいわゆる独自実装の API として始まり、後追いで標準化される。 したがって、 Web API の中でもかなり異質な命名である XHR が、 XmlHttpRequest でも XMLHTTPRequest でもなく XMLHttpRequest である理由も、 Microsoft の命

この記事の対象読者はもちろんGit初心者である。 あなたがGit初心者かどうかは自分で判断してもらえればいいが、ある程度明確には以下のようになる。 Git初心者・・・主要なコマンドを覚え使っているが、しばしば直観と挙動の差に悩まされる。 Git中級者・・・おおむね意図した通りにGitを使える。 Git上級者・・・Git内部の挙動まで理解している。 重要なところは太字の部分だ。 個人的に、Gitを難しいと思う理由はここだと思っている。 私自身、業務で使えてはいてもコマンドの結果に不安や恐怖を覚えることが多かった。 しかしある時、私の直観とGitの挙動はたいてい一致するようになった。 Gitをシンプルで一貫性のある構造物として認識できるようになったからだ。 コマンドはあくまで構造を変えるためのインターフェースでしかなく、コマンドをいくら暗記してもGitはいつまでもブラックボックスのままだったの

Reactが好きです。 Reactが好きです。コンポーネントを関数として扱うのが好きです。 SolidJSはReactそっくりの書き心地(DX)を保ちつつ、Reactに足りない要素を兼ね備えた期待の新人です。 コードの比較 React const Counter = () => { const [count, setCount] = useState(0) useEffect(() => { console.log(`Count: ${count}`) }, [count]) return ( <div> <div>{count}</div> <button onClick={() => setCount(prev => prev + 1)}>Add</button> </div> ) } const Counter = () => { const [count, setCount] =

Welcome to CRIU, a project to implement checkpoint/restore functionality for Linux. Checkpoint/Restore In Userspace, or CRIU (pronounced kree-oo, IPA: /krɪʊ/, Russian: криу), is a Linux software. It can freeze a running container (or an individual application) and checkpoint its state to disk. The data saved can be used to restore the application and run it exactly as it was during the time of the

長い記事なので先に結論を書きます。 Spectre の登場で、ウェブサイトに必要とされるセキュリティ要件は増えました。具体的に必要な対策は下記の通りです。 すべてのリソースは Cross-Origin-Resource-Policy ヘッダーを使って cross-origin なドキュメントへの読み込みを制御する。 HTML ドキュメントには X-Frame-Options ヘッダーもしくは Content-Security-Policy (CSP) ヘッダーの frame-ancestors ディレクティブを追加して、cross-origin なページへの iframe による埋め込みを制御する。 HTML ドキュメントには Cross-Origin-Opener-Policy ヘッダーを追加して popup ウィンドウとして開かれた場合の cross-origin なページとのコミュニ

Intro Public Suffix List (PSL) は、現在の Web プラットフォームの一端を支えている非常に重要な要素だ。 実はこれが、少数のボランティアにより GitHub でメンテナンスされた、単なるテキストリストであることは、あまり知られていないかもしれない。 最近、このリストへの追加リクエストがあとを絶たず、問題になっている。 そもそも PSL とは何であり、今どのような問題が起こっているのかについて解説する。 Public Suffix List とは何か PSL を解説するには、まず関連する用語について整理する。 Top Level Domain (TLD) 例えば、このブログのドメインは blog.jxck.io であり、これは筆者が取得したドメイン jxck.io のサブドメインだ。 jxck.io は、 .io という TLD のサブドメインを販売しているレ

2018/05/02追記 ◆ホストマシンガチャについて 管理コンソールから強制リブートを実行するとホストマシンが切り替わるので、うまくいかないときはそこから実行しましょう。 2018/04/14追記 とりあえずインスコしたけど、仮想マシン作成後の起動がうまくできないのでまたどっかで追記する ホストマシンによって、CPUのマイクロコードアップデートを促すエラーメッセージが表示されてインストールが進まなかったりするので、どうしてもやりたい人はホストマシンガチャをするしかなさそう いろいろ画像増やした 備忘録 気が向いたら後で画面キャプチャ取ったりしてもうちょいきれいに手順を作る 多分公式でサポートされてないので自己責任ｵﾈｼｬｽ！ なぜやるのか 以下2点の理由から試してみた ・自分でESXi触りたいと思ったけど自宅鯖がない ・さくらクラウドのクーポンをもらったけど使い道がない 事前準備 さくら

Go を使ってプロダクトを作る時、Makefile を使ってビルドを指定することが多いです。 理由としては、 バージョン情報などを埋め込むのに都合がいい 複数のバイナリを吐き出す時に都合がいい Go のビルドオプションを指定するのにいろいろあって整理しておきたい 事前にコードジェネレータで書き出す部分があり、それを考えると Makefile などで整理したい などなどです。なので今回はプロジェクトが大きくなっていく中でどういう Makefile の書き方をしているか、というのをご紹介しようと思います。 サンプルとして、今回のプロジェクトでは gRPC を使ったチャットサービスのサーバーとクライアントを作ることにします。リポジトリは https://github.com/rosylilly/gochat に置いておきました。 Step 1. バージョン情報を埋める 今回はサーバーとクライアン

Go の module cache と vendor の違いがよく分からなかったので調べた。結論としては、違いというか go.mod に記述されているバージョンによってデフォルトで module cache と vendor のどちらを go run や go build 時に使うかが異なる。 環境 Go 1.15.3 $GO111MODULE = ON module cache 外部のモジュールに依存したコードをビルドする場合、依存モジュールを1度ダウンロードする。ダウンロードしたモジュールは、$GOPATH/pkg/mod/ にキャッシュされるので次回のビルド時には再度ダウンロードする必要はなくなる。 go clean --modcache で消せる go run -mod=mod フラグで明示的に module cache を使用するように指定できる vendor go mod ve

A DDoS attack is an attempt to make an online service unavailable to users.

Submarine Cable MapThe Submarine Cable Map is a free and regularly updated resource from TeleGeography.

頭の痛い表ができました。 いまどき「インターネット画像参照」NGなメール環境は世界的に珍しいのですが、さらに、メールアドレスだけ見ても「インターネット画像参照」できるかは分からないのです。だって、メールアドレスを見ても相手がどんな受信環境かは分からないですから。 ソフトバンクのiPhone用メールアドレス @i.softbank.jp は例外で、これだけは「インターネット画像参照」OK確定です。 携帯キャリアメールアドレスの「インターネット画像参照」NGな環境に、「インターネット画像参照」するHTMLメールを送ると、真っ白になったり、「×」画像がたくさん並んだ表示になります。 「えっ？テキストとHTML両方を含んだマルチパートで送るんだから、不都合なHTMLパートではなくテキストパートが表示されればいいのに」と思った方は鋭い。マルチパートはそのような目的のためにあるものですが、携帯キャリア

※この投稿について 前半でIPレピュテーションとは何か？という説明をしていますので、未読の方は一読することをお勧めします。 メールというインターネットの闇とIPレピュテーション（だけど重要）(前編) https://qiita.com/nfujita55a/items/5848fcfbbe6cbf7d98c3 この後半では、IPレピュテーションをよくしてメールを滞りなく送りたいときの光要素と闇要素を、光→闇の順に書いています。 メールを円滑に送るためIPレピュテーションを高めたい、何ができるの（光要素） まずは、IPレピュテーションを含めて、メール送信を円滑に行うためにすることが大別して3つくらいあると思います。 送信ドメイン認証する いわゆるSPFやDKIMです（最近はこれにDMARCが加わる）。SPFなら送信側が「DNSを使ってこのEnvelope-FromのメールはこのIPアドレス帯

と、この例では3回の通信がなされます。1が終わったら 2、2が終わったら 3とバケツリレーされます。 ※3の後に、メールボックスにあるメールをWebで見たりPOP3などでメーラーがメールを取得したりする このSMTPを使用したメールのバケツリレーの様相は、ブラウザとWebサーバーが End to End なHTTP(S)と大きく異なります（HTTPにもプロキシはあって通信が多段になることはありますが、バケツリレーではない）。 「IPレピュテーション」という概念は、上の表の2の通信、インターネット越しに送る側と受け取る側がSMTP通信するところに係わります。 レピュテーション=評価、です。メールにおけるIPレピュテーションとは、受け取る側の送る側の送信元IPアドレスに対する評価 です。この評価によって、受け取る側のメールサーバーは メールを速やかに受け取り受信者の受信箱に配送する メールを受