はぜにっき

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

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が欲しい。あれもあれでそこそこの値段するんだよな。

技術書典5 一般参加した

Enginnering

積本を減らす

日記: 試用期間が終わった - はぜにっき

こんにちは。積んでいる本が無くならないはぜです。
この記事はいつもの流れもへったくれもない雑な日記シリーズです。よろしくお願いします。

techbookfest.org

技術書典というイベントがあります。名前の通り技術に関する同人誌を売ったり買ったりする、エンジニア向けのコミケみたいなものです。
前回の技術書典4にも一般参加したのですが、今回も参加してきました。という話です。

前回とは場所が変わっていてサンシャインシティ隣の文化会館ビルでした、一回道間違えたけど行きやすかった。
整理券が無くて列が大変なことになってたけど、結構すぐ掃けたしすぐ入れたし中も結構広くて動きやすくて良かった。

会いたかった人たちにも大体会えたし、何故かハンバーグを2回食べたし、たくさん本も買えたので良い体験でした。
間違えて挨拶した人、逆に挨拶しそびれた人すみませんでした:bow:

ところで今回はアプリを一回も使わずに現金だけで特攻しました。大体の書籍が500円or1000円だったこともあってスムーズに会計できました。
QR決済って結構難しいなあと思うと同時に、iDとかsuicaとかのFelicaを使った決済がもっと一般に普及してほしいなと思ったり思わなかったり。
まあ認証難しいよなあ とか思うけど、そこらへんが一般に整備されてサクッと使えるようになるとスマホ持っていくだけで買い物できたりして便利なんだよね。
コンビニとかスーパーで使われている技術をもっと一般的に解放してくれたら良いなあ って。まあ色々グレーになりやすいんだろうけども...

Docker/Kubernetes本が読み終わったら今回買った本たちを一気に読む時間を取りたいなーと思っている。早く読まねば...

f:id:hazeblog:20181008212546j:plain

今回は "この本を買おう” と決め切らずに参加して、会場を2周ぐるっと回って雰囲気だけで買ってみた。
Webに偏っているのは置いといて、フロントエンドがちょっと多め。興味はあるんだけど手をつけられていない感がある。
やっていきたい

日記: 試用期間が終わった

Enginnering おしごと

入社して3ヶ月が経った

適当に思ったことを並べる。

体調

体調面は 睡眠障害（？）に悩んだり入院したりしたけど、今は元気なので良いことにする。

仕事の進め方

職場も家から歩いて5分の職場から自宅からのリモートワークがメインとなり、仕事の進め方がガラッと変わり、使う言語もプロダクトも変わる。
それは転職すると当たり前なんだけど、最初のうちは色々戸惑ったり焦ったりしてベストの選択を選べなかったり、普段だと普通にこなせることができなくなったりする。
それの矯正に3ヶ月掛かったのが少し心残りで、どうすれば良かったのか、次回環境が変わるときにどうなるかを考えている。

今回は使っている言語もツールもリモートワークも全てが初めて触れることだったということもあって、頭がパンク気味で焦りが強くなったのがよくなかった。
ただ、その焦っているという事実に最初の1ヶ月で気付くことができたのは良かったと思う。

自分が焦るタイミングは大体スケジューリング通りに物事が働かなくなる時だということを感づいたので、
2ヶ月目以降は敢えて自分もスケジュールをAsana/instaggantに入れずにやっていた（何も言われなかったのは有り難かった。ほんとすみませんでした）。
これで多少マシになった。

今でも手をつける仕事の8割〜9割は知らないことなので、どうやったら未知の物事を仕事に落とし込めるかをこれからの3ヶ月ぐらいで考えていきたい。

技術面

Railsをがっつりやると思ったら割とやっていない。
大きめのプロダクトの一部分（と言っても結構でかいけど）をいじり回していていて、Rubyを書くのは多少レベルアップした。と、思う。

Application Monitoringについて時間を割くことが多くて、これは今まで全く知らない方向のものだったこともあって面白く感じたし、勉強にもなった。

