雑な感想とメモ【Meguro.es #10 @ ラクスル】@20170615

TODO

  • リンクを適切にはる
  • 感想を書く
  • 体裁を整える

Meguro.es #10に参加してきたので感想とメモを雑に共有する。

感想

  • vueの盛り上がり
  • Reactは難しい？

まとめ

meguroes

10回目らしい

Raksul

  • 仕組みを変えれば世界はもっと良くなる
  • ただの印刷会社じゃない
  • Rubyを中心としたmicroservice化
  • 業界を変えていきたい
  • 60人のメンバー
  • 速い安い

ServiceWorkerを使ったtypescript開発考察@brn0227

ブルーノさん

what is ServiceWorker

es6 Modulesを使うには

typescript Compiler(この発表では、以下、僕には難しすぎてあまりまとまっていない。)

コンパイルの流れ

ServiceWorkerとMain threadの流れを追う（スライド中に図が有り）

Problem

ES6 Modulesに対応していないModuleは動作しない

GitHub

https://github.com/brn/swts.git npm moduleも公開済み

まとめ

ServiceWorkerでbabel、typescriptはめんどい

Contextual ThisType and Vue.js@katashin

vueの中の人？

*スライド中のコードは全てTypeScript

メソッド中のthisの型は"any"担っている Vueのコンポーネントの中のメソッドなどでthisを対応するため

ThisType

Contextual ThisType vuejs/vue #5887 今までは型を導入し易いラッパーを用意するのが一般的だったがThisTypeを使うと楽になった

react-boilerplate@さっちゃんさん

  • 普段はサーバサイド
  • Reactの入れ方 → めんどくさい

react boilerplate

git clone https://github.com/react-boilerplate/react-boilerplate

npm run generate

色々作ってくれる

reselect

Control.Lens(Haskellのもの?) Haskell勉強しようよ

react-boilerplateは趣味でやるにはちょうどいい！

Source Map Revision 3の仕様概要@rchaser53

SORABITO ※独自調査なので指摘をしてほしい

規格(リンク)

  • 7ページなのですぐ読める

interfaceと概要

sourceRootとsources

  • sourcesContent
    • 変換前のソース
    • ts=>JSであればTS
  • name
    • 変換後のファイルに単語がはいれつとして保存される
  • mappings

inline sourcemap

ファイルに直接sourcemapの情報を書き込む ファイルが重くなる

X-Sourcemap

sourcemapのイチをヘッダーで指定する ソースに不要な情報が表示されなくなる

便利なライブラリ集

  • mozilla/source-map
    • sourcemapの作成やsourcemapの関連付け
    • babel,webpack,ugilifyなどが使用可能
  • azu/malti-statge-sourcemap
    • サンプル・コードして優秀

Sentryで始めるJavaScriptエラーのトラッキング@endam

Sentryって？

  • アプリケーションのエラーをリアルタイムで教えてくれるサービス
  • どんな環境で何のエラーがおこったかがわかる
  • OSSとしても公開されている

なぜSentry?

検討したサービス

  • Google Analytics
    • カスタマイズ性に書ける
  • TrackJS
  • Sentry
  • New Relic
    • JSも実はできる

選定基準は3つ

  • コンパイル前のコードの場所がわかる
    • コンパイル後は見てもしょうがない
    • sourcemapに対応
    • new relicは今年の3月に対応
  • 料金
    • Sentryはただ！
  • バージョンを管理したい
    • デグレなども確認したい
    • リリースバージョンの管理

全てを満たすのはSentry

外部連携できるサービスも豊富

まとめ

  • リリースバージョンを含めたエラー管理

vue.js 2系でサービスリニューアル@tsukasa_murashige

Raksulの中の人 デザインテンプレートに関連する機能をVueJSで実装

使用したフレームワーク、ライブラリ

  • vuejs2.2.2

vueJS2系は良くなった

  • 単一ファイルコンポーネントで見通しが良くなった
  • データオブジェクトのネストされた子のプロパティもwatchできる
  • vue-routerのscrollBehaviorで、スクロールイチの管理がしやすくなった
  • axios(VueJSで推奨されている)でAPIのモックデータの開発がしやすくなった

Cloud Functions for Firebaseを始めよう@ovrmrw

ちきさん(Angularのハンズオンでチューターしていたのを見たことが有る！) ng-japanのスタッフ 5月からwebエンジニアになった

firebase/functions-samples

公式で様々な使い方が紹介されているので一部を紹介 firebaseはホスティングができるが、それを克服するためにfunctionsを公式で用意してある https://github.com/firebase/functions-samples

色々できる

  • firebaseにExpressアプリを組み込める？
  • 外部サービスの認証を用いていろいろする
  • SSRを行って返す
  • 不適切な画像を判定してモザイクをかける
  • 外部のサービスで文字列検索してfirebaseで使える
  • firebase認証したら、tripe(決済サービス)のユーザーを自動生成し、紐付ける
  • firebase/friendlychat

デモ

  • Googleの基準でchatで挙げられた不適切な画像にモザイクをかける
  • 入力されたテキストからgoogle cloud languageAPIでpositiveやnegativeを認識し大きさを変える

まとめ

Firebaseともっと遊ぼう。

