はぜにっき

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

herokuにRails Applicationをデプロイしようとしたら思ったより詰まった

趣味で勉強がてら適当に作るRails Applicationのデプロイ先、色々考えてみたけど結局今のところherokuが一番だよねーっていう結論になってしまった。
東京リージョンに結構な金が掛かるからherokuを触るのは避けていて、ようやくリージョンを諦めて 今回初めてデプロイしたんだけど思ったより詰まったのでメモがてら軽くまとめておく。

ローカル環境のバージョンは、それぞれ
ruby: ruby 2.5.3p105
rails: Rails 5.2.2
です。DBはmysql5.7。

前提として、 rails new [APP_NAME] --api -d mysql でアプリケーションを生成していることとする。まあAPIモードじゃなくても同じだと思う。

Bundlerのバージョン

remote:  !
remote:  !     You must use Bundler 2 or greater with this lockfile.
remote:  !

どうやらherokuの初期状態のBundlerは bundler-1.15.2 だそうで、ローカルでBundler2を使っていると怒られる。

jp.heroku.com

herokuにはbuildpackというのがあって、いろんな言語に対応するための仕組みが用意されている。それにBundler2への対応ができるpackがあるので、それを入れると解決する。

$ heroku buildpacks:set https://github.com/bundler/heroku-buildpack-bundler2
Buildpack set. Next release on [APP] will use https://github.com/bundler/heroku-buildpack-bundler2.
Run git push heroku master to create a new release using this buildpack.

何故かrubyがdetectedされないときがあって、その場合はrubyのbuildpackを入れると解決する

heroku buildpacks:set https://github.com/heroku/heroku-buildpack-ruby

これでとりあえずはbundle installができて、 remote: Verifying deploy... done. が出る。
特にrails自体をいじっていなければ open すればRailsの初期画面が出てきてくれるようになる。

mysql2対応

herokuのデフォルトで設定されるDBMSPostgreSQLらしい。mysqlでやりたいので変更する。
(Postgresを使う場合でもID/PW/Hostの設定は必要だろうけど)

devcenter.heroku.com

DBはAddonを使って設定を変える。
ClearDBというアドオンがあって、それを使ってMySQLを立ち上げる。

heroku addons:create cleardb:ignite

そのあとおもむろに heroku config をすると立ち上がったMySQLの設定が出てくる。

CLEARDB_DATABASE_URL:     mysql://ba1d50d1a663b5:891cd108@us-cdbr-iron-east-03.cleardb.net/heroku_4d7ba2ac4dad221?reconnect=true

ここに書かれている ba1d50d1a663b5 がユーザ名、 891cd108 がパスワード、 us-cdbr-iron-east-03.cleardb.net がホスト名、 heroku_4d7ba2ac4dad221 がDB名になる。

ので、 config/database.yml の設定をそれに合うように変更する。

[config/database.yml]

production:
  <<: *default
  database: heroku_4d7ba2ac4dad221
  username: ba1d50d1a663b5
  password: 891cd108

(わかりやすくするためにpassword直書きしてるけど、普通に環境変数使おうね。 heroku config:set '環境変数名'='891cd108' で設定できる )

あと、 DATABASE_URL という環境変数を作って、そこに mysql2://[CLEARDB_DATABASE_URLと同じ] を入れる。これでadapterがmysql2になってくれる。

そうしたら、 git push heroku master して、 heroku run rails db:migrate をして、成功したらOK。

どこか抜けてるかもしれない。もっかいやった時にまた詰まったら追記する。


終わり。
こういう環境構築みたいなので困ると本当にやる気が無くなるので「全部良い感じにデプロイできるマン」欲しい....まあ最初からサーバレスに乗っかれっていう話だけどさ...
SPAはNetlifyで良い感じにCDNとか証明書まで全部やってくれるから最高。多分Netlify + AWS Lambda + Dynamo? が一番手っ取り早いんだろうなあと思ったりした


追記

雑記: 自分で作る飯が美味い

飯がうまい

Nespresso + BALMUDA

オイルパスタ簡単だからすぐ作ってしまう

🍛

和風?ぱすた

🍖