Front-End側は自分でちょっと勉強しただけで仕事ができるレベルにはなっていないけど、雰囲気だけ。
10月〜12月はもう少し時間を取ろうと思う。

大きな課題はコンテナ, Docker。
これまで使わなかったし使おうとも思わなかった（去年も動きが激しくてキャッチアップ大変そうだったし）けど、ついに必要になってきたかーとなり、
同時に一通りがっつり理解するには良い本が出てきたという話も聞いたのでやっていこうと思う。

次の3ヶ月（〜22歳、2018年の間にやっておくこと）

体調

  • 入院しない
  • 体調が原因で仕事を休まない（社会人になってから体調が理由で休んだのほぼ無いはずなんだけどな）

仕事

  • 未知の領域に対する多少の恐怖感をなくすこと、良い取り組み方、キャッチアップの方法を考える
  • 情報の整理で悩まなくなる

技術面

  • Rails でAPI Server作れるようになる
  • GraphQLの理解とRESTとの組み合わせについてどっかで話せるようになる
  • SPAで画面作れるようになる
  • Docker/Kubernetesの本読んで理解する

なんかめちゃくちゃハードなこと言ってる感あるけど、上3つは7月〜準備をしているのでやっていくだけ。時間を作ってうまくやる

他

  • 勉強会そろそろ行きだしても良いと思うのでいく、LTしたりする（9月は1回した）
  • 積本を減らす

f:id:hazeblog:20180930205527j:plain これは今日整理した本棚。
いにしえの技術（Java Servletとか、MySQL4とか...）本と、情報処理技術者試験の本がこれの3倍ぐらいあったけど今後読まないだろうし捨てた。
本棚の左側に積んである本と、一番下の左側に積んである本がまだ読んでいない（or読んでいる途中）のもの。多いね。
予定が無い日とかは丸一日寝続けていて無になるので、少しずつ読んでいきたい。今日も寝てたけど。

まとめ

全体的にふんわりと課題を見つけたり、やっていきたいことの雰囲気を掴んだ3ヶ月だった。
技術的にもビジネスマン？的にも色々と課題があるけど、その辺が見えるようになってきただけマシという気持ちになっておくことにする。

彼女欲しい。

日記: BAROCCO MD600を買った

雑記

www.archisite.co.jp

買いました。

先日、だいたい新卒エンジニア向け技術交流会 vol.16に行ってきたんですが、その前に行われていたもくもく会でこれをおすすめされて即Amazonでポチりました。

ここ最近 肩凝りがかなり酷かったこともあって欲しかったんですよね。

FNを押しながらじゃないとEscや矢印が打てなかったりするのがまだ慣れてないですが、肩が広がってかなり楽 。操作も使っていればすぐ慣れるでしょう。
この機会だしホームポジションが一列ずれているのも直そう。

日記: 定期弁当宅配サービスを検討している／高校数学をやり直す／APIの歴史を振り返る／iPad Pro欲しい

雑記

コープデリ

ほぼ毎日リモートワークをしているのでずっと自炊をしているのですが、
独身の一人暮らし、めちゃくちゃつらくて辞めたいんですよね。

何故というと

  • 冷蔵庫のコントロールがめんどい
  • スーパーに野菜買いに行くのも割とめんどう
  • 頑張って作っても自分しか食べない
  • 時間掛かる
  • ここまで頑張っても一人だと全然安くならない、作る内容によってはコンビニで買ったほうが安い

という。険しい。
適当にウインナー焼いて卵焼き作ってご飯炊いて、みたいな朝ご飯とかなら全然良いんだけど、3食ちゃんと食べるとなると結構大変。
あと胃腸で入院した身ということもあって、食生活を真面目に考えていかないとなあという心意気にもなっていて、それを考えると更に大変になってしまう。。。

そういうわけで真面目に色々ぐぐってみたら、生協コープが健康的な弁当を毎日届けてくれるサービスをやっていることがわかり、試してみようという気持ちになっています。

というか安い。
一食520円。税込561.6円。
月〜木（金曜は出社する想定）で1日2食 届けてもらう考えで行くと、21日2561.6 => 23587.2円ぐらい。 全然良い。