雑な感想とメモ[WEBエンジニア勉強会 #01(東京都,新橋)]@20170602

WEBエンジニア勉強会 #01(東京都,新橋)に参加してきたので感想とメモを雑に共有する。 僕もLT枠として発表した。 togetterでもまとめられている。

感想

※お前の感想じゃなくてまとめだけ見たいという方はこちら

エンジニアの世代間の違いが現れていて面白かった

この勉強会ではまず、ある程度ベテランのエンジニアさんがたが20~30分の発表をされ、そのあと若手エンジニア勢（自分も含め？）のLTがあった。
ベテラン勢の方はWeb系エンジニアとして働く上で役に立ちそうな知識を話されていて、
若手はエンジニアとして仕事し始めて感じた悩みや楽しいことなどを話していた。
多くの勉強会と違い、新橋で開催されていることや、特定の技術にフォーカスを当てている勉強会ではなかったこともあって、普段とは少し違った雰囲気だったように思う。

ベテラン勢の発表が軒並み刺さりまくった

Web技術の歴史、OAuth2.0、開発環境についてという3つのベテラン勢の発表は忙しい昨今自分だけでは振り返ったり勉強できたりしない分野をしっかりまとめてくださっていて、
自分が気になった時に参照できるようなものになっていて、単体で見ても非常に良いものだった。

発表者 + 数人で打ち上げをした

主催のOSCAさんの声掛けで打ち上げの飲み会を会場の横のビルで行った。
ベテランの方々のSIerでの苦労話などが聞けて面白かったし、
僕がやっているpodcastをOSCAさんが聞いてくださっていて、そのFBなどが得られてよかった。
SIとか受託をしていたほうが技術的には幅が広く多くの経験をつめるという意味で良いのかなぁという気が最近してきている…どうなんだろう。
もっとキャリアの長い人、いろんなキャリアを歩んできた人のエンジニア観を聞きたい。
そういう意味ではこの勉強会はちょうどいい題材を扱っているとも言える。

以下、本編

勉強会の目的

  • Web技術の共有と学習
  • 普段の取り組みの発表
  • Webエンジニアの友達や仲間を作る

近年のWEBの歴史と現状について (@engineer_osca)

自己紹介

趣味

  • 夜景写真家
  • 舞浜在住（ディズニーの三歩が趣味）

主催の目的

  • エンジニアで現役
  • 友達づくり、知識を共有したい
  • 老害トークはしたくない

どこまでがWEB？を話したい

主催として過去ではなく、未来の話をする勉強会にしたいが、今回は歴史の話をする。

Web

ブラウザとサーバがHttpでやり取り

WEB GUI / インターフェース

→ FlashやSilverlightが駆逐されHTMLの時代に

HTML 5.1の話

  • pictureタグ
    • sourceタグを子に持ちmedia属性によって表示の制御が可能
    • スマートフォン対応やレスポンシブ対応がやりやすくなる
  • input type
    • datetime-local
    • week
    • month
      • 日付の入力を受け付けやすくする
      • input typeがHTML5で増えたがまだあまり使われていない？
      • 今後、どのように使えるのか、watchがひつよう

Webブラウザ

  • InternetExplorer
  • Mozilla Firefox
  • Apple Safari
  • Google Chrome
  • Edge
    • ブラウザの凌ぎ合いによる肥大化(誰が使うのかわからないような機能が追加される)
    • ブラウザに本当に必要な機能はなんなのか？
    • Electron
      • Webの知識でデスクトップアプリ
      • ブラウザの仕組みが裏で動いている
      • ブラウザ肥大化の象徴？
    • ブラウザでやるべきこととネイティブでやるべきことの線引をすることがこれからのエンジニアに求められる

クライアントサイド・スクリプト

通信(HTTP、HTTPS)

HTTP/2

  • 通信の高速化
    • ヘッダの圧縮
    • PUSH通信(サーバ側から送るものをスケジューリングできる)
    • HTTPバイプライン
    • Head of Line(HoL)ブロッキング問題の解消
  • HTTPS通信が前提
    • Let’s Encrypt
    • サーバ上で証明書の発行要求を行う
    • 取得できるのはDV証明書
    • 有効期限は3ヶ月だが、コマンドラインで要求可能なのでcronなどで自動更新が可能
    • 流れとしては、GoogleがHTTPSを優遇するということを公表していたり、通信の傍受を防ぐ目的でメジャーになっている
  • 各種サーバーのサポート()

サーバー環境の変化

その他の話題

次回以降の発表候補

OAuth 2.0 をかみくだく (@garbagetown)

認証と認可

  • 認証
    • Authentifcation(AuthN)
    • 誰であるかの証明(運転免許証やパスポートなど)
      • ID/Password
  • 認可
    • Authorization(AuthZ)
    • 何ができるか(鍵や切符など)
      • AccessToken

OAuth2.0が必要となった背景

サービス増加に伴う認証の課題

  • IDなどの文字数の制限がサービスによって違う
  • アカウント争奪戦
  • 文字種の強制 など

サービス連携に伴う認可の課題

ログインの共有、パスワード変更などの問題が有る 近年Finteh界隈ではパスワードをサービスに預けるということをゴリ押ししているため、 金融庁の指摘が入っているなどで話題

それぞれの課題と解決策

  • OAuth 2.0 2012年10月にRFC 6749 こちらでOAuth1.0が正式に廃止

  • 用語がわかりづらい

    • OpenIDなどで使われる用語との差異
    • 世間一般で使われる用語との差異
    • 混乱を招くので注意が必要
    • 現実で起こりうる問題
  • 仕様で定められていない処理が多い
    • クライアントを登録する方法
    • リソースオーナーを認証する方法
    • アクセストークンの内容と検証方法
  • 処理フローが複雑
    • HTTPリダイレクトの連続(OAuth Dance)
    • セキュリティの考慮事項が多い

身近な例Connpass(勉強会サービス)とTwitter(マイクロブログサービス)

  • リソースオーナー
    • エンドユーザー
  • リソースサーバー
  • クライアント
    • 勉強会サービス
  • 認可サーバー

事前準備

クライアント登録手順、リソースオーナーの認証手順は仕様の範囲外こちらはRFC6749を考える前に必要

  • Protocol Flow
    • クライアントクレデンシャル
      • クライアントIDとシークレットで認証
      • クライアントアクセス情報の取得
      • フォロワー情報取得などは可能
    • リソースオーナーパスワードクレデンシャル
      • リソースオーナーの認証情報(パスワード)を渡す
      • クライアントに悪意がある場合、リソースオーナーになりすまして任意の操作を行えてしまう
      • アカウントの乗っ取りが可能なのでサービスが信用出来ないと、エンドユーザーはこのフローを踏んではいけない
    • インプリシット
      • リダイレクト祭り
      • アクセストークンのやり取りの末、勉強会サービスがアクセストークンを入手する
      • アクセストークンがローカルに保存されてしまうため、端末共有時などは要注意
    • 認可コード
      • Webアプリケーションで使われている、一般的にOAuth2.0と呼ばれているもの
      • アクセストークンをローカルに保存されないため、勉強会サービスが攻撃に合わない限り大丈夫

OAuth 認証と OpenID Connect

まとめ

  • 認証と認可をちゃんと理解しよう
  • サービスの増加と連携に伴う認証、認可の課題
  • OAuth2.0は認可のためのものでOAuth認証を使われている

Appendixが資料に挙げられているので参考にする

webエンジニアがスタートダッシュをキメるためのローカル開発環境の勘所 (@nabedge)

ビズリーチの人(リンク)

新橋はいい街

  • 「魚金」(が多い)
  • 「なんくるないさ」（ガード下に有るらしい・ゴーヤチャンプル）
  • 「宇和島」（高いけど珍味が良い・板前さんがいかつい）
  • 「PUBこだま」がおもしろいらしい(アド街ック天国で紹介、90歳のママさん)
  • 「Footers」など

ローカル開発環境を素早く準備する（スタートダッシュは大切）

  • 目的にフォーカスする
  • 炎上した時に助っ人にすぐに仕事に入ってもらえる

Webサービスのコードをどこで、どうやって書くのか？

  • 【レベル0】データセンター建物内にて本番サーバにアクセスしてコードを書く？
    • 古き良き思い出
    • データセンターで寝泊まり
  • 【レベル1】エディタとSCPクライアントによって本番サーバにアップロード
  • 【レベル2】ローカルなサーバXAMP、MAMPで書いて、SCPクライアントで本番サーバにアップロード
  • 【レベル3】検証サーバを立てて、動いたら本番サーバにアップロード
  • 【レベル4】MySQL,Redis,…チーム開発、VCS、CI、で検証サーバと本番サーバを運用

レベル4のローカル開発環境の話

  • ローカル開発環境の要件

    • コードをサクサク書ける
    • 書いたコードが動くことを自分のPCで確認できる
      • コードが動くための バックエンドサーバが必要

  • ミドルウェア群

長大な「ローカル開発環境構築手順書」

  • 長い
    • 抜け漏れ、手順書書き直すの忘れ
    • 他のWebサービスの開発環境とバッティングしてインストールできない(バージョン違いなど)

NOT 手順書、そして仮想OS

OracleVirtualBox or VMWare、Vagrant, Docker

  • ホスト型(ハイパーバイザ型)
    • IPをずらして複数の開発環境の共存によるバッティングを起こさないようにできる
  • コンテナ型
    • 起動速度が軽い

組み合わせでやるのが良い

ローカル開発環境4原則

  • サルでもできるくらいの自動化
  • 誰でも環境を変更して配布可能に
  • 他の開発環境と干渉しない
  • 金の弾丸（富豪的開発）

エンジニアになって2ヶ月経って思うこと (@ak6mcz2)

自分の前の発表だったのでまとめきれなかったorz

大企業でWeb開発はできるか (@renjikari)

  • 通信業界のエンジニア(サーバ寄り)
  • 新卒2年目
  • MSPのベンチャーでアルバイトしてました
  • 好きなこと
    • Infrastructure as Code
    • ISUCON

Web開発の話

  • 業務向けのシステム
    • SIに近い
  • クラウド利用のための契約とかprovisioningとかをポチポチできるようにする

  • 社内の人がクラウドを触る助けをする

  • 内製開発

  • Python + Django

pros , cons

pros

  • スピード感
    • ある意味丸投げ
    • 2月
  • エンジニア間
    • 大企業でもコードが書ける
    • ツールとか言語はなんでも基本OK
    • Gitlab+Jenkins+Slack+Trello

cons

  • POがいない(責任を取りたくない?)
  • Testを書かない
  • レビュー
  • 継続的デプロイができない
    • 商用環境が神聖

ロードマップ（これからしたいこと）

  • フィードバックを貰ってUI改善
  • マルチクラウドも契約から疎通まで
  • テストを書いてほしい

まとめ

  • どうも大企業でもWeb開発はできる

雑な感想とメモ | Geeks Who Drink in Tokyo -Design Renewal Edition-(デザインリニューアルのしくじり特集)@ヌーラボ　20170526

勉強会 サービス開発

Geeks Who Drink in Tokyo -Design Renewal Edition-(デザインリニューアルのしくじり特集)に行ってきたのでその感想と、話を聞きながら書いたメモを共有する。あくまで自分の備忘録として書いているので、抜け漏れ解釈違いなどはあると思う。

感想

※お前の感想じゃなくてまとめだけ見たいという方はこちら

デザイナー、フロントエンドの担当が数字に敏感

両者(フリルさん、ヌーラボさん)でおっしゃっていたが、デザインや導線を決めるときにもっと数字に敏感になったほうがよいということだった。
当たり前のようで忘れがち。
結局感情や直感で決めるにせよ後々の理由付けのため、という意味でも数字は非常に有効。

目的への立ち返り

こちらも両者で述べられていたが、目的を事前に明確にし、事あるごとに立ち返って良くしていこうということだった。
これも忘れがち、というか、仕事してたらそんな余裕が無いことは多々ある。。自戒。

結局はコンバージョンしてくれるユーザーを獲得することが大事

流入元がWEBのユーザーのほうがアプリから入ったユーザーよりも回遊率が高くコンバージョン率も高い、とフリルさんがおっしゃっていた。 検索からの流入を見込んでWEBを強くしたという話だったが、流入の違いによって以下の属性の違いがある。

  • WEBの商品検索から入った人 → その商品を買うためにフリルに出会った
  • 始めからアプリをダウンロードした人→なにかいいものがないか眺めている

という感じで、ハナから目的が違うので、たしかに動きも違いそう。
アプリを使っているユーザーという一括りでみると、わざわざアプリをダウンロードしてくれているという意味でブランディング的にロイヤルユーザーが多いと安直に考えがちだが、流入元を見てユーザーをもっと細かく分析することが今後は大事になってきそう。

見た目はユーザーのリアクションを見て調整できるようにしておく

Backlogのβテスト期間で見た目の調整に継ぐ調整を行っていたという話だった。
この話を聞いて僕が思ったことは、いま自分が作っているものはこんなに簡単に隅々まで調整できないんじゃないか、ということ。
CSSについては全然わからないが、なにか見た目に関わるものを作っている場合は、簡単に調整できるように設計しておくことが必要だと感じた。
ユーザーの意見を反映するには、反映へのハードルを下げられる開発をしておくことが重要。(後にA/Bテストにも使える)

以下、本編

「小さく早く試す」 フリルのリニューアルの舞台裏

株式会社Fablic プロダクトマネージャー / デザイナー 山口 有由希さん フリルの分析、企画

アプリファースト

  • 2014年ベストアプリ
  • 2016年ベストデザインアプリ

フリルWebリニューアルプロジェクトの話

手付かずなWEB
→最適化により流入量の増加を見込める

WEBでは購入の口がなかった
→WEBきっかけのユーザーをもっと増やせる

WEBメンバー

  • 企画・デザインフロントエンド(本人)
  • サーバーサイド * 2

現状分析・調査

  • 検索流入の最大化
    • フリルの現状
    • 3ヶ月で実現可能なKPIの策定
  • 購入動線の最適化
    • 現状フローのCVRを調査

フリルの現状を知る

購入導線の調査する

データ参照元

  • GA
  • Party Track
  • DB →現状の離脱ポイントとConversion Rate(コンバージョン率: CVR)の洗い出し

ECサイトのカートのCVRを調査し、現状のフリルと比較 分析結果から指標を仮置きし試算すると、アプリでしか購入ができないのは、かなり筋が悪いことが発覚

リニューアルの目的 = WEBきっかけで登録・購入するユーザを増やす

検索流入の最大化のために

オーガニックUU目標を設定

購入動線の最適化のために

WEBで完結するように機能追加

やること

  • 拡張しやすい構造にして組み直す
  • 適切なページを増やす
  • 各ページで適切なワードが表示されるようにする
  • 欲しい商品を見つけやすくする

やらないこと

  • 登録・購入までのステップ以外のUIの最適化はやらない
  • その他のアイコンなど、ディテールの最適化

どのようにしたか

  • 検索については、SEOで段階的なリリースによるトライ&エラー
  • 並行して、様々な機能を順にリリースし、最後に購入機能をリリース

WEB登録、購入が可能にするには工数が必要だったので、ちゃんと時間を取った

結果

  • オーガニックUUは3倍
  • 登録ユーザ数は20倍

振り返って、デザイナー視点でもっとやりたいこと

  • 購入に至る経路以外の体験の最適化
    • ユーザーインタビューを重ねて突き詰めたい
  • ディテールへの最適化

今回の目標は達成できた

目標に対してしっかり結果を出す

  • リニューアル時に最初から全てを完璧にやりきるのは時間的にもコスト的にも難しい
  • 結果がついてくればまたチャレンジできる
  • 経営判断を引き出せる
  • 引き続き改善もできる

ゴールに合わせて都度最適な手段を選ぼう!

質問コーナー

  • リニューアルの設計タイミングで定性的な調査をしたか？
    • テストをして問題無いことは確認した
  • WEBとアプリでカスタマージャーニーの違い
    • 違う性質のユーザーが来るという想定
    • WEBは大量の検索からフリルに入る、アプリはフリルを使うと決めている
    • 上記の動機の違いを意識した
  • 登録後のユーザーはWEBでフリルを使うか？
    • 積極的にアプリに流したい
  • 実際に行った施策で狙った目標まで到達したか？
    • 購入導線を改善して、出品者への確認が必要、ECのCVRを超えることはできなかった
  • もともとWEBはあったわけだが、新しく作ったという認識で良いか？
    • 徐々に全部作り変えたので、順次りりーすだが、結果全く違うものになった
    • 新機能だらけ
  • 効果測定、WEBの改善によるアプリへの影響
    • WEBで登録した人をアプリに流す施策を打ったので、アプリのユーザー数も増加した
    • WEBからアプリに入った人のほうが、アプリから入った人よりもよい動きをしてくれる
  • CMなどの影響とWebリニューアルの影響はどう違うのかを判定できたのか
    • CMなどの広告では基本アプリを宣伝するので、今回に限っては分けて考えることができた

Backlog UIリニューアルの舞台裏

株式会社ヌーラボ Webデザイナー 中川 裕二

  • typetalk: チャット
  • cacoo: デザイン
  • backlog: プロジェクト管理

リニューアル

5年ぶり2度目の大規模リニューアル

目的

  • これからの時代にあったデザイン
  • ユーザーがやりたいことに集中できる
  • 新機能などを追加しやすくする

どんな問題があったのか

“課題”(backlogの1つの単位)の詳細についての情報が一番重要だが、周りに情報が多すぎてわかりづらい、分散している

やること

「仕事の中に楽しさを」というBacklogのコンセプトをひきついでかつ、画面をスッキリして、整理

やらないこと

大幅な画面構成の変更

約一年に渡るビッグプロジェクトになったが、開発の後のリリースまでの話をする

リニューアルに当たって事前にケアしたコト

  • リニューアルのストレスを最小限に
    • 大幅な画面構成は変更しない
    • 既存機能の削除はしない
  • ユーザビリティテストをする
    • 自分たち以外の人に使ってもらう
  • β期間を設ける
    • いつでも新旧を切り替えられる

結果

ユーザーから不満の声が大量に…

フィードバックの主な経路

→Typetalｋで議論しBacklogに課題として登録、対応

現実的なすり合わせと対応

  • ダッシュボード
    • タブで切り替えるようにした→3つの情報が俯瞰して見れない
  • コントラスト
    • 今風なものにした→目が疲れる…
  • メリハリ
    • よりスッキリに→コンテンツの境目がわかりにくい

Backlogの課題でやり取りしつつ週次のデザインMTGで議論 - Cacooでのイメージ共有 - デザインカンプ - プロトタイピング - 実装してから暫く使う

コンセプトに立ち返ろう

ダッシュボードのしくじり

  • 大幅な画面構成をしてしまった→戻す

    コントラスト、メリハリのしくじり

  • 見づらい→下地とコンテンツの背景色を逆転させた
  • フォントがぼやけて目が疲れる→フォントの変更
  • wikiで整形後のテキストにメリハリがない→差し色を入れる

ちょっとずつ前のデザインに戻る？生まれてくる葛藤

  • 慣れと使いづらさ →新デザイン + 旧デザインの良さ 溶け込ませる

リニューアルの極意(1): 旧デザインの優れていたところは活かす(featuring)

眩しさの原因を調査

  • 報告のあったディスプレイを買ってまで調査
  • 背景がグレーが真っ白で緑が目に痛い

→ 実際辛い 色という色の調整した

何が悪かったか

ユーザビリティテストは、人はもちろん様々な環境でテストをするべきだった

眩しさの葛藤

  • ディスプレイによって違う
  • どの環境が最もあるべき状態なのかわからない

→眩しさは辛くて仕事にならない、これは一番ダメ P/D/T型 色覚で状態の色が見分けづらくなった リニューアル前程度に見分けられるように再調整

  • 少しずつ濃くしていった
  • 背景や文字色も更に濃く

遠目からの比較

  • 必要な情報にパッと目が行く

リリースしてみて

  • 実際暗さに対する意見はなかった
  • ユーザーからの良いフィードバックがあった

機能は削除せずに画面をすっきりさせてやりたい作業にという目的の達成

リニューアルの極意(2): 三歩進んで二歩下がれ!（ユーザーの皆さんにとってはインパクト大！）

β提供後一ヶ月経過、フィードバック二期を取られて気づかなかった問題が…

新デザイン使ってる人、少なすぎ問題(10%)→このままリリースしたら間違いなく炎上

  • ブログ
  • アプリ内ヘッダーにお知らせ
  • βリリースのお披露目イベント
  • 目立つダイアログ

答えられないと旧デザインに戻れないアンケート

  • 大きな声が上がっていたものを出す
  • どれも主観的なところなので実際どのくらい調整できているかわからないから、だったらユーザーに直接聞いてみた

アンケート結果の分析

  • 旧デザインに戻したユーザーが8%
  • 良いFBを得た→修正

→予定通り切り替えても良さそう

リニューアル後の効果

  • これからの時代にあったデザイン
  • やりたいことに集中できるデザイン
  • さらなる機能追加・改善の余地を作る
  • 嬉しい意見もたくさん

最近はA/Bテストもやっている

こちらが提供したいUIと求められているUIを比較

まとめ

  • コンセプトを持つ
  • ユーザーとコミュニケーションをする
  • 数値の計測と分析をする

質問コーナー

  • β版で出そうな問題を事前に潰すためにはどうすれば良いと、今は思いますか？
    • ちゃんといろんな環境でチェックする
    • ユーザーの多様性を考える
    • ユーザーインタビューの徹底
  • Twitterのエゴサーチは毎日してるの？
    • 日常的に使うアプリのアプリなので、Twitterへの書き込みが多いこともあり、良くしている
    • 社内チャットにエゴサ専用のチャンネルが有る
  • UI改善の契約数への影響
    • 全体的な成長もあるので、確実な情報がない
    • しかし、最近はトライアルが増えていて割合的には正式登録数が減っている
  • 1年にも及ぶリニューアルへの社内の合意を得るために
    • 社内の合意を得ることは全く問題なく、ユーザーの反発を防ぐことに注力した

両者への質問

  • 辛かったこと
    • フリル
      • プロダクトオーナーデビューだったので、結果への要求とデザイン、マークアップに忙殺された
    • Backlog
      • 調整期間で、なにが良いのかわからなくなって、葛藤する
      • 自分の判断の正しさがわからなくなる
      • 自分は何と戦っているのか
  • 開発とデザインはどのように連携していたか、日程調整、QA(Quality Assuarance)的な意味で
    • フリル
      • 密にコミュニケーションを取っていた
    • Backlog
      • スクラムで、デザインは開発の1週間前に始める
  • 予想できなかったアクシデントの印象的なエピソード
    • フリル
    • Backlog
      • ちゃんとしてれば予想できたんじゃないかなーと思ってしまう
      • 毎日Backlogのことを考えていたので、わからなくなってしまった

雑な感想とメモ【まつもとゆきひろ氏特別公演】若手エンジニアの生存戦略 @DRECOM #colab_matz 20170520

勉強会

若手エンジニア()なのでMatzさんの若手エンジニアの生存戦略というサポーターズさんの講演に行ってきた。

※あくまで自分の備忘のためかつ、発表を聞きながらとったメモなので注意。

感想 ミーハーなのでMatzさんを見ただけでテンションが上がった。

ロールモデルを持て、みたいなことをよく言われるけど、確かに人と同じようにキャリアを歩むことは不可能だなという感じ。
で、そうするとパターンが重要ということで、今回はMatzさんのこれまでのキャリアの話を聞くことができたが、もっといろんなパターンを聞きたいなと思った。そういう本とかあるのかな？

言語を作りたい、と言うと怪訝な顔をされるとおっしゃっていたが、エンジニアについて興味を持ってから、Matzさんをずっと知っているし、 職場のもっとも近しい先輩が〇〇言語、と自分の名前を冠した言語を作ったことがあると行ったような話をしてくれていることもあり、意外と僕も力があればして見たいなと思うことだけどな、と思った。

我慢は価値ではない。
という話をしきりにされていたが、残業しているからといってその人が評価されるといったような文化は本当に良くないと思う。
ただ、そういう文化はどんどんなくなってきているんじゃないかなと感じていて(特にIT系の企業やスタートアップについては)、残業という文脈でいうと生活残業であったり、家に帰りたくないから残業する、といったような人がいるのはまた別の問題としてあると思っている。ちゃんとした価値が評価できる環境を作るのはどうしたらよいか、というのが、これからの(これまでも十分議論されているかもしれないが、)主な問題だなと思った。

怠惰が重要という話があったが、意識的にしないといつも忘れるなと思った。
自分がやっている作業をコマンドにしておくとかについてはコードを書くのが楽しくてやる気持ちが強いけれど、他の人に説明するのが面倒でドキュメントを書く、というのは、本当に意識をしないと忘れてしまう。
web系はもっとドキュメントをかけ、みたいなことをt_wadaさんがつい最近言っていたというのをどこかで読んだが、肝に命じなければならない。

僕は転職を進めるようなpodcast(楽しくて仕方がないラジオ)をしている(Matzさんが推奨しているアウトプットだ！)ので、そこでも似たようなことを話しているのだが、理不尽な環境に置かれたら転職を考えるというのは普通にもっと選択肢として上がっていいと思う。
クライアント(時には上司になる)と開発者(自分)は対等でないとダメだし、Win-Winの関係でないと、やる価値がない(No Deal)。この指標は非常にいいな、と思った。(前職の富士通ではwin-win-winとか言っていたな)

問題を解決するということがエンジニアの仕事だ、と言われることがあるが、人生にも当てはまるから、それだけでエンジニアは人生の勝ち組になるという意味で強いというようなことを言っていたが、そういうふうに思ってとりあえずやっていこうと思えた講演だった。

過去のMatz氏関連の主な記事

まつもとゆきひろ氏がSpeeeで語った、勉強会・英語・プログラミングの話 まつもとゆきひろ氏が「生涯プログラマー」でやっていきたい若手に贈る3つの言葉

以下メモ

こんな目的をもってやろう

  • Matzのご尊顔を拝む
  • エンジニアとしての行き方を学ぶ
  • 何かを始めるきっかけにする

協賛企業

  • Speee (Matzさんが顧問)
  • DRECOM

本編

自己紹介

まつもとゆきひろ(Matz)

  • 松本は鳥取で5番目に多い苗字なので差別化を図ってひらがなにした
  • こちらも差別化を図ったのだが、ドイツとかスェーデンにはMatzという苗字の人がいた
  • 日本人で一番有名なエンジニア
  • 政府IT総合戦略本部委員(プログラマ代表、意見が通るわけではない)
  • 松江市名誉市民

生き残るには

  • 死ななければ良い(本気)
  • デス・トラップ、たやすく絡みつく死の鎖

人によって違う

自分の生存戦略を見出すための戦略を話す(メタ戦略)

スタートアップ業界において成功する人が共通に持っているものは何か？という調査で明らかになったこと

IQが高い？ → 実際には相関はそんなにはなかった
パターン認識能力を意識的に鍛えることによって成功できる!!?

ロールモデルを持つ、ということ

スティーブ・ジョブズなどと同じことをしても、上手くいかない
人と全く同じことはできない

バタフライ・エフェクト 誰かと全く同じことをしても、いろんな違いの影響によって結果は予測がつかない
そもそも自伝などを読んでも成功のために何をしたかは本人も覚えていない

だから、パターン認識

Matzの場合

12d歳でボードマイコン遭遇(L-kit16)

Lチカしてた

15歳でポケコン遭遇(ポケコンBASIC)

400ステップのメモリ ユーザー定義関数なし 変数が1文字しか使えない ローカル変数はなく、グローバル変数の26個しか作れない

「Pascal入門」(工学社)に遭遇

紙にプログラムを書いて勉強

プログラミング言語に興味

Lisp, Logo, Smalltalk 言語自体に興味、言語を作りたいなと思った

大学進学

コンピュータサイエンス
筑波は都会
プログラミング言語を作りたいというと、怪訝な顔をされる
当時はプログラミングしている人の3割くらいは言語を作ることに興味があるとおもっていた → そんなことはなかった
とはいえ、地元に比べると、大学のあった筑波は「ここは天国か」という感じだった

プログラミング言語研究室

卒業研究で自作プログラミング言語を作ったら、教授と反発して、卒業発表で一番辛い質問をされた

就職が苦痛

浜松の会社に就職、寮から徒歩五分
同期200人でコンピュータサイエンスの専攻6人しかおらず大切にしてもらえた → 社内システムの開発
当時他の人の働き方はやばかった(残業160時間？)

クライアントのものを開発するわけではなかったので
開発しているシステムが「どうあるべきか」を決めることができた

スーツが嫌
「みんながやっている」は我慢の理由にならない
「我慢」の価値
我慢することが価値を出しているような社会になってしまっている
「俺も我慢してるんだからお前も我慢しろ」
価値を出さなかったらビジネス的に全く意味はない

理由のある我慢
  • 納得できない理由を押し付けられるのは理不尽
プログラミング三大美徳 by Larry Wall

1.怠慢(Laziness)
全体の労力を減らすために手間を惜しまない気質。
この気質の持ち主は、役立つプログラムを書いてみんなの苦労を減らしたり、
同じ質問に何度も答えなくてもいいように文書を書いたりする。
よって、プログラマーの第一の美徳である。

2.短気(Impatience)
コンピューターが怠慢な時に感じる怒り。
この怒りの持ち主は、今ある問題に対応するプログラムにとどまらず、
今後起こりうる問題を想定したプログラムを書く。
少なくともそうしようとする。
よって、プログラマーの第二の美徳である。　

3.傲慢(Hubris)
神罰が下るほどの過剰な自尊心。
または人様に対して恥ずかしくないプログラムを書き、
また保守しようとする気質。
よって、プログラマーの第三の美徳である。

反対は？
  • 勤勉: 苦労を我慢する。他人が勤勉であることに価値を求める
  • 寛容
  • 謙遜

「我慢」の価値
無意識の価値構造

労働することは我慢することではない
報酬 <> 苦痛の対価
報酬 == 価値の対価

上から下まで総勘違い

会社が自分を養っているという誤解
会社に反抗するのはまちがっているのは本当にダメなことだろうか？

  • 「結果よりも過程」
  • 「生産性よりも忍耐」

理不尽は拒否しないといけない
理不尽を断れなくなること = 「死の鎖」

我慢による苦痛への耐性→鈍感になる
致死量は変わらない

怖い話をしたが、ポジティブ思考に考えると

みんながやらない、やっても良いこと = 裏ワザ
楽をして少しの労力で結果を得る
そのためには…

  • 空気を読まない
  • 目的を明確化する(本質ではない目的には目を向けない)

Dont work hard, Work smart.

どうやって理不尽を拒否するか

価値観にアプローチ
話が通じない人に通じるようにすることはなかなかつらい
社会的圧力を自覚する
理不尽に対して声を上げる
リスペクトできる関係を構築する

開発者とクライアント(上司の場合がおおい)が対立構造となることが多い
仕事の価値でいうとその対立構造は無駄にしかならない

Win-Win 7つの習慣
WinとLose

  • Win-Win
  • Win-Lose
  • Lose-Win
  • Lose-Lose

4種類もない！
ビジネスの現場では2種類しかない
- 2人ともWin (Deal) - どちらかもしくは両方がLose (No Deal)

(死なないために)逃げてもいいんだ！(場合によっては)

あなたの場合

平気平気フレンズにとっていんな得意なことが違うんだから

メタ戦略
  • 得意を見極める
  • 我慢に価値を置かない

プログラミング言語を作りたいってどういうこと？って言われる
違い自体がメリット

  • 継続することが一番重要 Rubyひとすじ25年
  • 勘が働く「こっちにいけば幸せになれそう」(センスが必要？)
  • (社会的圧力に対する)鈍感さ

cf. イミテーションゲーム アランチューリング 暗黙のプロトコルがわからない

あなたの得意は？
  • インベントリ(棚卸し)
    • 何が得意で何が得意でないか
    • 得意なものを組み合わせ価値を出す(複数なジャンルを組み合わせることによって価値を出せる)
思い込みを自覚する
  • 身の回りには思い込みが沢山ある
  • キャッシュ
  • 時代や状況の変化によって思い込みは変わる
  • Phil Karlton cache
  • 思い込み = インバリデーションのないキャッシュ
  • バグ原因の95%は思い込み

There are only two hard things in Computer Science: cache invalidation and naming things. – Phil Karlton

問題解決をする

プログラマが日々行っていることは人生にも適用できる プログラマは人生の勝ち組！

インプットとアウトプットのバランス

勉強する
Qiita
はてブ？

インプットは必要
でも、インプットするだけでは差別化要因にならない

鍵になるのは、 アウトプット

  • OSS
  • ブログ

高いハードル、心理的障壁

  • まさかり
  • 面倒・億劫・羞恥心

高収入芸能人やユーチューバーを見て「あんなの誰にもできる」は半分本当
しかしながら、思い込みと同じ心理的障壁によって多くの人にできない

みんなと一体になっている方が良いというのは過去のキャッシュ
クオリティは棚上げ

人間の可塑性に、かける
OSSのかなりの割合は自分でもできる、ということが多い

ずっと機械に向かっているわけではない

ソフトウェアを作るのは人間
ソフトウェアの対象は人間

心理的な問題は重要
心理的側面に興味を持つ

若手エンジニアの生存戦略

  • 理不尽を拒否
  • 鈍感になる
  • プログラミングを極める
  • 人間心理に興味を持つ

プログラマは人生の勝ち組

勝ち組になろう

質問コーナー

勤勉に価値を置く上司を潰すには?

価値観を覆す
その上司がどのくらい邪魔か、による

  • 成果によって黙らせることができることもある
  • 成果なんかどうでも良いという人もいる

上司に上司の話をする

やめることによる上司の教育

Matzの失敗談(恥ずかしさ)

首相官邸でのミーティングでジャケットパンツでも大丈夫なのであんまり失敗はない

1日中Rubyのことを考えているのか？

正月にコミット 結構考えている 3大バグ見つけるタイミング

  • 散歩
  • 風呂
  • 寝る前

Matzが読む本オススメ

  • ソフト・スキルズ
  • エラスティック・リーダーシップ
  • 言語のしくみ

大学に行く価値

Rubyは便利なメソッドがありすぎるので、裏側を知る必要のある初心者には向かない論について

  • 裏を知らないといけないというのは老害
  • 全員が裏側を知らないといけないわけではないんじゃないか？

今20代なら勉強したいこと

  • 勉強に年齢は関係がない
  • 新し目のトレンドについて、それがなぜ出てきて、なんで流行っているのかを知る、使うかどうかは重要
  • 例えばkotolinがなぜ出てきたかは知りたい

楽をして価値を出す

  • やるべきことをリストアップする
  • 小さなことを積み重ねて生産性を上げる
  • 小さなことを続けて信頼関係を気づけたら、自分のできる範囲を広げて行く

SIer業界や大手、そして海外は？

  • SIの全てがダメというわけではない
    • 構造上対立構造を生み出しやすい(クライアントと開発)いいものを
    • 対立構造を生み出さない仕組みを作り出すことが重要
  • 海外の柔軟な雇用
    • 対立構造を産みにくい
    • しかし日本的な仕事をする会社もある

我慢の根源

  • 戦前、戦時中、武道の中で我慢を求めることがある

雑な感想とメモ【React Native Meetup #5】 20170519 @mercari

勉強会 JavaScript

React Native Meetup #5に参加したので簡単な感想とメモを備忘録的に残しておく。

当日のビデオが公開されている。詳しく知りたい方は見ることができる。

Reactを業務でやっているけど、Reactでも活かせそうな知見もあった。 ReactNativeでなにか作ってリリースしてみたい！という気持ちの盛り上がりを感じた

  1. Why not React Native
    いきなり英語セッションで面食らう。
    ただ、始まったらゆっくりだし、内容は基本的にReactNativeのモチベーティング系の話だったのでスッと聞けた。
    すでにReact Nativeを触っている自分としてはそんなに目新しいことはなかったが、Maya-Kaiというツールは触ってみようかなと思った。
    日本語資料も後悔してくださっていたのでリンクはそれを張っている。

  2. Our choice in ReactNative
    Electronの入門本を書いてらっしゃる方で、この本は僕も読んでいたので一気に親近感(恐れ多いけど)。
    Native Bridge系の話を中心に話されていた印象だったので、Native連携は考えたことがなかった僕にとっては、なるほどこういうこともできるのか、という感じ。
    今回のミートアップで全体的にNative Bridgeのことが多く語られた気がするので、大きいアプリを作ることになったら考えよう。
    リリースの時の話もリリースする時になったらここに帰ってこよう。

  3. async/await 構文を使った Android とのブリッジ
    まず、async/awaitをReactでも使ったことがないんだが…
    というのは置いておいてReact NatveでNative連携をasync/awaitで書く話。
    まとめとしてはPromiseで統一した方がよいという話になっていて、書いて見ないとなんとも感。

  4. Introduction to React Native Animated Animated入門
    某SIer所属！趣味でReact Nativeやられているとは、すごい(僕も趣味だが、業務でReactやってるのでちょっと違う)
    Animated APIの話をされていて、僕も4月に行われたReact&React Native入門者の会 #2で話したが、さらに深掘りされていてためになった。
    ちなみに僕の発表資料は以下
    React Nativeでお絵描きしてみた

  5. react-navigation について
    セコンさんの発表。Rebuildfmなどで名前は知っていたが、ちゃんとにんしきしたのは初めてだった。
    react-navigationについて話されていたが、3月末くらいに触り始めた僕にとってReactNativeのルーティングライブラリはまだ正式ではないものの、公式にあったreact-navigationだったので、最近できたと聞いてそうだったのか、と思った。
    ReduxとMobXの話もちらっとされてて、会場の興味的にこちらの方を喋って欲しい感を感じた。
    僕は業務でReduxを触っていて、最近インターネットでReduxが複雑を助長していてよくないみたいなことでdisられているのを聞いて悲しい。
    MobXを使って見て、Reduxを使う理由を主張しようかなと画策するなど。

  6. ReactNativeで9個アプリを作って、1個リリースして、使ったおすすめツールを紹介
    React Native関連でいろんなツールを紹介。
    まとまっていて参考になるやつ。

  7. Web開発者がReact Nativeで開発から運用までして辛かった事
    最後で押していたからか、かなり足早に説明されていた印象。
    コンパクトにまとまっていた感があって聞きやすかった。
    Web感覚で開発できるというのはそれだけで完全に良いことだと思った。
    会場で挙手のアンケートをしていたのだが、Rubyを業務でやってらっしゃる方がかなりいて、Webで仕事をしていてNativeも触りたいという人の簡単な入り口になるというのは作られた目的の一つが達成されている感があるなあと思った。
    しかしなんでこんなにRuby経験者が多かったのだろうか？

懇親会
1人目に話されていたmercariの中の人に話を聞くことができた。
聞いたこととしては、以下

  • mercari appではどのくらいの割合でReact Nativeが使われているのか
    • 20%程度
  • 型判定のライブラリは使っているのか
    • プロジェクトにもよるが、typescriptとflowの両方を部分的に使っている
  • ReduxとMobXではどっちが好きか
    • MobX、やっぱりReduxは複雑になりがち

以下メモ

React Native Meetup #5

Why not React Native @dotPKG

英語セッション!

React Nativeを導入すると考えたときに条件がある

  • 既存アプリとの連携
  • 最良のプログラミング言語
  • 最高の開発体験
  • 習得の氏やすさ
  • 最高のQA体験
  • 最強の監視ツール
  • 盛んなコミュニティ(※現在48kのgithubスター)

2015年はまだ使うべきじゃなかった

要件

  • 既存アプリ上に構築できるコト
  • 敏速性の高さ
  • 最高なQA体験
  • 最強の監視ツール
  • 最大級のコード共有

ローンチした後

クラッシュリポーティング

Exponent + Maya-Kaiで最高の開発体験が得られる

Maya-Kaiがbrowser-sync的に働いてReact Nativeで作ったアプリのQAの工数削減としてすばらしいツールになった @sota1235さんが作ってる？

Mercariアプリの技術スタック

  • React
  • MobX
  • React Navigation
  • ES6
  • clarifai

2017年はReact Nativeを始めるのに十分良い JavaScriptでアプリ開発を始めよう

Our choice in ReactNative @joe_re

freeeの人 Electron本の作者

交通費精算アプリをReactNativeで作ってリリースした

注意(Android向け)

How was ReactNative

  • 開発期間3ヶ月
  • 2名(フロントとサーバサイド) + インターン
  • モバイルエンジニアなし

やっぱりNativeの知識は必要

Nativeの試算を活かしたい場面ではNativeコードを書くことができる

開発体制的に、正解だった

モバイルエンジニアが近くにいるとよい

NativeLayerの試算を活かす方法

  • NFCタグを読み取り使用履歴に変換 Android SDKはNFCを読み込む操作を提供 NFCAdapterをwrapしたものをReactのライフサイクルメソッドから呼ぶ componentDidMountで呼び出す

簡単にAndroid SDKを呼び出せる

JS Layerのミドルウェア

  • redux-thunk
  • redux-promise-middleware
  • redux-logger

redux-promise-middlewareを選択した理由

Promiseの状態に従ってアクションの発行を自動化してくれる

payloadにpromiseを渡す→promiseのstateの遷移に従ってactionが自動でdispatchされる

NativeアプリケーションとReduxStateとの相性は良い

Router = react-native-router-fluxを使っているが…

個人的にはreact-navigationが良いっぽい？

HOCの活用

  • ログイン必須ページのログイン要求
  • flex-boxだけでは対応の難しい画面サイズ
  • Indicatorの表示

リリースのためにやったこと

Crashlyticsを導入 ReactNative向けにreact-native-fabricというモジュールがあるのでいれておくとよい　

不要な権限を消す(Android)

デバッグツールのために要求されているのでmanifestを書く Androidのgradleスクリプトではディレクトリの規約によりリリース時のManifestを選択できる

YarnのLicense表記

package.jsonの依存定義からLicense表記を生成するコマンドがある ※ あくまでも雛形

AsyncStorageREPL

AsyncStorageをNodeのREPLから見ることができる(使ってみたい！)

質問

flexbox使わなかったらAndroid確かに大変そう

async/await 構文を使った Android とのブリッジ @nullpoo

mercari フロントエンド

Androidのインテントを使って、処理結果を受け取りたい

なぜ？ 音声入力をもとに表示内容を切り替え 音声入力ダイアログを呼び出したい Android開発の知見があるので、Androidのブリッジを使ってできそう

what インテント

アプリ間連携のためのメッセージングオブジェクト

Androidでインテント遷移先の結果をハンドリング

ReactNaiveでブリッジするには

1.Android側でJS側に公開するメソッドを作成"@ReactMethod"を付与するとReact native側で付与したメソッドを呼ぶことができる 2.React Native側に公開するパッケージを作成&登録 3.JS側で公開されているメソッドを呼び出す

async/awaitを使って結果を受け取る

ReactMethodでPromiseを扱うことができる 引数にPromiseを追加するとReactNative側でPromiseとして受け取ってくれる

しかし、async/awaitを使えばPromiseより直感的に扱うことができる

まとめ

  • Callbackを渡す方法やAndroid→JSのブリッジを使うこともできる
  • しかしPromiseをasync/awaitでハンドリングするほうがスマート
  • 同期処理でない処理を行うブリッジはPromiseで統一したほうが引数もスッキリして良さそう

Introduction to React Native Animated Animated入門 @nolick1219

某SIerで介護評価検索サービスの立ち上げ 普段はRuby on Rails

React Nativeにおけるアニメーション

  • Animated
  • LayoutAnimation 簡易的

アニメーションの流れ

  1. アニメにより変化する値を定義
  2. 変数にCSSプロパティを紐付け
  3. 変数をAnimated.timing()などに渡す
  4. 変数の値の変化にあわせて変化させる

Animated.Value()

変数とは別レンジでCSSプロパティを紐付けたい

interpolate()

連続するアニメーション

  • Animated.parallel()
  • Animated.sequence()
  • Animated.stagger()

今後試したいこと

Animated.Value同士を足したり書けたりできる Animated.event()でユーザーのジェスチャーによってValueを変えることができる

react-navigation について @hotchpotch

セコンさん WAmazing CTO not flux → Mobx

navigationライブラリの必要性

画面構成数が少なければ必要ない

  • タブ型
  • スタック型
  • タブ+スタック型

ナビゲーションを実装するにあたり、必要な要素

画面を構成する部分を決定

  • stackならナビゲーションバー
    • タイトルや戻るボタン、その他ボタン
    • おもにヘッダに実装される

何を表示するかを決める部分

  • Router + state管理
    • stackならstack管理
    • タブならツリー構造管理
  • deeplinkからの復元
    • appname://search/キーなどでどのように表示するか

どうアプリにナビゲーションを組み込むか

  • 自前
  • 既存のライブラリ いろんなものが有る

PureJS と Native実装両方

react-navigation

2017初頭に登場 4月末に1.0.0betaをリリース

pureJS - ネイティブの気持ちを考えなくて良い - JSが分かれば自前でどうにかできる

例)examples/NavigationPlayground

