nabeliwo note(旧)

5万人に1人になる。

メモツールを作りたい。調査編

僕の現在のメモツール環境

僕はこれまで普通のメモとしてはEvernote、技術系のメモとか勉強会行ったときのメモとかはQuiverを使っていました。

使い分けてる理由としては、基本的にEvernoteは複数端末で同期できてチェックボックスとかそこらへんとても便利で、PCでもスマホでも即メモできるってのがよくて、ただmarkdownに対応していなくて、確か拡張でmarkdown対応してた気がしたのですがあんまり融通きく感じではなくて。
そんなわけでmarkdown使いたいときはQuiverを使ってました。markdown使えるメモツールはいっぱいあるんですけど単純にQuiverが一番UIが良いなあという理由で。ただこちらは同期ができないので僕がメインで使っているPC限定という感じ。

こんな感じでまあ不満はありつつも満足していたわけではありますが、そんな僕のメモライフを揺るがす一大事が…。
そう、「Evernoteの無料枠で同期できる端末が2台までになる事件」ですよ。

まあ年間3100円払えば複数端末同期できるからたったそれくらいの額払えば良いじゃないって話なわけではあるんですよ。
ただ僕の中でEvernoteからそろそろ移ろうかなって理由が他にもあって、基本的にいらない機能が多いんですよね。
僕としてはメモツールってメモできてそれが同期できればそれで良くて。webクリップとかチャットとかグループ共有とかそういうのが必要なくて、だから僕の用途だとEvernoteが適してるわけじゃないんだよなってのがあって。

そしてQuiverの方も、同期できないのがやっぱり不満でした。なのでこの機会にこっちの方も移行したいなというモチベーションに。

そんなわけで「僕のEvernoteの用途 + 僕のQuiverの用途」を満たしてくれるメモツールを見つける旅に出たわけですよ僕は。
勉強会とかでささっとメモできるってのと、買い物行くときにチェックボックスのリスト作って買い物中にひとつずつチェックすることができる、でそれらが同期できる、みたいな。
具体的に用途をまとめると、

  • markdownで書くことができる(リアルタイムプレビュー付き)
  • 複数端末同期ができる
  • スマホからもメモを作成することができる
  • markdownじゃない書き方もできる(チェックボックス作成とか)

って感じ。あとUIがシンプルでかっこよくないと使いたくない。
そういう意味でEvernoteは微妙ってところもあった。 ※僕の好みの話です。

探した

メモツールを色々みたけれどこんな感じ

他にも色々見たけれど惜しかったのはこれら。

結論から言うとどれもだめでした。
僕の需要に対していまいちでした。

Boostnoteとかはmarkdown対応だし、Dropbox使えば一応同期もできるんだけれど、そのためにDropboxも使わなきゃいけないってなると微妙すぎる。

一番おしかったのがBearで、複数端末同期できるしmarkdownだし見た目かわいいしで、テンション上がったのですが、多分メモをフォルダ分けできない。Evernoteで言うnotebook的なやつ。僕にとってそれがとても大事。
「後出しじゃねーか」ってなっちゃうんですが、最初の前提で探してBearに出会った結果、「僕に必要だったのはフォルダ分けの機能だったんだ！」って気づいたわけです。

そんなわけでこんな不幸がもう起きないように僕がメモツールにもとめているものをちゃんとまとめてみました。

顧客(僕)が本当に必要だったもの

  • markdown対応(リアルタイムプレビュー付き)
  • 複数端末同期
  • スマホからもシンプルにメモ作成できる(チェックボックス作成したりとかも)
  • タグ付けできる
  • 検索できる
  • フォルダ分けできる(木構造)

これでファイナルアンサーです。 タグ付けと検索は一般的なメモツールなら当たり前のやつ。

結論として

そんな需要に応えるメモツールはなかったです。もしあるなら誰か教えてください…。

作ることにした

無いのでつまりは作るという結論にいたった。
ということで作り始めたので進捗共有していければなと思っています。

こちらからは以上です。

【メモ】市ヶ谷Geek★Night「型のあるフロントエンドの世界〜フロントエンド・フロンティア〜」 2016/11/4 @株式会社オプト

TypeScript Flow JavaScript

これに行ってきたのでそのメモ。
市ヶ谷Geek★Night「型のあるフロントエンドの世界〜フロントエンド・フロンティア〜」

型の話だ

TypeScriptの勉強を個人的にやっているだけでまだ業務で使ったことがないので導入事例を聞きたいというそういうあれです。
市ヶ谷Geek NightはいつだったかScalaの回に参加したとき以来だったので久しぶりの会場でした。
そんなわけでメモを投下していきます。

目次

  • フロントエンドが本当に必要だったもの
  • 型を使うと便利な開発
  • 実践投入してわかったflowtypeのメリデメ
  • Scalaによるタイプセーフなフロントエンド開発

本編

残しといたメモを貼りつつ感想を付け加えていくスタイルで。

フロントエンドが本当に必要だったもの

@_sisisinさん

スライド： http://sisisin.github.io/s_s/type/index.html#1

内容

近年のフロントエンドは「jQueryの次の時代」

  • モダンブラウザの台頭
  • モバイル対応の比重の激増
    • フロントでやる幅が増えた
  • GUI構築を支援する様々なツール・概念の登場
    • npm
  • トランスパイラ・AltJSの登場
    • 静的型付けがフロントでできるようになった

静的型付け

実行前にコードの整合性をチェックできる

静的型付けの恩恵

  • 実行しなくともコンパイルの段階でしょうもないミスを発見できる
  • クラスがどこで使われているか、どこで定義されているかなどが参照できる

何を与えてくれるのか

不安定な世界に安定をもたらしてくれる

フロントエンドが本当に必要だったもの

