valid,invalid

関心を持てる事柄について

npm run eject で create-react-app はアプリケーションの長寿を保証する

create-react-app すごい。React アプリを開発する環境構築が圧倒的に楽になった。

開発も素早く始められて build も一瞬で出来るように用意されている。Rails なんかもこうやって参入障壁を下げていくことで広まったのかなと思う。

npm run eject

まだ始めてみたばかりで諸々見ている最中なのだが、用意されている npm コマンドの中に一つだけよくわからない npm run eject というのがあったので調べた。

TL;DR

npm run ejectcreate-react-app の裏側で react-script を介して使われている諸々のツール・スクリプトをコピーしたり、依存関係を package.json に書き込んだりして、自分で用意したのと同じ状態にするコマンド。実行以降、好きにカスタマイズし放題となる。

これがいつでも出来るのでロックインを回避できる、create-react-app が死んでもアプリケーション側で自前でこれらのツールを制御することが出来る。

つまり、create-react-app はこのツールよりも、アプリケーションの方が長いライフサイクルを持てることを保証するということ。

多くのユーザーから使われるツールになるためにここまで考えているのは純粋に凄いと思う。

公式

You can “eject” to a custom setup at any time. Run a single command, and all the configuration and build dependencies will be moved directly into your project, so you can pick up right where you left off. https://github.com/facebookincubator/create-react-app#philosophy

"カスタマイズ用にいつでも「取り出す (eject) 」ことができる。 単一のコマンド ( npm run eject ) を実行するだけで、すべての構成とビルドの依存関係がプロジェクトに直接移動されるため、中断した箇所からすぐに再開できる。"

If you’re a power user and you aren’t happy with the default configuration, you can “eject” from the tool and use it as a boilerplate generator.

Running npm run eject copies all the configuration files and the transitive dependencies (Webpack, Babel, ESLint, etc) right into your project so you have full control over them. Commands like npm start and npm run build will still work, but they will point to the copied scripts so you can tweak them. At this point, you’re on your own.

Note: this is a one-way operation. Once you eject, you can’t go back!

You don’t have to ever use eject. The curated feature set is suitable for small and middle deployments, and you shouldn’t feel obligated to use this feature. https://github.com/facebookincubator/create-react-app#converting-to-a-custom-setup

"もし「パワーユーザー」としてデフォルト設定に満足できない場合は、ツールから「取り出し」てボイラープレートジェネレータとして使用できる。

npm run eject を実行すると、すべての設定ファイルと依存関係(Webpack、Babel、ESLint etc.)がプロジェクトに完全にコピーされるので、完全に制御できます。npm startnpm run build のようなコマンドは引き続き動作する。これらはコピーされたスクリプトなのでカスタマイズが可能になる。

注: これは片方向操作であり、 いったん eject したらもう戻れない!

eject を使用する必要はない。キュレーションされた機能セットは、小規模から中規模の開発に適しており、この機能 (eject) を使用する必要はない。 "

npm run eject 試す

実際に何が起きるか試してみる。

$ create-react-app hello
$ cd hello
$ npm run eject # and answer `y`

実行前後の Diff

長いので特に解説しないが、特に pakage.json を見ることで使われているツールが見て取れる。

gist.github.com

GitHub Issue Reader の Jasper を1週間使っての所感

Jasper 使い始めた - valid,invalid で書いたとおり、GitHub の通知管理を Gmail から Jasper へ乗り換えてみた。

一週間使っての所感とかメモ。