良いデモ!!

クラスと実装

  • Routerクラス
    • TabRouter / StackRouter

内部状態ツリーを理解すると簡単

reduxやmobxではstateを管理する必要がある

Reduxの場合

公式ドキュメント()がある

MobXの場合

react-navigation-mobxサンプルがある

MobX

Hello, MobX? https://leader22.github—hogehoge

実アプリで乾燥

stateをどう扱うか意識できるところまで理解できると思った通り動くようになる タブとスタックの実装を考えることが重要

まとめ

素のRNならすんなり使える

PureJSは楽 ReduxやMobXの場合はコストが掛かる

  • まだ気楽に使える形では無い
  • 今後エコシステムの改善が見込まれる

※ MobXの選定基準 非同期処理の扱い方がfluxよりもシンプル Observable

ReactNativeで9個アプリを作って、1個リリースして、使ったおすすめツールを紹介 @mat_aki

SonicGarden CTO

Remoty

why ReactNative

少人数でおおきな成果 RailsでのWeb開発がベース learn once, write anywhere. webが中心でデータの参照が楽

使っておくべきツール・機能を紹介

どういうものを使ってるのかが、まだまだ

Webっぽいやつ

cmd + d

React Native Debuggeer

Reduxのステート コンポーネントの構造 デバッガがまとまっている