「型」ではなく、ユーザーへの価値の提供だ！

オプトのTypeScript導入事例

tech-magazine.opt.ne.jp

感想

フロントエンドの歴史と静的型付けについての解説に関しての話でした。
特に実践的な話ではなかったのですが、導入事例としてあげていたブログの記事の内容がとてもためになりました。

型を使うと便利な開発

@teyoshさん

内容

歴史の話

  • ちょこっと動きをつけるだけ
  • 昔はページが重くなるのでjsは基本offの時代

googleショック => google map
↓
webアプリ大航海時代に入る

その頃の開発環境

なるべくしてなるデスマ

救世主の登場

それでもまだIE6対応は続く…

時は経ちgoogle chromeが登場

その頃の開発環境

革命

Node.js

AltJSの台頭

TypeScriptの登場

JavaScriptのコードをそのまま利用することができる

ジェネリクス

  • リストを作るのに型が多いとその分作らないといけないのか？
  • クラスやインターフェースをパラメータ化できる

デコレータ

@Componentと記述することでclassやmethodに付加情報を投与することができる

型を使うなら

  • 厳密ではなくてゆるーく使っていきたい(型を使うのが目的になってはいけない)
  • 複数人でやる場合はほぼ必須
  • 色々準備が必要なのが面倒

感想

こちらも現在のフロントエンドに至るまでの歴史と、TypeScriptに関しての説明と言った感じでした。
JSの歴史の中で「愛生会病院」が出てきたときはやっぱウケてました。みんな好きすぎなんだなあ。

僕がエンジニアになったときはIE7の対応をするってなったら「まじか」ってなる雰囲気くらいの時代だったので僕は辛い世界を知らずに生きているのか、とそういう気持ちになりました。

実践投入してわかったflowtypeのメリデメ

@shinoutさん

内容

キュア・アップからきた

  • 業務でも積極的なOSS活動
  • flowにも3commit出している

ネットで拾えるflowの特徴

JSのよくあるバグを未然に防ぐことができる。
undefined is not a function を取り除く。

アノテーションのための文法は実行時にはすべて取り除かれる。

使ってわかったflowの良さ

  • 導入がシンプル
  • とにかくnullに強い
  • NodeやBrowserのAPIのサポートが充実(基本的なAPIは網羅されている)
  • React / React Native周辺技術の型もサポートされている
  • 初回のflowコマンドでサーバが立ち上がり、2回目以降は必要な部分だけ型チェックするのではやい

クライアント側でflowに怒られないようにするnull対応が毎回めんどくさいので、nullを返さずにthrowするって形でAPI側を変更した。
=> APIの見通しがよくなった。

使ってわかったflowの辛さ

  • node_modules内にあるエラーで怒る(空のjsonファイルに対するparse error) -> ignoreを一つ一つやる
  • 設定ファイルの正規表現がカオス
  • バージョンが変わるたびにエラーが増える -> バージョンの変化に自動的に追従しないように変更
  • @flowを忘れると何もしてくれない
  • オーバーロードはない -> 型のある言語のパラダイムが全部あるのかというとそういうわけではない
  • Magic typeがドキュメントされていない(のに便利)
  • ライブラリにすると型情報が使えない
  • experimentalな文法の一部は解釈できない -> stageが低い記法は対応してなかったりする(OCaml製ゆえに)
  • 依存モジュールのflow versionに縛られる

Magic typeに関しては以下を読めばok

qiita.com

それでもflowを使うべき理由

  • 1回設定すればいい辛さは1回頑張って乗り切る
  • 時が解決するやつ -> バージョンが1になることで解決しそう
  • しょうがないやつ -> 我慢するしかない(我慢し得る)
  • すぐにやれるし、やめられる

導入も簡単だし、flowのコードを抜くのも簡単。
進化を続けるJSのスピードについていくのはロックインされない「ツール」ではないのか？

感想

とても実践的な内容ですごく参考になった。
やっぱり導入しやすいし捨てやすいってのは気持ち的にも障壁が少なくて良い。
僕も趣味開発だとReactのプロジェクトはやっぱflowかなあーと思う。

Scalaによるタイプセーフなフロントエンド開発

@takezoenさん

スライド見つからず。見つけたら貼ります。

内容

Scala.js

Scala.jsはbabelのようなトランスパイラ。
Type-safe frontend development with Scala.js.

一つのscalaのコードを書くと、サーバで使えるjavaのclassファイルとjsのファイルを両方生成する。

scala.jsはscalaの機能が多く使えて、scalaのIDEも使える。

scalaだけで完結できるわけではなく、既存のJSとの相互運用が必要になってくる。
型のマッピングのファイルを作らないといけない。

scala-js-ts-importer=> tsのマッピングからscala.jsのマッピングを自動生成できる。
ただ、表現力の差があるので、そういう部分はコンパイルが通らなかったりする -> そこは手でなおす。

js.Dynamicというものを使うと、マッピングファイルがなくてもJSのメソッドをよびだせる。

ScalaTags -> JSX的なやつ ScalaCSS -> CSSをscalaで書ける(sassっぽい感じ)

問題

  • 生成したjavascriptのファイルサイズがでかい
  • マッピングファイルを生成するコストが高い
  • フロントエンドのエコシステムが使えない
  • フロントエンドの人がscala書くのが

別のアプローチ

scala.jsはサーバ側でフロントとのやり取りのインターフェースとして使うのが良い。
いわゆる二槽式的な考え。

まとめ

scala.jsは全部scalaを使うかというとそういうわけではない。
フロントエンドの人が使いやすいようなAPIの提供を可能にするという使い方。

感想

Scalaパズルの人と聞いてびっくり。すごい人がJSの勉強会にやってきた。
Scala.jsって初めて聞いたときはネタかと思ったけど結構いろんな人の話を聞く中でなかなか良いっぽいという噂は聞いていた。

