Cloud Runを使ってRailsアプリを公開する【公式チュートリアルをなぞるよ!】
GCPのCloud RunでRailsアプリを立ち上げるチュートリアルをベースにRailsアプリを立ち上げを実践していってみます。
Cloud Runのデプロイ設定ができればコンテナの設定だけすればWebアプリの外部公開がだいぶ手軽になると思うのでまとめてみます。
今回はGUIのコンソールを使わずgcloudコマンドを使って各種サービスのインスタンスを作成したりしていきます。
サンプルアプリケーション
デプロイするサンプルアプリケーションを用意しました。
最初にDockerfileやdocker-compose.ymlなどの設定は実施されていることを前提としていきます。
Cloud SQLの準備
インスタンスの作成
今回はMySQLのインスタンスを作りたいのでチュートリアルのコマンドとは --database-version
の設定は MYSQL_8_0
を使用したいと思います。
リージョンは asia-northeast1
、インスタンス名は cloudrun-app-sample-db-instance
とします。
インスタンス名は任意の好きな値にしましょう。
gcloud sql instances create cloudrun-app-sample-db-instance \ --database-version MYSQL_8_0 \ --tier db-f1-micro \ --region asia-northeast1
データベースの作成
次は作成したインスタンスにデータベースを作成します。
cloudrun-app-sample-production
はデータベース名なので任意の名前を記載します。
また --instance
はインスタンスの作成で作成したインスタンス名を設定しましょう。
gcloud sql databases create cloudrun-app-sample-production --instance cloudrun-app-sample-db-instance
※ 認証関連でエラーが出るかもしれませんが、GCPのコンソールでCloudSQLにインスタンスが作成されれば問題なくインスタンス作成はされています。
ユーザーの作成
データベースを作成したら、データベースにアクセスするためのユーザーを作成します。
system_user
はユーザー名なので任意の名前を記載します。
データベースの作成と同様に --instance
は作成したインスタンスを指定します。
--password
はパスワードジェネレータなどでパスワードを作成して任意の値を設定します。
gcloud sql users create system_user \ --instance=cloudrun-app-sample-db-instance --password=hogehoge
ここまででCloudSQLの準備は完了です。
RailsプロジェクトでDBパスワードを暗号化する
ユーザー作成時に設定したパスワードをRailsのcredentials.yml.secを使って暗号化してプロジェクトに設定をしておきます。
docker compose run --rm app ash
docker-composeでアプリをコンテナで立ち上げられる前提で、docker compose runでappコンテナを起動しashでアクセスします。
EDITOR="vi" bin/rails credentials:edit
コンテナ内でcredentialを編集するコマンドを実行します。
viでエディタが起動するので以下を追記します
gcp: db_password: mysqlのユーザー作成時に設定したパスワード
追記したら保存してconfig/database.ymlのproductionの設定を更新します。
production: <<: *default database: cloudrun-app-sample-production # 作成したDBの名前 username: system_user # 作成したユーザーの名前 password: <%= Rails.application.credentials.gcp[:db_passsword] %> # socket: 後ほど追加する
ここまでできたらDBに関する設定は一旦終了です。
ちなみにsocketの部分はPostgreSQLではhostで指定するのですが、MySQLの場合はsocketとなるので注意が必要です。
Secret Managerでmaster.keyを管理
パスワードなどの秘匿情報を管理するためにSecret Managerを使います。
シークレットの作成
今回はRailsのcredentials.yml.secを利用するためmaster.keyをSecret Managerにて管理します。
gcloud secrets create sample-app-rails-master-key --data-file config/master.key
今回シークレットの名前はサンプルアプリのmaster.keyでわかるように sample-app-rails-master-key
という名前にしました。(こちらも任意の名前でOKです)
--data-file
でconfig/master.keyを指定することでmaster.keyに書かれている暗号鍵をシークレットに登録できます。
※ このコマンドは作成したRailsアプリのプロジェクト直下で実行しています。
作成したシークレットの確認
以下のコマンドで登録されたシークレットの値を確認することができます。
gcloud secrets versions access latest --secret sample-app-rails-master-key
--secret
に記載する値は作成したシークレットの名前を記載します。
Cloud Build, Cloud Runにアクセス権をつける
Cloud BuildとCloud Runからシークレットにアクセスできるようにアクセス権を付与します。
Cloud Runへのアクセス権付与はこちら
gcloud secrets add-iam-policy-binding sample-app-rails-master-key \ --member serviceAccount:PROJECTNUM-compute@developer.gserviceaccount.com \ --role roles/secretmanager.secretAccessor
Cloud Buildへのアクセス権付与はこちら
gcloud secrets add-iam-policy-binding sample-app-rails-master-key \ --member serviceAccount:PROJECTNUM@cloudbuild.gserviceaccount.com \ --role roles/secretmanager.secretAccessor
sample-app-rails-master-key
と PROJECTNUM
については自分のこれまでの作業などに合わせた値に設定してください。
PROJECT_NUM
については以下コマンドで取得できます。
gcloud projects describe PROJECT_ID --format='value(projectNumber)'
このコマンド打たなくてもGCPコンソールのダッシュボードのプロジェクト情報の欄に記載してあるのでお好きな方法でプロジェクト番号を取得すると良さそうです。
Cloud Buildを設定
DBとシークレットが用意できたのでアプリケーションをビルドしていきます。
ビルドにはCloud Buildを利用します。
Cloud Buildを利用するために cloudbuild.yaml
を作成し、以下を記載します。
steps: - id: "build image" name: "gcr.io/cloud-builders/docker" entrypoint: "bash" args: [ "-c", "docker build . \ -t gcr.io/${PROJECT_ID}/${_SERVICE_NAME} \ --build-arg RAILS_ENV=production \ --build-arg RAILS_MASTER_KEY=$$RAILS_KEY \ --build-arg GOOGLE_PROJECT_ID=${PROJECT_ID} \ --build-arg CLOUD_SQL_CONNECTION_NAME='${PROJECT_ID}:${_REGION}:${_INSTANCE_NAME}'", ] secretEnv: ["RAILS_KEY"] - id: "push image" name: "gcr.io/cloud-builders/docker" args: ["push", "gcr.io/${PROJECT_ID}/${_SERVICE_NAME}"] - id: "apply migrations" name: "gcr.io/google-appengine/exec-wrapper" entrypoint: "bash" args: [ "-c", "/buildstep/execute.sh -i gcr.io/${PROJECT_ID}/${_SERVICE_NAME} -s ${PROJECT_ID}:${_REGION}:${_INSTANCE_NAME} -e RAILS_MASTER_KEY=$$RAILS_KEY -- bundle exec rails db:migrate", ] secretEnv: ["RAILS_KEY"] substitutions: _REGION: asia-northeast1 _SERVICE_NAME: cloud-run-app-sample _INSTANCE_NAME: cloudrun-app-sample-db-instance _SECRET_NAME: sample-app-rails-master-key availableSecrets: secretManager: - versionName: projects/${PROJECT_ID}/secrets/${_SECRET_NAME}/versions/latest env: RAILS_KEY images: - "gcr.io/${PROJECT_ID}/${_SERVICE_NAME}"
設定ファイルは基本的にGCPのサンプルアプリに記載されている内容をそのまま使っています。
ここで _SERVICE_NAME
の名前は英数字か -
しか使えないので注意です。
このSEVICE_NAMEがContainer Registryに登録されるイメージの名前になります。
チュートリアルと異なる点としては環境変数周りを .env
を使って設定するのではなくdocker build時に --build-arg
で渡している点です。
--build-arg
で渡した値をイメージビルド時に活用できるようにDockerfileに以下を追記します
ARG RAILS_ENV ARG RAILS_MASTER_KEY ARG CLOUD_SQL_CONNECTION_NAME ARG GOOGLE_PROJECT_ID ENV RAILS_ENV=${RAILS_ENV} ENV RAILS_MASTER_KEY=${RAILS_MASTER_KEY} ENV CLOUD_SQL_CONNECTION_NAME=${CLOUD_SQL_CONNECTION_NAME} ENV GOOGLE_PROJECT_ID=${GOOGLE_PROJECT_ID}
こうすることでdocker build時に設定したい環境変数の値をARGとして渡して、コンテナの環境変数に設定することができます。
データベース作成時点では設定していなかったconfig/database.ymlのsocketも設定します。
Cloud SQL proxyはホストで繋ぐというよりソケット通信でDBと接続するためhostではなくsocketを設定する必要があります。
production: ~ socket: "<%= ENV.fetch("DB_SOCKET_DIR") { '/cloudsql' } %>/<%= ENV["CLOUD_SQL_CONNECTION_NAME"] %>"
Cloud BuildからCloud SQLにアクセスできるようにロールを追加しておきます。
gcloud projects add-iam-policy-binding PROJECT_ID \ --member serviceAccount:PROJECTNUM@cloudbuild.gserviceaccount.com \ --role roles/cloudsql.client
PROJECTNUM
はシークレットでアクセス権を設定した際に用いたものと同様です。PROJECT_IDは自分のGCPプロジェクトのIDを設定してください。
ここまで設定できたらいよいよCloud Buildを実行してみます。
gcloud builds submit --config cloudbuild.yaml
チュートリアルでは --substitutions
を指定していますが、cloudbuild.yamlに必要な内容は書いているので指定しなくても問題ありません。
gcloud buildsが完了すればDockerイメージがContainer Repositoryに登録され、Cloud SQLへのmigrateが完了した状態になります。
あとはCloud Runへのデプロイが完了すればWebアプリケーションが立ち上がります。
Cloud Runへのデプロイ実行
Cloud Runへのデプロイはコマンド一つで完了します。
gcloud run deploy cloud-run-app-sample \ --platform managed \ --region asia-northeast1 \ --image gcr.io/PROJECT_ID/cloud-run-app-sample --add-cloudsql-instances=CONNECTION_NAME --allow-unauthenticated
PROJECT_ID
は自身のGCPプロジェクトのID、 cloud-run-app-sample
の部分はcloudbuild.ymlで _SERVICE_NAME
で設定した値を当てはめてください。
CONNECTION_NAME
はCloudSQLのコンソールから取得できます。( PROJECT_ID:REGION:DBインスタンス名
のやつです)
※ --add-cloudsql-instances
オプションを付けないとアプリケーションアクセス時にCloud SQLに接続できずにConnection Errorとなるので注意が必要です。(私はこれを忘れて無駄にハマりました...チュートリアルにもちゃんとかいてあるのに...)
コマンド実行が完了したら最後に表示されるURLにアクセスすることでアプリケーションを表示することができます。
まとめ
Cloud Runへのデプロイができることでコンテナの設定だけしておけば簡単に外部公開できるアプリケーションができてしまいます。
チュートリアルだと.envで環境変数を設定していたり、PostgrSQLだったりとちょっと工夫したくなるところがあって微妙にハマりましたが、一回型ができてしまえばあとは無限に公開環境が作れてしまいますね!
スクレイピングで必要なデータを取得する
今回はプロ野球の試合結果を取得するプログラムを作成してみます。
rakeタスクを準備
今回はバッチ的な処理を想定してrakeタスクを使って実装していきます。
Railsプロジェクトは作成されている前提です。
まずはrakeタスクを作成します。
$ rails g task game_result
lib/tasks
配下にgame_result.rakeが作成されます。
まずは動作確認するためgame_result.rakeを書き換えます。
namespace :game_result do desc "試合結果を取得する" task :fetch do puts "fetch" end end
動作確認するためrails game_result:fetch
を実行します。
fetchという文字列が表示されればうまく作成できています。
データを取得する対象を特定する
スクレイピングで取得したいデータを確認します。
https://baseball.yahoo.co.jp/npb/schedule/ にアクセスすると最新の試合結果がわかります。
赤枠の部分を操作することで試合結果が取得できそうです。
class="bb-score__content"
となっている要素を取得すれば結果が取れそうです。
htmlを取得する
まずは試しにスポーツナビのHTMLを取得してtitleを表示してみましょう。
Nokogiriを使ったRubyスクレイピング [初心者向けチュートリアル] | 酒と涙とRubyとRailsと
こちらのサイトのコードを参考に書いてみます。
desc "試合結果を取得する" task :fetch do url = "https://baseball.yahoo.co.jp/npb/schedule/" charset = nil html = URI.open(url) do |f| charset = f.charset f.read end doc = Nokogiri::HTML.parse(html, nil, charset) p doc.title end end
この状態でrails game_result:fetch
を実行しましょう。
プロ野球 日程・結果 - スポーツナビ
が表示されていればうまく取得できています。
試合結果を取得する
試合結果を取得したいのでGoogle Chromeの検証ツールを使用してチーム名と得点付近のDOMに特徴がないか確認してみます。
確認してみるとホームのチーム名にはbb-score__homeLogo
、ビジターのチーム名にはbb-score__awayLogo
というclassが付与されています。
スコアの方にはホーム側はbb-score__score--left
、ビジター側にはbb-score__score--right
というclassが付与されています。
これらを使って欲しい値が取得できそうです。
スクレイピングのコードに次のコードを追加します。
先ほどのコードのp doc.title
の部分を以下に置き換えましょう。
doc.css(".bb-score__content").each do |node| home_team = node.css(".bb-score__homeLogo").first.content away_team = node.css(".bb-score__awayLogo").first.content home_score = node.css(".bb-score__score--left").first.content away_score = node.css(".bb-score__score--right").first.content p "#{home_team} #{home_score}" p "#{away_team} #{away_score}" end
試合結果が記載されているカードのパーツにはbb-score__content
というclassがついているので、それを起点に値を取得していきます。
cssメソッドを使うことでclass名やid名、タグ名を指定することで合致した要素が配列で取得できます。
bb-score__content
が存在するclassの中にあるチーム名、得点を取得したいので、先ほど検証ツールで見つけたclass名をcssメソッドを使って指定していきます。
cssメソッドは配列が返ってくるため、firstメソッドを使って要素を取り出します。
そしてcontentメソッドを使うことによってタグの中に記載されている文字列を取得することができます。
コードがかけたらrails game_result:fetch
を実行してみましょう。
$ rails game_result:fetch "ソフトバンク 4" "巨人 1"
上記のような形でスコアとチーム名を取得できたら成功です。
あとは自分の書いているプログラムで取得した値を使ってやりたいことを実現しましょう。
ぼやき
2019年振り返り・2020年について
完全にブログを放置していました。
新年になったということで、恒例の振り返りと新年について考えてみます。
2019年振り返り
2019年は環境の変化が大きかった1年でした。
大きく変わったことは3点くらいあります。
- 新しい職場で働いたこと
- 結婚したこと
- 結婚に合わせて住むところが変わったこと
新しい職場
今年1年は2018年12月に転職した先で働く1年となりました。
1年間新天地で働いてみて学びは色々あったと思います。
転職当時はWeb系の企業に転職してやっていけるか不安だったのですが、なんとかはやっていけそうという感覚が得られたことが大きいです。
また主体的に動けるプロジェクトを半年ほど経験することができ、なんとなく開発チームが抱える課題感が見えてきた気もするので2020年はそれをどうするか考えていきたいです。
新生活
今年は結婚しました。
2019年の自分史の中では一番大きなイベントだったと思います。
結婚に伴って、普段の生活に自分以外の人がいるという状態になっています。
当初はどうなるか読めなくて結構不安でしたが始めてみたら、意外と違和感ない感じがしています。
時間の過ごし方がなんとなく似ているところがあるのか無理せず生活できています。
むしろ嫁がいない状態の方が違和感が強いです。
まだ始まったばかりなので、なんとも言えない部分はありますがこの先もやっていけそう感はあります。
キャリア
今年は自分のキャリアについてかなり迷走する1年だったなーと思います。
去年取得したMBTI認定ユーザーであったり、今年取得した国家キャリアコンサルタントの資格に翻弄されたなあと...
せっかくとったし自分はキャリアの分野に興味があるはずだと思い込もうとしていたのかもしれません。
ただふと振り返ってみるというほど人のキャリアを考えていきたいという思いは強くないなーと思いました。
むしろ下手に関与すると消耗してしまうことにも気づきました。
キャリアに困っている知人をなんとか助けられないかなーと思ったりした時期もありましたが、これは能動的に動いてくれる人でないと助けたいと思えないという気づきを得ました。(きっかけがあったというよりは内省したら気づいた)
その結果、自分が興味がある分野の方向性も見えてきたので2020年はその方向性を大事にしたいです。
2020年目標
2020年は自分の軸を見つける年にしたいと考えています。
最近興味があると感じている分野はITとチームです。
ITは仕事をしているからというのもあるのですがやはり好きなんだと思います。
新しい変化を感じたり、自分で取り組むことで新しい見識が広がったりすることを感じられるからです。
キャリアに興味があるといって2019年はIT知識の吸収を怠った部分があるので2020年は技術もきちんと追っていきたいです。
もう一つ興味がある分野としてチームがあります。
多分私は何かの目標に向かって一丸で立ち向かえるチームで働くことに強い興味関心があります。
今の会社でも強いチームの構築が課題感としてあると感じています。(働いている人たちはみんないい人だけど何かよそよそしさがある的な)
2020年はチーム運営に手を出せそうなので本で得た知識などを実戦で試してチーム運営の知見を貯めていきたいです。
おわりに
とりあえず書いとこって感じの記事だったので取り止めがないのですが、 今年は自分の軸を見つける年だと思ってます。
新しく発見した興味関心であるチームについて強めに関わってみて本当に興味があるのかまず実験していきたいです。
Railsでソーシャルログインを作る(Yahoo編)
あけましておめでとうございます。
今年も気が向いたらブログ更新していくスタイルでぼちぼちやっていきたいと思います!
今日は突然Yahooでソーシャルログインを作る機運が高まり、試し実装したのでメモ書きしておきます。
少し古めではありますが、このエントリーにある内容をそのままなぞる形でいけました。
準備(YahooのAPIキーを取得)
YahooのID連携を利用する場合は以下のURLにアクセスします。
右横にあるアプリケーション開発のボタンをクリックして、遷移したページでアプリケーションを登録のリンクにアクセスします。
次にアプリケーションの初期設定を行います。
今回は開発用としてサイトURLにhttp://localhost:3000
を設定します。
あとはガイドラインへの同意を同意するを選択してください。
ここまで設定したら画面下部の確認ボタンをクリックして先に進んでください。
確認画面に遷移するので内容に誤りがなければ登録ボタンをクリックして登録完了です。
登録完了時にClient IDとシークレットキーが表示されるのでメモしておきます。
コールバックの設定
登録時の画面には項目がないので見落としますが、コールバックするURLの設定をしておく必要があります。
アプリケーションの管理:Yahoo!デベロッパーネットワークにアクセスして自分が作成したアプリケーションの編集ボタンをクリックします。
編集画面に遷移します。
コールバックURLという項目があるのでコールバックしたいURLを設定します。
今回はhttp://localhost:3000/auth/yahoojp/callback
としておきます。
ここまでできたら更新ボタンを押して準備が完了となります。
アプリケーション作成
Yahoo ID連携の準備が整ったので、コードを書いていきます。
バージョン
サンプル
今回作成したサンプルは以下になります。
GitHub - kimuray/social_test: OAuth実装して遊ぶ
開発手順
ひとまずrails new
し終わっている前提でやって行きます。
ライブラリの追加
yahooとOAuthするために必要なライブラリをGemfile
に追記します。
gem 'omniauth' gem 'omniauth-yahoojp'
追記したらbundle install
します。
omniauth設定
config/initializers
配下にomniauth.rb
というファイルを作成します。
作成したファイルに以下のコードを書きます。
Rails.application.config.middleware.use OmniAuth::Builder do provider :yahoojp, ENV['YAHOOJP_KEY'], ENV['YAHOOJP_SECRET'], { scope: 'openid profile email address' } end
APIキーとシークレットキーはそれぞれYAHOOJP_KEY
、YAHOOJP_SECRET
という環境変数に設定します。
YahooでID連携のアプリケーションを作成した際に表示されたClient IDとシークレットキーを設定しておきます。
また、scopeの設定はしておかないとOAuth時にエラーになるので設定しておきます。
Yahooと連携する処理を作成
ルーティング
root 'sessions#top' get '/auth/:provider/callback' => 'sessions#callback'
参考にしているエントリに習って、雑にルーティングを設定します。
'/auth/:provider/callback'
のルーティングはYahooで設定したコールバックURLとして扱います。
コントローラ
rails g controller sessions top callback
として雑にコントローラとviewを作成してしまいます。
app/views/sessions/top.html.erb
に
<%= link_to 'Yahoo Japanでログイン', '/auth/yahoojp' %>
を追記します。
これでYahooと連携できるアプリケーションができました。
あとはsessions_controller.rbのcallbackアクションにbinding.pry
を仕掛けるなどしてrequestを見て見たりすると連携できていることが確認できます。
本当にこれぐらいしかコードは書いていませんが、中身を見たいという方はサンプルを見てください。
最後に
めちゃんこ雑に紹介しましたが、ライブラリの力を使えば30分ちょいぐらいでYahooと連携できてしまうってすごいですねえ。
2018年振り返り
2018年も残すところ2日ということで今年の振り返りをざっくりしておこうかなと。
今年の年始に立てた目標を元に振り返っていきます。
年始に立てた目標
- 個人的にサービスを10個作ってリリースする
- 使える技術の幅を広げる
- 現在の会社で収益の柱になるサービスを立ち上げる
- 自分のブランディングを考える・土台を築き始める
- 人との繋がりを広げる
- 副収入を今の3~5倍にあげる
うーん、我ながら香ばしいくらいに意識高い目標です。
とりあえず一つずつ振り返ってみます。
振り返り
ではでは早速振り返っていきましょう。
個人的にサービスを10個作ってリリース
これ絶対『とりあえずキリいいし10個目指そ』のノリで立てたんだろうなあ。当時の自分。
今年リリースしたサービスは結局1つでした…. とはいえ1つリリースできたというところは褒めていきたい。えらい自分。
リリースしたサービスは『まんがのおばけ』という漫画の感想を質問箱的に投稿できるサービスでした!
これは友人の企画で作ったサービスなんですが、気の置けない人とのサービス開発の楽しさを知ることができました。
気兼ねなく議論して、より良いサービスを提供するにはを考えるのは控えめに言ってすごく楽しかった。
次はサービスをどのように運用して行くかも考えて、また新しくサービス開発したいです。
達成度的には1/10なので10%って感じですね。
使える技術の幅を広げる
これは定量で測れる指標を用意してなかったので達成度は測れなさそうです…
当時の記事を見てみるとデータ解析系の知識を云々と言っていますが…
データ解析系の勉強は1mmもしてないですね…
今年は幅の広がった技術領域があまりないのでエンジニアとしてやばい感
DockerやReactなど軽く触れるみたいなことはしたものの、手に馴染むまではいっていないというお粗末な状況…
12月に転職してWebエンジニアとしてやって行くことになったので、来年は技術の分野もしっかり磨いて行きたいです。
現在の会社で収益の柱になるサービスを立ち上げる
これは完全に未達ですね…
2018年開始当初は立ち上げに向けて動いていたのですが、なかなか前に進まない感じと結局何がしたかったのかがわからなくなってしまい頓挫しました。
サービス立ち上げにはそれなりのエネルギーを使わないといけないのだなあという学びでした。
達成度0%です…
自分のブランディングを考える・土台を築き始める
当初の記事を見てみると自己分析をして自分が何をやりたい人間なのかを考える的なことが書いてありました。
そういう意味で行くと今年は自分が向かいたい方面が少し見えた年だったかもと思います。
キャリア × IT
この方向性に興味があることが個人的に判明しました。
これは迷走しながら転職活動やMBTI認定トレーナー取得などに取り組んだ結果かなあと思います。
自分を嫌でも見つめ直す機会ができたことで、自分が密かに感じていた課題感に気づくことができたのかもという振り返りです。
MBTIは今年どハマりして無事認定トレーナーにもなっているので、来年どうにか活用して行きたい所存。
来年は国家キャリアコンサルタントの試験も受けるので、しっかり取得したいところです。
達成度としては定量目標ではなかったので、肌感で考えると方向性は見えたので50%くらいでしょうか。
人との繋がりを広げる
全然広がっていないです(白目)
1, 2月に勉強会などに週3, 4ペースで入れて参加していたのですが、目的なく人が多い場所に行くと何もできずにただただ精神が消耗して疲れだけがたまりました…
結果3月は仕事以外は外に出ない引きこもりになりました…(白目)
成果としては自分は見知らぬ人が不特定多数いる空間に行くと非常に精神が消耗することがわかったことでしょうか。
立食系の懇親会とか地獄でしかないということがわかりました。
そして人脈は目的なく広げるべきものでもないのかなと思いました。
昨日、陸王の再放送を見ていて思ったことがあります。
それは人脈は目的を持って行動している時に作られて行くものだということです。
陸王では社長である宮沢が陸王を作ろうと奔走することでシルクレイ著作者の飯山やシューフィッターの村野といった色々な人と繋がっていました。
これは陸王を作ろうという目的と意思があったからこそ出来上がった人脈だと思い、大事なのは場数を踏むことではなく目的を持つことなのだと勝手に解釈しました。
達成度的には圧倒的0%です。
2019年は人と繋がる意味や目的を見出して、時がきたらきちんと人脈を広げていきたいです(戒め)
副収入を今の3~5倍にあげる
この目標、金額だけでいえば達成はできているんですよね(困惑)
というのも仮想通貨でそれなりにプラスになったのが大きな要因です。
某取引所のXEM流出事件にしっかり巻き込まれたのですが、XEMを買った時期が春先だったので某取引所の補償額でかなりプラスになったんですよね。
ただ年始の目標を見ていると文脈的に仮想通貨というより副業でという側面が強そうなのでなんとも言えない…
仮想通貨は一過性の副収入で、副業は現在何もやっていないので来年どのように収入の戦略を立てて行くかが課題ですね。
達成度的には金額は満たしているので70%にしておきます。
ただ来年も副収入はなにかしら得たいので、来年は収入の口を増やすこともKPIとしてやっていきたいです。
総括
とりあえず全体の達成度を出すと
(10% + 0 + 50% + 0 + 70%) / 5 = 26% ※ 技術の幅の目標は定量化不可だったので除外
正直定量目標が少なかったので参考値でしかないですが26%の達成です。
感覚値だと3%くらいだと思っていたので、意外と高いかもしれない。
思ったより人生は進捗していたとポジティブに考えよう(現実から目をそらしながら)
文中に何回か出しましたが今年は転職やプライベート的に変化のあるイベントをこなしているので、目標以外のところで進捗が出ている面はありそうです。
とはいえ2018年の目標は雑だったなと思うので2019年の目標はもう少しリアリティ出しつつ、ストレッチできるようなものを考えていきたいです。
なんやかんやで今年も色々ありました。
2018年も残り2日ですが少しでも進捗出していきたいです。
AWS LambdaでSinatraを動かしてみる
12月から晴れてWebエンジニアになりました。
ということでアウトプットを増やしていかねばと久々の執筆です。
概要
今回はRubyのランタイムが追加されたAWS LambdaでSinatraを動かしてみたいと思います。
GitHub - aws-samples/serverless-sinatra-sample: Demo code for running Ruby Sinatra on AWS Lambdaを使ってREADMEに書かれているコマンドを実行していけばサクッとできます。
ただ個人的に何が起きているのかさっぱりで釈然としなかったので自分なりに理解しながら新しく作ってみました。
↓ 今回作ったサンプルコード
https://github.com/kimuray/sinatra_lambda_sample
登場人物
今回登場する役者は3つです。
AWS Lambda
言わずと知れたサーバーレスのコード実行サービスです。
サーバーを管理する必要がなくなるのでサーバーの準備や運用を考えなくてよくなります。
Sinatra
Ruby製のシンプルにWebアプリケーションが作れるフレームワークです。
Railsほど機能はいらんけど、ルーティングあたりの機能は欲しいなどの要望に応えてくれます。
AWS CloudFormation
AWSでのインフラ構築を自動化してくれるサービスです。
一度設定してしまえばそれに従って同一環境を何度でも簡単に作れるようになります。
今回はCloudFormationが主役になります。
AWS CloudFormation (設定管理とオーケストレーション) | AWS
Sinatraアプリを作る
今回はサンプル的に雑にテキストボックスを用意して、POSTリクエストを投げたら、投稿内容が画面に追加されていくようなアプリを作りました。
AWSのサンプルコードでもよかったのですがDynamoDBが使われていたりして、
俺は単純にviewをレンダリングさせて、POSTしてみたいだけなんじゃ!
という気持ちになったので新しく作りました。
AWS Lambdaのコードを書く
コードは以下になります。
https://github.com/kimuray/sinatra_lambda_sample/blob/master/lambda.rb
これは完全にAWSサンプルをそのまま持ってきました。
AWS Lambdaを使う際は
def handler(event:, context:) # なんらかの処理 end
という形で処理を書いていきます。
AWS LambdaでHello worldしてみるとわかると思います。
コードの内容的には受け取ったリクエストを整形してSinatraに食わせてレスポンスを整形して返却といったことをやっているようです。
CloudFormationを設定する
CloudFormationの設定はtemplate.yaml
というファイルに書いています。
https://github.com/kimuray/sinatra_lambda_sample/blob/master/template.yaml
これも大体AWSサンプルと同じです。
唯一違うとしたらDynamoDBを用意する設定を書いていないぐらいです。
設定内容のざっくり説明としては
といった設定が書いてあります。 template.ymlを設定し終わったらCloudFormationの準備は環境です。
デプロイ
デプロイはAWSのサンプルに書いてある通りawscliのコマンドを叩いていくだけで完了します。
※ 前提としてS3にソースを配置するバケットを作っている
必要があるので作っておきましょう。
まずはデプロイをするための設定ファイルを作成します。
以下のコマンドでserverless-output.yaml
という名前で作成されます。
aws cloudformation package \ --template-file template.yaml \ --output-template-file serverless-output.yaml \ --s3-bucket { your-bucket-name }
{your-bucket-name}
には自分で作ったS3のバケットを設定します。
次に生成された設定を使ってAWS Lambdaにデプロイします。
aws cloudformation deploy --template-file serverless-output.yaml \ --stack-name { your-stack-name } \ --capabilities CAPABILITY_IAM
{your-stack-name}
は任意の名前になります。
これでデプロイが完了します!
デプロイの完了を見届けたらAWSコンソールにアクセスして、AWS Lambdaに作成したアプリケーションがデプロイされていること確認します。
作成された項目にアクセスするとAPI Gatewayの欄をクリックすると、画面下の方にアプリケーションのエンドポイントが表示されます。
このエンドポイントにアクセスして、自分が作ったSinatraアプリが表示されたら成功です。
最後に
久々のブログだった...
ちゃんとエンジニアになったのでもっとインプット・アウトプットの量を増やさねば...
プログラミングスクール勤めのエンジニアが転職するってよ
お久しぶりです。
かなり久々のブログ投稿になります。
今回は転職活動
について取り上げたいと思います。
というのも7月あたりからぼちぼち転職活動していて、最近転職先が決まったのです。
私はWebエンジニアとしてプログラミングスクールで開発を行っています。
しかし、かなり我流で開発を行なっている状態になっています。
そこでエンジニアとして今後通用していくのか?と疑問を感じて転職活動を始めました。
そんな中で数社の企業様から内定をいただくことができました。
今回の転職活動で精神面がかなり成長したと感じています。
そして、もしかしたらこの2ヶ月ほどで考えていたことが誰かに役に立つかもしれないと思い記事を投稿することにしました。
特に自分のキャリアに迷っている人や何かに駆られて転職活動している人に届けられたら嬉しいと感じます。
転職活動記録
これから感じたことを書いていこうと思うのですが、その前に自分自身の体験を知ってもらった方が良いかと思います。
割と赤裸々に書いているつもりです(照)
転職活動のきっかけ
ここ1年くらいずっとエンジニアとしてのキャリアについて悩んでいました。 そんな悩んでいる中で今年の7月に完全にスケジュール管理おじさんになるような業務をすることになり、
『あれ?俺このままでええんかな?』
という気持ちに駆られるようになりました。
個人的には20代をどのように過ごすかが30代以降の生き方を左右すると考えています。
私はエンジニアとしてのキャリアを積みたいと考えていました。
そのため、スケジュール管理おじさんの状態は20代の時間を棒に振ってしまっているのではないか?と感じるようになりました。
7月 転職活動の火蓋が切って落とされる
一回転職しているとはいえ、現在の職はお声をかけてもらっての転職でした。
そのため、ほぼ転職活動は行なったことがなく実質今回の転職活動が初めての転職活動という形でした。
何がともあれ情報収集だと思ってとりあえずエージェントに話を聞きに行きました。
行ったエージェントはIT系に強い、よく名前を聞く2社とビズリーチ経由で繋がったエージェントが1社です。
3社のうち2社は転職活動の最後まで付き合うことになりました。
個人的な感覚ですがエージェントの良し悪しみたいなところはなんとなく見えた気がします。
エージェントの話はまた別記事で出していこうかと思います。
あとは転職ドラフトに参加しました。
思い悩んだタイミングがちょうどドラフトが始まる時期だったので、参加して選択肢を増やして行く手段に出ました。
選択肢は多めに用意しておくと思いもよらない形で結果が出たりするので種は撒いておいて損ないです。
7月は本当に種まき的な感じで情報収集ぐらいしかしてないですね。
実働はエージェントと話した3時間くらいかなあ
8月 面接面談が始まり迷路に迷い込む
8月になり、転職ドラフトで数社から指名いただきました。
とにかく話は聞こうというスタンスで指名いただいた全社にカジュアル面談を申し込みました。
そして、3社のエージェントのうち1社で
エージェント「とりあえず興味のある企業選んでください」
僕 「このあたりの企業さん興味ありますね」
と雑に興味ある企業を数社選んだらいつのまにか全社にエントリーされ、書類もするっと通ってしまい面接の予定がどんどん組まれていきました。
このあたりから平日夜の予定が面談面接で全て埋まってしまって精神が疲弊しはじめました。
そして、面談面接に行っては
「kimurayspさんはなんで転職しようと思ったんですか?」
「どのようなキャリアを積みたいと考えていますか?」
となんとなくで転職活動を始めてしまった自分には辛い質問を受け、うろたえる日々を繰り返していました…
雰囲気では答えられるけど深められるとすぐに底についてしまうということがかなりありました。
ある企業さんでは技術スキルを見られる面接を受けて、固まってしまうといったことがおきました。
もはや自分はエンジニアに向いていないのではないだろうか…?
ぐらいまで落ち込むこともありました。
そして始まる自己啓発
これは自分の癖のようなものなんですが、
自分が苦しい時や怒っている時に、なぜそう感じているのかを紙に書いてみて整理したり、自己啓発本を読んだりして自分にない考え方を取り入れたりしてみる
ということをよくやります。
今回も例に漏れず苦しさが尋常じゃなかったので自分についての整理を始めました…笑
整理の前に自己肯定感が尋常じゃなく下がっていたので自己啓発本を読むところから始まりました。
今回読んだのは「嫌われる勇気」でした。
チョイスは完全に勘だったのですが、これが意外といいチョイスでした。
読む中で 目的論 の考え方や 他人の人生ではなく自分の人生を生きる ことが重要だと知りました。
そこで考え始めたのが自分はなぜ転職活動を始めたのかというところです。
この時期は転職活動もやめようとも考えたりしていたので、このあたりが何を目的にしているのかも考えました。
転職活動を始めた目的
- スキルを身につけられる環境にいきたい
- 自分の将来を考えた時に現状の状態だと活躍している姿がイメージできない
- 成長できずにいたら最終的に自分に無能の烙印が押されてしまうことに恐怖を感じる
転職活動をやめようと考え始めた目的
- 迷っている状態で転職活動をしても結果に繋がらない
- 面接に行って自分という人間が否定された気持ちになるのが辛い
- 今の状態で転職できても役に立たないのではないか?
- 転職活動やめて現職に残れば役に立つ存在ではい続けられるかも
ざっと転職活動を始めた目的とやめようと考えた目的を見て行くと 自分の無力感を感じることを避けたい という目的があるように感じました。
自分の中に渦巻いていた感情がはっきりして割とスッキリはしました。
ここで出した結論は、持ち玉があるうちは転職活動を続けるが内定が出ても出なくても持ち玉がなくなったらきっぱり活動をやめる
ということでした。
どちらの選択肢をとっても感じる不安が同じなのであれば、全力で転職活動をして運命に身を委ねて、選択された運命の中で全力を出し切ろうという方針ができたという形です。
8月はそんな感じで方針がなんとなく決まって自己肯定感が少し回復してきたところで終わりました。
9月 自己理解が深まる、そして内定へ
9月の1週目にとある心理検査の認定トレーナー資格取得研修に参加しました。
この心理検査との出会いが自分の運命を変えました。
正直心理検査一つで大げさなという感じですが、マジで変わりました。
この出会いがあったから転職決まったと言っても過言ではないです。
この心理検査は自己理解を深めることが目的の検査でした。
認定トレーナーの講座では実際に心理検査を受験しました。
9月1週目は自分の性格を知り、自分の考え方について深掘りをひたすら行いました。
そこで無意識的だった自分の認知と考え方が意識できる領域に出てきました。
その結果自分は人の可能性を引き出せるようなこと
に興味があるのだとわかりました。
自分の行動や思考を振り返ってみると
- なんとなく国家キャリアコンサルタントの講習を受けはじめる
- プログラミングスクールで楽しいと感じたのは一緒に開発している人が成長したなと感じる時
など無意識のうちに人に関する領域に興味を持っていたと認知しました。
心理検査を受けた後の変化
自分の興味がはっきりしたことが転職活動に転機をもたらしました。
まず大きく変わったところとしては自分の興味がはっきりしたことで、今回の転職活動に目的が見えてきました。
人の可能性を引き出すことに携わって行く上で、まずは自分自身が行動することで自分の人生を選択することができることを証明すること
今後の長い自分の人生キャリアを考えた時に、この目的を達成することがまず重要であると考えられるようになりました。
次に自己理解が進んだため、面接で自分の考え方について深掘りされてもうろたえることなく自分の見解を伝えることができるようになりました。
その結果、心理検査を受けた後の面接は一度も落ちることなく最終的に数社から内定をいただくことができました。
この結果から 転職活動において自分への理解を深めることがとても重要 だと感じました。
自己理解を深めることの重要性
自分の転職活動の中で自己理解がかなり重要な要素だと感じました。
では、なぜ自己理解を深めることが転職活動で有効になるのか?
その理由を考察してみます。
なぜ転職するのか?に対応できる
この質問は面接の際には95%ぐらい(肌感)の確率で聞かれます。
転職活動に至る動機は人によって異なります。
ただこの動機をうまく言語化するのは難しかったりするのではないかなと感じています。
その結果、割と漠然とした動機しか話すことができずに爆死するという事案が起きる印象です。
例えば
未経験だけどWebエンジニアになりたいという動機
- なぜWebエンジニアになりたいと感じたか?
- Webエンジニアになってどんなキャリアを描きたいか?
- Webエンジニアになることでそのキャリアに向かって何が必要だと感じている?
現職が劣悪過ぎて、会社を変えたい
- 現職がどのように劣悪で、自分はそれに対してどんな印象を抱いているのか?
- 劣悪さの内容によっては会社を変えても変わらない可能性があるが、どんな観点で次の会社を探しているか?
- 現職の問題がもしかしたら業界の問題かもしれないが、なぜ同業界で会社を探しているのか?
- 会社を変えてどんなキャリアを描きたいか?
のような形で漠然とした動機だと、ざっくり掘るだけでもそれなりに質問ができてしまいます。
うまく動機が言語化できていないと、深掘りされた時に支離滅裂になってしまったり、イメージを言語化できずあやふやになってしまいます。
自分自身も自己理解が深まるまではこの辺りがあやふやでした…。
「なぜ転職するのか?」
という質問には
- 転職することで次の職場に何を期待しているのか?
- その人の考え方と会社の志向がマッチしているか?
- 会社はその期待していることを提供できるか?
といった会社と転職者の考え方の方向性があっているか見たいという意識があると思います。
漠然としていると会社とマッチしている人かどうかが不透明となり残念な結果になる傾向あるのではないかなあと推測しています。
これを明確にするためには、
自分の興味関心
将来のキャリア像
現状と理想のギャップ
この辺りを言語化できると、深掘りに耐えれるようになりますし、軸を持って転職活動に取り組めるので自分が求めている環境を探しやすくなります。
ちなみに自分は
- 興味関心
- 将来のキャリア像
- エンジニアチームでメンバーのやりたいことを引き出したり、仕事と関連付けたりするようなポジションに興味がある
- キャリアに困っている人を助けられるような仕事に興味がある
- いずれの方向性に進むにしてもエンジニアという仕事をベースにしたいので技術スキルを固める必要がある
- ギャップ
- 現職だとサービスの性質上システム開発はクリティカルではなく、開発スキルをもりもり身につけていくことが難しそう
- 色々な人に使ってもらえるものを作りたいが、スクール事業で今作っている受講生管理システムは最大でも200人ぐらいにしか使ってもらえない
- 立場的に上の人間がいないので、自分が目指すべきエンジニア像が見えない
- どのように成長する必要があるかが見えづらい
といったあたりの理由がありました。
個人的な見解ですが、だいたいこれぐらいの筋道が立っていると納得していただけたり、深められても自分の中から答えを探し出しやすくなる印象があります。
自分という人間がどんな思考をするのか伝えられる
正社員の採用だと、その人がどんな思考をして、どんな行動をするのか?
という部分は重要視されるのではないかと考えます。
この思考と行動の傾向がみえるとその人がどのように働く人なのかが見えてくる
と個人的に感じています。
思考がわかれば少し長い目で見た時にどれぐらい成長して成果を出してくれるかが見えてくると考えます。
自分の思考と行動を認識することができれば、
- どのような環境なら成長しやすいか?
- 成長のためにどのような取り組みをするか?(してきたか?)
- 何が得意か?苦手か?
- 仕事で大事にしていること
- やりがいに感じること
この辺りを面接等で伝えられるようになると
- どのように働く人なのか
- どのような成長をしてくれるのか
- 将来的なポジションのイメージ
といった仕事についての考え方のマッチ度合い、どれくらいで会社の利益に繋がる成長
をしてくれるかが見せることができると考えます。
つまり思考と行動がどれだけ整理されているかで一緒にやっていけるかどうかのイメージに与えられるかに繋がってくると考えられます。
ここで一緒にやっているイメージを与えることができれば採用に近くことができます。
ここまで自分の思考を明確にして、お互いに一緒にやっているイメージがつかないのであればマッチしなかったんだなと割り切ることもできます。
ここでも自分の考えを当てはめてみます。
- どのような環境なら成長しやすいか?
- ある程度裁量があって自分で動いたりすることができる
- モチベーションの高い優秀な人がいる
- 自分がその人とどんな差異があるか見出し埋めていけると考えている
- 成長のためにどのような取り組みをするか?(してきたか?)
- 足りないと感じたスキルについては自己学習
- 自分の感情や思考について分析している(内省)
- 自分の感情・思考に関する気づきがあると改善に繋げられる
- 何が得意か?苦手か?
- 得意
- チームの中で調和をとって活動すること
- 人の感情について考えながら仕事に取り組む
- チームの中で調和をとって活動すること
- 苦手
- 決断すること
- 人の感情などを気にして決断を思い切ってすることが苦手
- 合理的な判断基準を設けることで決断に踏み切るようにしている
- 決断すること
- 得意
- 仕事で大事にしていること
- 仕事は一人ではできないのでチームで協調することが重要
- やりがいに感じること
- 自分が作ったものが人に使ってもらえる
- チームメンバーが成長していることを感じるとき
当てはめてみると自分は
人との接し方に気を使ったり、チームで何かを成し遂げたりすること
にモチベーション感じる思考をしているのだとわかりました。
これをもう少し深掘りできると大体の質問には答えられると思います。
自分の場合は過去の経験の中にチームで一つのことを成し遂げた経験があったのがあったのでそれがベースという考えを伝えていました。
総括
個人的な感性ですが、自分は自己理解を深めたことで転職活動の風向きが変わったと感じています。
自分のことを自信を持って伝えられるようになることは面接の場面においてはかなり有効だと思います。
これはエンジニアへの転職活動に限らず、様々な業種で転職活動をしている人に共通するのではないかと考えています。
転職活動は内定をもらうことがゴールではありません。
働き始めた後に良い状態で働き続けられることが重要なのです。
そのためには自分のことをできるだけ多く会社に伝えてマッチするかを測っていくことが重要です。
実際に働いてみないとわからない要素もあると思いますが、全力のミスマッチは防いでいけると思います。
そして会社に多くのことを知ってもらうためには、自分のことを理解することが重要です。
自分のことを考えるのが難しい場合は、世にあるアセスメントツール(心理テスト等)を使ってみるといいかもしれません。
客観的に自分を分析する助けになります。
自分の場合はこれが9月に受けた心理検査でした。
この体験が転職活動を行なっている人が自分のことをきちんと理解し、より幸せな人生をあゆむための一助になれば嬉しいなあと感じます!