Firebase

Native SDKとのやり取りが簡単 - プッシュ通知 - アクセス解析 - エラー検知

CodePush

Storeの審査無しにアプリをバージョンアップできる JSの部分のみ変えることができる

Bugsnag

エラー検知サービス SourceMap に対応

React Native Router Flux

ナビゲーションコンポーネント

Redux

redux-persist redux-logger reduxsauce redux-saga ducks

Expo

Qiitaに記事あり

fastlane

pem PUSHの証明をコマンドで作る

Web開発者がReact Nativeで開発から運用までして辛かった事 @DotEarl

Toggetter

技術的な話はしない 辛かった話をする

ToggeterはReactNativeで作り直してリリース!

広告SDKの組み込み

Facebook広告を組み込みたい いい感じのパッケージが見つからない 結局じぶんで　Bridgeを書いた

JSだけでかけると言ってもネイティブ側のコードも必要な時がある

RN本体のアップグレード

react-native-git-update だいたい落ちる

本体のバージョンはこまめに追従しないとダメ ライブラリの作者がやめることもある

エラーはIssue検索すれば代替見つかる

アップグレードは気合

  • プッシュ通知
  • WebView

安定しなかったので自分たちで直した

嬉しいこと

  • Web感覚
  • 公開されてる機能でだいたいなんでもできる