やっぱり全てをScalaで完結させるというのは厳しいっぽくて(特にフロントの既存のエコシステムが使えないというのがやばい)、でもサーバ側の中でクライアント側とのやりとりをする部分をScala.jsで書くっていうアプローチの仕方は確かにとても良さそうな感じだった。

自分がScala.jsを使うとは思わないけれど。

LT

今回LTがとてもよくって、特に@ovrmrwさんのGraphQLの話が面白かった。
例によってLTの時間は食事をするので精一杯だったのでメモはとってないのでスライドだけ共有しておきます。

qiita.com

まとめ

今回はTypeScriptとFlowの導入事例を聞きたかったのでとても満足した。
実際にはTypeScriptの導入事例的な具体的な話はなかったけれどオプトさんの記事を発見できたので良し。

最大の成果はGraphQLほんとすごいなあって気持ちになれたこと。
僕の観測範囲のAngular界隈の人たちはほんとアウトプットが活発で素晴らしいなあと思う。

とりあえずAngular2 + GrapuQLってのはやってみよう。
もちろんTypeScriptで。

こちらからは以上です。

5万人に1人になる。

Poem

今日とても強く感じた感情。

なんで5万人かっていうと、「ごまんといる」っていう言葉があるように、そのごまんといる中で飛び抜けた1人になりたいという思いから。
しかし後でその言葉の意味を調べてみたら「巨万といる」という漢字で、「きょまん」ではなく「ごまん」と読ませるようです。意味としては、「数が大変に多い」というそれだけのことでした。

まあでも僕の中で「5万」という数字がしっくりきたのでそれでよし。

とてもバランスが良い気がしていて、数百万の中の1人になるってなると現実味がうすくて、だからといって決して5万人のうちの1人だと現実味があるかというとそうでもないけれど、まあそれでも目指すにはちょうど良い数字だと僕は感じた。

なれるかなれないかなんてのは僕の中で関係なくて、目指すか目指さないかなんだ。
もちろんなれるつもりなしに目指すってのは違うと思うから本気出していくんだけれど、大事なことはどこを目指すかなんだ。

もちろんどういう方向性で5万人に1人を目指すのかってのを明確にしないといけないのは当たり前なんだけれど、そこらへんは僕が日々ブログで書いてるような話で察してもらえればよくて、僕は僕のやりたいと思っている領域で5万人に1人の人間を目指していこうと思う。

っていうそういう宣言をしたいポエムでした。おわり

明日から心機一転なのでやりたいことまとめる

Diary

最近は

絶賛ニート生活を送っていて、その期間にひたすらペルソナ5をしていたわけで。
そんで明日からニート生活が終わるので気持ち入れ替えてやっていこうと思う。けれどニート期間中にペルソナを全クリしようと思っていたのに結局全クリできないままこの日を迎えてしまった。

明日からはバランスよくやっていかなければならないわけで、とりあえずペルソナは金夜か土夜だけにしようかと思う。

まあそんなわけでやりたいこととかをまとめておく。
やりたいことというか全部プログラミング的な話だけれど。

やりたいことまとめ

短期的にやりたいこと

中期的にやりたいこと

  • Angular2を趣味開発で使う
  • 他人の作ったライブラリやFWを読む(直近だとFlumptやWaltsなど)
  • 外部の勉強会でLTする

長期的にやりたいこと

  • C++の勉強(ふわっと)
  • Luaの勉強(ふわっと)

以上な感じです。

長期的にやりたいことってのはコンシューマゲームを見据えていたりする。
いやこれは本当に今ふわっと思ってるだけだから全然確度低いけれど。

明日からのルーチン決めた

明日から以下のことをします。

  • 毎朝ベッドで目覚めた瞬間のやる気度を10点満点で採点する(詳細メモ付きで)
  • 毎晩寝る前にその日の充実度(プログラミング的な)を10点満点で採点する(詳細メモ付きで)

週次か月次で結果をグラフ化してやる気出た理由とか出なかった理由とか、充実した理由とか充実しなかった理由とか、そこらへんを見つけ出して満足度の高い日々を送るための材料にしていきたい。

そんな感じでまとめ終わりです。
こちらからは以上です。

【メモ】React.js meetup #4 2016/9/27 @サイボウズ株式会社

JavaScript React SPA Redux

これに行ってきたのでそのメモ。
React.js meetup #4

Reactですよ

まさかSPAを語り尽くす会から引き続いてこちらも抽選当たるとは思ってなかったけれどラッキーなことに当たったので行ってきました。
そして全力でメモしてきました。

目次

本編

残しといたメモを貼りつつ感想を付け加えていくスタイルで。

Graph API: GraphQL and Falcor

@Quramyさん

Graph API: GraphQL and Falcor

内容

GraphQLやFalcorの目的

一つのサービスに対して複数のクライアントがAPI接続してくるようなシステムを効率よく開発したい

githubの最近starしたrepositoryを取得する例

従来 => まずはユーザー情報を取得してからそのユーザーを元にstarを取得する
希望 => 2回リクエスト送るのはめんどいからユーザー情報とってきた時点でstarしたrepositoryも一緒にほしい

ならば最初からほしいやつを言え => それがGraphQLとかFalcor
「欲しい情報をほしい分だけ」っていうこの仕組み -> Demand Driven Architecture (以下DDA)

GraphQL

  • facebook社作のクエリ言語
  • 2015年オープンソース化

  • 2016年にproduction ready

  • データの検索や操作にはqueryを利用する

  • ほしいものを書けば一気にとってくれる
  • イメージとしては独自のSQL
  • 独自のSchema Systemが備わっている