リモートワークしてると朝昼晩すべて自炊ができるようになる。おかげで段々料理の腕が上がってきていて良い感じ。

この前低温調理器も買ったので、ローストビーフが無限に安定して作れるようになって最高だったりします。

Rails Guide読んだ

railsguides.jp

去年、機能の存在自体を知らずに損することが多かったのでとりあえずと思って読みました。
使う予定のなさそうだったり、興味が全く湧かなかった部分は飛ばしてざーっと「どんな機能があるか」をさらった。
半分以上は忘れていると思うので、随時ぐぐりながら、たまにrails/railsを読みながら少しずつ深く理解していけたらなと思う。

そろそろ外向けの何かを作れたらなーって思うけど、思いつかないうちはサービスのクローン作ったり、公開されているコードを読んだりする方針で良いかなあ。

雑記

Nespresso Essenza Mini + aeroccino 買った

hazediary.hateblo.jp

バルミューダのパンと一緒にコーヒーを飲むと幸せになれます。
牛乳泡立て器であるエアロチーノは買う予定ではなかったんですが、ヨドバシカメラで試飲させてもらったら最高だったのでセット購入しました。
楽に美味いものが食べたり飲んだりできると文明を感じて良いですね。

AWS Amplify ConsoleからNetlifyに移行した

hazediary.hateblo.jp

こんなエントリを書いたりしたんですが、historyApiFallbackの設定のやり方がわからなくてリダイレクトが上手く行かなかったり、東京リージョンがなくて遅くて結構つらかった。

nabettu.booth.pm

この本を買ってシュッと読んで、公式ドキュメントのRedirectsページ読んでたらこっちのほうが良くない??ってなったので即移行しました。
DNSの設定とかNetlifyのほうが楽で良かった。

f:id:hazeblog:20190102103133p:plain
Topic branchを作ったら自動で動作確認用の環境が生えてきて便利

あとついでにポートフォリオサイトをCSS in JSにしました。emotion-jsにしたのは会社で使ってるからです。

Rails Applicationの良いデプロイ先を探している

雑にサービス作ったりしたいってなった時に、デプロイ先って今どこにすれば良いんだろうなーって思って少し調べています。
Herokuは東京リージョンは数万かけないと使えないっぽいし、EC2は監視とかデプロイ面倒だし、VPSはもっと面倒くさそう...
今時はRails使わずにNode.jsとかをLambdaに乗せて手軽にサーバレスAPIサーバなんだろうか

痩せたい

2016年4月段階では45kgだったはずなんだけど、いつの間にか60kgになっていた。
運動不足だし酒も結構飲んでるし仕方ないかなあという感じなんだけど、お腹も柔らかくなってきたのでなんとかしようかと。
家で酒飲むの控えるのと、運動したりするかなーって思っています。

BALMUDA The Toasterが届いた

会社のYear End Partyのじゃんけん大会で勝って貰いました。やったね。

最高。朝はパン派に転派します。よろしくおねがいします。

パンが美味いっていうのは当然っちゃ当然なんですが、それ以外も本当に良い。
前方2つのロータリスイッチはとても軽いのに回すたびにカチッという心地良い音が鳴るし、トーストの間は1秒ごとにカチカチ良い音がなる。
トーストを始めてから10秒ぐらいで水蒸気が出てくるんですが、それを眺めるのも結構楽しくて、貰って嬉しい食べて美味しいというものでした。

こうなるとコーヒーも美味しいものを淹れたくなってくる。

(これも前職で貰ったものですね...)

今はネスレのカプセルのやつを使ってるんだけど、豆から作るやつも用意してみようかな。おすすめ教えてください。

2018年総括+2019年やっていき予定

クリスマス、如何お過ごしでしたか。
3連休は泥酔イベントが3連続だったので酒を飲み続けていました。年末年始も飯+酒イベントばかりなので太りそう。心配です。

タイトル通り、今年一年の総括ということで、色々振り返っていこうと思います。

年初に立てていた目標を見る

hazediary.hateblo.jp

完全に忘れていたけど、年初になんか書いていた。
会社も変わったし、事情も色々変わったので全く参考にならないけど、一応見ておこう。

貯蓄