まとめ

  • 難しいことするならネイティブは必要
  • バージョンアップはこまめに
  • モジュールの選定は重要

スポンサーLT

シューマツワーカー

CureApp

Mercari

雑な感想とメモ【eureka Meetup #02 - Machine Learning Eve -】@20170518

勉強会

eurekaさんのオフィスで開催された勉強会に参加してきたので、忘れないように簡単な感想とメモを残しておく。 あくまで自分の備忘のためかつ、発表を聞きながらとったメモなので、詳しくは近いうちに上げられるであろう発表スライドを参考にするのが良い。

基本的に機械学習未経験者だが、興味はあったし、eurekaさんのオフィスを見てみたいというのもあったので目的は達成できたかなと思う。ピザも美味しかった(夜の炭水化物を控えているのになんてことだ)。

肝心な内容については、機械学習未経験者だったのでついていくのがやっとだった。聞いたことが用語もあったのでその辺はふんふんと聞いていた。

1人目の@pottavaさんの発表は機械学習について導入から浅く広く解説してくれていた印象があり、わかりやすかった。1人目でよかった。 元はAWSで機械学習をするという話をするつもりだったそうだが、この変更はかなり僕にとっててはありがたかった。

2人目の村上さんはNVIDIAの方で、終始NVIDIAの宣伝という感じだったが、GPUがどういう風に機械学習の流行に影響を与えていたか、についてより具体的に知れたのはよかった。 また、ディープラーニングフレームワークについて、簡単にまとめられていたので参考にできると思う。