React and GraphQL

  • Relay

  • react-apollo (Meteorが開発した)

  • Relay Architectureはfluxライクな感じ(公式サイトに画像あり)

  • RelayコンテナでReact Componentをラップする(reduxのconnectっぽい)
  • コンポーネントとクエリをペアで作る
  • 最終的に一つのクエリにまとまる

Caution

  • GraphQLのserverがある != Relayから接続できる
  • GraphQL Relay Specを実装する必要がある(cache管理やPagingのため)

Falcor

  • netflixが開発
  • まだDeveloper preview

One Model Everywhere

  • クラサバ間でグラフ構造を共有しましょう
  • 必要なパラメータを列挙したらそれに応じたデータがもらえる

内部でJSON Graphというデータ形式でCacheを構築する。JSON Graphは参照をクラサバで共有するための仕組み。

  • Falcorが扱うデータは正規化されている
  • One Fact in One Place
  • normalizrと似てる

React and Falcor

Falcorはviewには依存していない(modelのみを担当する)。
componentDidMountでmodelを監視するイベントを設置するみたいなやり方がある。

Other Resources

DDA for Front-end

  • フロントの都合に合わせてAPIをリクエストできる
  • データの正規化も面倒みてくれる

しかし

  • サーバ側に押し付けているのでは？
  • データの結合関係を決められない(SQLに頼りにくい)
  • 容易にN + 1問題が発生する。性能を担保できるのか

(dataloaderなどのcaching/batching libraryを用いて負荷の低減は可能)

ほんとにDDAは必要か？

向いてるやつ

  • 複数のクライアントを考えてる
  • 通信料を絞り込みたい
  • データ構造に多対多が頻出する

向いてないやつ

  • デスクトップメイン
  • 自社のクライアントから呼べれば良い
  • 木構造が扱えれば十分なもの

まとめ

DDAがほんとに必要かはしっかり考えてからGraphQLやFalcorを導入すべき

感想

GraphQLとFalcorに関しては、Relayを初めて知ったときに触ってはみたものの、そのときに使ったサンプルが全く動かせず、解決できずで断念した記憶があった。
そこからちょいちょい名前は聞いていたが全然深堀りせずに今に至るわけだが今日話を聞いた限りだと上手くはまれば便利にはなりそうだが、それがはまるパターンがそんなに多くなさそうっていう印象。

クライアントで気持ち良くなるためにGraphQLをやりたいがためにサーバーで頑張ったりクラサバ間にまた一個レイヤー作ったりとか、涙を流さずにはいられない努力が必要になりそう。

でもとても気持ち良くはなりそうなので一回勉強してなんか作ります！

複雑なJavaScriptアプリケーションを考えながら作る話

@azu_reさん

複雑なJavaScriptアプリケーションを考えながら作る話

内容

前提

  • 作成するアプリケーションによって必要な構造は違う
  • SSRはしない

Almin.jsを作ったという話

目的

  • 難しいものは考えてつくるしかない
  • 構造かすることでメンテナンス性を高める

構造化の目的

  • 属人性が高くならないようにする

fluxのデータフロー

  • ドメイン、ロジックはどこに書くか
  • ドメインモデルはどこにいるか？(データとふるまいをもったclass)

fluxの見方をかえる

ドメインモデルを作る目的は切り分け

fluxの曖昧なところ

ショッピングカートの例

storeが曖昧になる。
商品の一覧とカート(ProductSore, CartStore)。

CartStoreからカートのstateをとれる。CartStoreはProductStoreに依存している。 => storeは独立させると問題がおきる。

  • Reduxはsingle storeなので問題はない

  • fluxだとwaitForでdispatchされたActionの順番を明示できるから問題ない

  • 掛け算じゃなくて足し算にしたい -> CQRS(コマンドクエリ責務分離)

  • WriteとReadを明確にわける

=> Storeが色々やってるのでわけづらい

Almin.jsを作った話

  • Write * ReadをWrite + Readに(アプリケーションの構造によって掛け算の方がいいこともある)
  • ドメインモデルを扱える構造を作る
  • start from the use cases(UseCase => アクターがシステムに対して何をしたいのか)
  • モデル自身は自分の永続化に関心がないってのが良い方法
  • Repositoryがドメインモデルのインスタンスを永続化する

情報量が多すぎてここらへんからメモを取ることを諦めたのであとは資料を読んでくれれば。
というか本当に深い内容なので是非ちゃんとみんな読んでほしい。

ここに全部書いてある => Introduction · Almin.js

感想

凄まじい情報量でした。
これはあとでじっくり全部の資料読み込んで実践しなきゃってなるやつでした。早く帰ってやりてえって気持ちがとても高まった。
これだけでも本当に来てよかったと思う内容でした。

Should I use redux-saga or not?

@kuyさん

内容

redux-sagaの話

  • reduxのmiddleware
  • reactにもreduxにも書きたくないコードをおく場所を提供
  • yieldによって非同期処理を同期処理として書ける
  • 副作用をデータとして扱える

登場人物

  • saga 実行したい処理をまとめたプロセスのようなもの
  • effect データとしての副作用
  • saga runtime 実行環境

effectを使って処理を書く。

  • call: Promiseの完了を待つ
  • select: Stateから必要なデータを取り出す
  • put: Actionをdispatchする
  • take: Actionを待つ、イベントの発生を待つ
  • fork: 別のタスクを開始する
  • cancel: タスクを終了する

saga rauntimeの中でeffectを実行する。

redux-sagaのコードが増えてきたら

  • 適切に分割する
    • 単一責務を意識する
    • actionを受け取ったら別のactionをdispatchして画面遷移する => actionをチェインさせるsagaとactionを受け取ったら画面遷移するsagaを独立して動作させる
  • 共通のsagaを切り出す
  • 変化の少ないソリッドな処理はmiddlewareで書く(Socket.IOとの連携など)

