風邪っぽいので肉を食べて元気を出そう大作戦です
— はぜ (@haze_it_ac) 2019年1月17日
自分の作った飯がうまい2019
— はぜ (@haze_it_ac) 2019年1月17日
リモートワークしてると朝昼晩すべて自炊ができるようになる。おかげで段々料理の腕が上がってきていて良い感じ。
この前低温調理器も買ったので、ローストビーフが無限に安定して作れるようになって最高だったりします。
去年、機能の存在自体を知らずに損することが多かったのでとりあえずと思って読みました。
使う予定のなさそうだったり、興味が全く湧かなかった部分は飛ばしてざーっと「どんな機能があるか」をさらった。
半分以上は忘れていると思うので、随時ぐぐりながら、たまにrails/railsを読みながら少しずつ深く理解していけたらなと思う。
そろそろ外向けの何かを作れたらなーって思うけど、思いつかないうちはサービスのクローン作ったり、公開されているコードを読んだりする方針で良いかなあ。
ネスプレッソ エスプレッソマシーン エッセンサ ミニ ピュアホワイト D30WH
Nespresso ネスプレッソ エアロチーノ ブラック 3594/JP/BK 日本正規品
バルミューダのパンと一緒にコーヒーを飲むと幸せになれます。
牛乳泡立て器であるエアロチーノは買う予定ではなかったんですが、ヨドバシカメラで試飲させてもらったら最高だったのでセット購入しました。
楽に美味いものが食べたり飲んだりできると文明を感じて良いですね。
AWS Amplify Console -> Netlify
— はぜ (@haze_it_ac) 2018年12月28日
こんなエントリを書いたりしたんですが、historyApiFallbackの設定のやり方がわからなくてリダイレクトが上手く行かなかったり、東京リージョンがなくて遅くて結構つらかった。
この本を買ってシュッと読んで、公式ドキュメントのRedirectsページ読んでたらこっちのほうが良くない？？ってなったので即移行しました。
DNSの設定とかNetlifyのほうが楽で良かった。
あとついでにポートフォリオサイトをCSS in JSにしました。emotion-jsにしたのは会社で使ってるからです。
Heroku Private Spaces, Enterpriseにしないと使えないのか
— はぜ (@haze_it_ac) 2019年1月2日
雑にサービス作ったりしたいってなった時に、デプロイ先って今どこにすれば良いんだろうなーって思って少し調べています。
Herokuは東京リージョンは数万かけないと使えないっぽいし、EC2は監視とかデプロイ面倒だし、VPSはもっと面倒くさそう...
今時はRails使わずにNode.jsとかをLambdaに乗せて手軽にサーバレスAPIサーバなんだろうか
3月までに55kgまで戻す＋骨格筋を標準まで上げる pic.twitter.com/Wes4D2XP1C
— はぜ (@haze_it_ac) 2019年1月1日
2016年4月段階では45kgだったはずなんだけど、いつの間にか60kgになっていた。
運動不足だし酒も結構飲んでるし仕方ないかなあという感じなんだけど、お腹も柔らかくなってきたのでなんとかしようかと。
家で酒飲むの控えるのと、運動したりするかなーって思っています。
バルミューダ スチームオーブントースター BALMUDA The Toaster K01E-KG(ブラック)
昨日の忘年会？みたいなので貰ってしまった🍞 pic.twitter.com/SUC11fxOPO
— はぜ (@haze_it_ac) December 14, 2018
会社のYear End Partyのじゃんけん大会で勝って貰いました。やったね。
— はぜ (@haze_it_ac) 2018年12月27日
— はぜ (@haze_it_ac) 2018年12月27日
— はぜ (@haze_it_ac) 2018年12月27日
パンめっちゃ美味い
— はぜ (@haze_it_ac) 2018年12月27日
最高。朝はパン派に転派します。よろしくおねがいします。
パンが美味いっていうのは当然っちゃ当然なんですが、それ以外も本当に良い。
前方2つのロータリスイッチはとても軽いのに回すたびにカチッという心地良い音が鳴るし、トーストの間は1秒ごとにカチカチ良い音がなる。
トーストを始めてから10秒ぐらいで水蒸気が出てくるんですが、それを眺めるのも結構楽しくて、貰って嬉しい食べて美味しいというものでした。
こうなるとコーヒーも美味しいものを淹れたくなってくる。
ネスカフェ ドルチェグスト ドロップ レッドメタル MD9774RM
今はネスレのカプセルのやつを使ってるんだけど、豆から作るやつも用意してみようかな。おすすめ教えてください。
きっと君は来ない
— はぜ (@haze_it_ac) 2018年12月24日
ひとりきりのクリスマスイブ
｜
｜
＼(´･_･` )
(| |)::
( Ｙ /:::
(ノ＼:
＼
クリスマス、如何お過ごしでしたか。
3連休は泥酔イベントが3連続だったので酒を飲み続けていました。年末年始も飯＋酒イベントばかりなので太りそう。心配です。
タイトル通り、今年一年の総括ということで、色々振り返っていこうと思います。
完全に忘れていたけど、年初になんか書いていた。
会社も変わったし、事情も色々変わったので全く参考にならないけど、一応見ておこう。
100は貯めてない。
必要ではなくなったので切羽詰まらず生活していた。
ちょっとだけ給料の少しは貯蓄用口座に投げつけている。貯めることに力を入れるより稼いだ上で残していく方針で行きたい。
受けてない。
〜20の間に基本情報/応用情報/データベース/セキュリティを取っていて、冷静に考えたら別にネスペ取っても仕事に活きることなくね？という気持ちになったので放置に。
今の界隈（Web / スタートアップ？）に居る間は必要にならないだろうし、来年も多分受けずに行くと思う。
7月に転職をしていて、去年と比べると年収が約150万円ほど上がっています。めでたい。
来年もこれぐらい上げたいけど、結構厳しそう。頑張りたい
. ∧_∧ ミ ＿ ドスッ
— はぜ (@haze_it_ac) 2018年12月23日
(´･_･`)┌───┴┴───┐
/ つ. 彼女募集中 │
～′ /´ └───┬┬───┘
∪ ∪ ││ _ε３
゛゛'゛'゛
よろしくおねがいします。
7月に転職をして、今はKaizen Platformという会社でApplication Engineerをしています。
周りはつよい人達ばかりで、毎日知らないことを考えたりぐぐり続けて、Qiita:Teamにポエムを投げてやっています。
本当に学ぶことが多くて給与分の見返りができているか怪しいけど、半年が立って少しずつ落ち着いて動けるようになってきました。
まだまだ一線でバリバリやっていきには程遠いので、少しずつ頑張っていきたい所存。
今のところ毎年転職していますが、来年はしないようにしたいですね
少し脱線。
給料の話、だいたいの会社（弊社もだけど）や社会全体でクローズド気味な話題なんだけど、オープンにしても良いんじゃないかと思っています。
透明感のある評価制度が好きなので、VOYAGE GROUPの技術力評価会とか、GMOペパボのGitHub公開評価PRとかに憧れがある。
業界全体でオープンな感じになっていけば色々良い感じになると思っているんですがどうでしょう。
ということで、自分も書きます。
2018年の源泉徴収票上での給与総額は4,861,045円でした。昨年が340万程度だったので、大体150ぐらい上昇しました。
社会人3年目 / 満23歳にしては良い額なんじゃないでしょうか。
2019年は650を目標にしていますが、あんまり現実味が無い。本業もそれ以外も頑張っていきたい気持ち。
「自分が何したいのか」をここ一ヶ月考えていますが、まだ全然答えが見えていません。
眼の前の仕事を全力でやっていくのが今は良いとは思うんだけど、とはいえ先が見えないと足がすくむ人間なので自分で道は作っておきたい。
とりあえず来年は本業以外でも仕事を持ったり、自分で考えてプロダクトを作って利益を少しでも出すことを目標にしたい。
Actions on Googleハンズオン参加した - はぜにっき
「LINE Pay APIによる決済機能を実装しよう」勉強会に行った - はぜにっき
Microservices Meetup vol.9 (FiNC App & Frontend)に参加した！ときのメモとか感想レポート - はぜにっき
「Cookpad Tech Kitchen #20 クックパッドのマイクロサービスプラットフォーム現状」に参加しました #cookpad_tech_kitchen - はぜにっき
今年はいろんな勉強会に行った。
インフラ業、バックエンド業、フロントエンド業をすべてかじった仕事をしていたので範囲が広く、結局自分はなにが強いのか？というのは悩みとしてあるけど、色々広く視点を持てるのは良いかなと思っている。
来年はもうちょっとサービス作りとか、自分の触っている技術を深く掘り下げていくことに力を入れたい。
https://haze-page.tokyo/activities
LTでお話をするようになった。
ある程度自分の考えをまとめる作業が必要になり、自分の考えとかやっていることを振り返る良い機会になる。
LTのために色々考えるのはあんまり自分は合わないと思うので、人に話せる良い仕事/趣味をしていくことを意識してやっていきたい。
来年はLTだけじゃなく、20分〜とかの登壇をしっかり準備して話したい、し、そういう発表ができるような経験も掴んでいこうと思っている。
一年半で17kg太ったら案の定健康診断に引っかかったので生活習慣を改めていく - はぜにっき
おそらく人生で一番体調を崩していた期間が長い一年だった。
今もずっと咳をしていて、病院で薬をもらっている。
入院したのは本当にきつくて、ただでさえ絶食して身体がボロってなっているときに1週間で6桁が一気に飛んでいくのは結構心に来る。
最終的に高額医療費控除である程度返ってきたから良いものの。。。
生活リズムも一時期治っていたけど少しずつ崩れ始めていて、今も崩壊気味なのでなんとかしていきたい。
でも今直しても年末年始でまた崩壊するので年明けからやっていきます...
バックエンド業（Rails）、フロントエンド業（React）の精度を上げたい。
共に入社前には触っていないものであると同時に、現時点で裏側の仕組みをまともに理解せずに触っているので表面しかわかっていない。
「どう使っている技術が動いているのか」「どう作られているのか」「どうすればいじることができるのか？」を知るのは必須だと思うので、やっていきたい。
と同時に、OSSへのコントリビュートとか、そういうところにも手を出せると良いなと思っている。
技術だけではなく、サービス設計、組織などについても考えていきたい。
"なんか違和感があるけど言葉にできない" ということが今年は多くて、そういったことは減らしていきたいしアウトプットとして表に出す努力もしていく。
自分で考えたものを作って、公開して、利益を出す までをやりたい。
利益は大きく出したいというわけではないけど、マネタイズとか、今後きっと考えていかざるを得ないことを先取りしてやるには趣味開発が一番良いと思っているので、色々試していきたい。
仕事で得た知識を趣味で使って、趣味で得た知識を仕事で使うのを繰り返したい。
アウトプットを増やしたい。
今年は意識して増やしたつもりだけど、思ったより少なかったし質の面でも良いとは言えなかった。
来年は量は同じぐらいで良いけど、安定して、良いアウトプットを出していきたい。
LTも、登壇もタイミングがあればやっていく気持ち
とりあえず昼寝がめちゃ長いのと、寝起きが最悪なこと、生活リズムがすぐ崩壊するのをなんとかしないといけない。
肩凝りが悪化しすぎて肩が上がらなくなったりもしたので、定期的に整体とかマッサージに行くべきかなあと思ったりもしている。
あとは入院しないこと...
キャリアの話も被るけど、今後何やっていくかは割と不透明な分、わかってきたときに選択肢が狭くなっていてほしくない。
わかりやすく言うと、例えば "海外で働きたい" てなったときに、英語だとかビザで落ちるとかはなりたくない。
し、大学院に行って論文が書きたい、ってなったときに、専門卒だから無理、みたいなことになりたくないわけで。
色々考えたんですが、とりあえず基礎教養としての英語とか諸々を勉強する口実も兼ねて学士を取ることにします。
放送大学が学費も安いし、高校レベル〜の英語の授業もあったのでそれをやってあとは自分で頑張っていこうと思っている。
お金も投げるからやらざるを得なくなる、はず。やっていきたい
というわけで来年も結構色々詰め込んでやっていくつもりです。
身体ぶっ壊さないようにがんばります。来年もよろしくおねがいします。
この前のre:Invent 2018でAWS Amplify Consoleっていうのが発表されて、丁度使う機会があったので使ってみたよ。
あと2ヶ月弱でGCPのクレジット消滅するからどうすっか
— はぜ (@haze_it_ac) 2018年12月20日
GCPの無料枠を使って、g1-small のCompute Engineにnginxを入れて、ソースコードを中に投げて運用してました。
で、deployは 手元で npm run build して、生成された /build ディレクトリをsshでぶん投げる っていうのを雑にスクリプト書いて叩いてやってました。
まあ、それもそれで面倒なのでどこかのタイミングでgithubにpushしたら良い感じにデプロイしてくれるように仕組みを作ろうかなーと思っていたところ。
そもそもAWS Amplifyっていう静的サイトのホスティングサービスがAWSにはあって、それにいろいろ機能が付きましたよっていうのが、re:Inventで発表された内容。
その追加機能の中に、GitHub/GitLab等にpushすると勝手にデプロイしてくれるCD機能があったので、それを使っていこうという感じです。
今回デプロイするリポジトリはこれ。
AWS コンソール画面のサービス一覧から AWS Amplify を選んで作成を押すと、トリガ/ソースコード元となる連携先を選ぶ画面になる
で、認証したらリポジトリとブランチを選んで
buildの設定（create-react-appで作ってたらそのままでおっけーっぽい）をして、環境変数を設定して、
ポチッと押すと、
デプロイがはじまる。
で、うまく行ったら、デプロイ先のURLリンクが出てくるからそれを押せば、デプロイされたページが出てくる。
便利じゃん。。。
ドメインはお名前.comで取っていたんですが、お名前.com側でDNSネームサーバをRoute53に向けて、Amplify側でドメインを設定すればおっけーでした。
お名前.com <-> Route53 の部分はこのエントリを参考にした。わかりやすい。
上記エントリに従ってRoute53側でドメイン設定ができていれば、Amplify Consoleの「ドメイン設定」で連携が一瞬でできます。便利。
というわけで https://haze-page.tokyo をAWS Amplifyに移したログでした。
サーバレスだしCompute Engineよりは安いやろ！という勘で移行したんですが実際毎月いくらぐらいの請求になるんでしょうね。
ところで、東京リージョンがまだ対応してなくてオハイオリージョンでやっているので結構遅いです。画像も小さくしてないから更に描画が遅い。。。
ちゃんとWebサービス作ってその上に乗っけるんだったらCDN必須っぽいですね。そういうのも今後やっていきたいです。
さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー2.0
この本を読んで、ウェブテストを受けた。
本には、「不得意なことにたくさんの
時間をかけて克服するよりも、得意なこと・才能があることに時間をかけて特化しよう」といった内容が書いてある。
自分は学生の頃、英語や漢字の暗記がとても苦手で、試験期間中ずっとその勉強をしても平均の点数さえ取れなくて諦めた覚えがあり、耳が痛くなった。
まあ今は知っている中で一番得意であろう分野で仕事をしているので良いと思う。他の仕事できる気しないし。
このウェブテストは、性格診断っぽい質問を答えると自分の「強み」がわかるというテストで、弊社のマネージャ研修などでも活用されている。
かなりの実績があるっぽく、参考程度になるかなと思ってやってみた。
ストレングス・ファインダー受けてみたけど案の定最高に自分勝手な頭しててウケる
— はぜ (@haze_it_ac) 2018年12月9日
納得感がある。
テストを受けると、「強みの理解レポート」と「自分だけの特徴的な資質レポート」が出力される。
「強みの理解レポート」を一部抜粋。（引用の枠を超えているんだけど、自分用のレポートだから良いよね...？）
「学習欲」の資質が高い人は、学習意欲が旺盛で、常に向上を望んでいます。結果よりも学習すること自体に意義を見出します。
あなたは本能的に、 自分の研究や仕事関連の任務で優れた能力を発揮するために必要であれば、どんなことでもすることがあります。 これが、あなたのやる気をそぐような人がいるチームよりも、一人で課題に取り組むことを好む理由の1つなのでしょう。
おそらくあなたは、 あれこれと考えを巡らせたり、興味深い話題について読んで検討したりする静かな時間を好みます。 あなたは、邪魔されずに思考できる時間が得られると、大きな喜びを感じます。 あなたは、自分のアイデアを徹底的に検証するため、騒がしく、気ぜわしい、集中できない状況から逃れようとするはずです。
多くの場合、あなたは、 ときどき、難易度が高かったり、課題の多かったりする講座に登録することがあります。 特定の物事について自分の知識を広げたり考えを試したりしたいのでしょう。
今回の転職理由がそのまま書いてあって笑った。
"必要であれば、どんなことでもすることがあります。"
この前書いていたエントリのお話ですね。
「内省」の資質が高い人は、知的な活動に多くの時間を費やします。内省的で、知的な議論が好きです。
おそらくあなたは、 1人で思索にふける時間を切に求めています。 自分の知的好奇心をかき立てるものなら何についても考えます。
毎週時間を取って自分のアイデアを追求することは、喜びであるばかりか必要な活動でもあります。
あなたは、沈黙が長く続くと心から安心感を覚えます。 なぜなら、 沈黙のおかげであなたや他の人たちは、歴史の流れや人々の生活を変えるような理論を検討したり、何かを発案したりできるからです。
あなたは、 さまざまなアイデア、理論、または概念について疑問を呈する傾向があります。
あなたは普段、結論を出したり、新しいアイデアを提示したり、状況を違う観点から見たり、詳細な質問をしたりする前に、よく考えを巡らします。
多くの場合、あなたは、 自分の本質や自分の存在理由に関する質問と戦っています。
学習欲に近しい部分が多い。
基本的に出社せず家でリモートワークしているのは、一人で居られる時間が多いってのも理由の一つだったりする。
オフィスに行っても端っこのソファに座ってもくもくしているのも同じ理由。
雑談が嫌いなわけじゃないんだけどね
「自我」の資質が高い人は、大きな影響を与えることを望んでいます。独立心に富み、組織や周囲の人々に与える影響の大きさに基づいてプロジェクトに優先順位をつけます。 多くの場合、あなたは、 ときどき、個人的なまたは仕事上の特定の目標を達成するためにがんばります。 これには、昇給、昇進、学位の取得、あなたが価値を置くものの取得、または認証プログラムの完了などが含まれますが、これに限るものではありません。 あなたは本能的に、 個人プレーヤーであり、自分が達成したものを人々に確認してもらうことで、彼らに影響力を行使します。 あなたは、 仕事を自分の私生活の中に切れ目なく織り込みたいと思っています。 この2つを線引きして分けることはしません。 おそらくあなたは、 いつも、さまざまな専門上の問題に対処するために必要な強みを持つことを認められたいと考えています。 他の人にあなたが重要人物であると見られたいため、わかりづらい情報をマスターしたり、高度に特化した能力を獲得したりしようという気になるようです。
承認欲求ですね。
「目標志向」の資質が高い人は、目標を定め、その目標に向かってまい進し、目標達成に必要な修正を行うことができます。優先順位をつけてから、そのとおりに行動します。
おそらくあなたは、 自分が達成すべき物事を的確に把握します。 そしてそれに専心します。
多くの場合、あなたは、 一人で仕事することを選ぶことがあります。 そうすれば、あなたがこれからの数週間、数か月、数年、数十年に実現したいことを綿密に計画することがずっと容易にできるかもしれません。
必要であれば、会話を実際的または事実的なものに戻す役割を担うこともあります。
あなたは、 自分自身の週間パフォーマンス目標を設定することに真剣に取り組むことがあります。
あなたは、 時折、事実を強調し、他の人に真実の方向性を示すことがあります。 あなたはだまされやすい人の目を覚ますようです。
事実に基づくあなたのスタイルの手助けで、他の人は共通の基盤を見いだすのかもしれません。 完全に同意に至るようなコンセンサスが得られることがあるかもしれません。
ずっと悩んでいるのは、何を持って"事実"と認識するかどうか。最近ここが雑になっていて、事実ではないことを事実と思い込むことがある。
仮説検証の能力をつけると、もっとうまくできるのかなーって思ったりしている。
"多くの場合、あなたは、 一人で仕事することを選ぶことがあります。"
自分のコントロール権限がある仕事をしたいっていう話かな
おそらくあなたは、 ときどき、今後数週間、数か月間、数年間、数十年間で達成できることを考えることがあります。
改善できることを考えるだけで、あなたが特定の仕事で成果を上げる原動力になります。
あなたは本能的に、 これからの数週間、数か月、数年、数十年に、世界や自分自身をどのようにしたいのか心に思い描くことがあります。生まれながらにして、あなたは、 今後数週間、数か月間、数年間または数十年間に到達可能なことに関して革新的な構想を練るために、自然と多くの時間をかけます。 あなたは、専門分野に集中しているとき、発明家、空想家、夢想家としての行動を見せることがよくあります。
あなたは、 今後数週間、数か月間、数年間、数十年間の内に、よりよくできることについて想像することがあります。 あなたには、改善したり、改良したり、また完成させたりできる事柄が、鮮明に見えているでしょう。
またあなたは、環境や自分自身、周りの人、システム、プロジェクト等において、変える必要のある点についても判断することができます。
多くの場合、あなたは、 自分の選んだ将来を形作ることにたっぷり時間を取ります。 そして頻繁に、今後数か月、数年、数十年で可能性のあることに関する自分のアイデアを共有します。 おそらくは、自分のイメージした生き生きとした詳細をあなたが語ると他の人の注意を捉えるのでしょう。
スタートアップっぽい感じのことがたくさん書いてある。
ビジョン・ミッションを明確に定めている環境に行きたかったので、そうだなあ、と思いながら読んだ。
全体的に納得感がある。というか自分本位なのがよくわかる。
同時に、やっていることがそこまで間違ってなさそうという安心感が出てよかった。
今後もしばらくはスタートアップ企業でエンジニアを続けていくんだろうな、と思いました。
本を読んでいると "大学院などに興味を持つでしょう" って書いてあって、去年大学院行こうと思って色々調べてたり、今は仕事しながらでも行ける通信制の大学に出願しているので良く当たるもんだなあと驚いたり。
書籍にも書いてあるけど、世の中には様々な考え方をしている人がいて、それぞれのパターンをある程度知ることで仕事でのコミュニケーションを円滑に進めて行ける可能性が高くなるので、やったことがない人はやってみると良いと思う。
@haze_it_ac はこういう考えなので だいぶ面倒な人間だと思いますが、今後もよろしくです。（？）
なりました。めでたい。
23歳になった
— はぜ (@haze_it_ac) 2018年12月5日
20歳を超えてからは嬉しい気持ちは無くなりました。めでたいって言いましたが特にめでたくもないですね...
今日は有給取って1日中寝てやろうかと思ったんですが、入社時にもらった有給は試用期間中に入院して消滅していたんでした。普通に仕事です。
22歳は何していたかというと、前職でChefをいじったりチャットボットを作ったりして、今の会社に転職して、APMを調べて、RailsとReactを触り始めていました。
今回（？）はどうなるんでしょうか。正直もう転職と引っ越しは面倒だからやりたくない。
新卒（20歳）のころは5年後こうなっていたいとか、10年後はこういう立場になっていたい みたいなことを考えていたんですが、今は1年後すら想像ができないです。5年後なんてもう。
今。何がしたいかみたいなところはある程度わかるんだけど、1年後にそれを達成していたら次はどういうことをしたくなるかが全くわからないですね。
で、今後自分はどうなっていきたいんだろう っていうのを考えるために、自分が大切にしている考え方みたいなものを最近は考えていたんですが（ 市場価値と自分の技術に対する興味 / 「一番下手くそでいよう」のつらさ ）、うまくあらわせないし、割と短期的な目線でしか物事考えてないっぽいし、今後に繋がるわけでもなかった。
その代わりに、自分の気持ちとか、その時々の感情には正直に向き合えるようになってきた気がします。悪く言えばわがままになったんですが、それでも良いでしょう。
このエントリも本当は "今年を振り返って〜〜" みたいな感じでゆるく総括するつもりだったんですが、発散しまくりで無理でした。
あと1年ぐらいは色々考え込んだり方向転換しても許されるんじゃないかと思ってます。パートナーもいないし（？）。
もう暫くはこんな感じでふわふわ生きていると思います。23歳のはぜもよろしくお願いします。
技術ブログ書かねばなんだが、ポエムしか書けないのでダメ
— はぜ (@haze_it_ac) 2018年12月6日
こんにちは pic.twitter.com/M7Ffy6evUi
— はぜ (@haze_it_ac) 2018年12月3日
eufyよりちょっと大きい pic.twitter.com/fNpJbPyY5F
— はぜ (@haze_it_ac) 2018年12月3日
11月末に890だけがビックカメラで30,000円引きになっていて、よくみたらポイントが余っていて、気付いたらポチっていた。
写真の通り、これまでは eufy という、Anker製のちょっと安いロボット掃除機を使っていました。
これはこれで安いしちゃんと仕事してくれるしちょっと小さいので一人暮らしには丁度良いんだけど、7月に1LDKに引っ越したタイミングで取り残しが発生するようになってしまった。
ので、適当なタイミングでグレードをあげようかな（上位互換としてeufy 20というものがあります）と思っていたんだけど、まさかルンバのWiFi対応モデルがここまでやすくなるとは。。。。
まだ一回しか走らせていないけど、力強い動きをしてくれていて安心感がある。
その代わり、ちゃんと固定できていない家具（軽い椅子とか）がぶつかって少し動いてしまうけれど、それはまあ仕方ない。
ルンバにはバーチャルウォールという機能があって、どういうものかというと、デュアルバーチャルウォールという付属品を適当な場所に置くと、その周りだけは立ち入らないようになってくれる。
はぜハウスでは衣類乾燥機があって、その下に排水用のバケツとか2Lペットボトルを置いていて、それを倒されると大惨事なのでこれが重宝する。
これまでeufyを使っている時は、掃除させる前に避難させていてちょっと手間だったんだけど、バーチャルウォールを使うことで避難しなくてもよくなり、最高。
というわけで良い買い物っぽい。長持ちさせたい。
お古になったeufyはクリスマスイブに男友達にあげる予定。はぜサンタです。よろしくお願いします。
若めのエンジニアこみゅにてぃで「設計よくわからんのだが」みたいなことを話していたときに、 ダンボー田中さんが提案・開催してくれたので参加してきたレポ。
主催側の経緯や、話の流れについてはダンボーさんのエントリを参照してくださいな。
tanakalivesinsendai.hatenablog.com
会場はLINE株式会社のセミナールームでした。 nasa9084 さんありがとう。
ダンボー田中さんと一緒にiOS設計パターン本を書いたtakasekさんも参加してくれた。
各種アーキテクチャパターンについてのわかりやすい解説をしてくれたり、議事録をまとめてくれたり、最高でした。ありがとうございました :bow:
「iOSアプリ設計パターン入門」執筆企画スタート！著者一同、内容練りこんで盛りだくさん（これはページ溢れるから表紙裏に入れようとか相談するレベル）でお送りします。クラウドファンディングです。応援いただけると嬉しいです！https://t.co/b68hcJFEZC #peaks_cc #技術書クラウドファンディング
— takasek (@takasek) 2018年5月22日
iOS設計本についてはダンボーさんからもオススメされたのでしばらく前に買った。年末に時間あるのでゆっくり読みたい。
参加者は9人ぐらい。
属性は iOS / BackEnd / FrontEnd / Infra? といった感じでした。
以下メモ
手を抜くためにフレームワークを使う
Rails/Laravelと心中する？
主にGo界隈で生SQLを書く、OR Mapperを使わないでモノを作るという話が出てきたりする
人の話になるけど、どう秩序を担保していくか、コントロールしていくかは重要
理解が弱い人でも正しく使えば正しい設計になる、ということを期待してフレームワークを使うこともある
レビューする人がいなくなる、のは組織が死んでいることを表している。秩序が無くなる＝そういうこと
ドキュメント化とレビューのタイミング: 後述
うすうす感じてはいたけど、人が「MVC」と言うときに同じことを指しているというわけではない。
言語化する時点である程度はそうなるんだけど、同一のイデアを持てていないよね、っていう話がある。
MVCに限らず、〜〜アーキテクチャは全てそうなりがちだと思うし、色んな文脈で語られるDDDとかClean Architectureとかも多分共通認識が取れているかと言われるとそうでもないと思う。
（勿論正しく認識を取れている人が一定数いることは知っているんだけど、全員がそうではないよねっていう文脈です）
その共通認識を持つための議論は定期的に組織内でしたほうが良いだろうし、
新しい概念を社内で共有するより「現状触っている物事の言葉やプロダクトの設計について共通の認識を持つことのほうが重要なのでは？」と思ったりした。
takasek先生がまとめてくれているスライドがある :bow:
大きく分けて2つある
（上のスライドの5枚目）
https://www.amazon.co.jp/dp/B00ZQZ8JNE/www.amazon.co.jp
DDDとかの概念をC#で丁寧に説明してくれている本とのこと
www.slideshare.net
Goにおけるレイヤ構造の実装の話
およびその本（買った）（積本が増えていく）
takasekさんにアーキテクチャをどうやって理解するの？って聞くと、本読んだ上で自分で実装している、とのこと。
聞いていて本当にさっぱりだった。
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をさらい続けるのは正直きつくて、「今の仕様を表すドキュメント」が他に必要になる。
それの場所って、どこが良いの？という議論が最後のほうであって、とても考えさせられた。
リポジトリに閉じた話はこれでやるのが一番良さげで、HistoryもGitで管理ができるし、ソースコードと同じ場所にあるから参照がしやすい、また更新されやすい。
ただし、複数リポジトリに跨った仕様はどうするか？という話があって、意見がわかれそうなところ。
個人的には別途Issueとか複数リポジトリにまたがったドキュメントを管理する用のリポジトリを別途作っておいて、そこにサービス全体としての仕様を書いたりすると、なんか良いんじゃないかなと思う。管理大変だけど。
--
メモおわり
終わったあとはラーメンを食べました。おいしかったです（こなみ
ここ最近、「自分がどこを理解できていなくて、どうやってそれを深掘りして、理解できないことをどう説明するか、調べるか」みたいなことを悩んでいて、それの足がかりになるような話がいくつか出てきてとても良かった。
アーキテクチャの分類の話は自分の中でとてもすっきり頭に入って、なるほど〜となった。
と同時に、全く理解できていない概念が沢山あるんだなと思うような話もいくつかあって、一つの言語、アーキテクチャ、フレームワークを突き詰めるだけでなく広く視野を持っていくことの重要性みたいなものも感じた。
特に、Back-Endに閉じているとMVVMとかは全くピンと来ないし、モバイルアプリケーションだからこその設計もある、というのが面白かった。触ってみたい。
とても楽しかったし、勉強になりました。開催してくれたダンボーさん、会場用意してくれたnasaさん、takasekさん（先生）、一緒に参加してくれたみんなありがとう〜〜
Cookpad Tech Kitchen に ブログ枠 で参加してきました。課題となるレポートエントリです。
目次が長い＞＜
I'm at クックパッド株式会社 in 渋谷区 https://t.co/rz0B34kPHI
— はぜ (@haze_it_ac) 2018年11月28日
恵比寿ガーデンプライスタワーに潜入するのは2回目。
この時期はイルミネーションで輝いていて、独り身にはつらい。
オフィスはとても綺麗で、入った瞬間にめちゃくちゃ広いキッチンがある。羨ましい
クックパッドオフィスのキッチンで、開発について知見や学びを共有する勉強会「Cookpad Tech Kitchen」。第20回は技術部開発基盤グループから3名が登壇し、クックパッドにおけるマイクロサービスプラットフォームの現状についてお話したいと思います。
タイトル通り、マイクロサービスの運用に関するお話を3つ聞く会でした。
以下はその内容、およびそのメモ。と、補足。
一応参加してない人にとっても（前提知識があれば）理解できるように書いたつもり。
聞きながら買いたメモを書き直したり、わからなかった用語を調べてたら遅くなりました :bow:
＠クッ社の方々
間違っている表現、用語、説明があったら教えてください。修正します
@hogelog さん
cookpad_all というでかいRail Applicationをどうにかするチーム）発表者: @taiki45 さん
料理に関する様々なサービスを作っている会社です。
プロダクトは レシピ共有サービス（ cookpad.com ）がメイン
組織規模: サービス開発者は200+ , サービス数は100+
サービスチーム（サービス毎に存在） + SREチーム
使用技術はRailsがメイン。たまに他言語。
=> 現在中央集権的に行なっているサービス運用を、サービス毎に自律的にできるような仕組みを作ること。
立ち上げ当初はモノリシックな1つのRails Applicationを運営すればよかったが、今は沢山のアプリケーションがある。
「1つのアプリケーションが死んだら複数のサービスが落ちてしまう」
「サービスが増えて連携すればするほど障害がおきた際の根本原因の調査が難しくなったり、障害の対象範囲の把握が難しくなる」
といった課題が出てきて、運用方法をちゃんと考えよう、という流れになった模様
ライブラリとかマネージドサービスで楽をしたい！！！
マイクロサービス運営において、障害が起きた際に影響を小さくすることができるやつ、との説明がありました。
聞いたことがなかったので調べたら、クックパッドの開発者ブログが出てきました。
というかこのライブラリ自体、クックパッドのOSSだった。
クックパッドの開発者ブログ曰く
リクエストを並行処理したり、よしなにリトライしたり、あるサービスで一定以上のエラーが発生したら、一定期間そのサービスへのリクエストを停止する。
もの。
AWS X-Ray (製品や分散アプリケーションの分析とデバッグ) | AWS
いわゆるDistributed Tracing, 分散トレーシングを提供するAWSのサービス。
サービスマップを良い感じにシュッと作れる。
ただ、これらは Ruby (on Rails) プロダクトであれば便利なんだけど、それ以外の言語/技術だと使えない。特にExpeditor。gemだし。
x-ray はAWSが頑張ってくれているから割と対象多いけど
言語ごとの対応とかは置いといて、「ネットワークプロキシを間に挟んで、それにアクセスをコントロールさせる」という方針が良いのでは、という話に。
その手法を取ることで、アプリケーションがどんな作りになっていても関係なく、ネットワークレベルでの制御が可能になる。
SRECON America 2017での発表でSREチームが言葉を知ったことがきっかけらしい。
どんなもの？
-> 今までライブラリレイヤでリトライやサーキットブレイキングをしていたものを、外の別のプロキシに任せる
-> そのネットワークプロキシを、中央の別のもので管理する
中央管理にすることで、運営チームであるSREが管理をしやすく、分散していないため監視が行いやすく秩序を保ちやすい。
上記で説明した「ネットワークプロキシ」に該当するOSS。
当時（2017年前半）の段階では一番良いプロダクトだったので採用となった。
Istioという別のものがあったが、そちらはKubernetes前提で作られているプロダクトなこともあり、ECSを使っているクックパッドでは見送りとなったらしい。
resiliencyの意味・使い方 - 英和辞典 Weblio辞書
Reciliencyという言葉がピンとこなかったのでぐぐった。 「弾性力」「回復力」といった言葉らしい。
話を聞く限り、リトライやタイムアウトに関する設定、リクエストの飛ばし先、その他諸々のネットワークプロキシが管轄する設定を全サービス分一覧で見れるようにしたい、ということっぽい。
クックパッドでは、（前半でもかいたけど）サービスを開発・運用する担当がサービス毎にあって、それらを横断的に見るためのチームが存在している。その横断チームのことを「中央」と呼んでいて、この後は説明が面倒なので "中央" と呼ぶ。
その中央で横断的にサービスを監視し、及びどういったプロトコルで通信をし合うかを管理・管轄できるようになることが今回の目的。
リクエスト量、その他諸々の可視化をするためにPrometheusを採用している。
Envoyに便利なAPIがあるのでそれを使う。
各サービスのconfigファイル（アクセスポイント、リトライ秒数、タイムアウトの判断秒数など）はS3で保管する。それを元にプロキシの設定を行う。
JSONをやり取りするマイクロサービス: APIサーバはELBを使ってロードバランシングしているため、EnvoyはELBへアクセスする。
gRPCをやり取りするサーバはロードバランサに対応していないため、サーバへ直接アクセスする形を取る。
Route Config: path毎に設定を記述する。リトライ、タイムアウト秒数など
Cluster Config: どこにリクエストを飛ばすか、といった設定を記述する。先はだいたいELB
Service Discovery Service API というものがEnvoyに生えていて、それを叩いて設定を変更したり諸々を適用する。
lify/discovery という参考実装が存在したが、要件が合致しなかったらしく cookpad/sds を自作した。らしい。
正直なところここら辺からよくわからなくなりました
-> retry overflow counter などの値が異常値を示すようになる
それにより、エラーが多少起こったりしたとしても問題のない範囲でリトライを実施したりといった形で自動対処ができるようになった。
=> SRE等の運用コストが減った
各サービス毎に各々で管理されていた設定が集まることで、適切な設定を行いやすくなった。
サービスレベルや、ヘルスステータスの一覧表示、状況の監視がやりやすく、わかりやすくなった。
発表者: @ganmacs さん
2017卒とのこと
前からマイクロサービスは推進していた。
Garage, GarageClientでAPIを共通化してたり、Autodocでドキュメントを自動生成したりしてきた。
（Cookpadほんと色々gem作ってるな）
シンプル
※Slow Startって？
-> サーバを立ち上げた直後はリクエストの送信量を少なめにして、安定する（と仮定）に従って、少しずつ送信を増やしていくサービスイン時のやり方。
富士通のこの記事がわかりやすかった
負荷分散入門(ロードバランサ入門) 第8回 連続サービス機能 : Fujitsu Japan
サービスひとつに対し、 app コンテナ、 front-envoy コンテナ、 envoy コンテナ、registrator コンテナが立ち上がる。
動きは言葉よりスライドを見た方がわかりやすそう（12ページ〜）
registrator がappにヘルスチェックしてくれるのが良い
Service1: App -> Service1: envoy -> Service2: ftont-envoy -> Service2: App
リクエスト送信をenvoyが、受信をfront-envoyが担当している
Protocol Buffers定義用のリポジトリがあってサービスごとにディレクトリがわかれてる
repos/ ├── service_a ├── service_b └── service_c
lintがあったり、ドキュメントを自動生成するツールが用意されていたりと色々楽そう
Envoy Status っていう機能がEnvoyにもともとあって、それを利用
アクセスログはサービス開発者が1〜2行シュッと定義を書くだけで取ってこれるようになるらしい
Prometheus, Grafanaを使っている
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:
gRPCのつらみ（CPU使いきれない toka Graceful Shutdownがなかったり toka 諸々）を解消するために作っているgem
grpc gemが良い感じになったら戻れるように互換性を気にして作っている
移行中らしいです
発表者: Kohei Suzuki さん
Twitterアカウントわからんかった(´･_･`)
ほぼ全てのアプリケーションが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から外したら止める + 突然一部タスクが死んでも大丈夫なようにちょっと余裕を持ったキャパシティのプランニングをする
fluentd経由でAmazon S3保存、Athenaで検索できるようにしている。
CloudWatch Logsはログが多すぎて使い物にならなさそうだったので使わなかった＋高い とのこと
コンテナインスタンスのホストにfluentd -> fluentdの集約ノード -> S3
cAdvisor, Prometheus, Grafanaで実現
コミュニケーションコスト＞マイクロサービス化のコスト になったらやる質問2つぐらい聞き取れなくて抜けてます
Envoy は各サービスインスタンスにたくさんいて(side-car container)、中央管理している Envoy のための API サーバーは冗長化している、という状況ですね
— Taiki Ono (@taiki45) November 28, 2018
（ありがとうございます）
キッチンで作りたてっぽい色々を食べました。おいしかったです
懇親会中にスタッフの自己紹介タイムが入ってたけど全然聞けてなくて残念
100+ 規模だからこその取り組みという感じで、とても面白い事例を知ることができて良かった。
エコシステムや既存のツールをどう使って課題を解決していくかといった話に対して、自作ツールをガンガン作っていけるのはかなり強みな気がする。
とはいえやりすぎるとそれはそれでつらいので、OSS化したりするのは良いと思った。
Container, AWSのサービス群に詳しくなくて、その場で調べながら聞いていた。多分他の人もだいたいそうなんじゃないかと思う
実際に各々の環境で使っていくかはさておき、名前が出てきたツールやサービスは概要だけでもさらっておくと、たまに役に立つ気がするのでおすすめ。
要望、というか自分が気になったのは、今回はプラットフォームを作る側の話だったけど、 それを使ってサービスを作る開発者側の意見。
これによってどれぐらい楽になったか？とか、アプリケーション側でハマったところ、とか、気になる。
ところで、AWS App MeshがEnvoyを中で使っているとのこと。共通点とか違う点が少し気になる。
まあ、東京リージョンには暫くこなさそうだけど。。。
Cookpad Teck Kitchenは初めて参加しましたがとても楽しかったです。また行きたい。
運営の方々、懇親会で話してくださった方々ありがとうございました！