3人目、4人目は、eurekaの中の人で、実際にpairsでどのように機械学習を利用しているか、導入しようとしているか、という話が聞けたので、今後、もしも機械学習をプロダクトに入れることになった場合には参考になると思った。あんまり詳しいところは、confidencialと言っていたので、メモもいい感じにカットしてあるつもり。

4人とも、機械学習を触ったことがなくても、クラウドAPIでもローカルでも良いからまず触ってみよう、ということを言っていて、こういう勉強会で少しでもモチベーションが上がっているうちに手を動かしておいた方が良いなと思っている。 実際無記名のアンケートでもそんな声がちらほらあったように思う。

TODO: 上げられた資料のリンクを貼る

以下メモ

あまり本には載っていない機械学習の話

@pottava さん SUPINF

機械学習で何が変わるの

どんなふうに応用されているのか

サービスに導入するには

職種によって考えるべき

先ずはクラウドのAPIを叩いたり本読んだりしよう

おすすめ書籍 「Hands-On Machine Learning with Scikit-Learn & TensorFlow」 使うところから、運用までカバーしている

機械学習のおさらい

機械学習とは

客観的事実をコンピュータに与えなにかの結果を出力させる 実テータを食わせて、コンピュータに計算させる 関数の定数をコンピュータが決めさせる