redux-sagaの問題点

  • 初見殺し
  • generator/yieldが必須(regeneratorRuntimeによってスタックトレースが死ぬ)
  • dispatchされたActionをrejectできない(reducerの後ろにあるので)

side effect middlewareに求めているもの

  • scalability + composability
  • testability
  • background/long-running process(UIコードと完全分離したい)

redux-sagaよりいいものは -> redux-logic???

redux-logicとは

  • middlewareを構造化してくれる、内部はRxJS
  • 副作用コードをvalidate,transform,processの3つに分ける
  • サービスがDIされるのでテストは比較的しやすい(モックは避けられない…？)

まあ他にも今さらに色々出てきているよ。

まとめ

middleware戦争は収束の見込み無しなので、本当に必要なものを見極めて使っていくべき。

感想

僕はReact + Reduxのアプリケーションを業務で書いていてそこでredux-sagaを使っているので、うんうん言いながら聞いていたが、確かにredux-sagaはgeneratorとかyeildとか使ってるし、while(true)とかやっちゃったりするし、初見だと相当気持ち悪さを感じるかもしれないけれど、ここまで責務を分けていると本当にどこに何を書くべきかがわかりやすくてとてもやりやすい、と思っている。

そんなわけでわりと満足してしまって最近にredux middlewareの話を追いかけていなかったけれど、そんな間にまた相当でてきたみたい。
そっちも今度試してみよう。

Real World React2

@mizchiさん

qiita.com

内容

いかにReactをふつうのwebアプリに導入していくかという話。

普通のwebアプリとは

  • SPAではない
    • SPAでなくてもReactは使える
    • jQueryに支配された現代のフロントエンドを改善したい
  • 複雑なモジュールを局所的に解決するのにReactが有用である事を示したい

フロントの流れ

(次は仮想DOMの隠蔽が来そう)JSXに縛られる状況の改善とか

Reactの難しさ

  • エコシステム構築 <= ここを解決する
  • flux概念
  • (React自体は難しくない)

Reactが乗るためのモダンJS

  • npm/browserify or webpack
  • babel/es2015
  • react/flux
  • testable
  • no more jquery plugins
  • no side effect on module loaded(importした時点で副作用が発生するようなモジュールが多い。関数を返すべきである)

なんかよくする

  • モダンな開発環境を導入する
  • 再利用するコードとできないコードを分別する

失敗。

  • 仕様を理解してないもののコードは書けない
  • モジュールの境界面が明示されていないものは分解できない
  • 「別実装で実装を完全に再現」は無理

ゴールの設定

  • React/babelで新規モジュールを受け入れられる環境
  • turbolinks(PushState)が導入可能な初期化フローを作る(使うかはともかく)

Reactのテストはenzymeをつかう

とりあえずこれ使っとけばok

flowtypeの導入理由

  • 段階的に導入できる
  • reactのpropsに対して型がきく
  • 推論が優秀

最終的に

今は最初に失敗したQiitaの編集画面のリファクタに戻ってきた。がんばる。

感想

これ今年の頭に参加したJSer.info 5周年記念イベントで話してたのと同じやつだあと思ってたら本当に同じやつだった。
ただそのときから内容がアップデートされていた。

@mizchiさんほどのエンジニアでも失敗を繰り返して泥臭く奮闘をしているその圧倒的現実感に胸を打たれつつ、こういう夢物語ではないReact話をもっと聞いて勇気をもらいたいとそう思ったのでした。
そしてQiitaとかでも仕様書なしに進めていくんだなあ…しみじみ。って感じでした。

これ以降はピザ食べながらのLTタイム。
ピザ食べてたのでメモできなかったり中途半端だったりするけれどご了承ください。

ReactコンポーネントとCSSコンポーネントは1対1なのか問題について

@shibe97さん

内容

1対1派の話。以前は1対1ではない派だった。

React ComponentとCSS Component

React ComponentはHTMLのまとまり、CSS ComponentはCSSのまとまり。
CSSはHTMLに紐づく。 => つまり1対1

browserify/webpackによって分割ができるようになったため、CSSと同じ粒度に揃えることができる。

極端な話、DOMの一つ一つがcomponentになりうる。

ベストはAtom単位(atomic design)でComponent化。
現実的には工数の問題もあるので、徐々にComponent化していく。

超ちっちゃい単位でもコンポーネント化する意味はある

  • スタイル込みのComponentにできる
  • 他のComponentに流用できる

CSS Componentの難しいところ

  • コンポーネント内にスタイルは閉じている必要がある
  • 外部に影響を与えるスタイルは外側で定義

各Componentに必要なこと

  • 自分自身のスタイリング
  • 子Componentのレイアウト

これはReactと同じ => つまりReact Componentと粒度は揃う

まとめ

感想

ここ最近でわりと熱い話題。この話題になるといつも言っちゃうけど、僕は以前にこの記事を見てから完全にそれに共感してしまっている立場。

morishitter.hatenablog.com

しかしスライドを見ていて、理想論をつきつめると確かにそうだなあーと同意できる話だった。
しかし現実問題として、ここで話されているレベルのComponentの細分化は無理だと思うのでやっぱり僕はCSS in JSは現状はしないで実装していくかなあーっていう。

もちろん無理というのは工数的な話なので趣味開発では@shibe97さんの言うやり方でやってみたいなと思った。

ReactとGoogle Analytics

@naoki_kurosawaさん

内容

reactアプリケーションのアクセス解析について

  • react-gaとかのComponentがいまいち
  • 従来通りheaderに埋め込むのか？
  • Componentを使うのか？

結局Componentもscriptタグがappendchildされる。
初期化タイミングが遅くなる。
reactアプリ外からsendするときはだめ。