所感

  • 初日は Gmail と Jasper を両方見て両方の未読を消化したくなってしまった
    • が、数日で Gmail のほうの通知は見なくなった
    • というのもフィルタリングのカスタマイズ性が Jasper の方が高いので、これまで Gmail ではできなかったラベリング(Jasper でいう Stream)ができるようになりそれ抜きでは辛くなってきたため
  • 自分のアクティビティも通知されてドキッとする
    • GitHub のメール通知では Include your own updates をオフにしている
  • GitHub のメール通知(コメント単位)よりもアクティビティの粒度が細かい(Assignee や Label の変更も含まれる)
    • たまに通知を開くと何も起きていない?と思ったりするのでここを改善したい
  • built in browser 含む3カラムをフル画面で表示している
  • 各 issue / PR といったアイテムを開くのが遅い
    • built in browser にしろその他のブラウザにしろ、毎回ページをロードするので Gmail でメールを開封していくのよりはどうしても遅くなってしまう
  • unread のアクティビティにスクロールしてくれ、かつ未読のコメントに付けてくれるのでどこまで読んだか / どこから読めばよいかが圧倒的にわかりやすい
  • 覚えることは多くないので公式ドキュメントはあまり見ていない(良いことだと思う)
    • team へのメンションを mention:username/teamname のように書いていて通知されないなーと思った時だけ見た( team:username/teamnase が正しかった)

改善要望

  • Include your own updates をオフにしたい
  • 通知するアクティビティを絞りこめるようにしたい
  • 開封をより高速に行える
  • [minor] クラウドで同期?今のところ必要ない

うまいやり方があれば教えて欲しいです。


「Jasper か Slack を見ておけば通知を見逃すことはない」というところまであっさり近づけたので、(無料のクーポンで手に入れたものの)有料で買っても良かったと思う。

Jasper 使い始めた

Node 学園祭2016 で 100% OFF のクーポンコードをもらったので Jasper 使い始めてみた。

jasperapp.io

これまで

Gmail の Fileter / Label 機能で頑張ってきた。

各種サービスからの通知や Google Calendar の invitation など、GitHub の notification 以外から受け取るメールも大量にあるので「Gmail か Slack を見ておけば通知を見逃すことはない」という状況を作り、スイッチングコストを下げてきた。

上記の理由により確認すべきプラットフォームが増えるのは正直よくないことなのだが、よりリッチな通知管理が無料で出来るならと思って試してみる。

GitHub から来る通知以外でそれほど緊急度の高いメールを受け取る機会もほぼないので、純粋に「Jasper か Slack を見ておけば通知を見逃すことはない」ということになってほしい。

Jasper について

少し触ってみたところ、かなりサクサク動く。また、わかってはいたが Gmail よりも見やすいし、より細かい設定もできる。デスクトップアプリ作りたくなってくる…。

技術的なところで言うと

という話を聞いてなるほど〜と思っていたが blog にも詳しく書いてあった。

blog.h13i32maru.jp


今日のところはセットアップだけ、明日からどう通知管理が変わるだろうか。

Apple Pay Purchases と In-App Purchases (IAP) の違い

www.mobomo.com

In-App purchases (IAP)

In-App purchases は iOSバイスや PC にて追加コンテンツの購入やサブスクリプションの購読を行える仕組み。全てのアプリがこの機能を提供しているわけではないが、いくつかのアプリでは多くの機能を開放する鍵やゲーム内における強力な武器といった追加コンテンツを購入できる。

Apple Pay purchases (APP ... とは流石に略さなさそう)

Apple Pay puchases は携帯による決済とお財布ケータイを可能にするサービス。iPhone6 や 6 Plus, Apple Watch といったiOSバイスと決済機関との間のセキュアなトランザクションを実現する。これにより財布無しで、アプリをタッチするだけで実店舗での買い物が可能になる。

その他

  • In-App purchases は仮想的(バーチャル)な商品を買う手段、 Apple Pay purchases は物理的な商品やサービスを買う手段。
  • Develper API も異なる。
  • In-App purchases は手数料30%、 Apple Pay purchases は FREE! (クレカ手数料はかかる)

目的が違うので使い分けましょう、とのこと。

BEM と MindBEMding

CSS 周りで何が起きているかどころか、これまでにどういうパラダイムがあったのかもわかっていないので、昨日初めて BEM という方法論を知った。