そのうちコープの人が資料持って説明しにきてくれるらしいので、とりあえずそれを待つことにする。

高校数学をやり直す

新体系　高校数学の教科書　上 (ブルーバックス)

新体系　高校数学の教科書　上 (ブルーバックス)

新体系・高校数学の教科書 下 (ブルーバックス)

新体系・高校数学の教科書 下 (ブルーバックス)

買った。
高校数学、II + B までしかやってなかったから、正式には「やり直す」じゃなくて「やる」なんだけど。

仕事も仕事以外でも数学が必要だと感じるタイミングはかなり多くあるのと、そもそも数式に対する恐怖感がある状態でソフトウェアエンジニアやっていけないやろ という気持ちから手をとった。
とりあえず気が向いたときにさらっと読んでいるけど、一通り読んだ後にもっかい見てノート残しつつ頭に叩き込むぐらいの気持ちでやりたい。

英語はひとまず停止中。必要なことはわかっているけど、英語学習よりも優先度が高いことが多い＋必要な時間に対してのメリットが少ない気がするので後回し。。。

APIの歴史を振り返る: Webを支える技術・Web API The Good Partsを読んだ

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Web API: The Good Parts

Web API: The Good Parts

入院中に読んでいた2冊。
Railsの本を読んでいるときやそれ以外にもRESTful APIが出てくる。
それに、普段叩いているAPIも大体RESTfulなんだけど、そもそも「RESTful API」の定義をちゃんと理解しないまま使っていて、割とずっともやっとしていたので読むことにした。

結論からするとRESTful APIの定義が割と雑に使われていることがわかって微妙にもやっとしつつ、まあ大方内容は理解したと思うので良いことにする。
次はGraphQL APIについてまとまった本を読む予定。

iPad Pro + Pencil 欲しい

Pixel 3が日本で発売されるっぽいので全裸待機中。と同時に今メインで使っているiPhone8がいらなくなるので売り払ってiPad Pro買いたい。
iPad ProとPencil買ってお絵描きしたいっていうのは1年以上言い続けているけど、絶妙な優先度のせいで結局未だに買っていない。
そろそろ欲しい。

でかい4Kディスプレイがめちゃくちゃ良い

雑記

f:id:hazeblog:20180913224005p:plain

リモートワークの様子です。
なんかパッと見が浪人生の机っぽい感じがしますが、ここで仕事をしています。角砂糖は辛くなってきたときに齧る用。身体に悪い。

机はIKEAの200cm*75cmの板に高さ調節のできる脚をつけたやつです。

【Amazon.co.jp限定】LG モニター ディスプレイ 32UD60-B 31.5インチ/4K/VA 非光沢/HDMI、DisplayPort/スピーカー搭載/高さ調節対応

【Amazon.co.jp限定】LG モニター ディスプレイ 32UD60-B 31.5インチ/4K/VA 非光沢/HDMI、DisplayPort/スピーカー搭載/高さ調節対応

本題のディスプレイはこれです。三週間前ぐらいに買って使っているんですが、端的に言うと最高です。
31.5inchなので、首を動かさずに大体一望できるし、文字が潰れないので普通に読める。（コンタクトをつけた状態で視力1.0~1.1）

買った時より5000円ぐらい値段が下がっていてちょっと気分が落ちた。

f:id:hazeblog:20180913224228p:plain

4Kなのでこういうことができる。
作業しているメインで使うウィンドウだけMacbookProのディスプレイに写して、他は外部ディスプレイに投げる。
近いウィンドウを見れば集中はできるし、途切れてきたら上の方を眺めて休憩としてTwitterを眺めたり溜まったslackを見たりしてやっている。

これに慣れてきたせいか、オフィスに行ってMacbookProのディスプレイだけにすると、地味にウィンドウ移動でつらく感じる様になってしまった、この点が一番のデメリットかもしれない。

入院していた

雑記

前兆。

日曜日の夕方に氷結を一本飲んで、ピリ辛きゅうりを食べて「明日仕事か〜9月だしもう入社して2ヶ月経ったのか」みたいなことを考えていた。
夜に軽くお腹を下していたけど、元々お腹はゆるくてしょっちゅう下しているので（これはこれで駄目）気にせず寝た。