=> コンポーネントは良いことが特にない

アプリ内のどこにsendするコードを書くのか

画面表示用コンポーネントに書いてはだめ => まったく同じComponentインスタンスが再利用されるときとかあるから

正解 => routingポイントでsendする(react-routerとか)

react-router-reduxのreadmeでhistory.listenってのがあるけど…
pathnameってのがコールバックに渡ってくるけれど、それだとURLにIDが入っちゃって同一ページでもばらけてよくわからない。

react-routerのonEnterフック => pathという情報がとても有用。これを使うと良い感じになる

まとめ

感想

僕はまだSPAやってるときにGAを使う状況になってなかったので全く未経験の話だったがこれは覚えておくとあとあととても役に立ちそうだなと思った。
こういう現実的なsolutionはgladな感じです！

reduxを使わずにreact+railsする

@muratayusukeさん

内容

※ピザに夢中でしたすみません。

感想

1ページ1コンポーネントで運用しているという話には「なん…だと…」っていう感想を持った。

Jest

@cpojerさん

資料は見つからないので見つかり次第載せます。(多分見つからない)

内容

Jestというテストフレームワークの話。
facebookからやってきてくれたらしい！

facebook.github.io

  • Jestは複数のworkerでテストを動かす
  • とても早い
  • npm install -D jest babel-jest
  • enzyme使ってるならJest使うべし
  • toMatchSnapshot() => UIのdiffがとてもわかりやすい
  • カバレッジの仕組みもある

感想

英語聞き取れません…。つらい…。
僕がわかったのはこの程度です…。ふえええ…。

とりあえずとても良さそうというのはわかった。painlessとはなんとも素敵な響き。
その前にクライアントのテストを書いてないのでまず僕はそこからしっかりやらねばならない。テスト書くぞ！

まとめ

とても熱い一日だった。
特に@azu_reさんのスライドはとても気合が入るというかモチベーション上がる話だったのでしっかり資料読み込んで学ぼうという気持ちになった。
なんかもはやReactの話が前のように「Reactはいいぞ」一辺倒ではなくてしっかり現実と戦う感じの話が多くなってきたのが聞いていてためになる感じで良い。
@mizchiさんの話とかは今年頭からのアップデートって感じで1年を感じられた気がしたのもまたおつでした。

そしてピザがひたすらおいしかった。ピザがくると話を聞く力が1/5くらいになっちゃうのがちょっと困ってしまう。

そして最近は発表者が何を使って発表してるかってのを観察しているのだけれどやっぱりもはやslideshareは本当に少なくて、サービスとしてはspeaker deckの方が使われてる。そんでその上をいくのがHTMLベースで自分のサーバーに置くパターンだった。
僕も今まではspeaker deck使っていたけれどgithub pagesとかで管理していきたい。
やっぱり@mizchiさんはQiitaスライドだった。Qiitaスライドはこれからどんどん増えていきそうな気配。あーでもスライドだとフォントサイズで困っちゃうっていうパターンを何度か見てるからそこはネックかもしれない。

とにかく今日は熱い一日だったので明日からも頑張っていこう。
でもその前にペルソナ5を終わらせたい。

こちらからは以上です。

【メモ】Frontend Meetup vol.1 -SPAを語り尽くす会! 2016/9/16 @株式会社FiNC

Angular2 React Redux SPA JavaScript

これに行ってきたのでそのメモ。
Frontend Meetup vol.1 - SPAを語り尽くす会!

SPAと聞いて

SPAの開発が好きすぎてたまらないのだけれど毎回破綻する僕としてはSPA系の勉強会と聞いたら行きたくてたまらないんです。
やっぱりSPAという言葉にはわりと多くの人が反応するようで今回の勉強会は抽選でした。運良く当たったので行ってきました。
ということでメモったので共有します。

関係ないけどここで勉強会の抽選運を使ってしまったことで次のReact meetupの抽選での運が奪われたのではないかという心配をしてます。

目次

  • React/Reduxで半年くらい真面目にSPAするとわかること
  • 革命と秩序とSPA
  • Angularと心中する
  • コンテンツ配信とSPA
  • SPAと覚悟
  • Angular2でつまづいたところ
  • 1pxをめぐる戦い
  • SPAでのセッション管理とセキュリティ

本編

残しといたメモを貼りつつ感想を付け加えていくスタイルで。

React/Reduxで半年くらい真面目にSPAするとわかること

@takayuki_shmzさん

内容

  • Finc app webをSPAで作った
  • Reactは学習コスト高くないから良い
  • fluxフレームワークはいろいろあるけれどReduxに行き着いた

React/Reduxをよく調べていけそうだったのでプロジェクトにいれてみた。 しかし

コンポーネントで大事なこと

this.context

バケツリレーをせずに値を受け渡すことができる。 全部のビューで使うやつとかはcontextでわたしちゃうと良い。

  • UIにあわせたentityをつくってはいけない
  • あくまで概念として正しい最小単位
  • Storeの設計も自ずと決まる

まとめ

  • 正しいコンポーネントを積み上げねば、幸せはやってこない。
  • this.contextの活用 => DRYとDI
  • エンティティと型 => 見通しをよくする

感想

「CSSとcomponentが一対一」ってところにはいまいちぴんとこなくて、以下の記事で言われていることの方が僕はすんなり納得できる。

morishitter.hatenablog.com

ReactコンポーネントとCSSのコンポーネントの粒度は同じにならないと思っていて、CSSのコンポーネントの方がJSのコンポーネントよりも多くなる（細かくなる）。 JSとCSSのコンポーネントが1対1に対応しないので、CSS ModulesやRadiumなどのCSS in JS系ツールのアプローチは合わないと思っている。

