フロントエンドのテストは皆のためのもの | POSTD
テストとは人によって反応が分かれるものの1つであり、大喜びする人もいれば、見ないようにして去ろうとする人もいます。あなたがどちらの側であるにせよ、ここではフロントエンドのテストは皆のためのものであるということを説明します。実際、テストには多くの種類があり、それがテストに対して初めに恐れや混乱を感じる一因なのかもしれません。 この記事では、特に有名で広く利用されている種類のテストを扱います。なかには目新しいものはないと感じる読者の方もいらっしゃるかもしれませんが、少なくとも復習にはなるでしょう。どちらにせよ、筆者の目標は、この記事を通じて世の中のさまざまな種類のテストについて理解を深めてもらうことです。ここではユニットテスト、統合テスト、アクセシビリティテスト、ビジュアルリグレッションテストなどを一緒に見ていきます。 さらに、Mocha、Jest、Puppeteer、Cypressなど、各種
モノリシックなバージョン管理の利点 | POSTD
以下は、私がよく交わす会話の一例です。 人物A：FacebookやGoogleは、巨大なモノリシックリポジトリ（モノレポ）を使っているんだってよ。 私：みたいだね。あれは本当に便利だと思う。 人物A：僕に言わせれば最悪の愚行さ。全てのコードを単一のリポジトリに入れるのがヒドイ考えだと、FacebookやGoogleはなぜ思わないんだろうか。 私：FacebookやGoogleのエンジニアたちも小さなリポジトリには精通しているだろうけど（ 濱野純（Junio Hamano） 氏はGoogle勤務だし）、単一の大きなリポジトリの方が、きっと”ある理由”で好みなんだよ。 人物A：なるほどね。僕としては、まだちょっと違和感はあるけど、モノレポが使われる理由は分かったような気がするよ。 “ある理由”はかなり長いので、同じ会話を何度も繰り返さなくていいように、ここに書き留めておこうと思います。 シンプ
Bashアプリケーションをテストする | POSTD
以前、bashスクリプトをテストする仕事に取り組んだことがあります。最初、Pythonユニットテストを使うことにしましたが、プロジェクトに外部技術を持ち込むのは気が進みませんでした。そこで、仕方なく、悪名高い bash で書かれたテスト用フレームワークを使いました。 既存ソリューションの概要 手に入るソリューションを探してGoogle検索しましたが、選択肢はほんの少ししかありませんでした。そのうちいくつかについて、詳しく見ていきましょう。 重要になるのは、どんな基準でしょうか？ 依存関係： bass のテスト用フレームワークを選ぶときに、 python 、 lua などのシステムパッケージも一緒に引きずり込むのは嫌ですね。 インストールの難しさ：継続的な開発の実装とTravis CIでの継続的な統合も仕事の1つだったので、私にとってインストールにかかる時間と手間数が妥当だということは、重要
正式リリースされたES8の主な新機能 ???? | POSTD
EcmaScript仕様第8版の新機能 EcmaScript 8もしくはEcmaScript 2017が、6月末にTC39から正式にリリースされました。私たちはこの1年、EcmaScriptについて色々と議論しているようですが、それは無駄なことではありません。現在、ES標準は新しい仕様のバージョンが年1回公開されています。ES6は2015年、ES7は2016年に公開されましたが、ES5のリリース時期をご記憶でしょうか。JavaScriptが魔法のように普及する以前の、2009年のことでした。 つまり私たちは、安定した言語としてJavaScriptの開発上の変化をたどっており、今や自分の語彙にES8を加える必要があるのです。 ES2017 (the 8th edition of the JavaScript Spec) was officially released and publishe
JavaScript モジュールの現状 | POSTD
(注：2017/07/19、いただいたフィードバックを元に翻訳を修正いたしました。) ESM、CJS、UMD、AMD — どれを使うべき？ 最近、 Twitter では、 ESモジュール の現状、特に、 *.mjs をファイル拡張子として導入すると決めた Node.js の現状について大騒ぎになっています。この話題は複雑で、かなりの労力を費やしてそれに専念しないと議論について行けないので、 皆が恐れと不安を抱く のも無理はありません。 古き恐れ フロントエンド開発者なら、 JavaScriptの依存関係の管理に悩まされた日々 を憶えている人も多いでしょう。あの頃は、ライブラリをベンダーフォルダにコピー&ペーストし、グローバル変数に依存し、あらゆる物を正しい順序でconcatしようとしてもネームスペースの問題に対処する必要がありました。 何年もかかって、私たちは共通モジュール形式と中央集権
2017年JavaScriptのテスト概論 | POSTD
本稿は、JavaScriptのテストについて最も重要な根拠、用語、ツール、アプローチなどの知識を身に着けることを目的とした簡略版ガイドブックです。本稿で検討する数々の側面に関する最新の秀逸な記事も紹介しつつ、私たちが経験的に得たことも多少付け加えたいと思います。 Facebookによるテスト用フレームワークであるJestのロゴをご覧ください。 見てお分かりのように、このフレームワークは「苦痛のない」JavaScriptのテストをスローガンに掲げています。しかし、 “次のように言う人” もいます。 苦痛のないテストなんてあり得ない。 実際、Facebookはこのスローガンを掲げるだけの素晴らしい理由があります。一般的にJSのデベロッパは Webサイトのテストにあまり満足していません 。JSのテストには制限があり、実装が難しく、低速である傾向があります。 一方、正しい戦略を立てて適切にツールを
マイクロサービスはもう十分 | プロダクト・サービス | POSTD
モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。要旨 モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。 – Martin Fowler 明確に構造化されたモノリスを構築できない時、なぜマイクロサービスがその答えだと思うのか。 Simon Brown 始めに マイクロサービスの利点と欠
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
webpackとRollup：似て非なるもの | POSTD
先日、Facebookは 膨大なプルリクエスト をReactにマージして、既存のビルドシステムを Rollup ベースのシステムに移行しました。 その結果 、 何人もの人々 から「なぜwebpackではなくRollupを選んだのか」という質問が寄せられました。 これは、もっともな疑問でしょう。 webpack は、近年JavaScriptコミュニティで最も評価されているツールの1つです。毎月のダウンロード数は何百万件にもおよび、何万個ものウェブサイトやアプリケーションに使用されています。巨大なエコシステムがあり、コントリビュータも多くいます。さらにオープンソースプロジェクトとしては珍しく、 かなりの寄付金 が集まっています。 それに比べるとRollupは小規模です。しかしReact以外にも、Vue、Ember、Preact、D3、Three.js、Momentなど、数々の有名なライブラリに
くだらないAPIなんていらないよ – 2016年のウェブスクレイピング事情 | POSTD
ソーシャルメディアのAPIとそのレート制限は、あまり気分のよいものではありません。特にInstagram。あんな制限つきAPIを欲しがる人がいったいどこにいるんでしょうね？ 最近のサイトは、スクレイピングやデータマイニングの試みを阻止するのがうまくなってきました。AngelListはPhantomJSすら検出してしまいます（今のところ、他のサイトでそこまでの例は見ていません）。でも、ブラウザ経由での正確なアクションを自動化できたとしたら、サイト側はそれをブロックできるでしょうか？ 並行性を考えたり、さんざん苦労して用意した結果として得られるものを考えたりすると、Seleniumなんて最悪です。あれは、私たちが「スクレイピング」と聞いて思い浮かべるようなことをするためには作られていません。しかし、賢く作り込まれた今どきのサイトを相手にして、インターネットからデータを掘り当てるための信頼できる
Bluebirdの高速化を可能にする、3つのJavaScriptパフォーマンスの基礎 | POSTD
最近Reaktorが掲載した『 Promises made by a Reaktor developer had an impact on the industry article 』で約束した、Bluebird promiseライブラリの製作者であるプログラマのPetka Antonovからの知見です。 Bluebirdは広く使用されているJavaScript用のpromiseライブラリで、同じような機能が実装されているにも関わらず、他のpromiseよりも100倍速いという理由から最初に知られるようになったのは2013年でした。Bluebirdが高速な理由はライブラリ全体にJavaScriptの最適化の基礎を一貫して適応しているからです。この記事ではBluebirdの最適化に使用する3つの重要な基礎について詳細に説明します。 1. 関数オブジェクトの割り当てを最小限に抑える オブジェク
Essential Electron : Electronの簡潔・平易な概要 | POSTD
Electronとは？ Electronは JavaScript、HTML、CSS を使ってデスクトップアプリケーションを作ることができる ライブラリ です。作ったアプリケーションはMac、Windows、Linuxで動かせます。 次は： なぜ重要？ 定義： JavaScript、HTML、CSS はWeb用の言語で、Webサイトの基本的な構成要素です。Chromeなどのブラウザは、コードをふだん目にするグラフィックに変えて表示します。 Electronはライブラリです Electronはコードですが、再利用でき、自分で書き起こす必要がありません。ユーザはその上にプロジェクトを構成します。 参考資料 Apps built on Electron Electron API Demos （Electronで何ができるかをみてください） なぜ重要？ 一般に、デスクトップアプリケーションは各オペレ
WebSocket大合戦：Clojure、C++、Elixir、Go、NodeJS、Ruby | POSTD
Webアプリにリアルタイムの双方向通信が必要な場合、WebSocketを選ぶのは自然なことだと思います。では、どのツールでWebSocketサーバを構築すべきでしょうか。パフォーマンスは重要ですが、開発のプロセスも見過ごしてはなりません。パフォーマンスを基準にするだけでなく、開発のしやすさも考慮に入れるべきでしょう。今回の大合戦では、Clojure、C++、Elixir、Go、NodeJS、Rubyのそれぞれの言語によって慣用的な手法で実装されたシンプルなWebSocketサーバを比較したいと思います。 テスト内容 サーバに実装するのは、 echo と broadcast の2つのメッセージのみを扱う非常に単純なプロトコルです。echoは送信クライアントに返され、ブロードキャストは全ての接続クライアントに送信されます。そしてブロードキャストが完了すると、結果メッセージが送信者に返されます。
GitHubのコード検索 : プログラマにとっての宝の山 | POSTD
新しい言語やフレームワークを学ぶことは、時には苦闘になることがあります。従来のアプローチは、概念を説明し簡単な例を提供するドキュメントを読むことです。それで十分な場合もありますが、ドキュメントに高度な例や実際のプロジェクトでの使い方が書かれていない場合も多々あります。 ドキュメントに記載されていない問題に出くわすと、大抵の人はStack Overflowで解決策を探します（またはソースコードを丹念に調べます）。しかし、「使っているフレームワークが登場してから十分に期間が経っておらず、思い浮かぶ質問全てにStack Overflowが答えてくれない」ということもありえます。 今まで問題にはまって、こう考えたことはありませんか？ 「誰かが既にこの問題を解決しているはずだ！では、なぜこの問題に対する答えがStack Overflowにないのだろうか？」 そのとおりです。恐らく誰かは既にそれを解決
React Fiberアーキテクチャについて | POSTD
初めに React Fiberは、現在進行形で進められているReactのコアアルゴリズムの再実装であり、Reactチームの2年以上にわたる研究の成果です。 React Fiberは、アニメーション、レイアウト、ジェスチャーといった領域に対する適性を向上させることを目指しています。React Fiberの目玉となる インクリメンタルレンダリング は、レンダリング作業を分割して、複数のフレームに分散させることができる機能です。 他には主に、新たな更新があった際に作業を休止・強制終了・再利用できる機能、更新の種類別に優先順位をつけられる機能、新しい並行プリミティブなどが挙げられます。 このドキュメントについて Fiberは、コードを見ただけでは分かりにくい斬新な概念をいくつも導入します。このドキュメントはそもそも、ReactプロジェクトにおけるFiberの実装に伴って私が取っていたメモを集めたも
初心者のためのSQLガイド???? : SQLを直感的に理解しよう | POSTD
SELECT * WHERE a=b FROM c ？ それとも SELECT WHERE a=b FROM c ON * ？ もしあなたが私のようなプログラマだったら、SQLは、初めは優しく見える言語の1 つかもしれません（ただ単に普通の英語通り読めばいいですから）。ですが、何かしらの理由で、なんてことのないクエリにもいちいち正しいシンタックスをググらなければいけないでしょう。 いずれJOINにAGGREGTATION、サブクエリにたどり着くでしょうが、読んだとしてもさっぱりでしょう。例えば次のような感じです。 SELECT members.firstname || ' ' || members.lastname AS "Full Name" FROM borrowings JOIN members ON members.memberid=borrowings.memberid JOIN
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を学ぶ上での中核にはならないものの、カバーしておくべきだと私が思っているもので
ReactでTDD（テスト駆動開発）を始めよう : 環境構築からテスト作成、機能実装までの詳解ガイド | POSTD
最小限の設定のTDD手法を使い、「何をテストすべきか？」から、よくある落とし穴の避け方まで、Reactコンポーネントをテストする方法を学びましょう。 導入 まず、 React を触ったことがあり、更にはいくつかのテストも書いた経験があるとしましょう。それでも、コンポーネントをどうテストするのが最善なのか、よく分からないかもしれません。どこから始めるのでしょう。具体的には何をテストすればよいのでしょうか。 いくつかのReactコンポーネントは簡潔過ぎて、そもそもテストが必要なのかすらはっきりしません。 AngularからReactに乗り換えた 人なら、テストには愛憎のような思いがあるかもしれません。 確かに Angular にはテストを支援するツールがたくさんありますが、同時にテストを書くのが難しくなる可能性があります。冗長ながら省略できない定型コードが多々ある上、 $digest の呼び出
効果的なフォームをデザインする：構造、入力、ラベルおよびアクション | POSTD
画像の出典：form-ux-tips あなたのアプリやサイトを利用する人々にはある一定の目的があります。そしてその目的を達成するために フォームに 記入しなくてはならないことがよくあります。Webやアプリにおいてフォームは、ユーザにとって未だに最も重要な 種類の操作 であるからです。事実、フォームは目的を達成するまでの 過程における最後のステップ と見なされることも多いのです。 フォームは目的達成の手段にすぎません。迅速に混乱なく、ユーザがフォーム入力を完了させられるようにするべきです。 この記事では、ユーザビリティテスト、フィールドテスト、視線計測（アイトラッキング）、そしてユーザからの実際の不満の声に基づく実用的なガイドラインを紹介します。 フォームの構成要素 一般的にフォームは以下の5つの要素から構成されます。 構造 。フィールドの順番、ページの外観、各フィールドとの論理的な関連付け
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ページネーションのベストプラクティス | POSTD