BEM

Key concepts / Methodology / BEM

DOM 内の要素とその固まり(コンポーネント)をブロック(Block)、エレメント(Element)、モディファイア(Modifier)に分類して整理するテクニック。ロシア最大の検索・ポータルサイトを提供しているYandexで培われた。

MindBEMding

MindBEMding – getting your head ’round BEM syntax – CSS Wizardry – CSS, OOCSS, front-end architecture, performance and more, by Harry Roberts

CSS のクラス名に BEM を適用するために作られた規則。各要素に以下のようなクラス名を与える。

block
block__element
block--modifier
block__element--modifier
block--modifier__element

この表現たしかに幾つかのライブラリで見たことあって、typo かと思っていたが違っていた。(こういうのを見つけた時や困った時にどういう用語で調べればよいのかわからない…という体験が個人的に CSS 周りでよくある…)

慣れると開発者間、デザイナー間でその要素の役割が瞬時にわかる(らしい)。シングルクラスによるマークアップも実現しやすい(らしい)。


なんかどちらも名前、発音(ベム、マインドベムディング)が馴染みにくい気がする。自分とロシア人のセンスがかけ離れているからだろうか?

どんなによく考えられたデザインもユーザに届くまでは仮説にすぎない

昨日参加したFront Line of Frontend − Forkwell Meetup #2 - valid,invalidで一番印象に残っているのは何だろう…とぼんやり思い返してみたところ、以下の言葉が浮かんできた。

"どんなによく考えられたデザインもユーザに届くまでは仮説にすぎない"

NHN テコラスの方による UX プロジェクトファシリテーションという題の Lightning Talk で語っていたことだ。

UX プロジェクトファシリテーション

発表のスライドは見つけられなかったけど、話されていた内容の一部は 消費者視点から考えるプロジェクトファシリテーション「消費者ファースト思考」|おかいもの研究室 に書いてあることだったと思う。

上記の言葉は、「プロダクトの提供者が想像する消費者と実際の消費者には必ずギャップが存在する、だからこそプロダクト関係者全員がそれに自覚的になり、ギャップを埋める努力(ユーザーテスト etc.)をしていかないといけない」という文脈で語られていた。なのでデザインというのは必ずしも見た目に限った話ではなくプロダクトの設計を指していると思う。

Web サービス経験の浅そうなコンサルタントが要件定義フェーズで Excel に書いた画面も、生態心理学に精通した UX デザイナーによるプロトタイプもユーザーの目の前に出るまでは有効な仮説として同時に存在しうる。(重ね合わせの原理みたいだが...現実的には当然確度の高い方を選択する)

ユーザーに届けてわかること

プロダクトが世に出るまでのスパンが長くなってしまうと、どの案がよいかと議論したり、やっぱりこっちが良いと主張が変わったりしやすい。ひどい時には決め方を決める議論に時間を費やしたりしてしまう。

そうした議論を通してベストを尽くそうとしているのはみんな同じなのでそれ自体は悪くないのだが、結局机上の空論になるのならやっぱり出してみないと何が正しいかは誰にも確信はない。だからユーザーに出してみる。ユーザーは殆どの場合において答えを教えてはくれない、というか持っていない。プロダクトおよびその一部が好きか嫌いか、良い方向に向かっているのかその逆か、なら教えてくれる。

届け方

「じゃあ、出してみましょう」と出すときにも必ずしも本番環境にデプロイする必要はない。プロトタイプを見せるユーザーインタビューを実施するとか、数%のユーザーにだけリリースするとか。A/B テストもデプロイ抜きで行えるツールがある。もしこうした仮説検証の仕組みが無いのなら創ってみる。

どんなによく考えられたデザインもユーザに届くまでは仮説にすぎないのだから。

.

.

.

.

.

.

.

.


(まだまだ一部しか実践できていないので、ここまでをもっと声高に述べられるようなプロダクト開発をしていきたい)