今更ながらなんだけれど、そしてみんなそうなんだけれど、なんで最近はみんな自らSPAが良いと思って手を出して、つらいつらい言ってるんだろうとそう思いました。

革命と秩序とSPA

@joe_reさん

内容

フロントの歴史

  1. Ajax
  2. Backbone
  3. 2way-binding
  4. virtualDOM

freeeのフロントエンド

  1. Backbone(SPAではない)
  2. ページ単位でBackboneでSPA -> メモリリークするしDOM操作大変だし辛い
  3. freee-mvc-framework -> 社内フレームワークの誕生(Backboneの機能拡張) -> それでもDOM操作辛い
  4. vueのVMを追加して2way-bindingして完全なSPAになる(vue on backboneだと...) -> 状態管理辛い
  5. React + flux -> 革命！

flux選んだ理由

  • 既存実装があるところに導入する上でReduxはつらい
  • flux-utilsを使うという選択(flux実装のベストプラクティスのいいとこどり)
  • ミニマムな実装でロックインが少ない。既存のfluxから乖離しない

機能はReduxっぽい。Reduxぽいけど軽い。

さらに

  • bower => npm
  • sprockets => webpack

それでもなお…
実装やIFに統一性がなくてつらい…型さえあれば…

flowtype

  • 強力な型推論
  • babelを使っている場合はpluginを追加するだけで使える
  • チーム開発では必須！
  • 自分が実装したモジュールのIFを明確にする

感想

やっぱり辛いって言葉が出すぎてた。
でも一つ一つ解決に持っていってるのは素晴らしい。
僕もReact + Reduxのコードにflowを入れたくてたまらない近頃なので良い話を聞いた。

Angularと心中する

@Quramyさん

https://quramy.github.io/spa-knowhow-note/#/

内容

webサイト解析をするサービスをSPAで作っている話。

フロントエンド: TypeScript, AnglarJS(1.x)
バックエンド: golang, mongodb, elastic search 解析基盤: Scala, Apache Cassandra

Angular 1.xでの取り組み

  • Component
  • コード自動生成
  • エラー周り

Component

AngularJS1.5からはcomponentが利用可能に。directiveは余程のことがないと利用しなくなった。
AngularJSといえばscopeと2-way bindingだが、今は1wayか2wayか自分できめられるのでどっちでも良い。 それよりもCSSのscopeのが問題 => そこでBEM

でもclass名ながい => 独自directiveで解決。名前空間を指定してclass名をつづける

コード自動生成

gulp + inquirer + mustacheを使ってcomponentやserviceのscaffoldタスクを用意。

Componentの場合生成されるやつ

  • Component本体となる.ts
  • Componentに対応するBEMの.scss
  • Karma用のspec.ts

エラーまわり

TSで型を手に入れたからエラーでない！ => 出る
Rollbarを利用。エラーモニタリングサービス。

Rollbarにした理由

  • sourcemapを公開する必要がない
  • stack traceとsource mapが紐付けられる

覚えて帰ってほしいこと

  • CSSをComponentに閉じ込める仕組みがあるとよい
  • コード生成でよい進捗
  • それでもエラーは起きるので通知機能は入れた方が良い

Angular2の取り組み

書いているコードは別物感が相当強い。
DIや変更検知などの根本的な思想は1系と同じ。
慣れてくるとあまり1と2の違いは気にならない。

componentのcompile問題
componentのテンプレートは実行時にcompile => 遅い

solution => AoT compile
事前に変換して実行時オーバーヘッドを削減する仕組み。
Angularが公式にcompiler CLI(ngc)を提供している。
体感で違いがわかるくらい違う。

感想

SPAやっててCSSの問題は悩まされることが多いなあと思う。
ReactでBEMやるなら@axrossさんのbemmerが良いって聞いた。

github.com

あとはscaffoldどエラー検知は素晴らしかった。とても参考になる話。
会社単位でAngular2にこの段階で取り組むってすごいことだなあと思う。

コンテンツ配信とSPA

@konpyuさん

内容

noteをAngular 1.xで作っているのでその話。

現役でAngular 1.xだが

  • 機能や仕様が肥大化してどんどんカオスに
  • 超巨大directiveがいくつもうまれ
  • 低いテストカバレッジ、人による実装の違い
  • モバイルwebで信じられないくらい遅い

=> 構成見直しの機運。まずは初期ロードをなんとかしないと。

  • DOMの数を減らす => デザインをなおしてDOMの描画をへらす
  • HTTP負荷を減らす => cacheしにくいものはwindow.PREFETCHにつめたり

結果、すげー早くなった(それでもまだ遅いけど)。

SPAで高速(に感じる)コンテンツ配信

  • 体感を早くする
  • 最初に枠組みだけを高速にロードして、準備ができたコンポーネントから表示
  • 静的なコンポーネントはSSRで
  • 出せるものから出す。総ロード時間に変化はないけれど体感速度は変わる

Reactでnoteのタイムラインを再現してSSRしたけど、実現するには実装が煩雑

HTTP/2

  • HTTP1時代のベストプラクティスが裏目に出る
  • facebook: 大量のアセットを一斉に落としにかかる様は圧巻！

まとめ

SPAはモバイルですぐに性能が悪化するので注意。初期ロードを早くする要件があるならDOM構築は必要なものだけ最初に。
コンポーネント化 + コンポーネントごとにSSR + コンポーネント単位の遅延ロード + HTTP/2 = よさそう

感想

以前にnoteをぼんやりと見てたらAngularだったことに気づいたのでAngularを使っているということは知っていたのだけれど(あとmozaic.fmでも言ってた気がする…)、その裏側で結構苦労したのだなあーと。

