概要 以前、zipcode_jpという住所検索APIを作った (github) と紹介したのですが、その後も徐々に機能追加を重ねてきました。その結果、割といい感じの住所入力フォームが作れるようになりましたので、追加機能の紹介をします。 zipcode_jpを開発した理由 郵便番号検索機能をいろんなサービスで実装してきた。 その際、郵便番号検索機能のためのDBを保守するのが面倒。ken-all.csvのパースとかしないといけない。 外部サービスを使うのも、料金とか利用制限とかサービス停止時の対応とか考えると別の面倒事が増える。 そもそもそこまですごいことがしたいわけじゃない。郵便番号検索に対応する住所情報をダウンロードすればいいだけなので、これってそもそも動的なサーバープログラムを準備しなくていいのでは？ と思って作ってみたら、まあまあいい感じに使えた。 みたいなことを 郵便番号から住所を検

はじめに React 16.8でhooksが導入されましたが、Suspense for data fetchingやreact-cacheが登場するまでは、データ取得のベストプラクティスは曖昧です。しかし、キャッシュさえ重要でなければuseEffectで比較的簡単にFetch APIのフックを実装することができます。 実装 import { useEffect, useReducer } from 'react'; const initialState = { loading: false, // データ取得中はtrueに設定される error: null, // データ取得でエラーになると設定される data: null, // データ取得結果が設定される }; const reducer = (state, action) => { switch (action.type) { cas

JavaScriptでWebRTCやるための基礎知識 - console.lealog(); 春なので書きました。 言うなれば、これの2019年度版です。 はじめに 最低限のJavaScriptでWebRTCを扱うにあたり、どういうクラスがあって、どういうAPIを、どう使うのかについての記事です。 いわゆるフロントエンドのエンジニアがWebRTCを使ったサービスを作るなどの場合は、だいたい何かしらのSDKを使うと思います。 その場合はそのSDKのDocsを読めばそれで十分で、その先の仕組みを知る必要はないかなーと思います。 ただし、 SDKの中で何が行われてるか知っておきたい WebRTCのSDKを作る側である みたいな場合は、一読の価値ありかもです。 ようするに、弊社の新入社員のような人材のための記事です！ 基本的なWebRTCの仕組みみたいなパートはざっくり軽めにして、JavaScri

こんにちは！dely でフロントエンドの開発をしています @all__user です。 今回は kurashiru のフロントエンド開発に導入されたビジュアルリグレッションテストについてご紹介したいと思います。 【反応を多くいただいた点について記事の最後に追記しました】 目次 目次 ビジュアルリグレッションテストとは 導入の背景 フロントエンドのテスト？ SPA移行前後の比較 ツール reg-suit Loki Wraith BackstopJS テストのフロー GitHub + CodeBuild + BackstopJS ステージング環境 テストケースは Google スプレッドシートで管理 結果を S3 にアップロードして Slack に通知 まとめ 【追記】 運用が大変ではないか？ 1pxの違いにそこまで工数かける？ 広告が差し込まれたり変わっただけでテストが壊れるのでは？ ビジュ

最近は設計をする際にできる限り API 仕様を正確に記述するようにしている。このことを意識し始めた大きな要因は主に次の 2 つだと思う。 1 つ目は以前、前職で働いているときに柴田さんに API 仕様の重要性を教えてもらったことから。この時に聞いたことは以下のブログ記事にまとまっているのでぜひ読んでほしい。 yshibata.blog.so-net.ne.jp もう 1 つは、今年の頭に読み終えた A Philosophy of Software Design から。この本では、複雑さを減らすために API の仕様が限りなくシンプルで、多くの機能を提供する deep module を目指すべき、といったことが言及されている。 Go ではドキュメントシステムとして GoDoc が提供されているため、上記のような洗練された正確なインターフェースを記述するためにこれを開発時に利用している。 ロー

Visual Studio Codeが、Webページやアプリのフロントエンド開発用ビジュアルツールになる機能拡張「Gimli」がリリース予定なので紹介します。 CSS GridやFlexboxの実装が単純化されるビジュアルツールで、React、VueJS、Angularなど、さまざまなフレームワークやライブラリもサポートされています。 Gimli Gimliはフロントエンド開発者を対象にしたVisual Studio Codeの機能拡張です。多くのビジュアルツールがリリースされており、それらは「コード無し」を売りにしていますが、Gimliは「コード有り」を特徴にしています。 Visual Studioのコード開発環境とビジュアルツールの融合です。 Gimliのデモ Gimliは複雑なレイアウトを作成するプロセスを非常に単純化するビジュアルツールが用意されています。もちろん、CSS Grid

noteの記事ページがリニューアルしてパワーアップしました。記事の読み込み、描画が格段に高速化されています。 noteのフロントエンドはAngular.jsの1系で運用されてきましたが、実行効率が悪く表示速度が遅いという問題がありました（特に古いスマホで顕著）。問題を根本解決するためにNuxt.jsへの移行を進めていました（詳しい経緯は以下の記事をごらんください）。 今年から、おすすめページ、マガジンページ、コンテスト一覧ページなど部分的にNuxt版に置き換えていきました。nodejsやNuxt.jsサーバーの運用が初めてだったので一気に置き換えるのではなく少しづつリリースして様子を見ながら進めました。 運用を2ヶ月ほどしてみて、インフラ面、実装面で問題なさそうなことが確認できたため、noteのトラフィックの多くを占める記事ページ（このページがまさにそうですね）のNuxt.js版リリースを

何かのサービスを改修するときには、まず最初に「速度の改善」をオススメしている。 たとえば表示速度の向上、データ転送速度の向上、ロード時間の短縮、アニメーション時間の短縮、カスタマーサポートのレスポンスタイム etc, etc… これらのスピードスペックを単純にあげるだけで、かなりの打率でコンバージョンや売り上げなどが向上する。「グロースに銀の弾丸（万能の解決方法）は存在しない」とはよく言われるが、速度改善はその唯一の例外だと思う。GoogleもAmazonも、スピードとECの相関関係は様々なところで謳っている。 1秒の表示遅延で、コンバージョンレートが最大20%悪化する from Google Think肌感覚としては、変なCMをうったり、新機能を追加するよりも、まず色々なものをスピーディにするのが一番効率がよい。 noteでも、表示スピードを重要視している。CTOのこんぴゅさん主導で、n