はぜにっき

日記です。（毎日更新ではない）

「設計について語る会」参加してきた

Enginnering

なにこれ

若めのエンジニアこみゅにてぃで「設計よくわからんのだが」みたいなことを話していたときに、 ダンボー田中さんが提案・開催してくれたので参加してきたレポ。

主催側の経緯や、話の流れについてはダンボーさんのエントリを参照してくださいな。

tanakalivesinsendai.hatenablog.com

会場はLINE株式会社のセミナールームでした。 nasa9084 さんありがとう。

f:id:hazeblog:20181201230435j:plain:w300

げすと

ダンボー田中さんと一緒にiOS設計パターン本を書いたtakasekさんも参加してくれた。
各種アーキテクチャパターンについてのわかりやすい解説をしてくれたり、議事録をまとめてくれたり、最高でした。ありがとうございました :bow:

iOS設計本についてはダンボーさんからもオススメされたのでしばらく前に買った。年末に時間あるのでゆっくり読みたい。

f:id:hazeblog:20181031112028p:plain:w500

流れ

  • 自己紹介
  • ダンボー田中氏による基調講演: 設計とは？
  • 議論

自己紹介

参加者は9人ぐらい。

属性は iOS / BackEnd / FrontEnd / Infra? といった感じでした。

議論内容と個人用メモ

ほわいとぼーど

f:id:hazeblog:20181201235901p:plain:w600

f:id:hazeblog:20181202000444j:plain:w600

f:id:hazeblog:20181202000517j:plain:w600

f:id:hazeblog:20181202000545j:plain:w600

以下メモ

フレームワークに依存するお話

  • 手を抜くためにフレームワークを使う

  • Rails/Laravelと心中する？

  • 主にGo界隈で生SQLを書く、OR Mapperを使わないでモノを作るという話が出てきたりする

秩序を保ち続けるのは難しい

  • 「強いエンジニア」しかいなければ秩序は保たれる

  • 人の話になるけど、どう秩序を担保していくか、コントロールしていくかは重要

  • 理解が弱い人でも正しく使えば正しい設計になる、ということを期待してフレームワークを使うこともある

人への依存について

  • 組織のスケールを考慮から外せば、「レビュー」の仕組みで良い

  • レビューする人がいなくなる、のは組織が死んでいることを表している。秩序が無くなる＝そういうこと

  • ドキュメント化とレビューのタイミング: 後述

設計に関する共通認識が必要という話

うすうす感じてはいたけど、人が「MVC」と言うときに同じことを指しているというわけではない。
言語化する時点である程度はそうなるんだけど、同一のイデアを持てていないよね、っていう話がある。

MVCに限らず、〜〜アーキテクチャは全てそうなりがちだと思うし、色んな文脈で語られるDDDとかClean Architectureとかも多分共通認識が取れているかと言われるとそうでもないと思う。
（勿論正しく認識を取れている人が一定数いることは知っているんだけど、全員がそうではないよねっていう文脈です）

その共通認識を持つための議論は定期的に組織内でしたほうが良いだろうし、
新しい概念を社内で共有するより「現状触っている物事の言葉やプロダクトの設計について共通の認識を持つことのほうが重要なのでは？」と思ったりした。

MV* の話

speakerdeck.com

takasek先生がまとめてくれているスライドがある :bow:

アーキテクチャの分類

大きく分けて2つある
（上のスライドの5枚目）

  • GUI Architecture
    • MVC, MVP, MVVM, etc...
    • UIにどう関係するかどうか を基準に機能を分けている
  • System Architecture
    • Hexagonal Architecture, Onion Architecture, Clean Architecture
    • UIの部分だけでなく、Model部分の分類をしようとして概念が作られている

MVVM

  • （正しい） MVCのControllerとViewのロジック部分以外を合わせてViewと表現
  • ViewのロジックをViewModelとして切り出し

アーキテクチャの理解って本読んだりエントリ読んだりするだけだと理解できないよねという話

https://www.amazon.co.jp/dp/B00ZQZ8JNE/www.amazon.co.jp

DDDとかの概念をC#で丁寧に説明してくれている本とのこと

www.slideshare.net

Goにおけるレイヤ構造の実装の話

booth.pm

およびその本（買った）（積本が増えていく）

takasekさんにアーキテクチャをどうやって理解するの？って聞くと、本読んだ上で自分で実装している、とのこと。

名前付型付けと構造的型付けの話

聞いていて本当にさっぱりだった。

qiita.com

otiai10.hatenablog.com

Goにおけるインタフェースは、他言語のインタフェースとは定義が逆で、
他言語（Javaとか）は、データ側に設定されているけど、Goだと持ってくる側が形を指定する、とのこと、

型でなんとかなる部分と、そうでない話

「ID」が複数同じような形式であると型を定義していても取り違う可能性があるよね
（ user_id: 12345678 , terminal_id: 11335588 みたいな）

ドキュメント化とレビューのタイミングについての考察

レビューをする前の認識合わせが必要 という話をした。
コードを書く前に、どういうものを作るか、何を検討した上で、どういう設計にするのか、についてチームと合意をとる必要がある。
=> Design Doc

弊社事例

この辺の話は開発者ブログとかで紹介したほうが良いような気がしたけど、とりあえずここに書く。
（※この発言や説明や解釈は会社としてのアレではなく個人のどうのこうの）

Kaizen Platformでは、機能を開発するとき、改修するとき、何かしらある程度設計や動作確認テストを必要とするコード変更を伴う場合、Design Docというドキュメントをコードを書く前に書きます。

機能開発の流れを説明すると、
まず、Product Managerとか担当Engineerが、「どんなものを作るか、何を達成するためのものか」を明文化・定義するためのPRD（Product Requirements Document）を書く。
その次に、前述したDesign Docを書く。
そして、PRDとDesign Docをもとに、内容をPM+Engineer（+レビューEngineer）で確認して、OKだったらやっとコードを書き始める。

product issue（要望）
 ↓
PRD （製品仕様書、要求定義と必要条件）
 ↓
Design Doc （設計書、動作確認内容と考慮点）
 ↓
ソースコード

これらは開発時に使われる他、「どんな理由でこの機能を作ったか？」を示すログの役割を持っていて、Qiita::Teamにタグをつけて保管されています。
（ログ以外の役割として、リモートワークをする上での共通認識を作るため、および暗黙知を無くすためなどがあります）

当然、PRDやDesign Docに沿って正しく実装されたかは、レビューとQA（動作確認）で確認します。

「今のシステムを説明するためのドキュメント」

"Design Docを更新するか否か？” という話があり、何のために書くか、という話に落ち着く。
自分は更新すべきではない（前述した通りログ、Historyの意味合いを持つので）と思っている。

現状の仕様を確認する際に、機能ごとに分けられたDesign Docをさらい続けるのは正直きつくて、「今の仕様を表すドキュメント」が他に必要になる。

それの場所って、どこが良いの？という議論が最後のほうであって、とても考えさせられた。

GItHubリポジトリのREADME.md

リポジトリに閉じた話はこれでやるのが一番良さげで、HistoryもGitで管理ができるし、ソースコードと同じ場所にあるから参照がしやすい、また更新されやすい。
ただし、複数リポジトリに跨った仕様はどうするか？という話があって、意見がわかれそうなところ。
個人的には別途Issueとか複数リポジトリにまたがったドキュメントを管理する用のリポジトリを別途作っておいて、そこにサービス全体としての仕様を書いたりすると、なんか良いんじゃないかなと思う。管理大変だけど。

--

メモおわり

終わったあとはラーメンを食べました。おいしかったです（こなみ