100は貯めてない。
必要ではなくなったので切羽詰まらず生活していた。
ちょっとだけ給料の少しは貯蓄用口座に投げつけている。貯めることに力を入れるより稼いだ上で残していく方針で行きたい。

情報処理技術者試験

受けてない。
〜20の間に基本情報/応用情報/データベース/セキュリティを取っていて、冷静に考えたら別にネスペ取っても仕事に活きることなくね?という気持ちになったので放置に。
今の界隈(Web / スタートアップ?)に居る間は必要にならないだろうし、来年も多分受けずに行くと思う。

実績による昇給

7月に転職をしていて、去年と比べると年収が約150万円ほど上がっています。めでたい。
来年もこれぐらい上げたいけど、結構厳しそう。頑張りたい

彼女

よろしくおねがいします。

振り返り

仕事について

hazediary.hateblo.jp

7月に転職をして、今はKaizen Platformという会社でApplication Engineerをしています。

周りはつよい人達ばかりで、毎日知らないことを考えたりぐぐり続けて、Qiita:Teamにポエムを投げてやっています。
本当に学ぶことが多くて給与分の見返りができているか怪しいけど、半年が立って少しずつ落ち着いて動けるようになってきました。
まだまだ一線でバリバリやっていきには程遠いので、少しずつ頑張っていきたい所存。

今のところ毎年転職していますが、来年はしないようにしたいですね

給料

少し脱線。

給料の話、だいたいの会社(弊社もだけど)や社会全体でクローズド気味な話題なんだけど、オープンにしても良いんじゃないかと思っています。
透明感のある評価制度が好きなので、VOYAGE GROUPの技術力評価会とか、GMOペパボのGitHub公開評価PRとかに憧れがある。

業界全体でオープンな感じになっていけば色々良い感じになると思っているんですがどうでしょう。
ということで、自分も書きます。

2018年の源泉徴収票上での給与総額は4,861,045円でした。昨年が340万程度だったので、大体150ぐらい上昇しました。
社会人3年目 / 満23歳にしては良い額なんじゃないでしょうか。

2019年は650を目標にしていますが、あんまり現実味が無い。本業もそれ以外も頑張っていきたい気持ち。

キャリアについて

市場価値と自分の技術に対する興味 - はぜにっき

「一番下手くそでいよう」のつらさ - はぜにっき

「自分が何したいのか」をここ一ヶ月考えていますが、まだ全然答えが見えていません。
眼の前の仕事を全力でやっていくのが今は良いとは思うんだけど、とはいえ先が見えないと足がすくむ人間なので自分で道は作っておきたい。

とりあえず来年は本業以外でも仕事を持ったり、自分で考えてプロダクトを作って利益を少しでも出すことを目標にしたい。

業務外の色々 / 社外活動

はじめてOSSのPRを送った話 - はぜにっき

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桁が一気に飛んでいくのは結構心に来る。
最終的に高額医療費控除である程度返ってきたから良いものの。。。

生活リズムも一時期治っていたけど少しずつ崩れ始めていて、今も崩壊気味なのでなんとかしていきたい。
でも今直しても年末年始でまた崩壊するので年明けからやっていきます...


2019年やっていき予定

仕事 - Ruby on Rails + React

バックエンド業(Rails)、フロントエンド業(React)の精度を上げたい。
共に入社前には触っていないものであると同時に、現時点で裏側の仕組みをまともに理解せずに触っているので表面しかわかっていない。
「どう使っている技術が動いているのか」「どう作られているのか」「どうすればいじることができるのか?」を知るのは必須だと思うので、やっていきたい。
と同時に、OSSへのコントリビュートとか、そういうところにも手を出せると良いなと思っている。

技術だけではなく、サービス設計、組織などについても考えていきたい。
"なんか違和感があるけど言葉にできない" ということが今年は多くて、そういったことは減らしていきたいしアウトプットとして表に出す努力もしていく。

趣味えんじにありんぐ - プロダクト開発 / 利益

自分で考えたものを作って、公開して、利益を出す までをやりたい。
利益は大きく出したいというわけではないけど、マネタイズとか、今後きっと考えていかざるを得ないことを先取りしてやるには趣味開発が一番良いと思っているので、色々試していきたい。
仕事で得た知識を趣味で使って、趣味で得た知識を仕事で使うのを繰り返したい。

