Developer Summit 2025いってきた
最近勉強会やカンファレンスなど参加してなかったなーと思い、有休消化中のこのタイミングでDeveloper Summitに参加してきました!
生成AI周りの考え方は学びになることが多く、エンジニアキャリア系のセッションはこれから習慣見直していくぞという気持ちになれてよかったです。
印象に残ったセッション
生成AIアプリの本番導入を可能にした3つの評価プロセス~DB設計レビュー自動化の取り組み~
生成AIアプリの評価に関するセッション。
生成AIアプリはまだ作ったことがないのですが、作るならなんとかできるかもしれないが評価は確かに難しいなとセッションを聞いて思いました。
定量での評価も大事だが、LLMに評価をさせる文脈でクライテリアを言語化して評価するみたいな話もあり、人間の会社員を評価するのと差がなくなってきているなと感じました。
具体的にどんな世界になるかは想像がついていませんが、AIをマネジメントする時代はもう遠くない感覚を受けました。(セッションの本筋と外れた印象抱いている感はありつつ)
生成AI時代のプロダクトの現在地点
LLMを中心に見据えたプロダクト構成を念頭においた開発が今後主流になっていく感覚を感じました。
文脈は違いそうですが別のセッションでもLLMフレンドリーなアーキテクチャを考えていくことが重要になっていくという話もあったので、コードの作りにせよプロダクトのデータの活用にせよLLMを意識した開発をできるかがプロダクトを成長させるのに重要になりそうです。
既存業務を変えずに自動化できるという方向性が出てきたことにより、既存業務をツールに合わせて変えていくといったこれまでのDXとは違う潮流が来そうな予感がします。(既存業務を変えないSaaSというパラダイム)
目の前の仕事と向き合うことで成長できる - 仕事とスキルを広げる
内省とフィードバックループをいかに習慣に取り込むかを考えさせられるセッションでした。
業務の8時間だけ理想のエンジニアを演じるという考え方も自分の観点になかったものでした。
内省は不定期でするのですが、日報によって習慣化されたりはしていないので、まずは日報始めたいと思いました。
ゲーム業界のホワイト化の光と影は後で読んでおきたい。
エンジニアコミュニティでひろがるキャリア、深まる人生 - “コミュニティへの還元”リレーション -
コミュニティを運営されたり、登壇したりをやっている方々のセッション。
みんなパワーがある感じでした。
あなたのネクストアクションはなんですか?という問いがすごくよかった。
これまでコミュニティに関わったりという活動はしてこなかったのですが、今年は何かのコミュニティに飛び込んだりしてみたいなと思いました(こなみかん)
まずはどこかのコミュニティに飛び込んでみる。これがネクストアクションになりそう。
そして人と話すコミュニケーション能力つけていきたいです(切実)
おわりに
久々のカンファレンス参加でしたが色々と刺激をもらって、これから何を変えていこうかなとか何を学んでいこうかなとか色々と考えることができました。
少しずつこういう場に参加する回数を増やしていきたいぞ
2025年はコンフォートから抜ける
めちゃめちゃ久しぶりの投稿です。
娘が生まれてから大晦日がただの日常になってしまい、年末感を全く感じないのでせめて目標だけでもと筆を取ることにしてみました。
2025年の変化
2025年は少なくとも転職をするという変化が決まっている。
設立して数年も経っていないスタートアップに1人目エンジニアとしてジョインする。
チャレンジングな選択をしたので期待ありつつ、やれるのか...!?みたいな不安が付き纏っている。
ここ数年、なんとなく逃げていたハードスキルと向き合う年になる。
そして組織づくりなど人間としての器も試される。
これまた目を背けていた実行力と真正面から向き合う必要がありそう。
プライベートとしてはイヤイヤ期の娘を抱えながら、仕事とどう向き合うかという問いも問われる。
諸々考えると2025年は多分ここ数年で一番試される年になるんだろうなあという気持ち。
2025指針
2025年は色々な思考や選択が次から次にやってくる。
思考が迷子になることも多く出てくると思うので、迷った時に目指す方向を自分に示したい。
- プロダクト価値の向上に貢献する
- 思考や経験をアウトプットする
- メタ視点を強化する
ざっと思っているのはこんな感じ。
プロダクト価値の向上に貢献する
これは転職するからには一番意識したいことだと考えている。
アプリケーションやアーキテクチャの設計・実装など責任を持って考える立場になるため技術の向上に努める。
市場的にはLLMをアプリケーションに組み込む流れが加速すると思うので、LLMを利用したアプリケーション設計は特に学習を進める必要がある。
思考や経験をアウトプットする
ここ数年は思考や経験を自分のものに落とし込めるところまでいかない状態でやりくりしていることが多かった感覚。
自分のものに落とし込めていないのは言語化できていないことが要因として大きいので、意識的にブログ等のドキュメントにアウトプットしたい。
ポエミーな思考まとめははてな、技術系はZennでやっていく予定。
メタ視点を強化する
人間としての器を大きくする上で自分自身がなにを感じているか、どんな感情が生まれているかに自覚的になる必要があると考えている。
例えば何か逃げたくなるようなことがあった時に、無意識がなにを拒絶しようとしているのかを理解できるようにしていきたい。
メタ視点が強化されることで実行力を向上させるきっかけを掴んだりできるのかなと考えている。
兎にも角にも頑張る
2025年はコンフォートゾーンを脱する年。
コンフォートを超えた先の景色がどんなものかを知るためにもこれまでの自分を乗り越えていきたい。
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日ですが少しでも進捗出していきたいです。