f:id:hazeblog:20181202032458j:plain:w500

感想みたいなもの

ここ最近、「自分がどこを理解できていなくて、どうやってそれを深掘りして、理解できないことをどう説明するか、調べるか」みたいなことを悩んでいて、それの足がかりになるような話がいくつか出てきてとても良かった。
アーキテクチャの分類の話は自分の中でとてもすっきり頭に入って、なるほど〜となった。
と同時に、全く理解できていない概念が沢山あるんだなと思うような話もいくつかあって、一つの言語、アーキテクチャ、フレームワークを突き詰めるだけでなく広く視野を持っていくことの重要性みたいなものも感じた。
特に、Back-Endに閉じているとMVVMとかは全くピンと来ないし、モバイルアプリケーションだからこその設計もある、というのが面白かった。触ってみたい。

とても楽しかったし、勉強になりました。開催してくれたダンボーさん、会場用意してくれたnasaさん、takasekさん（先生）、一緒に参加してくれたみんなありがとう〜〜

「Cookpad Tech Kitchen #20 クックパッドのマイクロサービスプラットフォーム現状」に参加しました #cookpad_tech_kitchen

Enginnering

cookpad.connpass.com

Cookpad Tech Kitchen に ブログ枠 で参加してきました。課題となるレポートエントリです。

目次が長い＞＜

場所: クックパッド株式会社

恵比寿ガーデンプライスタワーに潜入するのは2回目。
この時期はイルミネーションで輝いていて、独り身にはつらい。

f:id:hazeblog:20181128235724j:plain
ビル前
（移動しながら撮ったからぶれまくっている）

オフィスはとても綺麗で、入った瞬間にめちゃくちゃ広いキッチンがある。羨ましい

info.cookpad.com

概要

クックパッドオフィスのキッチンで、開発について知見や学びを共有する勉強会「Cookpad Tech Kitchen」。第20回は技術部開発基盤グループから3名が登壇し、クックパッドにおけるマイクロサービスプラットフォームの現状についてお話したいと思います。

タイトル通り、マイクロサービスの運用に関するお話を3つ聞く会でした。

以下はその内容、およびそのメモ。と、補足。
一応参加してない人にとっても（前提知識があれば）理解できるように書いたつもり。

聞きながら買いたメモを書き直したり、わからなかった用語を調べてたら遅くなりました :bow:

＠クッ社の方々
間違っている表現、用語、説明があったら教えてください。修正します

挨拶/会の説明

@hogelog さん

Cookpadの技術部の説明

  1. 技術部？
    -> サービス全体、横断的な技術課題を取り組む部署

技術部の構成

  • モバイル基盤グループ
  • ユーザ決済基盤グループ
  • 品質向上グループ
  • 開発基盤グループ
    • お台場チーム （※ cookpad_all というでかいRail Applicationをどうにかするチーム）
    • プラットフォームチーム （マイクロサービス技術基盤の開発、および運営を担当）

サービスメッシュの構築と運用

発表者: @taiki45 さん

speakerdeck.com

Agenda

  • 背景の説明
  • クックパッドにおける課題
  • 導入
  • どんな良いことがあったか？
  • 次の課題

Cookpadの組織について

料理に関する様々なサービスを作っている会社です。
プロダクトは レシピ共有サービス（ cookpad.com ）がメイン

組織規模: サービス開発者は200+ , サービス数は100+
サービスチーム（サービス毎に存在） + SREチーム

使用技術はRailsがメイン。たまに他言語。

SREチーム（おそらく技術部）の目標

=> 現在中央集権的に行なっているサービス運用を、サービス毎に自律的にできるような仕組みを作ること。

もともとあった課題

  • 歴史を踏まえた運用の課題

立ち上げ当初はモノリシックな1つのRails Applicationを運営すればよかったが、今は沢山のアプリケーションがある。

「1つのアプリケーションが死んだら複数のサービスが落ちてしまう」
「サービスが増えて連携すればするほど障害がおきた際の根本原因の調査が難しくなったり、障害の対象範囲の把握が難しくなる」

といった課題が出てきて、運用方法をちゃんと考えよう、という流れになった模様

ソリューション

ライブラリとかマネージドサービスで楽をしたい！！！

Expeditor

github.com

マイクロサービス運営において、障害が起きた際に影響を小さくすることができるやつ、との説明がありました。
聞いたことがなかったので調べたら、クックパッドの開発者ブログが出てきました。
というかこのライブラリ自体、クックパッドのOSSだった。

techlife.cookpad.com

クックパッドの開発者ブログ曰く

リクエストを並行処理したり、よしなにリトライしたり、あるサービスで一定以上のエラーが発生したら、一定期間そのサービスへのリクエストを停止する。

もの。

AWS X-ray

AWS X-Ray (製品や分散アプリケーションの分析とデバッグ) | AWS

いわゆるDistributed Tracing, 分散トレーシングを提供するAWSのサービス。
サービスマップを良い感じにシュッと作れる。

ただ、これらは Ruby (on Rails) プロダクトであれば便利なんだけど、それ以外の言語/技術だと使えない。特にExpeditor。gemだし。
x-ray はAWSが頑張ってくれているから割と対象多いけど

サービスメッシュの検討と概要

言語ごとの対応とかは置いといて、「ネットワークプロキシを間に挟んで、それにアクセスをコントロールさせる」という方針が良いのでは、という話に。
その手法を取ることで、アプリケーションがどんな作りになっていても関係なく、ネットワークレベルでの制御が可能になる。

サービスメッシュ

SRECON America 2017での発表でSREチームが言葉を知ったことがきっかけらしい。

どんなもの？
-> 今までライブラリレイヤでリトライやサーキットブレイキングをしていたものを、外の別のプロキシに任せる
-> そのネットワークプロキシを、中央の別のもので管理する

中央管理にすることで、運営チームであるSREが管理をしやすく、分散していないため監視が行いやすく秩序を保ちやすい。

Envoyについて

www.envoyproxy.io

上記で説明した「ネットワークプロキシ」に該当するOSS。
当時（2017年前半）の段階では一番良いプロダクトだったので採用となった。
Istioという別のものがあったが、そちらはKubernetes前提で作られているプロダクトなこともあり、ECSを使っているクックパッドでは見送りとなったらしい。

サービスメッシュ、Envoy採用における目的と目標

Resiliencyの設定を一覧で見れるようにしたい

resiliencyの意味・使い方 - 英和辞典 Weblio辞書
Reciliencyという言葉がピンとこなかったのでぐぐった。 「弾性力」「回復力」といった言葉らしい。
話を聞く限り、リトライやタイムアウトに関する設定、リクエストの飛ばし先、その他諸々のネットワークプロキシが管轄する設定を全サービス分一覧で見れるようにしたい、ということっぽい。

クックパッドでは、（前半でもかいたけど）サービスを開発・運用する担当がサービス毎にあって、それらを横断的に見るためのチームが存在している。その横断チームのことを「中央」と呼んでいて、この後は説明が面倒なので "中央" と呼ぶ。

その中央で横断的にサービスを監視し、及びどういったプロトコルで通信をし合うかを管理・管轄できるようになることが今回の目的。

リクエスト量、その他諸々の可視化をするためにPrometheusを採用している。

仕組み

Envoyに便利なAPIがあるのでそれを使う。
各サービスのconfigファイル（アクセスポイント、リトライ秒数、タイムアウトの判断秒数など）はS3で保管する。それを元にプロキシの設定を行う。
JSONをやり取りするマイクロサービス: APIサーバはELBを使ってロードバランシングしているため、EnvoyはELBへアクセスする。
gRPCをやり取りするサーバはロードバランサに対応していないため、サーバへ直接アクセスする形を取る。

