このスライドは令和元年5 月18日に東京で開催された Inside Frontend #3で発表した資料に簡単な説明を追加したものです。 フィーチャーフォンからデスクトップまですべてのデバイスで動くマインスイーパークローン(proxx.app)を作った経緯と開発の過程を発表しました。 なにか質問があればTwitterで@kosamriまでどうぞ。 スライドのライセンスはCC BY-NC-SA 2.0です。資料等でレファレンスとして使われる際は教えてくれると(本人が)喜びます😊
フロントエンドチームのSET(Software Engineer in Test)の @urahiroshi です。 メルカリのフロントエンドチームは、JavaScriptを中心とした技術を用いてメルカリのWebサイトやアプリ内WebViewの開発を行っています。 私はチーム内のSETとして、開発環境の構築やトラブルシューティング、CI・運用ツールの導入やビルド・デプロイ処理の修正などを主に行っているのですが、今回は私たちが利用しているCircleCIの設定についてご紹介したいと思います。 CircleCIでは以下のようなタスクを実行しています。 Lint ユニットテスト ビルド・デプロイ Storybookのデプロイ npmパッケージのpublish 脆弱性検知 各タスクの詳細について、順に記述していきます。 1. Lint コードに対してLintツールを走らせます。 最近のプロジェクト
BFF(Backends For Frontends)超入門――Netflix、Twitter、リクルートテクノロジーズが採用する理由:マイクロサービス/API時代のフロントエンド開発(1)(1/2 ページ) マイクロサービス/API時代のフロントエンド開発に求められる技術の1つBackends For Frontends(BFF)について解説する連載。初回は「超入門」としてBFFの概要や事例を中心に紹介する。 本連載「マイクロサービス/API時代のフロントエンド開発」では、今注目のBackends For Frontends(BFF)について数回にわたって解説します。初回である今回は「超入門」としてBFFの概要や事例を中心に紹介します。第2回はBFFの作り方について、第3回はBFFを使ったフロントエンド開発者主導のマイクロサービス/API化の手順について解説します。 想定読者は、Webア
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか? react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
色々なパフォーマンス指標のこと 何かを評価するときには何らかの指標(メトリクス)を定めますが、何を指標として設定してどのように測るかというのは重要です。 いわゆる KPI もそうですが、扱っている商材やビジネスのステージ(フェーズ)によっても適切な指標は変わるかもしれません。色々な指標をよく理解して引き出しを広げておくことは、状況に合わせて適切な指標を選んで改善していく過程で役立ちます。 これまでのパフォーマンス指標 過去の Web パフォーマンス界隈はバックエンドから HTML ドキュメントを返却する際の所要時間や、Web ページロード時の各イベントの発火時間を計測する方法が多く見られました。 Backend Time Browser Event Based DOMContentLoaded Page load ( onload ) 近年は特に後者の、既定のイベント発火に依存していたクラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く