学習と推論

y = ax + b でaとbを決める段階が学習 yを決める段階が推論

優れた推論のためには優れたモデルが必要

解きたい問題によってaとbの決め方が変わる

例）恋愛 * 機械学習

  • その人との相性
  • その人の5年後の収入予測
  • 純粋に幸せになれるのか など

機械学習と深層学習

ディープラーニング = 深層学習 多層構造のネットワーックを用いた機械学習 解決したい問題によって使うロジックが異なる

例)AlphaGoなど

実践的なネットワーク

層の深さ 152層が意味のある深さということが言われ始めている できるのか？→フレームワークが助けてくれる 利用者はアルゴリズムの実装をすることなく各種パラメタの指定だけで学習・推論ができる

フレームワークを使って、アルゴリズムの実装を知ることなく実装できる TensorFlow、MXNet、CNTK、Caffe2、Chainer…

機械学習の流れ

  1. データ収集
  2. データ前処理
  3. 学習
  4. 推論

データ収集

自社製品に沿ったデータ 一般公開されたデータで勉強もできる(MNISTなど)

データ前処理

pythonだけで済むならそれでいいものの専用ソフトウェアやサービスを使わないと辛い

学習

推論

ビジネスと直結するので24/365の運用

ローカルでもできるのでまず叩いてみるというのが重要