configファイルの詳細

Route Config: path毎に設定を記述する。リトライ、タイムアウト秒数など
Cluster Config: どこにリクエストを飛ばすか、といった設定を記述する。先はだいたいELB

EnvoyのAPI

Service Discovery Service API というものがEnvoyに生えていて、それを叩いて設定を変更したり諸々を適用する。
lify/discovery という参考実装が存在したが、要件が合致しなかったらしく cookpad/sds を自作した。らしい。

github.com

正直なところここら辺からよくわからなくなりました

Prometheusの画面紹介

障害が起きたときにどうなるか？

-> retry overflow counter などの値が異常値を示すようになる

何がよかったか？

一時的なエラーレートの上昇などの対応が、リトライやタイムアウトの設定によりだいたいなんとかなるようになった

それにより、エラーが多少起こったりしたとしても問題のない範囲でリトライを実施したりといった形で自動対処ができるようになった。
=> SRE等の運用コストが減った

configの中央管理化によるメリット

各サービス毎に各々で管理されていた設定が集まることで、適切な設定を行いやすくなった。
サービスレベルや、ヘルスステータスの一覧表示、状況の監視がやりやすく、わかりやすくなった。

これからのミッション

  • EnvoyのAPI（xDS）のバージョンアップなどを行なっていく予定とのこと

gRPC in Cookpad

発表者: @ganmacs さん

speakerdeck.com

2017卒とのこと

もくじ

  • これまでのサービス間連携
  • gRPC運用
  • rubyでのgRPC

これまでのCookpad

前からマイクロサービスは推進していた。
Garage, GarageClientでAPIを共通化してたり、Autodocでドキュメントを自動生成したりしてきた。

github.com

github.com

github.com

（Cookpadほんと色々gem作ってるな）

なんでgRPCを導入するのか

  • IDLとスキーマが欲しい
    • IDL: Inrerface Description Language
  • RESTだとマッピングつらい
  • 他言語も積極的に使えるようにしたい

gRPCについて

grpc.io

Protocol Buffersでの定義の紹介

grpc.io

シンプル

動作環境

  • hakoっていうツールを使っているらしい（Dockerのデプロイをするやつ？）

github.com

  • cookpad/sds + Envoy でClient Side Loadbalancing

slow startについて

※Slow Startって？
-> サーバを立ち上げた直後はリクエストの送信量を少なめにして、安定する（と仮定）に従って、少しずつ送信を増やしていくサービスイン時のやり方。

富士通のこの記事がわかりやすかった
負荷分散入門(ロードバランサ入門) 第8回 連続サービス機能 : Fujitsu Japan

サービスひとつに対し、 app コンテナ、 front-envoy コンテナ、 envoy コンテナ、registrator コンテナが立ち上がる。
動きは言葉よりスライドを見た方がわかりやすそう（12ページ〜）

speakerdeck.com

registrator がappにヘルスチェックしてくれるのが良い

サービス間通信の動き

Service1: App -> Service1: envoy -> Service2: ftont-envoy -> Service2: App

リクエスト送信をenvoyが、受信をfront-envoyが担当している

Protocol Buffersの管理

Protocol Buffers定義用のリポジトリがあってサービスごとにディレクトリがわかれてる

repos/
├── service_a
├── service_b
└── service_c

lintがあったり、ドキュメントを自動生成するツールが用意されていたりと色々楽そう

メトリクスを取る

Envoy Status っていう機能がEnvoyにもともとあって、それを利用
アクセスログはサービス開発者が1〜2行シュッと定義を書くだけで取ってこれるようになるらしい

Prometheus, Grafanaを使っている

Ruby / Rails でのgRPC実現

grpc っていうgemがある

grpc | RubyGems.org | your community gem host

grpc-tools gemでサーバ/クライアントのコードを生成してくれる、あとは実装を書くだけでOK

grpc-tools | RubyGems.org | your community gem host

Interceptorや一部ライブラリは自作

その他諸々

rails runner使っているとのこと
rakeはなんかハマるらしい :thinking:

griffin

github.com

gRPCのつらみ（CPU使いきれない toka Graceful Shutdownがなかったり toka 諸々）を解消するために作っているgem
grpc gemが良い感じになったら戻れるように互換性を気にして作っている

移行中らしいです

今後

Amazon ECS の安定運用

発表者: Kohei Suzuki さん

