はぜにっき

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

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

□□ おしごと

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

技術書典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ヶ月だった。
技術的にもビジネスマン？的にも色々と課題があるけど、その辺が見えるようになってきただけマシという気持ちになっておくことにする。

彼女欲しい。