ただやっぱりSPAのモバイルで速度の問題が出るのはまあありがちなことだと思いつつ、しっかり対応してる話を聞けたのは良かった。
速度を早くするってのは、物理的な速度ももちろんなんだけれど、体感速度を早くすれば良いってのは本当にその通りだと思うので、その目線で考えてみるとチューニングの幅が広がりそう。

SPAと覚悟

@teppeisさん

内容

SPAとは

ブラウザにとっては1枚のページ。そこに様々なハックを駆使してリッチな体験を提供するアプリケーション。
ブラウザの標準的なUXに満足できないから自分でつくる。
SPAとはブラウザを超える体験を再実装する覚悟 => その覚悟がないならSPAを選択するべきでない

例えば遷移

ユーザーの気持ち

A => B => C 戻る C => B => A

作ったSPAの動き

A => B => B' 戻る B' => A

ページナビゲーションの設計とかもSPAでは全部自分で考える。

  • いつヒストリに積む/復元するか
  • どこまで状態を記憶するか
  • dispose問題/投げてるXHRどうしよう

SPAゆえの考慮事項

  • 初回ロードパフォーマンス
  • パーマリンク
  • SEO(クローリング対策)
  • スクロール制御
  • 各種オブジェクトのライフサイクル管理(オブジェクトの樹苗が長くなるのでいつ破棄するのかとか)
  • ページ間親子間の協調

SPA => 頭悪い流行

SPAとa11y

ブラウザが実装している標準要素は実は標準でかなりa11y対応されてる。
オレオレSPAでおらおらDOM構築する場合、自分でa11y対応していく必要がある。 divだらけのReactコンポーネント書いてない？(正確にはSPAというよりcustom element)

あなたのSPAは本当にブラウザを超えてますか？

ブラウザを超えすぎてはだめ

ブラウザを触ってるときはユーザーの頭はブラウザを想定している => 驚き最小の法則

SSR(SPAじゃないやつ)のUX(速度)も高まってる

  • HTTP/2
  • Service Worker
  • AMP
  • Preload

SPAとはブラウザを超える体験を再実装する覚悟である！！

感想

エモくてかっこいい話だった。そして色々考えさせられた。
僕はわりとSPAをやりたくてSPAをやっていたりするので(さすがに業務でその考えで導入したりはしないが)、本来の目的である問題の解決のための最適化ができているかと言うとそうでもない気がしてきた。
ここらへんから僕の心がマイナス方向へ向き始めてなんだか落ち込みつつ話を聞いていた。

ただまあその覚悟をもってSPAで全力で作るのが楽しかったりする。

Angular2でつまづいたところ

@nacika_insさん

内容

一人でSNSを作った話。構想4年。OSSで。

フロントエンドだけ完成したので見せますよ。 技術スタック: Angular2, TypeScript, webpack, Node.js, system.js

認証機能で困った

  • Angular2では状態をcomponentが持つ
  • serviceは持たないようにしたい
  • つまりcomponentが認証情報を持つ？
  • 形のないものにcomponentを使うのがいや

bootstrapでたちあげるときに認証用のserviceにわたす

感想

初めての発表の舞台ということで大分緊張されていた。しかし、その一歩を踏み出したことってのはとても尊いことだなあと。
僕はまだ踏み出せていないので、まぶしい感じで見ていた。

SNSを作っている途中なので見てくださいって内容でした。
Angular2のチュートリアルしかやってない僕でもぎりぎり理解できた。良かった。

1pxをめぐる戦い

@yoshiko_pgさん

1pxをめぐる戦い - @yoshiko_pg

内容

縦並びのリストのborder-bottomに1pxつけてるときの一番下のliのborder-bottomだけ消したいけど状況的に色々厳しいときにCSSでどう頑張るかっていう話。
とにかくCSS力の高い話だった。スライドが全て。

感想

CSS深い。

SPAでのセッション管理とセキュリティ

@uryyyyyyyさん

qiita.com

内容

  • SPAでのセッション管理
  • CSRF対策
  • CORS

SPAでのセッション管理

基本的に普通にcookieつかえばいい。

localStorageはどうか

  • 認証の前にjsが呼ばれてないと値を読めない
  • ブラウザでcookieを消しても認証は続く
  • 外部の悪いJSを読むとtokenをぬかれる危険
  • tokenのexpireを自分で実装する必要がある

CSRF対策

SPAだとcsrf tokenを仕込むタイミングが難しい => ブラウザのpre flightを利用する
pre flightで事前に安全かどうかを見る。

CORS

cross originのリクエストは許可しないとできないので、逆に言うと許可すれば別ドメインでサーバ置いたりできる。

まとめ

  • ざっくりでもセキュリティの話を知っておくのは大事
  • ブラウザの制約などは意味のあることなので、ちゃんと理解して使う
  • サーバーサイドのツラミを知ろう

感想

セキュリティの話。
僕はセキュリティのところとても弱いので、しっかり勉強しなきゃなと考えさせられた。

ちなみに、僕はSPAで認証するときはJWTとsession/localStorageでやっています。
詳細を詳しくQiitaで書いてるので詳しくはそちらで。

qiita.com

まとめ

途中で休憩で軽食食べさせてくれたり、あと普通にそれが作ってくれたやつでとてもおいしかったり、途中のフィットネスタイムみたいなやつとか、顧客満足度を上げる努力がとても良かった。
FiNCでやるイベントはどんどん参加したいと思った。

内容としては、僕のSPAに対しての覚悟が問われた1日だったという感想が頭の中を占めてしまった。
本当に色々なことを疎かにしている中で、流行っているという理由でSPAをしてしまってるだけではないだろうかとか自問自答しちゃったり。

とにかくがむしゃらにコードを書こうというそういう意識を持てたことはとても良かった。
この連休中はひたすらコードを書く。

こちらからは以上です。とても楽しい勉強会でした。