表に出る機会

アウトプットを増やしたい。
今年は意識して増やしたつもりだけど、思ったより少なかったし質の面でも良いとは言えなかった。
来年は量は同じぐらいで良いけど、安定して、良いアウトプットを出していきたい。
LTも、登壇もタイミングがあればやっていく気持ち

健康

とりあえず昼寝がめちゃ長いのと、寝起きが最悪なこと、生活リズムがすぐ崩壊するのをなんとかしないといけない。
肩凝りが悪化しすぎて肩が上がらなくなったりもしたので、定期的に整体とかマッサージに行くべきかなあと思ったりもしている。
あとは入院しないこと...

今後の選択肢を増やす

キャリアの話も被るけど、今後何やっていくかは割と不透明な分、わかってきたときに選択肢が狭くなっていてほしくない。
わかりやすく言うと、例えば "海外で働きたい" てなったときに、英語だとかビザで落ちるとかはなりたくない。
し、大学院に行って論文が書きたい、ってなったときに、専門卒だから無理、みたいなことになりたくないわけで。

色々考えたんですが、とりあえず基礎教養としての英語とか諸々を勉強する口実も兼ねて学士を取ることにします。
放送大学が学費も安いし、高校レベル〜の英語の授業もあったのでそれをやってあとは自分で頑張っていこうと思っている。
お金も投げるからやらざるを得なくなる、はず。やっていきたい


というわけで来年も結構色々詰め込んでやっていくつもりです。
身体ぶっ壊さないようにがんばります。来年もよろしくおねがいします。

ポートフォリオサイトをAWS Amplifyに移した

dev.classmethod.jp

この前のre:Invent 2018でAWS Amplify Consoleっていうのが発表されて、丁度使う機会があったので使ってみたよ。

以前

GCPの無料枠を使って、g1-small のCompute Engineにnginxを入れて、ソースコードを中に投げて運用してました。
で、deployは 手元で npm run build して、生成された /build ディレクトリをsshでぶん投げる っていうのを雑にスクリプト書いて叩いてやってました。

まあ、それもそれで面倒なのでどこかのタイミングでgithubにpushしたら良い感じにデプロイしてくれるように仕組みを作ろうかなーと思っていたところ。

f:id:hazeblog:20181220224347p:plain:w300
あと51日で無料枠も消滅するので丁度良かった

AWS Amplify Console やるぞ

そもそもAWS Amplifyっていう静的サイトのホスティングサービスがAWSにはあって、それにいろいろ機能が付きましたよっていうのが、re:Inventで発表された内容。
その追加機能の中に、GitHub/GitLab等にpushすると勝手にデプロイしてくれるCD機能があったので、それを使っていこうという感じです。

github.com

今回デプロイするリポジトリはこれ。

手順

AWS コンソール画面のサービス一覧から AWS Amplify を選んで作成を押すと、トリガ/ソースコード元となる連携先を選ぶ画面になる

f:id:hazeblog:20181220225038p:plain:w300
BitBucketもあるよ

で、認証したらリポジトリとブランチを選んで

f:id:hazeblog:20181220225233p:plain:w400
master以外も設定できる、便利

buildの設定(create-react-appで作ってたらそのままでおっけーっぽい)をして、環境変数を設定して、

f:id:hazeblog:20181220225349p:plain:w400
確認画面

ポチッと押すと、