Twitterアカウントわからんかった(´･_･`)

speakerdeck.com

もくじ

環境

ほぼ全てのアプリケーションがECS上で稼働、一部Fargate。
（FargateにしているのはECSクラスタ自体を操作するやつとか、でかいCPU/Memが必要なジョブ）

ECSクラスタ: 40
ECSサービス: 500

コンテナインスタンスの管理

比率: オンデマンドインスタンス =1 / スポットインスタンス =4

オンデマンドインスタンスのオートスケール

AutoScaling GroupとECSクラスタが1:1
AutoScalingの役割 -> desired capacityを上下すればクラスタの増減ができるようにする / 障害時の自動復旧

Auto Scaling グループ - Amazon EC2 Auto Scaling (日本語)

スポットインスタンス

Spot Fleet
役割 -> target capasityを上下するだけでクラスタの増減ができるようにする / 障害時の自動復旧

EC2 Fleet – Manage Thousands of On-Demand and Spot Instances with One Request | AWS News Blog

サービスアウトの話

interruption noticeが通知されてから2分以内にサービスアウトをこちらでやらないと強制的に殺される。
自前でELBのtarget groupから外したら止める + 突然一部タスクが死んでも大丈夫なようにちょっと余裕を持ったキャパシティのプランニングをする

スケールイン、スケールアウトの基準

  • 共通: CloudWatchのCPU/Memory値
  • スケールアウト: 各サービスのdesired_count, running_count、バッチジョブがリソース不足で失敗したとき

ログ

コンテナのstdout, stderr

fluentd経由でAmazon S3保存、Athenaで検索できるようにしている。
CloudWatch Logsはログが多すぎて使い物にならなさそうだったので使わなかった＋高い とのこと

コンテナインスタンスのホストにfluentd -> fluentdの集約ノード -> S3

aws.amazon.com

モニタリング

アプリケーションコンテナのモニタリング

cAdvisor, Prometheus, Grafanaで実現

GitHub - google/cadvisor: Analyzes resource usage and performance characteristics of running containers.

今後

QAディスカッション

サービスメッシュ

retryの冪等性担保ってどうやってますか

  • getとheadはそのままでOK
  • postはパス毎に設定をしていて、「このパスはリトライ化」みたいにしてたり
    • デフォルトはオフ

istio検討してますか

  • 現状で問題ないと思うので。入れ替えて導入するよりは他のところにリソースを回したい

istio.io

gRPC

git submoduleつらくないですか

  • 特につらくない

grpc-webの導入って検討してますか

  • Envoyに便利な機能があって、フロントからgRPCで投げられてもすぐ対応できる？らしい

インタフェース設計の共通化とか

  • 基本的にインタフェースはこちらは関与せず、アプリケーション開発者に任せている

ECS

Kubernetes, EKS採用しないんですか

  • オートスケーリングツールを運用できるほどの人員の確保は難しい
  • ECSはマネージドなので良い
  • EKSはECSより現状使いづらいのでなし

OSSの運用しんどくないですか

  • そこまで
  • 英語でのコミュニケーションがつらい
  • 社内事情と強制的に区切らなければならなくなるため、分離ができて良い

ECSクラスタの分け方ってどんな単位

  • 用途＋セキュリティグループ
  • 具体的には、Web App用のクラスタ、バッチジョブのみ起動するクラスタ　など
  • オートスケーリンググループなどの設定がやりやすい、セキュリティグループを全て同一にしたくない

共通

マイクロサービス化の始めるタイミング

  • 規模が大きくなってきたら
  • コミュニケーションコスト＞マイクロサービス化のコスト になったらやる
  • 人数でいうと150+が目安？

質問2つぐらい聞き取れなくて抜けてます

中央部分の耐障害性

（ありがとうございます）

懇親会

キッチンで作りたてっぽい色々を食べました。おいしかったです

懇親会中にスタッフの自己紹介タイムが入ってたけど全然聞けてなくて残念

感想とか

100+ 規模だからこその取り組みという感じで、とても面白い事例を知ることができて良かった。
エコシステムや既存のツールをどう使って課題を解決していくかといった話に対して、自作ツールをガンガン作っていけるのはかなり強みな気がする。
とはいえやりすぎるとそれはそれでつらいので、OSS化したりするのは良いと思った。

Container, AWSのサービス群に詳しくなくて、その場で調べながら聞いていた。多分他の人もだいたいそうなんじゃないかと思う

実際に各々の環境で使っていくかはさておき、名前が出てきたツールやサービスは概要だけでもさらっておくと、たまに役に立つ気がするのでおすすめ。

要望、というか自分が気になったのは、今回はプラットフォームを作る側の話だったけど、 それを使ってサービスを作る開発者側の意見。
これによってどれぐらい楽になったか？とか、アプリケーション側でハマったところ、とか、気になる。

aws.amazon.com

ところで、AWS App MeshがEnvoyを中で使っているとのこと。共通点とか違う点が少し気になる。
まあ、東京リージョンには暫くこなさそうだけど。。。

Cookpad Teck Kitchenは初めて参加しましたがとても楽しかったです。また行きたい。
運営の方々、懇親会で話してくださった方々ありがとうございました！

「一番下手くそでいよう」のつらさ

□□ おしごと

最近進捗がnullでつらい。はぜです。
ここ一年色んなことで悩みっぱなしというか、思考がふらふらしていて、良くないなーって思いながら生活している
そう至る考えとか、現状の課題とか、そういうことの棚卸しをやっておくと今後何かと役立つだろうし、何か大きな選択をするときに指針になるかなって思って色々表現しようとずっと紙にまとめたり、たまにブログ書いたりしています。

参考:

hazediary.hateblo.jp

まあ、何かというと、このエントリもそういう類のものです。独り言です。

仮にもプログラマ/エンジニアという役割で仕事している人間ということで、それなりにインターネットで情報収集をしたり、土日にコード書いてみたりしているんですが、
業務外に勉強するしないとか、どうすればキャリアアップができるか、みたいな話でTwitterとかはてブとかQiitaで盛り上がっていますね。

で、よく話にあがる意識付けとして、「情熱プログラマー」の "一番下手くそでいよう" という言葉があります。
どういう意味合いかというと、すごく出来る人たち（＝自分が一番しょぼい）で構成されている環境に身を投げれば、その中で頑張ると自分の能力も環境に適応する形で伸びていく、というもの。

自分は偏差値的にも能力的にも低みの世界に居て（所謂誰でも入れる専門学校）、その数年間、周りと協力してコードを書いたり技術的な話ができず、一人でずっと勉強していたことがあり、そういうこともあって強い人たちがどれぐらいすごいのか、自分の範囲外の技術や物事を全く知らずに生きていた。
それを今かなり後悔していて、これからはそうならないよう、前述した 一番下手くそになれる 環境に可能な限り飛び込んでいるつもり、で、仕事していたり、コミュニティに入ってみたりしています。

とはいえ、それはそれでつらいものがある、ということを最近感じてきた。
つらい部分は、一言で言えば 自分がその人たちに対して価値を提供できていない、とか、役に立てていない、と感じること。

環境を変えることで、当然知らないような分野の知識を要求されたり、その業界だと当然知っているべきような知識が無かったりすることが最近多くて、ここに居て本当に良いのか、みたいな、ことを考えてしまう、というわけ。
特に仕事の場合は給料を貰って、福利厚生を得た上で働いているので、給料分の成果を自分が出せているのか、みたいなところに落ちてくる。

当然その足りない穴の部分を埋めるために本を読んだり、コードを書く練習をしたり、仕事をするわけだけど、いつまで経ってもその穴が無くなるわけではないような感覚になる。
「苦手な部分より得意な部分を伸ばせ」という感じの言葉もよく聞くんだけど、それ以前の、前提となる部分が足りなかったりするわけです。

エンジニアの学習って、手を動かす部分と、方法論みたいな部分と、座学等で知ることで理解できる概念的な部分があり、それを繋ぎ合わせて能力を身につけて行くんだけど
手を動かしている回数・量も足りていないし、方法論みたいなことも経歴としてほぼ存在しないし、概念の理解も環境を変えた瞬間に一気に内容が変わって、自分が足りている、得意とする部分ってなんだっけ、みたいな感じに。

少なくともこの環境にいることで能力値は上がっているし、知らないことを知ることもめちゃくちゃ多いし、自分の今後のことを考えるととても良いことなんだけど、
ちょっとずつ精神的に疲れてきた、という感覚がある。

少し休むべきな気はするんだけど、進捗の部分とか、単純に周りをみた時の差に追い詰められているのか、頭の中でずっと考え事をしてしまうことが多い。。

というか単純に余裕が無くて、どうやって時間作って勉強するんだろう　みたいになって短絡的な発想になりがち。良くない。

という状況。
直近だと年末年始の予定を全て空けていて、がっつり休む予定（外行っても人多いだろうしすることもないだろうし）なんだけど、それまで頑張り続けられるかなーってふと思って書いた。

職場は一言で言ってエンジニアにとっては最高っぽい環境だし、人はエンジニアも、営業も、他の職種の人たちもとことん（このエントリみたいなことを思う程度には）すごい人たちばかりだし、良いんだけど、自分が追いつけなくてつらい。というだけです。

どうあがいても一歩ずつしか道は進めないし、仕事でつよい人から学んで、自分でもできる範囲で効率良く勉強して、追いつくように、越せるように頑張るしかないんだけど、
とはいえ、疲れる。72時間ぐらいずっと寝ていたい。にゃーん。

日記: SPAでリロードしたら404になる問題, その他

雑記

トップページ以外でリロードしたら404になる現象が起きて、ちょっと考えたら、まあそうだよなってことですぐ解決した。

/works にダイレクトアクセスしたときに、それに対応するファイルが存在しないとindex.htmlに届かずにnginxに404で弾かれる。
冷静に考えたら当たり前だけど、react-routerが勝手にやってくれるやろって思って考えてなかった。
その手前で死ぬのか。なるほどな〜ってなった。

トップ（ / 、 index.html ）のリンクを踏んで /works に遷移するとreact-routerがルーティングしてくれて、index.htmlの div = root のまま更新する分のコンポーネントだけ再描画してくれるから問題が起きなくて、リロードだけ問題になる。この説明であっているかはわからない。。。

ちなみに、create-react-appで作っている途中だと、 webpackDevServer.config.js にhistory api foolbackの設定が書かれていて気付かない。nginxもかまさないし。

[nginx.conf]
...
        location / {
            try_files $uri $uri/ /index.html;
        }
....

try_filesは、最初の引数から順番にパスに合致したファイルが存在するかを確認するやつで、
$uri はそのまんまURL, $url はURLに / を追加したもの
それらが存在しなかったら、 rootdir/index.html を探しに行くっていう流れになる。（当然そのindex.htmlもなかったら404になる）

この辺の設定、あんまりちゃんと理解せずに適当にコピペしたりしていたけどそろそろちゃんと中身理解しておかないと変なところで躓きそう。気をつけよう。

wakateweb.connpass.com

若手エンジニアイベントで雑にLTした。LTすることを2日前まで忘れていて急いで資料を作ったら、7分の発表なのに30枚オーバーとかになって頑張って削った。
なぜか偶然前職の人がいたり、若手（なのに）でPerlを書いたことがある人が多かったり、色々あって面白かった。

市場価値と自分の技術に対する興味 - はぜにっき
前の記事にも書いたけど、大きな技術特化のイベントとかで話せるようなぐらい専門的な知識をつけたいなあって一瞬思ったりした。
でもその前に、仕事にも影響が出ている設計周りの知識と実感（？）の無さ、頭のついていかなさをなんとかしないといけないなーっていう気持ち
がんばろう

ポートフォリオサイトを作り直した

Enginnering

f:id:hazeblog:20181111232016p:plain

一気に素っ気なくシンプルなページになってしまった。

github.com

こんばんは。はぜです。

プロフィールページみたいなものを作った（仮） - はぜにっき

フロントエンドの知識が全くなくてつらい - はぜにっき

半年以上前に作った haze-page.tokyo というポートフォリオサイトをSPAにしてみました。
アイコンとかサイドバーは semantic-ui-react を使った。知ってる人は一瞬でわかると思う。

create-react-app-tsをejectして、 semantic-ui-react入れて、react-router, react-router-domを入れて中身書いたら終わった。
2時間ぐらいで出来ると思って日曜日の昼から手をつけ始めたら、思ったより自分がCSSを理解していなくて、重ねて表示ができなくて困ったり、意味わからん場所にテキストが表示されたりした。
ぐぐりながら脱線したり、戻ったり、semantic-ui-reactをうまく使いこなせずに気付いたら22時過ぎ。つらい1日だった。。。

create-react-app, デプロイの方法を全く調べずに作っていて、できた瞬間にやり方わかんねえ〜〜ってなって困るなど。
npm run build して、buildファイルをサーバに投げて、nginxのrootディレクトリ設定変えただけで終わった。最高。

jestとか、その他諸々の全く使っていないライブラリをどうにかしたい。
というか使えるようになりたい。

とりあえず頭に浮かんだ画面をどうやって描画していくか、の練習になったのでよかった。
次はAPIを叩いたり、他のライブラリを使って良い感じのサービスを作りたい。API設計とかまともにやったことないからそこらへんも調べたり練習しなければ。。。

市場価値と自分の技術に対する興味

□□ おしごと

「エンジニアとしての市場価値を上げるために、今自分に足りていないこれを勉強しよう」っていうの、出来ないんですよね。
社内の誰にも負けない範囲の能力が一つ以上あると存在価値が上がるだろうし、
それこそ本を出したり発表をしたりできるようなレベルだったら会社をやめたとしても他の会社でも同待遇で雇われることができたりするだろうけど。

なんというか、組織の課題を解決する・目標を達成するために自分に足りていないものを習得するのはできるんだけど
自分の市場価値を上げるためにとか、エンジニアとして自分が強くなるために、みたいな発想にならない。

一応、技術者として仕事しているからあんまり言わないようにしているんだけど、
自分自身はあんまり好きな技術っていうのとか、好きな言語とかって特になくて、
課題を解決するための仕組み（＝サービス）を作ったり、目的をどうやって楽に達成できるかを考えて、その時その時で必要な技術を習得してる。

最近はバックエンドエンジニアとして入社したけど、フロントエンドも見れた方がサービス・開発組織全体を俯瞰して見れそうっていうことでReactを触り始めていたり、
単純に機能開発で必要になるからRailsを触っていたり、社内のソースコードを読んだり、GraphQLがわからんって言ってる。

でもそこまで深い興味があるわけでもないから、rails/railsのソースを読もう！って気持ちには全くならないし、メンテナになりたい！とは思わない。
（オープンソースコミュニティへのコントリビュートは自分ができる範囲でやりたいとは思ってはいる。これは単純に自分のためというより、感謝の分を返したいという気持ちから）

なんでこんなこと書いてるかっていうと、
最近Microservicesやアーキテクチャ周りに興味が強くなっていて、なんでだろうなーって考えて、
プロダクト開発をする上で、変更に対する影響範囲を小さくして安心したものづくりをできるようにする、一つの機能の開発速度を上げるようにできる仕組みを確立することで、
最初の方に書いた目的の達成や課題解決に繋がるからなんだろう、ということな気がしたから。

Microservicesっていう技術や、各種アーキテクチャそのものに興味があるわけではなくて、それを使うことでどれぐらい開発が早くなるのか、改修が楽になるのかを知っていきたいっていう結論になった。

とは書いているんだけど、一個一個の技術に対して深く興味が沸いてないのって、深く技術を見れるほど精神的な余裕がないっていう現れなんじゃないかなあと感じたりしている
自分の思い出せる限り1年以上安心して過ごしている感はないし、常に危機感というか、現状に対する焦りがある、それを無くせば別の見え方ができるんじゃないかなーと思う

でもまあ、焦りの感覚が無くなったら自分何にもしなくなりそうだし、どうなんだろう。よくわかんないや。

日記: Pixel 3が届いた / semantic-ui-react を触っている

Enginnering

Pixel 3, 発表当日に予約して、今日届いた！！！！やったね！！！

操作感とかは他に詳しくレポートしてる人がたくさんいるから特に言わない。
下の常時表示されるボタンがPieになったタイミングで大きく変わったけど、1時間ぐらいで慣れました。

肝心のカメラは暫く使う機会がないです。再来週ぐらいに横浜に行くからその時に風景を撮ってみようかなー？

store.google.com

同封されているEarbudsは思ったより音が綺麗だった。長いこと付けてるとちょっと耳が痛くなったのと、有線だからあんまり使わないと思うけど。

Reactの学習を続けているんですが、本でも使われていたsemantic-ui-reactをいじって遊んでいます。
cssを読み込むのを忘れていて（読み込めっていうのはUsageに書いてある）数時間溶かしたので日曜日はかなり凹んでましたが、今は元気です
introduction見てすぐコンポーネントを見始めたのが良くなかった。ドキュメント読もう。。

ある程度自分でちゃんと画面を考えて、なんか作ってブログを書きたい。今週中かな

Microservices Meetup vol.9 (FiNC App & Frontend)に参加した！ときのメモとか感想レポート

Enginnering

microservices-meetup.connpass.com

FiNC Technologies社が主催するMicroservices Meetup の9回目に行ってきた、ときに学んだこととか、話したこととか、わからなかったことのメモ。
間違った点とかあったら優しくマサカリを投げてくれると嬉しい。

（関係者のツイートを無許可で埋め込んでいます。駄目であればお伝えください。消します）

自分の立ち位置

主にバックエンドエンジニアをやっている人。
Microserviceはちょっとだけ。（？）
最近フロントエンド界隈のことに興味を持ってきてReactの勉強を始めたけどまだ全体像を理解できていなくて苦しんでいる。
最近はエンジニア組織全体での開発効率の向上、コミュニケーション、長期的な開発部隊の経営、みたいなことを一エンジニアとして考えていることが多い。

各発表についてのメモ、と思ったこと

ウェルカムトーク「マイクロサービスとクライアント: 理想と現実の狭間で」

主催の @qsona sanのウェルカムトーク。
Meetupの主題である「マイクロサービス」そのものの利点と注意点を説明してくださった。
マイクロサービスにすればサービスが全て疎結合になるわけではない という話がなるほど、となった。
「どこで結合させるか？」「どこで動作を確認するか？（責任の位置）」ということを考えて作っていく必要がある。
で、その結合させる点がフロントエンドで、ユーザ体験を作るために複数のマイクロサービスを使う という感じになる。（＝ハブ）

後半ではFiNC社で取り組んできた内容についての紹介と、重要な概念であるBFFとMicro Frontendsについての説明。

最後のスライドが好き。

https://speakerdeck.com/qsona/ideal-and-reality-of-microservices-from-the-client-side?slide=21

ウェルカムトークだからのんびり聞くかと思ったらめちゃくちゃ濃い内容でびっくりしてしまった。これだけでも考えさせられるお話で有意義でした

「クライアントサイドから考えるマイクロサービス」

FiNC Technologiesのクライアントアプリ開発者の @neonankiti san のクライアントアプリケーションから見たマイクロサービスについてのお話。

マイクロサービスによってリソースの表現が違っていて、それを統合させることが難しい、というリアルな課題と、それに対する解決策としての腐敗防止層の流れ。
APIガイドラインとかの考え方もとても参考になる。「コンセンサスを取った上で開発する」ことが明示的になり、重要性が増して、安定した開発フローになる。

腐敗防止層については質問したら細かい定義と必要性について答えてくださった。
（👇のツイートだけじゃなくて上下のスレッドを見ていただけると。）

あと、 次の発表者である@takasek sanと一緒に "iOSアプリ設計パターン入門" という本を書いている @ktanaka117 san からも補足をもらった。ありがとう。

次の話。
リソースの表現の差異と似たような話が別レイヤで起こっている件としてiOS/Android間での実装や設計の違いがあるという問題があった。
iOS/Androidはチームが違っていて、かつ使う技術も違うということで分断しやすそう、という印象は確かにある
で、それを定期的なコミュニケーションを取ったり情報共有をすることで解決した という話だった。

最後にはビジネスインパクトを踏まえた組織構造についての説明。
エンジニアだけで固まるのは確かに良くない（と haze も感じている）。ビジネスを考えた上でのべき論だったり組織構造を考えていくことは重要だと感じた。

「マイクロサービスとクライアントとコンテキスト境界」

FiNCでiOS Appを作っている @takasek sanのコンテキスト境界をどこに置くか、というお話。
境界はチーム編成の輪郭に従う という重要な概念をさらっと説明されていた。

その後の話は自分にDDDの理解が無さすぎて正しく理解できなかった。つらい。
（そもそも今回のMeetupのサブタイトルがApp & Frontendなので理解しておけという自戒）

DDDをはじめとした設計手法について理解がかなり薄くて、結構最近の悩みだったりする。
と思ってたらslackでdanboさんに本を勧められたので買って読んでみることにする。みなさんもぜひ（？）

f:id:hazeblog:20181031112028p:plain:w600

peaks.cc

実践、BFF ~ BFFはFiNCのアプリで何を解決したのか ~

FiNCでAndroid Appを作っている @izmeal2000 san のBFFに重きを置いたお話。
BFFの説明がめちゃくちゃわかりやすいので読んでみてください。

FiNCでBFFを入れたことによる恩恵は3つあって、
- 通信量を減らすことによるパフォーマンスの向上
- 集約ロジックをBFFに集中させることで、クライアントが異なっても挙動を安定させられた
- BFF側にロジックを一部移譲することで、Appの申請をせずに挙動を変更させられるようになった
というもの。

後半はそれの具体的な説明をされていた。と同時に、集約することでのデメリットについてもお話されていた。
完全に一本に集約させると、マイクロサービスが一つ死んだら全てに影響が出てしまったり、一つレスポンスが遅いものがあるとそれに引きずられるといった問題についてはなるほど、となった。

最後にBFFの開発者は誰か、という話について。
一般的に「BFFはクライアント・フロントエンド側の責務で管理するもの」となっているらしく、今はまだアプリ開発者がBFFをガンガンいじれるようになっていないとのこと。
これについては"BFFはその組織にあっているか？"という一つの大きな問題に関わってくる部分。

これを聞いていて、「簡単に言うけどこれ実現するのくそむずくない？？」とずっと思っていて、懇親会で聞いたらなんかそうでもない感があって驚いた。
具体的な実装のイメージがついていないんだけど、レイヤをうまく分けて一部レイヤをBFFに渡すことでできるみたいな感じのことを言っていた（わかってない）。

DDD含めて、レイヤの感覚もいまいちちゃんと持ててなくてそれを実装に落とし込めないので追いつきたい。。。

「お礼ポイント投票機能をSPAに実装してMicro Frontendsを実践している話」

FiNCでフロントエンドエンジニアをやっている@nobuhikosawai san の発表。
資料見つからなかった。見つけたら追記予定。

Micro Frontendsに焦点を当てたお話。
そもそもMicro Frontendsとは？ から、具体的にどんな技術を使っていてどんな実装なのか？をソースコードレベルで説明してくださっていた。

Reactのeventハンドリングに負債があるらしく、 React Fire というプロジェクトで返済をしようとしている話とかが出てきて、知らないことずくめで面白かった。

github.com

なんか日本語で説明しているQiitaもあった

qiita.com

説明されていたソースコードはあんまりちゃんと読めなかった。つらい。（2回目）

スポンサートーク

finc.com

「健康に気を使っているレベル」の段階に合わせてサービスを考えているっていうのが印象に残っている。

健康...健康になりてえ...

飛び入りLT 「マイクロサービス開発に分散トレーシングを導入してみた」

Wantedlyのインフラエンジニアの @bgpat_ san の飛び入りLT。すごい。
Distributed Tracingをどう実現したか、という話。Open Censusという分散トレーシングの仕組み（規約？みたいなものっぽい）を使って実現しているとのこと。
社内共有ライブラリでシュッと入れられるものがあるの強い。

https://opencensus.io/opencensus.io

Rails + Datadog APMであれば、Distributed Tracingはかなり簡単に導入できる。

docs.datadoghq.com

Wantedlyでは、Application MonitoringはDatadog APMとStackdrive Traceを併用しているとのこと。 併用をするとなると確かにOpen CensusとかOpen Tracingを使う選択肢になる。なるほどなあ

話はずれるけどKubernetesに全サービス乗ってる話も聞きたい。

懇親会

食べ物が一瞬でなくなって笑った
FiNCの方々やWantedlyの方、それ以外にも様々な方と話をして有意義でした。聞いた内容は大体このエントリに散らばって書いている。はず。

iOSの設計周りについて議論コーナーがあって、さらっと聞こうとしたけどさっぱりわからなかったのでBFF周りの話を他の方としてました。にゃーん

ハッシュタグ

twitter.com

話している内容をまとめてくれている人とか、発表資料とか、懇親会で話されていた話を書いてくれている人がたくさんいました。よかった。

概念について、考察 等

腐敗防止層について

  • Microservicesを束ねて、リクエストをクライアントから受け付ける役割のもの。
  • 集約することでリソースの表現を（クライアントから見て）統一することができる、投げるレスポンスの内容の変更をしやすくする、リクエスト数を減らすことでのパフォーマンス改善が実現できる。
  • 腐敗防止層＝BFF というわけではない（そういう場合もあるけど）

BFFを誰が運用するのか？及び導入するかの論点

前述した通り、一般的にはBFFはクライアントサイドのエンジニアが開発・運用するものらしい。
FiNCの場合、iOS/Android Engineerがエンジニア全体でも割と多いように見えていて、だからこそ運用できている感がある。
どういうことかというと、組織の状況・人数構成によってBFFが正しく運用されるかどうかが決まる。

バックエンドが多くて、かつサービスが別れまくっていない場合は恐らく自分が質問に書いたようにリソース定義を完璧に作る方が実現可能性は高くて、
BFFを作るコストのほうが高くなる。

で、バックエンドが多くて、サービスが大きく別れている場合はどうするか、となると、BFFとはまた別のバックエンド側で管理するリバースプロキシみたいなものが必要になるような気がしている。
それか、BFFまでにはならないけどAPI Gatewayに集約するとか、諸々。

あとは、ネイティブアプリが存在していないケース。
提供するサービスがWebアプリケーションしかない場合だと、「クライアント間で要求する内容が変わる」みたいなことがなくなる。

BFFを複数個用意する話

冗長化ではなく、役割の違うBFFを用意していく、という話。
ツリー構造っぽい感じになる。現時点でこれやっている事例ってどれぐらいあるんだろう？

コンウェイの法則・組織構造

「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」 (原文: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.")

引用: メルヴィン・コンウェイ - Wikipedia

職能横断 / 事業部型 の組織構造かによって採用する技術も、開発する体制も、必要な人員も変わってくる。
前述している「BFFを導入するか？」の話にも被るんだけど、組織ごとによって必要となる様々なリソースは変わるので、他社事例とかは参考にすべきだけど、それをそのまんま社内に導入するのは待ったをかけたほうが良い、という話。

FiNCの場合はこういう前提だった。弊社はどうだろう？を必ず考える必要がある。

他　参考資料

公式の参加レポート。

クライアントサイドとマイクロサービスの難しい関係 — Microservices Meetup Vol.9 (FiNC App & Frontend) 登壇内容レポート #microserv

ウェルカムトークでも紹介されていた、Microservices Meetup の2回前（ vol.7 Micro Frontends）に関するエントリ。

medium.com

と、そこで行われたパネルディスカッションのレポート。

medium.com

あと何人か既にレポートを書いているっぽいので、ハッシュタグをさらって見てみると良いかもしれません。
※この記事は @haze_it_ac の色眼鏡を通して書かれています。

おわりに

microservices-meetup.connpass.com

ウェルカムトークから発表、懇親会まで全てが濃い時間でとても楽しかったです。
全ての内容を理解して吸収できなかったことがとても悔しいので、これから概念とか用語とかを理解していきたい。勿論実装も。

自分たちでも知見を作って共有できる側になりたいので、がんばっていきたいぞい

主催・運営の方々、発表者や話してくださった方々、ありがとうございました！

create-react-app(version=react-scripts-ts) で生成されたコードを読む

Enginnering

追記: 2019-10-20

なんかGoogle検索からこのエントリにきてくれる人がそこそこいるっぽいんですが、かなり前のVersionの時に書いたエントリなのでそこまで参考にしないでください。
現在はcreate-react-app 自体でTypeScript対応がされていてそちらが一般的なため、この内容とはおそらく大幅に内容が違います。

github.com

Microsoftが create-react-app のTypeScriptバージョンを提供しているらしく、それを使って React + TypeScript でアプリケーションを作る練習をしようとした。
んだけど、どういう手順で作って行くのかがいまいちよくわからなかったので、とりあえず生成された中身を読んでみることした。

github.com

create-react-app の本体リポジトリにもTypeScriptのサポートが入るみたいで試してみたけど、上手く動かなかったのでやめた。
（型の確認まではできるようになったけど、 ソースコードは .js のままで、全部書き換えないといけなかった。それはそれでTypeScriptの勉強になりそうだからそのうちやりたい。）

レベル感

自分は、Node.js を使った外のAPIを叩いたりJSONを投げるアプリケーションは作ったことはあるけど、フロントエンドに関しての実装はしたことがない状態。
jQueryも知らないし、画面描画に関わるJavaScriptのコードはほぼ全く読めないと言ってもいい感じ。

Reactは2回本の写経をしたけど、あんまりちゃんと理解していない。コンポーネントのpropsとstateの使い分けは本に書いてあったから雰囲気でわかる、と思っていたけど完全に忘れた。
TypeScriptは名前しか知らなくて、型付きのJavaScriptにコンパイルしてくれる便利なやつ という認識。
本の写経したとき雰囲気だけはわかったけど、細かい仕様はわかってない。

ソースコードを読む前にやったこと

前提となるES2015〜のJavaScriptの文法を確認する

初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発 を軽く読む。 jQueryの話、基本的なデータ構造周りの話は飛ばして、ちゃんと理解しているか怪しい部分だけさらった。
具体的には、 ジェネレータ（ function * ）、class、prototype周り。

TypeScriptの基本的な部分を理解する

Qiitaを読んだりした。
Typeのことがよくわからなかったが、Qiita: TypeScriptのInterfaceとType aliasの比較 で雰囲気は理解したと思う。

init-appをつくる

$ npx create-react-app init-app --scripts-version=react-scripts-ts
$ cd init-app
$ npm run eject

github.com

これができる。
npm run eject は、create-react-app側で良い感じにまとめられていたパッケージを分解する処理を走らせる。

eject前は、 package.jsonのscripts欄は

  "scripts": {
    "start": "react-scripts-ts start",
    "build": "react-scripts-ts build",
    "test": "react-scripts-ts test --env=jsdom",
    "eject": "react-scripts-ts eject"
  },

こうなっていて、ejectをすると

  "scripts": {
    "start": "node scripts/start.js",
    "build": "node scripts/build.js",
    "test": "node scripts/test.js --env=jsdom"
  },

こうなる。
react-scripts-ts という便利コマンドが作られていて、それを解除するという感じ。

ちなみに、 start を実行をしたときに走る scripts/start.js は以下。

create-react-app-ts-init/start.js at master · haze-it/create-react-app-ts-init · GitHub

初期状態では混乱しないようにパッケージングされていて見えなくなっている、ということ。
（そもそもejectをする前は /scripts ディレクトリが存在しない）

中身

読んでいきましょう。

起動 - scripts/start.js

起動コマンドは npm run start か、 yarn start 。

f:id:hazeblog:20181029210648p:plain:w300

さっきも書いた通り、 start を実行すると、 scripts/start.js が実行される。
create-react-app-ts-init/start.js at master · haze-it/create-react-app-ts-init · GitHub

まず、14行目で config/env.js が読み込まれている。

f:id:hazeblog:20181029211757p:plain:w400

config/env.js はこれ。

create-react-app-ts-init/env.js at master · haze-it/create-react-app-ts-init · GitHub

env.js の中では、キャッシュを消したり、 NODE_ENV が存在するか確認したり、 .dotenv ファイルを読み込んだり、 NODE_PATH を設定したりしている。

その後は、色んなモジュールを読み込んで

f:id:hazeblog:20181029213333p:plain:w500

起動するためのホスト（通常は 0.0.0.0 ）とポート（通常は 3000 ）を指定している。
（この下に書かれているものは Cloud9内で起動した場合に実行される内容なので飛ばす）

f:id:hazeblog:20181029213824p:plain:w400

そして、63行目の choosePort でポートを取得する。
f:id:hazeblog:20181029214159p:plain:w300

この choosePort メソッドは react-dev-utils/WebpackDevServerUtils から持ってきているもので、「指定のポートが空いていたら獲得し、空いていなかったらユーザに次のポートを取りに行くかを確認する」機能を持つ。
試しに3000番ポートを埋めた（別Appを起動させた）状態で npm run start をすると、以下のようなエラーメッセージが出て、 y とかエンターを押すと 3001番ポートを取りに行ってくれる。

f:id:hazeblog:20181029214700p:plain:w400

npm - react-dev-utils: WebpackDevServerUtils
便利。

choosePort が成功したら、HTTP or HTTPS、Appの名前を確認して、URLを設定して、

f:id:hazeblog:20181029215103p:plain:w400

webpackで各モジュールをバンドル（複数のファイルをまとめる）して、

f:id:hazeblog:20181029215353p:plain:w500

proxyの設定を package.json から取ってきて

f:id:hazeblog:20181029215633p:plain:w500

起動！！＋ブラウザを開きます。

f:id:hazeblog:20181029215754p:plain:w600

その下には Ctrl+C 押したりした時に終了する処理が書かれている。

f:id:hazeblog:20181029220650p:plain:w500

というのが start.js の処理。この辺を全部勝手に用意してくれる create-react-app便利だなーという感じ。

src/index.tsx

ここからReact。

最初に開かれるアプリケーションは src/index.tsx 。
これは paths.js の appIndexJs という定数部分に記述されていて、 webpack.config.[env].js の entry でそれを最初に実行するように設定されている。
（webpackの仕様）

path.js
f:id:hazeblog:20181029223008p:plain:w400

webpack.config.dev.js
f:id:hazeblog:20181029223132p:plain:w600

src/index.tsx
create-react-app-ts-init/index.tsx at master · haze-it/create-react-app-ts-init · GitHub

短め。

react , react-dom モジュールをimportして、
./App.tsx , ./index.css , ./registerServiceWorker.tsx を取ってくる。

App が実際のアプリケーションで、 index.css は普通のライブラリで、 registerServiceWorker.tsx は名の通りServiceWorkerの部分。

行なっているメインの処理はこれだけ。
ReactのDOMに App.tsx の中身 と index.html 内にある <div id="root"></div> を投げている。 f:id:hazeblog:20181029225225p:plain:w500

div root が HTMLElement にキャストされている。 HTMLElement は任意のHTML要素を表すものらしい。

HTMLElement - Web API | MDN

document.getElementById() は普通のJSのやつ。

Document.getElementById() - Web API | MDN

そのあとにServiceWorkerを走らせているけど、これは後述。

App.tsx

create-react-app-ts-init/App.tsx at master · haze-it/create-react-app-ts-init · GitHub

メインの処理部分。
react モジュールをimportして、cssとlogoを取る。

f:id:hazeblog:20181029231203p:plain:w600

Reactはコンポーネントという単位でUIを分けていて、その定義は、 React.Component を継承することで実現する。( extends React.Component ）

初期状態だとコンポーネントは一つしかないので、この App コンポーネントが画面全てを描画している。

f:id:hazeblog:20181029232224p:plain:w500

一般的なReactアプリケーションだと、entryにルーティング用のtsxをかませて、それでコンポーネントを出し分けたりするっぽい。

training-react-app/webpack.config.js at master · haze-it/training-react-app · GitHub

training-react-app/Routes.tsx at master · haze-it/training-react-app · GitHub

くるくる回るロゴは普通にCSS animationだった。（なんかのReactの機能を使ってると思ったら全然そんなことなかった）

f:id:hazeblog:20181029233132p:plain:w500

メイン処理は以上。

registerServiceWorker.ts

create-react-app-ts-init/registerServiceWorker.ts at master · haze-it/create-react-app-ts-init · GitHub

Service Workerってなんだ。雰囲気しか知らない。

developers.google.com

ブラウザ上の描画とは別に、スクリプトが実行できる環境が用意されていて、そこでプッシュ通知の処理をしたり、バックで処理走らせたりができるもの。
Webページ側の処理とは全く別のものなので、バックグラウンドで同期処理を走らせたりしても描画に影響はないみたい。便利そう。

registerServiceWorker.ts を読んでいく。

前半の事前処理で多用されている window.location について 。表示しているURLの情報とかを取ってこれるっぽい。
Window.location - Web API | MDN

envがproductionじゃないと登録処理がそもそも行われないようになっている。
f:id:hazeblog:20181029235801p:plain:w600

後ろの 'serviceWorker' in navigator は ブラウザが対応しているかを確認する処理らしい。
Navigator.serviceWorker - Web API | MDN

これは、動くworkerが別ドメインのものでないかを確認している。セキュリティ対策かな？
CDNを使ったりする場合はそのURLを入れたりする処理も必要になるっぽい。
f:id:hazeblog:20181030001128p:plain:w600

で、メインの登録処理と実行処理。
f:id:hazeblog:20181030001509p:plain:w700

swURL は、 実行するスクリプトのURLを入れている。
初期状態だとローカルホストでしか動かないようになっていて、 checkValidServiceWorker(swUrl: string) で、別のアプリのservice workerが登録されていないかを確認している。
（ checkValidServiceWorker は下の方で定義されている）

navigator.serviceWorker.ready.then(() => { .... } でserviceworkerを登録する。
直接DOMを編集できないので、 postMessage という機能を使って送り込む処理が必要らしい。その辺は別の記事を読んでください。

App.test.tsx

create-react-app-ts-init/App.test.tsx at master · haze-it/create-react-app-ts-init · GitHub

create-react-app-ts-init/README.md at master · haze-it/create-react-app-ts-init · GitHub

Testing-Components というものがあるらしい。
テストは追々で。

というわけで、一部雑に飛ばしたけど、メインの機能周りはこれでおしまい。
package.jsonとかtsconfigとか、configのpolyfill（ブラウザで対応していない機能を独自で実装するやつ）とかjest（テスト）辺りは後々深く見ていこうと思う。

とりあえず、次はイメージする画面を作る練習をいくつかする予定。

日記: NETATMO ウェザーステーションを買った

雑記

NETATMO(ネタトモ) ウェザーステーション スマホ対応 温度・湿度・気圧・二酸化炭素・騒音を測定 【日本正規代理店品・保証付き】

NETATMO(ネタトモ) ウェザーステーション スマホ対応 温度・湿度・気圧・二酸化炭素・騒音を測定 【日本正規代理店品・保証付き】

ここ最近寒くて起きるのと、そろそろ乾燥し始めて体調を崩しやすくなる時期ということもあって、部屋の状態把握ができると良いなと思っていた。

最初はCO2センサとか温度センサとかを買ってIoT的なことをしようかと思ったけど、思いの外CO2センサが高かったのと、調べてる途中でめんどくさくなってきたので既製品で良いか、となり、前から気になってはいたNETATMOの製品を購入。

説明書は海外製品によくある（？）、説明文がなくて図が順番に乗っている形式。
これがめちゃ分かりやすくて、最高の体験だったのでみんなそこだけは体験してほしい。

唯一、子機側の光る場所が地面に置くほうでそこだけびっくりしたけど、特に支障はなし。

親機はリビングの作業スペースに、子機は寝室に置いた。

セットアップが終わると、PCサイトでログインすれば部屋の状況が見れるようになる。

f:id:hazeblog:20181027084401j:plain

SPAのダッシュボード。
中心の表示内容をコントロールできて便利。レスポンスも早めで普通に体験として良い。

Angularだった。

アプリもiOS/Androidで提供されていて、ダッシュボード同様かなり見やすくて良い画面だと思う。

ダッシュボードとアプリが良い感じでもうこれでいいや〜感はあるんだけど、APIとSDKが提供されている。

dev.netatmo.com

適当にポーリングして、温度が一定以上に下がったら指定の処理を走らせたり、ウィジェットを作ってホーム画面に表示させたりができる。
なんか面白い使い方を考えたい。

とりあえずエアコンと連携させたいのでNeture Remoが欲しい。あれもあれでそこそこの値段するんだよな。