Front Line of Frontend − Forkwell Meetup #2

Forkwell 社主催の Front Line of Frontend − Forkwell Meetup #2 に参加した。

web フロントエンドが広域化していく中で"フロントエンド"という言葉に複数の意味が混在しているのがややこしい、というような雑談を前に banyan さんとした。曰く、主に2つの役割がある。

  1. HTML (含 テンプレートエンジン) や CSS (含 SCSS etc.) を中心としたマークアップを得意とするエンジニア (クライアントサイドのデザイン担当)
  2. jQuery に始まり Angular, Backbone, React など一連の JavaScript フレームワーク、エコシステム、ビルド環境などに精通したエンジニア (クライアントサイドのロジック担当)

自分はフロントエンドも多少触るが業務内容はほぼ後者なので、前者に寄った内容が多かった今回のイベントは結構新鮮で面白かった。

特に CSS の複雑さの解消方法やテスト手法、またはデザイン手法周り。これらは Quipper では designer と web engineer の隙間で埋まりきっていないところなのでまだ改善の余地がありそう。

懇親会では以前に Quipper の Meetup に来てくださった方と再会したりした。


メモ

発表を聞きながら取ったメモ。

トーク① 「スタイルシートの長い夢」 GMOペパボ @shikakun

  • カラーミーショップ
  • CSS の複雑さ 優先度を決める
    • ID, class, 重複, selector の合計, !important, reset
  • 普通に書いていれば !important は要らない。class セレクタをちゃんと使う
  • CSS にスコープがない、グローバルに定義しすぎている
    • 2万行の common.css

戦い方

  • global をリセットする reset_common.css を読み込む
  • BEM MindBEMding 名前の規約によって部品がわかる
  • frocss

CSS は何故増える?

  • 消せないから
    • 消したときの影響がわからない
    • 消せなくてもエラーが出ない
  • 2週間延々と消す期間を設けて一個一個消していった

  • Enduring CSS 消せる CSS にする

    • ページと対応するディレクトリを切ることで scope がわかる

整理するために

  • スタイルシートの先頭にドキュメント書いてパースしたり
  • sample page を作る
  • hologram / pepagram

  • gulp で vendor prefix は auto でつける

  • stylelint

  • ...というのは全て夢で、まだ何も手を付けてない

  • CSS Architecture は3年前に提唱されている

トーク② 「フロントエンド最前線に流されないAtomic Designという考え方」 サイバーエージェント @79yuuki

  • 最近複雑化しすぎているフロントエンド
  • まずウェブ標準に立ち返ってみよう、HTML, CSS, JS
  • W3C による Web Components
    • まだ実用的じゃない
    • Google が攻めてる Polymer もあるが実装が複雑
  • Bootstrap -> Material Design -> Atomic Design

Atomic Design

  • style guide に atom / molecules の一覧を作る
  • codepen みたいに見た目を確認しながら作れるようにしている

やるべき理由

  • スコープが良い
  • 仕事がし易い
  • これは Web の話ではなくデザインのスタンダードになる話

    • ツールを選ばない
  • Riot.js は良い

    • HTML ぽく実装できるので Web Components を体験できる
    • マークアップはわかるけど JS はちょっと…という人にオススメ
  • 色んなフレームワークが Web Components の考え方を採用してきている

トーク③「ビジュアルCSSスティング(仮)」 Forkwell @ringogirl

  • forkwell は5年続いているサービス、それなりに CSS の負債ある

戦い方

  • スタイルガイドを作っている http://styleguide.forkwell.com/

    • 機能とべったりなコードを防ぐためにアプリから切り離す
    • npm で管理
  • が、テストがない、見た目もテストしたい

    • 目視確認
      • 画面の状態が多い意図分岐の確認に時間がかかる
      • 再現性
    • E2E
      • 画面の崩れを完璧には防げない

visual css testing