GPUでディープラーニング開発を始めてみよう

村上真奈さん NVIDIA

NVIDIAとNVIDIAのGPUについて

1999年にGPUを発明 NVIDIA = AIコンピューティングカンパニー ビジュアルコンピューティング(NVIDIAを救ったのはバーチャファイター) ↓ GPUコンピューティング ↓ AIコンピューティング CUDA汎用計算による計算が根幹

GPUロードマップ

計算を早くするために2年に1度ハードウェアのアーキテクチャを変えている 現在はPascal次はVolta 頭文字がシリーズを表している

GPUディープラーニング

ディープラーニングを加速s流3つの要因

認識精度向上のためモデルはディープに、データはより大きく

ディープラーニングフレームワークはたくさんある

ディープラーニング CUDA数学ライブラリ cuBLAS、cuDNN、cuSPARSE マルチCPU間通信 ビデオ解析 インファレンス

どのようなフレームワークでもCPUモード、GPUモードがありGPUモードにするとNVIDIAのGPUが使われる

複数GPUを使うと、かなり線形的に計算速度が上がる

ディープラーニング

ディープラーニングを始める際に悩みがちなこと

計算リソース

オンプレ 既存のワークステーションNVIDIA GPUを増設 - PXIex16レーンに空きはあるか？ - 電源容量は足りているか？(例えばGeforce TITAN Xならピークで250w使う)

クラウド - AWS、Microsoft Azure、Google Cloud Platform、 IBM Bluemix Infrastructureなど Deep Learning AMI

ディープラーニングのフレームワーク

はじめはやりたいことによってググるべし コミュニティが活性化しているものを選ぶべし

hello worldの敷居が高い問題

ゼロから作るDeepLearning

イラストで学ぶディープラーニング

Pairsの成長を支えている機械学習の使いどころ

Tamaki Tetsumoto eureka

  • BIチーム立ち上げ
  • KPIの設定
  • 効果測定 Pairsは会員数500万人

Pairsのサービスモデル

ユーザーストーリー

Register Search Like Match Message Meet…

ユーザーとサービスの接点

  • Mail & Push
  • Help Center

組織体制

Acquisition UI/UX CRM CC / PCC

  • Brand & PR（オフラインでユーザーにアプローチするチーム）

CTOチーム - BI - Under the hood: 高い技術で解決 - SRE - QA

改善できそうなところ

  • より相性のよいお相手を表示してマッチ効率をあげたい
  • やり取りのスピードを上げてモチベーションを維持したい
  • 適切な対象者に効果的なお知らせを
  • 投稿監視や問い合わせのコストを削減したい

どうやって改善するか

  • 獲得予測モデル: 予算の再激化
  • 検索アルゴリズム: スコアリング調整
  • テキスト審査システム: 審査の自動化
  • KPI設計: ユーザセグメント最適化
  • 画像審査システム: 自動審査

具体例、顧客獲得予測

  • 新規獲得、流入予測の作成
  • 広告コストと獲得件数をExcelに取り込む
  • 式を組み、線形モデルを作成
  • 手動で調整を加えて予測を作成
  • 広告予算と獲得予測の作成

今後の展望は予測モデルを機械学習で獲得予測を算出する データの前処理で精度を上げていきたい

適切な対象者に適切訴求をする

各ファネルで効果的な訴求が何かを調査 - 登録経路 - いいね回数 - 返信までの時間

ゴール設定: 登録後の定着率アップ データセットの準備: いいね送信数やプロフィール設定 考察&再調整: 寄与率と特徴量の予測相関から着地を決める

Pairsの投稿監視システム

James eureka

投稿監視(Bayesianフィルター)

メールは99.5%なのに はじめは81%しかできなかった

考えられる理由

  • 件名がない
  • 日本語をトークンに分けるのは難しい、事例も少ない
  • Pairsの細かいルールが多い
  • メッセージは普通にメールより短い

→ パラメータチューニングで96%まで上げた

画像監視

暴力や裸 半分以上は友達も写っている写真

顔認識の背景

Viola-Jones

初めてのリアルタイムアルゴリズム(SNOWはこれ？)

Viola-Jones顔認識

  • 顔の明暗を見る
  • Haar Feature
  • 編集されたら厳しい
  • 質が悪ければ厳しい
  • 正面を見ていないと厳しい

OpenCV コードはわかりにくい

  • Goラッパーがわかりやすい
  • 顔認識の実装が簡単

Google Vision API

→ カメラを見ていて質が高ければViola-Jones

実際は組み合わせて使った