[f:id:hazeblog:20181220225427p:plain:w400
でぷろい開始

デプロイがはじまる。

で、うまく行ったら、デプロイ先のURLリンクが出てくるからそれを押せば、デプロイされたページが出てくる。

便利じゃん。。。

f:id:hazeblog:20181220225648p:plain:w300
ビルドがこけるとこうなります


ドメインはお名前.comで取っていたんですが、お名前.com側でDNSネームサーバをRoute53に向けて、Amplify側でドメインを設定すればおっけーでした。

お名前.com <-> Route53 の部分はこのエントリを参考にした。わかりやすい。

tech.tanaka733.net

上記エントリに従ってRoute53側でドメイン設定ができていれば、Amplify Consoleの「ドメイン設定」で連携が一瞬でできます。便利。

f:id:hazeblog:20181220230447p:plain
ドメイン設定画面


というわけで https://haze-page.tokyoAWS Amplifyに移したログでした。
サーバレスだしCompute Engineよりは安いやろ!という勘で移行したんですが実際毎月いくらぐらいの請求になるんでしょうね。

ところで、東京リージョンがまだ対応してなくてオハイオリージョンでやっているので結構遅いです。画像も小さくしてないから更に描画が遅い。。。
ちゃんとWebサービス作ってその上に乗っけるんだったらCDN必須っぽいですね。そういうのも今後やっていきたいです。

ストレングス・ファインダー2.0 受けた

この本を読んで、ウェブテストを受けた。

本には、「不得意なことにたくさんの 時間をかけて克服するよりも、得意なこと・才能があることに時間をかけて特化しよう」といった内容が書いてある。
自分は学生の頃、英語や漢字の暗記がとても苦手で、試験期間中ずっとその勉強をしても平均の点数さえ取れなくて諦めた覚えがあり、耳が痛くなった。
まあ今は知っている中で一番得意であろう分野で仕事をしているので良いと思う。他の仕事できる気しないし。


このウェブテストは、性格診断っぽい質問を答えると自分の「強み」がわかるというテストで、弊社のマネージャ研修などでも活用されている。
かなりの実績があるっぽく、参考程度になるかなと思ってやってみた。

f:id:hazeblog:20181209124107p:plain
結果

納得感がある。

テストを受けると、「強みの理解レポート」と「自分だけの特徴的な資質レポート」が出力される。

「強みの理解レポート」を一部抜粋。(引用の枠を超えているんだけど、自分用のレポートだから良いよね...?)

強みの理解レポート

学習欲

「学習欲」の資質が高い人は、学習意欲が旺盛で、常に向上を望んでいます。結果よりも学習すること自体に意義を見出します。
あなたは本能的に、 自分の研究や仕事関連の任務で優れた能力を発揮するために必要であれば、どんなことでもすることがあります。 これが、あなたのやる気をそぐような人がいるチームよりも、一人で課題に取り組むことを好む理由の1つなのでしょう。
おそらくあなたは、 あれこれと考えを巡らせたり、興味深い話題について読んで検討したりする静かな時間を好みます。 あなたは、邪魔されずに思考できる時間が得られると、大きな喜びを感じます。 あなたは、自分のアイデアを徹底的に検証するため、騒がしく、気ぜわしい、集中できない状況から逃れようとするはずです。
多くの場合、あなたは、 ときどき、難易度が高かったり、課題の多かったりする講座に登録することがあります。 特定の物事について自分の知識を広げたり考えを試したりしたいのでしょう。

今回の転職理由がそのまま書いてあって笑った。

"必要であれば、どんなことでもすることがあります。"
この前書いていたエントリのお話ですね。

内省

「内省」の資質が高い人は、知的な活動に多くの時間を費やします。内省的で、知的な議論が好きです。
おそらくあなたは、 1人で思索にふける時間を切に求めています。 自分の知的好奇心をかき立てるものなら何についても考えます。
毎週時間を取って自分のアイデアを追求することは、喜びであるばかりか必要な活動でもあります。
あなたは、沈黙が長く続くと心から安心感を覚えます。 なぜなら、 沈黙のおかげであなたや他の人たちは、歴史の流れや人々の生活を変えるような理論を検討したり、何かを発案したりできるからです。
あなたは、 さまざまなアイデア、理論、または概念について疑問を呈する傾向があります。
あなたは普段、結論を出したり、新しいアイデアを提示したり、状況を違う観点から見たり、詳細な質問をしたりする前に、よく考えを巡らします。
多くの場合、あなたは、 自分の本質や自分の存在理由に関する質問と戦っています。

学習欲に近しい部分が多い。
基本的に出社せず家でリモートワークしているのは、一人で居られる時間が多いってのも理由の一つだったりする。
オフィスに行っても端っこのソファに座ってもくもくしているのも同じ理由。
雑談が嫌いなわけじゃないんだけどね

自我

「自我」の資質が高い人は、大きな影響を与えることを望んでいます。独立心に富み、組織や周囲の人々に与える影響の大きさに基づいてプロジェクトに優先順位をつけます。 多くの場合、あなたは、 ときどき、個人的なまたは仕事上の特定の目標を達成するためにがんばります。 これには、昇給、昇進、学位の取得、あなたが価値を置くものの取得、または認証プログラムの完了などが含まれますが、これに限るものではありません。 あなたは本能的に、 個人プレーヤーであり、自分が達成したものを人々に確認してもらうことで、彼らに影響力を行使します。 あなたは、 仕事を自分の私生活の中に切れ目なく織り込みたいと思っています。 この2つを線引きして分けることはしません。 おそらくあなたは、 いつも、さまざまな専門上の問題に対処するために必要な強みを持つことを認められたいと考えています。 他の人にあなたが重要人物であると見られたいため、わかりづらい情報をマスターしたり、高度に特化した能力を獲得したりしようという気になるようです。

承認欲求ですね。

目標志向

「目標志向」の資質が高い人は、目標を定め、その目標に向かってまい進し、目標達成に必要な修正を行うことができます。優先順位をつけてから、そのとおりに行動します。
おそらくあなたは、 自分が達成すべき物事を的確に把握します。 そしてそれに専心します。
多くの場合、あなたは、 一人で仕事することを選ぶことがあります。 そうすれば、あなたがこれからの数週間、数か月、数年、数十年に実現したいことを綿密に計画することがずっと容易にできるかもしれません。
必要であれば、会話を実際的または事実的なものに戻す役割を担うこともあります。
あなたは、 自分自身の週間パフォーマンス目標を設定することに真剣に取り組むことがあります。
あなたは、 時折、事実を強調し、他の人に真実の方向性を示すことがあります。 あなたはだまされやすい人の目を覚ますようです。
事実に基づくあなたのスタイルの手助けで、他の人は共通の基盤を見いだすのかもしれません。 完全に同意に至るようなコンセンサスが得られることがあるかもしれません。

ずっと悩んでいるのは、何を持って"事実"と認識するかどうか。最近ここが雑になっていて、事実ではないことを事実と思い込むことがある。
仮説検証の能力をつけると、もっとうまくできるのかなーって思ったりしている。

"多くの場合、あなたは、 一人で仕事することを選ぶことがあります。"
自分のコントロール権限がある仕事をしたいっていう話かな

未来志向

おそらくあなたは、 ときどき、今後数週間、数か月間、数年間、数十年間で達成できることを考えることがあります。
改善できることを考えるだけで、あなたが特定の仕事で成果を上げる原動力になります。
あなたは本能的に、 これからの数週間、数か月、数年、数十年に、世界や自分自身をどのようにしたいのか心に思い描くことがあります。生まれながらにして、あなたは、 今後数週間、数か月間、数年間または数十年間に到達可能なことに関して革新的な構想を練るために、自然と多くの時間をかけます。 あなたは、専門分野に集中しているとき、発明家、空想家、夢想家としての行動を見せることがよくあります。
あなたは、 今後数週間、数か月間、数年間、数十年間の内に、よりよくできることについて想像することがあります。 あなたには、改善したり、改良したり、また完成させたりできる事柄が、鮮明に見えているでしょう。
またあなたは、環境や自分自身、周りの人、システム、プロジェクト等において、変える必要のある点についても判断することができます。
多くの場合、あなたは、 自分の選んだ将来を形作ることにたっぷり時間を取ります。 そして頻繁に、今後数か月、数年、数十年で可能性のあることに関する自分のアイデアを共有します。 おそらくは、自分のイメージした生き生きとした詳細をあなたが語ると他の人の注意を捉えるのでしょう。

スタートアップっぽい感じのことがたくさん書いてある。
ビジョン・ミッションを明確に定めている環境に行きたかったので、そうだなあ、と思いながら読んだ。


全体的に納得感がある。というか自分本位なのがよくわかる。
同時に、やっていることがそこまで間違ってなさそうという安心感が出てよかった。
今後もしばらくはスタートアップ企業でエンジニアを続けていくんだろうな、と思いました。

本を読んでいると "大学院などに興味を持つでしょう" って書いてあって、去年大学院行こうと思って色々調べてたり、今は仕事しながらでも行ける通信制の大学に出願しているので良く当たるもんだなあと驚いたり。

書籍にも書いてあるけど、世の中には様々な考え方をしている人がいて、それぞれのパターンをある程度知ることで仕事でのコミュニケーションを円滑に進めて行ける可能性が高くなるので、やったことがない人はやってみると良いと思う。
@haze_it_ac はこういう考えなので だいぶ面倒な人間だと思いますが、今後もよろしくです。(?)

23歳になりました

なりました。めでたい。

20歳を超えてからは嬉しい気持ちは無くなりました。めでたいって言いましたが特にめでたくもないですね...
今日は有給取って1日中寝てやろうかと思ったんですが、入社時にもらった有給は試用期間中に入院して消滅していたんでした。普通に仕事です。


22歳は何していたかというと、前職でChefをいじったりチャットボットを作ったりして、今の会社に転職して、APMを調べて、RailsとReactを触り始めていました。
今回(?)はどうなるんでしょうか。正直もう転職と引っ越しは面倒だからやりたくない。

新卒(20歳)のころは5年後こうなっていたいとか、10年後はこういう立場になっていたい みたいなことを考えていたんですが、今は1年後すら想像ができないです。5年後なんてもう。
今。何がしたいかみたいなところはある程度わかるんだけど、1年後にそれを達成していたら次はどういうことをしたくなるかが全くわからないですね。

で、今後自分はどうなっていきたいんだろう っていうのを考えるために、自分が大切にしている考え方みたいなものを最近は考えていたんですが( 市場価値と自分の技術に対する興味 / 「一番下手くそでいよう」のつらさ )、うまくあらわせないし、割と短期的な目線でしか物事考えてないっぽいし、今後に繋がるわけでもなかった。
その代わりに、自分の気持ちとか、その時々の感情には正直に向き合えるようになってきた気がします。悪く言えばわがままになったんですが、それでも良いでしょう。

このエントリも本当は "今年を振り返って〜〜" みたいな感じでゆるく総括するつもりだったんですが、発散しまくりで無理でした。
あと1年ぐらいは色々考え込んだり方向転換しても許されるんじゃないかと思ってます。パートナーもいないし(?)。

もう暫くはこんな感じでふわふわ生きていると思います。23歳のはぜもよろしくお願いします。

例のリスト


iRobot Roomba 890 買った

11月末に890だけがビックカメラで30,000円引きになっていて、よくみたらポイントが余っていて、気付いたらポチっていた。

写真の通り、これまでは eufy という、Anker製のちょっと安いロボット掃除機を使っていました。

これはこれで安いしちゃんと仕事してくれるしちょっと小さいので一人暮らしには丁度良いんだけど、7月に1LDKに引っ越したタイミングで取り残しが発生するようになってしまった。
ので、適当なタイミングでグレードをあげようかな(上位互換としてeufy 20というものがあります)と思っていたんだけど、まさかルンバのWiFi対応モデルがここまでやすくなるとは。。。。

まだ一回しか走らせていないけど、力強い動きをしてくれていて安心感がある。
その代わり、ちゃんと固定できていない家具(軽い椅子とか)がぶつかって少し動いてしまうけれど、それはまあ仕方ない。

www.irobot-jp.com

ルンバにはバーチャルウォールという機能があって、どういうものかというと、デュアルバーチャルウォールという付属品を適当な場所に置くと、その周りだけは立ち入らないようになってくれる。
はぜハウスでは衣類乾燥機があって、その下に排水用のバケツとか2Lペットボトルを置いていて、それを倒されると大惨事なのでこれが重宝する。
これまでeufyを使っている時は、掃除させる前に避難させていてちょっと手間だったんだけど、バーチャルウォールを使うことで避難しなくてもよくなり、最高。

というわけで良い買い物っぽい。長持ちさせたい。
お古になったeufyはクリスマスイブに男友達にあげる予定。はぜサンタです。よろしくお願いします。

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

なにこれ

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

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

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さん(先生)、一緒に参加してくれたみんなありがとう〜〜