今は Eyecatch

  • スタイルガイドのコンポーネントごとに Eyecatch でテストができる
    • JS を動かしてのテストもできる(React component に対してもできる)
  • 自前でスクショ撮る機能を作らなくてよい
  • 共通レイアウト部分に変更があるとまとめてくれる(ロゴとか)

  • ただしブラウザの種類が一つなので、クロスブラウザテストしたかったら BrowserStack が必要

  • まだ beta、これからどうなるかわからない

課題

  • アプリ側で入れたい
  • ランダムなデータだと差分が結構出てしまうのでテストデータ整備が必要

まとめ

  • CSS のテストはむずかしいがそれなりにツールが有る
  • 使っていきましょう

トーク④「Web ブラウザで DRMサイバーエージェント @ygoto3_

プロフェッショナルなコンテンツとは

  • それで生計を立てないといけない
  • 映画のウィンドウコントロール
    • 劇場公開 -> DVD -> BS/CS -> 地上波 (インターネットもココに入っていく)
  • コンテンツ保護しないといけない

コンテンツ保護

  • 保護のランクがある
    • ノーガード
    • ユーザー認証 コンテンツを配布するような悪意あるユーザーは防げない
    • コンテンツ暗号化 コンテンツを配布されても閲覧不可
    • DRM (Degital Rights Management)
      • ハリウッドからはより厳しい管理要望がある
      • 手法は幾つかある

web でできる DRM

できること

  • コピーは出来るが特定な環境に制限
  • 有効期限を設ける

仕組み

  • エンコードする時にライセンスサーバーと協同してパッケージングする
  • CDN に置く
  • クライアントがダウンロードする
  • クライアントは再生できない、ライセンスサーバに問い合わせ、OKなユーザーなら初めて鍵を渡して閲覧できるようにする

  • ただし web ブラウザごとに異なる鍵システム

  • 動画の数と組み合わせて膨大な量になってしまう

Common Encryption

  • Encrypted Media Extentsions ... HTMLMediaElement を拡張してコンテンツを保護する JavaScript API

  • Content Decryption Module ... 複合アルゴリズム。複数のブラウザで共通化された API を利用できる

  • どんな暗号もいつか破られるので、暗号を差し替えることができるようにする

  • ブラウザはコンテンツのメタデータから暗号化されていることを知る

LT フロントエンド開発のチームビルディング

  • 結論、エンジニア同士がディスカッションする機会を増やす
  • 他社の考え方やナレッジを取り込める
  • 習慣的にやることで自律的なチームになる
  • マネージャーは具体的な How to を提示するんじゃなくてチームが自立成長するために仕掛ける
  • トップダウンで完全にコントロールするのでもある程度は回るだろうが、スケールしない
    • 経験上7人が限界

Phenonic

  • https://phenomic.io/
  • static website generator
  • template / contents -> compile build -> website
  • React / Webpacck が使われている
    • issue / pull request 見ていても参考になる

UX プロジェクトファシリテーション

  • UX プランナー おかいもの研究室
  • 消費者行動の調査、発表、セミナー
  • ユーザテストのない UX は UX ではない

    • どんなによく考えられたデザインもユーザに届くまでは仮説にすぎない
  • ユーザーテストはプロジェクト共感ツール

  • ユーザーテストはには可能性がある、UX プロジェクトファシリテーションはその一手法

トーク⑤ 「フロントエンドのパラダイムシフトとプロダクトの成長」freee @joe_re

  • 2012 -> 2016
    • bower -> npm, coffee -> esnext, backbone -> react / redux
  • sprockets 捨てるか

    • webpack などのアセットバンドラーで何とかなる
    • require は js を concat してくれるだけなので順番守らないといけないのはいけてない
    • 使い続けてはモジュール化された ESNext の世界に到達できない
  • 今はビルド結果を app/assets に出力して最終的には Sprockets を通している

    • 既存のデプロイフローは変えなくても良い
  • 捨てるには

    • Rails に依存しているビルドを取り除く
    • webpack でフィンガープリント

