valid,invalid

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

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

Desktop Electron

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 使い始めた

Desktop Electron

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) の違い

Apple

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 Design

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 周りでよくある…）

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

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

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

Design Product

昨日参加した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 の追加

SPA サービスサミット #1 参加した

イベント

SPAサービスサミットとは

ホットスタートアップ、グッドパッチ、ピースオブケイク3社主催のイベント。 http://peraichi.connpass.com/event/42288/

3社のプロダクト（ペライチ、Prott、note）はいずれも知っているものだったのでその裏側の開発話などを聞ければと思って参加した。

React / Angular2 のような目新しいトレンドっぽい話はなく、Backbone.js や Angular.js、jQuery からの移行、CoffeeScript の負債化など、わりと泥臭い話・苦労話が多かった。弊社も Backbone.js から React.js への過渡期なので共感できる面は多い、というか大体同じような悩みがどこにでもあると再認識。

所感

SPA にすべき理由

ペライチや Prott のような、ユーザーの入力が多い、かつ直感的な操作を有するツール系のアプリでの使用例はわりとかっちりハマるというか理にかなっている。一方、読み物中心の静的に近いサイトではほぼ必要ない。

Quipper ではユーザーが触るアプリケーションはほぼ全て SPA。もちろんリッチな画面の実現による UI / UX 向上も目的にはあるが、SPA たる最も大きな理由を聞かれたらマーケットである新興諸国（フィリピン、インドネシア）の貧弱なネットワーク環境への対抗策と答える。

API を共有することにより iOS / Android とともに開発効率を上げる効果もある。

Isomorphic

Google のクローラが Ajax を使ったアプリケーションもちゃんと考慮するようになったと随分前に発表があったが実際の効果を見たところダメっぽく、やっぱり Server Side Rendering が必要なシーンはあるらしい。それが以前なら難しかったが、2016年時点では Server Side rendering は決してチャレンジングではなく現実味のある選択とのこと。

個人的にはまったく必要性に駆られていないのでまだまだ手を付ける気はしてない。（読み物中心の note のようなアプリケーションではもちろん必須）

Browser Support

SPA と直接関係ないが、どこまでサポートするかという話もあったが、ペライチは Chrome のみ、Prott もユーザーにクリエイター系が多いのでモダンブラウザのみというのに驚いた。（IE でアクセスすると Chrome download リンクを表示しているらしい。これは Quipper のプロダクトでもやっている）

Quipper のプロダクトを使うユーザーの中でも特に日本の学校は IE のシェアが高く決して無視できない。Pull Request の review の段階で Windows + IE での挙動を確認することもあるし、過去の経験から「このメソッドは IE で動かないよ」みたいな指摘もあったりする。そうした review やテストは存在するが、自動テストでは検出できない領域があるのがクライアントサイドと知っているので、リリース前には人力での IE テストも苦しみながらやっている。

それに比べて、「Chrome にしてね」でしてくれるユーザーが集まる優しいインターネットがあるとは…。

CoffeeScript

ES2015 以降、CoffeeScript が負債というのが共通認識になっていると思った。本体が Active でないだけでなく言語を取り巻く様々なものが相対的に劣化して見えるという不安を多くの人が抱いていた。

登壇者の話だと「ES Lint に比べて CoffeeLint は全然いけてない。そのぶん人間が review でカバーしなければならず、結果的に生産性を落とすことになる」というのも興味深かった。

フロント専業

他社の話を聞くと結構な割合で、フロントエンド（web）・サーバサイドのエンジニアが分業している開発スタイルを採用しているようだが、そんなにフロントエンドエンジニアを採用できるのだろうか…とふと疑問に思った。

弊社も以下のような求人を Wantedly に掲載しているが、フロントエンドエンジニアの募集は応募者数 / PV 比率が圧倒的に低い。PV はそこそこあるので関心は集めていそうだが応募が少ない。

英語を身に着けたいサーバーサイドエンジニア募集 - Web Engineer jobs at Quipper Ltd - Wantedly

（教育☓グローバル）フロントエンドが得意なweb developer募集！ - Engineer / Programmer jobs at Quipper Ltd - Wantedly

この謎を解いて採用につなげたい。（仮説はある）

その他

知らなかった技術要素など。

  • Aurora DB

    MySQL 5.6 と互換性を持ち、かつ MySQL の5倍のスループットを発揮する Amazon のデータベース・サービス。note のバックエンドで使っているらしい。寡聞にして知らなかったのだが、流行って無いのだろうか？

    https://aws.amazon.com/jp/rds/aurora/details/

  • Side CI

    GitHub と連携可能な静的解析ツール。セキュリティ issue や Lint 的な観点から、指摘を Pull Request に自動的にコメントしてくれる。ペライチで使っているらしい。

    https://sideci.com/ja