はぜにっき

日記です。(毎日更新ではない)

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

なにこれ

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

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

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

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-rayAWSが頑張ってくれているから割と対象多いけど

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

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

サービスメッシュ

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.jshistory 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を書いたことがある人が多かったり、色々あって面白かった。

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

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

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 を触っている

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

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

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

store.google.com

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


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

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