課題

振り返り

  • 2012年から Backbone、SPA ではなかった
  • 給与計算 freee は Vue.js と使用した完全 SPA としてローンチ
  • とはいえ VM 、状態管理は辛いし、Object.observe も死にました

React

  • 既存実装 (Backbone.js) があるところに導入するのはつらい
  • 初めは共存させたが、途切れ途切れの view、single store はどこに置く
  • flux-utils を使った

    • 既存の flux から乖離せずに済んだ
  • redux でないのは当時使用例が少なくてスケールしていくかわからなかった

天秤

  • プロダクトの置かれている問題を果たして解決するのか?を考える

人類共通コンポーネント

  • 複数プロダクトを抱えているのでそれらの間でコンポーネントを再利用していきたい
  • 再利用する上で
    • トランスパイルに必要なツールのバージョンは要求しない
    • スタイルは再利用したい
  • CSS Loader でスタイルもコンポーネント化していく
    • そのために DOM に規約を持たせる

開発体制

  • 60人のエンジニア
  • web エンジニアはフロント・サーバサイド両方やる

パネルディスカッション − Front Line of Frontend − freee @ymrl, Goodpatch @yoshiko_pg

どのフロントエンドの人?

  • ymrl: API からこっち側いろいろやる。欲しい JSON を作って UI 作り、CSS も書く。チームは5人で1サービスを担当している。フロントエンドだけ、だと狭すぎる
  • yoshiko: CSS も書いてるが業務だとほぼ JS の人。prott チームはエンジニア10人、biz 含めて30人

最前線での戦い方

技術の選定基準

  • ymrl: あまりはっきりしていない。過去にはっきりあったのは"辛くなったから"。それ以外は突然カッとなって入れたらり。この前は immutable.js しれッと入れた。事前に根回し的なことをやっても結構反対はあるので自分で面倒見る気持ちで(辛くなったら外す、入れるのは自分で外すのも自分)。
  • yoshiko: 情報量、エコシステム、チームのスキル。あと web 標準に沿っているか?も最近考える。CoffeeScript を使っていたが ES2016 のビルド環境を整えて、新機能はそちらで書くようにした。

レガシーからの移行

  • ymrl: ライブラリとかコードの負債についてはなるべく影響の範囲を小さくできないか考えつつ。SPA は一度やるとやめるのが大変になる。コツコツやって一周したら最初のところが古くなる。メジャーバージョンアップやフレームワークレベルのでかい改修はガーッとやるしかない。祭り。レビューは大変なので機能AはAさん、BはBさんが見るというチェックリストを作って見てもらう。
  • yoshiko: ガッと置き換えて動かないところは直していた。ES への置き換えは ES Lint 使いつつ。

反対意見があったらどうする?

  • ymrl: 反対意見というか、よくわからないので特に意見ない、というのが多い。過激派が声張って主張していくことでチーム内に空気ができていく。
  • yoshiko: うちはあんまり反対意見なくて好きにやらせてくれる環境。元々はいちいち許可を取っていたが、その権限を移譲されてテックリードになった。

最前線の一歩先

次に注目していく技術など

  • ymrl: 標準は見ていく。型、flowtype は入れたりしている。自分で各コードにはアノテーション付けている。同じメソッドなのに違う型返すみたいな事故を防げる。皆がちゃんとやるようになるまでは継続的に見ていく、型警察ほどではないがレビューでチラッと書いてほしいと言ってみたり。
  • yoshiko: プロットの目線で言うと service worker でオフラインでも色々動くようにしたい。モバイルのプログレッシブなどもあるが、PC がサービスにマッチするので入れてみたい。electron など、web を持っていく話もあるが、デバッグが難しいので辛そう。

10年後のフロントエンド

  • 人間が接するところ全てがフロントエンドなので色々追いかけるか。端末の多様化。それに伴う API の追加