朝の4時半に異常な鳩尾の痛みと、息ができなくて目が覚めた。
飛び起きようと思ったけど上半身が持ち上がらないし、そもそも力を込めて息をするのが精一杯な状態になっていた。
で、力を入れれば入れるほど痛みは増えるし、このままだと息出来なくなると思って気合いで声を出して救急に連絡。近くの病院に搬送された。

鳩尾が痛かったけども、痛みの種類はなんか覚えがあって、搬送されながら思い出すと高校の頃になった虫垂炎だった。
痛みの場所的には胃だから、胃潰瘍か何かだと思ったら急性胃腸炎だった。ついでに小腸にガスが溜まってて腸閉塞かと思われた。

というわけで月曜日から木曜日まで入院していました。今は退院して家に帰ってきています。
入院している間に平成最強の台風が来て地元が大変なことになっていたり、来週旅行に行く予定の北海道で大地震が起きていてびっくりした。

入院中に思ったことを適当に下にまとめてあります。緊急入院する際にでも思い出してください。

やることない問題

高校の時の盲腸で同じように緊急入院したときに何も持っていかなくて死ぬほど暇だったことを思い出して、救急を読んでから車が来るまでの間に、日曜日に買ったWebを支える技術とWeb API The Good Parts、スマホの充電器を鞄に入れて持っていった。
おかげで3日半入院していたがほぼほぼ暇にならずに済んで良かった。持って行かなかったらずっとTwitterで暴れているところだった。

とはいえこれは家に居て、救急車は呼ばないといけないけど最低限動ける状態で、かつ物を持って来てくれる家族や友人がいない時にしか意味がない。
自分は東京で一人暮らしだし、親や兄弟は全員関西に居るし、東京に居る友人は全員仕事だし、彼女もいない...。彼女ほしい。つらい。

点滴してても腹は減る

仕方ないとはいえ、めちゃくちゃきつかった。
急性胃腸炎なので当たり前なんだけど、胃腸を休めるために1日以上絶食をしなければならない。1日半経てば、胃の中身がなくなってお腹があいていくのがわかる。
で、胃腸が大丈夫そうになったら流動食で少しずつ胃腸の働きを戻していくんだけど、まあ流動食なのでスープとか重湯なわけで、全然お腹は膨れないしまあつらかった。

まあ食べられるようになっても、満腹まで食べるのが結構怖くて7分目ぐらいに抑えているんだけども。

いつ退院できるかは直前にしかわからない

退院直前に「あなたは急性胃腸炎で、こういう処置をしました」っていう説明を受けるんだけど、それまで自分の身体に起きていることはふんわりとしか伝えられない。
（まあこれは病院とか医者によるんだろうけど）
3交代で看護師さんが変わっていくので毎回いつ退院できるかと、そもそも身体の状態って初期はどうなっていて今どんな感じなのかを聞き続けていたんだけど、これがまあ毎回全然違ってかなり困惑した。
他は良いとしてこれだけはなんとかしてほしかった...つらみ...

家の鍵を閉めよう

鍵、空いてました。
1Fエントランスに入る前の扉がオートロックなので何とかなった。アパートとか一戸建てとかだったら大変なことになってそう。

眼鏡を持っていきましょう

普段はコンタクトで、外したらすぐベッドに入る生活をしていたせいか、救急車を呼んだときに眼鏡がどこにあるか分からなくて周りが見えない状態で搬送された。
右目がPWR -3.5で、一応何があるかぐらいはわかる程度には見えたので何とかなった。本は頑張って読んだ。

病院食

看護師さんが うちのご飯はあんまり評判が良くない と言っていたけど普通に美味しかった。
唯一、流動食のときに出てきた既製品の濃厚流動食だけめちゃくちゃきつい味がして飲むのが大変だった。
ディストピアの世界観の漫画でコレ飲むだけでOK、とか、ブロックみたいなご飯とかが出てくるけど、飲み物がこれだったら最悪だなーとか思った。
少し前に話題になった完全食COMPとか、BASE PASTAとかも試しに買ったけど口に合わなかったし、そもそも自分がこういうの苦手なだけかもしれん。

痩せると思ったら痩せなかった

全然変化無し。5kgぐらい減ってくれても構わないんだけども。
まあ全く動かなかったし冷静に考えると痩せる要素はそんなに無い。筋肉も少ないし。

体力はこれから戻していきますが、ひとまず退院して家でご飯作ってPC弄れる程度には回復しました。心配してくださった方ありがとうございました。

Reactの雰囲気はわかってきたけどサクッと画面作れるっていうレベルになるまでは結構時間かかりそう

Enginnering

hazediary.hateblo.jp

7月末にパンダの本でReactをちょっとやったんだけど、完全に記憶から消し飛んでいたからもう一回やりました。
最後はそれのメモが書いてあります。参考になれば。

タイトルの話

とりあえずイメージしている画面をサクッと作れるようになるまではひたすら演習っぽい感じでUIを作り続けるしかなさそう semantic-ui-reactしか使ってないけど、それっぽい感じの画面になるしひとまず慣れるまではこれで良いか感

ひとまずまだ本読みながら演習やるしかしてないから、自分で適当にAPIとUI考えて作ってみよう

React.Component

  • 表示要素の単位。UIとロジックをまとめて定義してる

Props

State

  • コンポーネントにおける状態をあらすための変数
  • constractorで初期値をセットする

ライフサイクル

  • Componentが
    • Mountされたら
    • Unmountされたら
    • Propsを受け取ったら
    • Updateされたら
    • など
  • を条件にして実行されるメソッド群を使って、ライフサイクルに沿った処理を行うことで画面を描画したり変更したりする

shouldComponentUpdate(nextProps, nextState)

  • 基本的に, propsやstateが変更されたらComponentは再レンダリングされるが、しなくても良い場合があったりする
  • shouldComponentUpdateはprops, stateが変更されたら呼ばれて、trueを返却したらレンダリングして、falseを返すと何もしないように処理を分けることができる
  • this.props.foo !== nextProps.foo みたいな条件でやっていく
  • npm init -y で package.json が生成される
    • package.jsonの scripts が便利

npmでとってくるものたち

$ npm i react@16.2.0 react-dom@16.2.0
$ npm i react-router@4.2.0 react-router-dom@4.2.2
$ npm i semantic-ui-react@0.78.3
$ npm i axios@0.18.0
$ npm i -D @types/react@16.0.40 @types/react-dom@16.0.4
$ npm i -D @types/react-router@4.0.22 @types/react-router-dom@4.2.4
$ npm i -D typescript@2.7.2 ts-loader@4.0.1
$ npm i -D webpack@4.1.1 webpack-cli@2.0.10 webpack-dev-server@3.1.0
$ npm i -D tslint@5.9.1
$ npm i tslint-config-typings@0.3.1
  • react-router: routing機能のパッケージ
  • semantic-ui-react: UIコンポーネントのパッケージ
  • axios: httpクライアント

使うAPI Server

  • https://us-central1-haze-development.cloudfunctions.net/v1

Endpoint

  • /channels/:cname/messages
    • GET: メッセージ一覧の取得
    • POST: メッセージ送信

ディレクトリ構成

.
├── dist
│   ├── img
│   │   └── avatar.png
│   ├── index.html
│   └── js
├── package-lock.json
├── package.json
├── src
│   ├── Routes.tsx
│   ├── client.ts
│   ├── components
│   │   ├── ChannelList.tsx
│   │   ├── MessageFeed.tsx
│   │   ├── MessageForm.tsx
│   │   └── index.ts
│   └── containers
│       ├── Channel.tsx
│       └── index.ts
├── tsconfig.json
└── webpack.config.js

+ node_modules

  • dist/ が実際にブラウジングする際に使われるところ

    • dist/js/ にbuildされたjsが吐かれる

  • src/components がcomponentsで

  • src/containers がcomponentsを束ねた上位のcomponentでロジックを定義する部分