Fun Done Run

yazawa's tech blog

Tama Ruby会議01 に参加した #tamarubykaigi01

f:id:yazawa_tech:20190707170552p:plain

2019年7月6日に開催された「Tama Ruby 会議01」に参加してきた。時間は5時間超と長いかな〜と思って参加したが、どのスライドも面白くて発表も人それぞれテクい内容とエモい内容とあって、時間が過ぎるのがあっという間だった。参加して良かったな〜という気持ちが冷めないうちに、参加レポートを書いてみようと思う。

tama-rb.github.io

はじめに

未経験でこの世界に入ってエンジニア歴は3年とちょっと、最近「楽しみながら仕事をしたい」「もっと成長したい」と思っている自分にとって、改めてモチベーションを掻き立てられるイベントだった。当日の発表内容は登壇者の方のスライドを見ればわかるので、自分の感じたことなどを書けると良いと思う。

テーマは「Rubyist としての成長」

Ruby を使ったハンズオン的な内容やライブラリのお話に関しては、実戦経験も特になく、かつ自分の勉強不足ゆえテクい話は「なるほどわからん」みたいな内容が多々あり、力不足を実感するばかりだった。しかし、「テスト」「レビュー」「OSS コードリーディング」「コミュニティ参加」の話などなど、「エンジニアとしての成長」に汎化できるものも多数あった。

Keynote: Junichi Ito さんと Kuniaki Igarashi さん

今回はキーノートとして、「プロを目指す人のためのRuby 入門」の著者である 伊藤淳一さん と、「ゼロからわかるRuby 超入門」や「RubyRails の学習ガイド」の著者である 五十嵐邦明さん のお二人が登壇されていた。

「なぜテストを書くの?(または書かないの?) 〜テストコードの7つの役割〜」

最初は伊藤さんの「テストコードの役割」についての発表。こちらは初心者向けとのことだったが、テストについて意識することなく通ってきた人 にとっては、経験年数によらず大事な内容だったと思う。

特に、つい最近テスト駆動で開発を実践した話で登壇した自分にとっては、スライドの中の 「テストがパスすれば、自信を持ってリリースすることができる」「自信を持ってリファクタリングができる」 などの 「自信が持てる系」 の部分にはとても共感し、テストに対して同じようにメリットを感じられていたので、この発表を聞く前に自分なりにまとめられておいて良かったと思った。

f:id:yazawa_tech:20190707133039p:plain
テスト駆動で開発した話をした時のスライドの一部

◆伊藤さんのスライドはこちら

白魔術師への道 ~ Road to white mages ~

五十嵐さんは、最初に自分が「Ruby を勉強するなら周辺技術も含めた体系的に勉強したいなあ」と思った時に BOOTH で「RubyRails の学習ガイド」を購入した時にTwitter などでプロフィールを覗いていた。その時から「わかりやすい文章と絵を書く方だなあ」と思っていたので、今回も楽しみに聞かせていただいた。

Ruby には黒魔術と呼ばれるメタプログラミングを使った技法があるが、それを応用して「デバッグのために使用する黒魔術を白魔術と呼ぶ」ことにしながら、デバッグのお話をされていた。 デバッグの話の中に、役に立ちそうなgem の紹介や、「Ruby 超入門」の内容も一部出てきていたので、 気軽に読めるように「Ruby 超入門」の書籍版を早速Amazon で注文した。

ゼロからわかる Ruby 超入門 (かんたんIT基礎講座)

ゼロからわかる Ruby 超入門 (かんたんIT基礎講座)

◆五十嵐さんのスライドはこちら

やってみようと思ったこと

発表はどれも素晴らしく、感想も自分なりに様々あるのだが とても全部書ききれなかった ため、イベントに参加して 自分がやってみようと思ったことを書いてみようと思う。

OSS コードリーディング

今回のしおいさんの発表では「たのしいOSSコードリーディング:Let's read "cookies"🍪」というタイトルで、OSS を読むことで、(コードが)書けるようにもなるし、もっと難しいものを読めるようになることで、成長に繋がる」 ということだった。確かに発表を聞いていて、これだけしっかりと処理が追えている時点で他のことにもロジカルシンキングが汎化できているのだろうなと思うような内容だった。

加えて、プログラマとして成長するのに、「アウトプットする」というのはとても大事だが、OSS へのコミット(プルリク) への第一歩としてのfuqda さんの「OSS 初心者がつまづきながらOSS マナーを学んでいく話」の発表もとても有意義だった。 「取り組んだ人の経験に応じた学びがきっとある」 という一言で、自分も コミットできそうなOSS を探してみよう という気持ちになった。


コミュニティへの参加

okuramasafumi さんが、発表と特別企画での司会の発言の中で 「先輩もメンターもいない状況で他に学ぶところが本しかない、みたいになっちゃうので、コミュニティに行って盗むしかない」 ということを言っていた。確かに今の自分には「こうなりたい」みたいなエンジニア像の人がいなくて、最近はもっと成長したい欲という刺激を求めてコミュニティに参加し出したりしているというのもあるので、 どこか気軽に参加できそうなコミュニティを見つけたい と思った。今度定員オーバーしていなければ是非Tama.rb に参加してみたいと思った。


成長させたい分野の選択

katsumata-ryo さんの発表のまとめで 「全能になろうとしてたら器用貧乏になっていずれ死ぬ」 という一文があり、ギクリとしたシーンでもあった。最近ではあれもこれも知りたいし使いこなしたい、みたいな欲が多くて、それ自体は悪いことはないのだろうが、 「〇〇と言ったらこれ」みたいな得意分野がない と思っている。そういう 自分の代名詞を見つける ために、身に付けたい分野やスキルは、自分の意欲も含めて 客観的に得意かそうじゃないか という視点を持って選択することも大事だな、と思った。

上記で紹介できなかった登壇者の方の資料 (発表順)

当日の発表資料を登壇者の方がTwitter で流してくれていたので、拾えたものだけまとめてみた。

プロになるためのレビューのススメ konchan さん

brainf*ck処理系で理解するパターンマッチングをつかった疎結合な実装 Shu OGAWARA さん

こわくないDSL ken3ypa さん

ぼくらのリファクタリングは裏切らない💪ほたてさん

コードを「見る!書く!見てもらう!」で爆速ステップアップ! s_naga03 さん

Dartに浮気したらRubyは最高だと再認識した話 makicamel さん

WebAssemblyをRubyコンパイルする黒魔術コード完全解説 alitaso345 さん

どの方の発表もみなさん時間の限られた中できちんと結論までまとめていらっしゃって、わかりやすくとても楽しく聴かせていただきました。ありがとうございました。

まとめ

  • 総じて雰囲気がとても良く、和気藹々とした勉強会だった
  • Tama.rb に参加したくなった
  • Rubyist になりたい自分にとって、やりたい分野を絞って身に付けていこうと思ういいきっかけになった

開発サイクルを爆速で回そう! ~ Herokuを使ってRailsアプリをデプロイするまで ~

f:id:yazawa_tech:20190705103445p:plain

仕事とは別にRuby on Rails(以下 Rails)を修得中で、作ったアプリをローカルホスト以外で動かすためにHeroku にデプロイしてみた。Heroku とは何かということと、実際にHeroku のプラットフォーム上でアプリが動くことをするところまでをまとめておく。

Heroku とは

PaaS(Platform as a Service) の一つで、主にアプリケーションのデプロイ、環境の管理、スケールなどをお任せできるサービス!デプロイするための環境の構築や管理が不要で、開発者にとってはプロダクトを完成することに集中できるという利点がある。また、様々な言語のアプリケーションに対応しているため、主要な言語で開発したプロダクトに関してはほぼほぼ動作させることができる様子。チームでDevOpsを回すにも有用なそうだが、今回は個人開発なので個人で使う人向け。

jp.heroku.com

Heroku 以外の選択肢は?

個人開発をするにあたり、PaaS やIaaS、VPS などなどいろいろな選択肢があるかと思うが、今回は 「インフラを全く意識せずWebアプリを公開して動作させること」 が目的だったため、Heroku を対象にしてみた。PaaS だけではないが、個人開発時にどのサービスを使うか、みたいな比較の記事はこちらのQiita の記事が参考になると思う。

qiita.com

アプリをHeroku にデプロイする

さて、ではさっそくRails で作成した簡単なWeb アプリをHeroku にデプロイしていく。Heroku の利用にはSign up が必要なため、登録してから進める。

signup.heroku.com

フロー

  • Heroku CLI のインストール
  • Heroku にログイン
  • Rails アプリケーションの準備
  • Ruby のバージョンの確認
  • Rails アプリのGit 管理化
  • Heroku にデプロイ
  • アプリケーションの起動

Heroku CLI のインストール

Heroku はログインすれば GUI(ブラウザ)でも操作できるが、CLI で操作できるように以下のコマンドを実行してインストール。

% brew tap heroku/brew && brew install heroku

brew install heroku はともかく、brew tap heroku/brew って何かと思って調べてみると、brew tap コマンドは 公式以外のformula をダウンロードすることのできるサブコマンド らしい。こちらの記事が参考になった。

qiita.com

コマンドの実行が完了したら、インストールされていることを確認する。

% heroku --version
heroku/7.25.0 darwin-x64 node-v11.14.0

Heroku にログイン

heroku login コマンドを使ってまずはHeroku にログインする。

% heroku login
heroku: Press any key to open up the browser to login or q to exit:
Opening browser to https://cli-auth.heroku.com/auth/browser/66fe1a7d-a267-45ca-a375-d396f030b12e
Logging in... done
Logged in as piyo@example.com

heroku: Press any key to open up the browser to login or q to exit: まで表示された時点でEnter を押すとブラウザが起動するので、「Log in」ボタンを押してターミナルに戻ればログイン完了になる。

f:id:yazawa_tech:20190705062725p:plain
ブラウザでログイン画面が立ち上がる

CLI オンリーでログインしたい場合は-i オプションをつければ、EmailPassword を入力するよう促されるので入力してEnter すればログインできる。

% heroku login -i
heroku: Enter your login credentials
Email: piyo@example.com
Password: **********
Logged in as piyo@example.com

Rails アプリケーションの準備

今回は既に作成してあるRails アプリを使う。

% cd /Users/piyo/env/work/taskleaf

新しくRails new して作る時に注意しないといけないのは、 Heroku にデプロイした後にルートアドレスにアクセスした時のページを定義することを忘れずに。

% cat config/routes.rb | grep root
        root to: 'tasks#index'

Ruby のバージョンの確認

Gemfile に記述してあるruby のバージョンとローカルホストにインストールされているruby のバージョンが同じである必要があるので、それを確認する。

% grep "^ruby" Gemfile
ruby '2.5.1'

% ruby -v
ruby 2.5.1p57 (2018-03-29 revision 63029) x86_64-darwin18

Rails アプリのGit 管理化

Heroku にデプロイする時にもGit を使ってデプロイしていくので、対象のアプリケーションがGit 管理されている必要がある。Rails アプリは Rails new した時点で.git ファイルが含まれているので、大丈夫かと思う。

% ls -la
total 72
drwxr-xr-x  22 piyo  staff   704  7  4 06:26 .
drwxr-xr-x  18 piyo  staff   576  7  4 06:01 ..
drwxr-xr-x  12 piyo  staff   384  7  5 06:47 .git
-rw-r--r--   1 piyo  staff   620  7  4 06:00 .gitignore
-rw-r--r--   1 piyo  staff     5  7  4 06:00 .ruby-version
-rw-r--r--   1 piyo  staff  2232  7  4 06:26 Gemfile
-rw-r--r--   1 piyo  staff  5739  7  4 06:26 Gemfile.lock
-rw-r--r--   1 piyo  staff   374  7  4 06:00 README.md
-rw-r--r--   1 piyo  staff   227  7  4 06:00 Rakefile
drwxr-xr-x  10 piyo  staff   320  7  4 06:00 app
:
:

Heroku にデプロイ

ではHeroku にデプロイをしていく!対象のRails アプリを新しいHeroku アプリとして追加する!

% heroku create
Creating app... done, ⬢ protected-sierra-22318
https://protected-sierra-22318.herokuapp.com/ | https://git.heroku.com/protected-sierra-22318.git

すると、Heroku に対象のアプリのリポジトリが作成される。

この時点で git remote -v するとHeroku のGit リポジトリが追加されている。

% git remote -v
heroku  https://git.heroku.com/protected-sierra-22318.git (fetch)
heroku  https://git.heroku.com/protected-sierra-22318.git (push)
origin  https://github.com/yazawatech/taskleaf.git (fetch)
origin  https://github.com/yazawatech/taskleaf.git (push)

ではmaster ブランチの内容をHeroku にアップしていく。

% git push heroku master
:
:
remote:        https://protected-sierra-22318.herokuapp.com/ deployed to Heroku
remote:
remote: Verifying deploy... done.
To https://git.heroku.com/protected-sierra-22318.git
    * new branch      master -> master

プッシュが完了したら、Heroku のサーバー上にあるPostgresql にもDB の内容を反映させる。

% heroku run rake db:migrate
Running rake db:migrate on ⬢ protected-sierra-22318... up, run.3150 (Free)
:
:
D, [2019-06-22T09:24:25.354947 #4] DEBUG -- :    (1.3ms)  SELECT pg_advisory_unlock(4371305944939093965)

デバッグログと共に準備していたマイグレーションファイルの適用内容が表示される。

アプリケーションの起動

heroku create コマンド時に表示されたURLをブラウザに入力しても、もちろんアプリは確認できるが、heroku open コマンドを使うと、そのアプリのルートアドレスをブラウザで表示してくれる。

% heroku open

f:id:yazawa_tech:20190705071240p:plain

今回はアプリの仕様でルートアドレスにアクセスした時にログインされていなければ/login にリダイレクトするようになっているため、 https://protected-sierra-22318.herokuapp.com/login が表示されている。これでHeroku にアプリケーションをデプロイすることができた!

まとめ

今回はHeroku を使ったハンズオンの流れを書いてみた。感想としては以下の通り。

  • PaaS を使うと簡単にWeb アプリを公開することができるので、LT でのデモにも良さそう
  • Heroku はAdd-on も充実しており、何か一つサービスを使ってみたい
  • CI/CD の練習としても使えそうなため、CI ツールとの連携を検討すると面白そう

これからも開発していく中で上記のことを試せないか考えつつ、ブログに書きたいと思う。

『テストファーストで開発したら最高だった!』というタイトルでLT をしてきた

先日社内イベントで、エンジニア4年目にして初のLTをしてきたので、その時のレポートをまとめておこうと思う。

発表資料(Speaker Deck)

テスト駆動開発

簡単に言うと、テスト駆動開発(DDD)とは 「レッド・グリーン・リファクタリング」という順番で開発を進めていく ことにより、 最終的に「動作するきれいなコード」 を実現する開発手法のことである。 テスト駆動開発については、有名なものに『テスト駆動開発 | Kent Beck, 和田 卓人』がある。 なお、現在Rubyを個人開発のために勉強中だが、『プロを目指す人のためのRuby入門 | 伊藤 淳一』も、ハンズオンを通してテスト駆動開発のフローを実践できるようになっているため、オススメ。

テスト駆動開発

テスト駆動開発

なぜLTをしようと思ったか

エンジニアとして、アウトプットが大事、というのは意識の中にありつつも「ネタがないから」とか「技術力がそこまで高いわけでもないし」みたいなことを言い訳にしてきた。 今年度に入って意識改革をして、登壇。以下のことを意識してアウトプットをとにかくやってみることにした。

  • はじめから上手くできる人はいない
    • やっていかないとうまくならない
    • まずはやることで良かったところ、まだまだなところが見えてくる
  • 失敗してもいい
    • 失敗しても『行動したという事実』だけは揺るがない(自信につながる)
  • レベルが低いと思われてもいい
    • 誰かのことを『レベルが低い』と言って笑う人がいても、その人も別の誰かから見たら『レベルが低い』かもしれない
    • 人の行動している姿を見て そんな態度を取る人の方がヤバイ
    • 実際にはそんな人はいなかった

LTしてみて良かったところ

綺麗なスライドが作れた

LTではそこまでスライドをこだわらない人が多いイメージだけど、自分は準備をきっちりかっちりやりたくなってしまうので、以下の @kakakakakku さんの記事を参考に資料を作った。

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

おかげでデザインほぼパクリみたいになってしまったが、どちらかというと『0→1』の発想が苦手なため、『1』となるものを作る経験ができて良かったと思う。 これから自分なりに見せ方等々を工夫していけたらと思う。

意外としゃべれないということを実感

今回は自分の携わっているサービスでの事例を紹介したものの、背景にある『サービスの概要』だったり『なぜそのAPIを作ることになったか』などの部分で、うまくトークができなかった。 これは圧倒的に 練習不足。 プレゼンやプログラミング体験会の講師をした時など、基本的には練習をするのだが、 今回はしなかった。 スライドを作って満足してしまったのかもしれないが、次からはやはり練習が必要だと実感。反省。

Q&A

有難いことにLTをした後に質問をくれた人がいたので、その時のやり取りをまとめてみる。

Q1

Q1. 今回は新しく作ったAPIユニットテストを導入したということだったんですが、既存のコードにもテストは書かれているのですか?

A1. 現状は書かれてないです。。。今のコードが他社から引き継いだもので、スクリプトのように記述してあるため、一気に切り出すのが難しそうで、ユニットテストの導入まで至っていないです。

既存のコードのロジック部分がほとんどスクリプトのような形式で書かれているため、メソッド化して切り出してあらゆる影響がないかを確認…みたいなことができていないのが現状。 こういうコードにテストを導入する時の手順というかベストプラクティスみたいなのはどうなんだろう…やっぱり地道にリファクタリングするしかないんだろうか。

Q2

Q2. 『レッド・グリーン・リファクタリング』のフローの『リファクタリング』の部分てやりましたか?自分は動くものができたらあまりやらないのですが…

A2. やりました!『グリーン』までの段階だと良くない変数名とか重複したロジックとか、全然残っているので、リファクタリング楽しいですしちゃんとやりましたね。笑

これは本当に、『グリーン』まで来てしまえば『要求される仕様』は満たせている状態なので、時間の許す限りコードのクオリティを上げる作業(=リファクタリング)に時間を使っていいと思う。

Q3

Q3. このケースだと最初の『テストパターンの洗い出し』が一番重要だと思うんですけど、何かコツとかってあるんでしょうか。

A3. 変動する値に関してはまずすべて洗い出して、取り得る値を列挙してみる。その洗い出したパターンを基に、上長や他チームの有識者の人と認識合わせをして、『このパターンはない』とか『こんなイレギュラーがある』とかを発掘していく。その後で、『実際にリリースする日時はいつが現実的か』などを詰めていって、現実の予測と一番近い変動値(日時・金額)等をテストパターンに組み込むと良いんじゃないでしょうか!

ちょっと回答が長くなったけど、自分なりに留意したのは以下の点だったと思うのでまとめておく。

  • 変動値はすべて洗い出す
  • 変動値が取り得る値のすべてのパターンを洗い出す
  • 有識者(運用T含む)と認識合わせをする
  • 変動値を実際のリリースに合わせてリアルなテストデータを作る
  • パターンの中でも優先度をつけ、優先度の高いものからテストコードを書いていく

まとめ

  • 6月のアウトプットの目標に掲げた『月に1LT』は達成できた
  • 引き続き社内イベントの幹事を継続するので、人数が足りないときや前座でできそうな時は積極的にLT をしていきたい

先週の振り返り (2019年6月17日週)

今週も振り返りを実施する。振り返りは内省のためにやった方が良いが、週に一度ブログにまとめるのは文字にするからいいかもしれない。

振り返り

  • ブログを1記事書いた: 仕事で使っているLaravel のTips 的な記事
  • 毎日コミットした: Rails の参考書とその他
  • 読了した!: 管理ゼロで成果はあがる ~「見直す・なくす・やめる」で組織を変えよう
  • LTの資料作り(社内ビアバッシュ用)

反省点

  • Trello のDoing レーンが消化できていない
  • 継続学習タスクが多すぎて、集中力が分散してしまっている(Rails 以外はできていないことが多い)

先週の自分より成長できているか

  • Yes
    • 【継続中】毎日1コミットして、Ruby on Railsに対する知識を身につけた

自分の目指すキャリアとズレが生じていないか

  • Yes
    • 【継続】アウトプットを積極的に行って知識の定着を図る: GitHub, ブログ, LT
    • 将来的に総合的な幅広い分野に対する知識を身に付けたいけれども、今は習得したいことを絞って実践するべき

やること

  • Trello の「Doing」リストの数を減らす
    • WIP: 6 → 4
    • 継続学習タスク1: Ruby on Rails
    • ハンズオン系: 興味のあること
    • 読書系: 読んだ本の感想や得た学びを書く
    • その他: 上記に当てはまらないもの
  • 【継続】引き続きRailsの基礎修得: 『Ruby on Rails 5 速習実践ガイド』
  • LTの資料を作る
  • LTする(社内ビアバッシュ)
  • 本を読む: 『RubyRailsの学習ガイド 2019 技術書典6 拡大版』
  • 本を読む: 『テスト駆動開発

参考図書

現場で使える Ruby on Rails 5速習実践ガイド

現場で使える Ruby on Rails 5速習実践ガイド

テスト駆動開発

テスト駆動開発

リクエストをすべてログに出したい / Laravel の Middleware を使ってリクエストをログに出す

f:id:yazawa_tech:20190617172010p:plain

Laravel で受け取ったリクエストをログ出力するために、Middlewareの機能を使って実装してみた。個人的なメモとして忘れないようにまとめておく。

完成形

  • RequestLogging.php
<?php
namespace App\Http\Middleware;
use Closure;
class RequestLogging
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle($request, Closure $next)
    {
        $query = collect($request->all())->except("q")->all();
        \Log::debug($request->method(), ["IP" => $request->ip(), "path" => $request->path(), "query" => http_build_query($query)]);
        return $next($request);
    }
}
  • Kernel.php (該当部分のみ)
<?php
namespace App\Http;
use Illuminate\Foundation\Http\Kernel as HttpKernel;
class Kernel extends HttpKernel
{
    /**
     * The application's global HTTP middleware stack.
     *
     * These middleware are run during every request to your application.
     *
     * @var array
     */
    protected $middleware = [
        \App\Http\Middleware\RequestLogging::class,
    ];

目次

  • Middleware とは
  • Middleware の作成
    • Middlewareクラスの作成
    • ログ出力処理の実装
  • Kernel.php の設定

Middleware とは

公式 より以下を抜粋して和訳してみる。

# Introduction
Middleware provide a convenient mechanism for filtering HTTP requests entering your application. For example, Laravel includes a middleware that verifies the user of your application is authenticated. If the user is not authenticated, the middleware will redirect the user to the login screen. However, if the user is authenticated, the middleware will allow the request to proceed further into the application.

Additional middleware can be written to perform a variety of tasks besides authentication. A CORS middleware might be responsible for adding the proper headers to all responses leaving your application. A logging middleware might log all incoming requests to your application.

There are several middleware included in the Laravel framework, including middleware for authentication and CSRF protection. All of these middleware are located in the  app/Http/Middleware directory.

(出典: Middleware - Laravel - The PHP Framework For Web Artisans)

和訳(Google翻訳より)

ミドルウェアは、アプリケーションに入るHTTPリクエストをフィルタリングするための便利なメカニズムを提供します。たとえば、Laravelには、アプリケーションのユーザーが認証されていることを確認するためのミドルウェアが含まれています。ユーザーが認証されていない場合、ミドルウェアはユーザーをログイン画面にリダイレクトします。ただし、ユーザーが認証された場合、ミドルウェアはリクエストがアプリケーション内部にさらに進むことを許可します。

認証以外にもさまざまなタスクを実行するために、追加のミドルウェアを作成することができます。 CORSミドルウェアは、アプリケーションから送信されるすべてのレスポンスに適切なヘッダーを追加する責任があります。ロギングミドルウェアはあなたのアプリケーションへの全ての入ってくるリクエストをログするかもしれません。

認証およびCSRF保護のためのミドルウェアを含む、Laravelフレームワークにはいくつかのミドルウェアが含まれています。これらのミドルウェアはすべて app/Http/Middleware ディレクトリにあります。

概要をまとめると以下のようになる。

今回は和訳の部分にもあるロギングのためのミドルウェアを作成したので、以下手順をまとめる。

Middleware の作成

Middlewareクラスの作成

php artisan コマンドを使用してMiddlewareのクラスを作成。

$ php artisan make:middleware RequestLogging
Middleware created successfully.

以下のようなファイルができあがる。

<?php
namespace App\Http\Middleware;
use Closure;
class RequestLogging
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle($request, Closure $next)
    {
        return $next($request);
    }
}

ログ出力処理の実装

ログを出力する処理を handle メソッドの中に記述する

    public function handle($request, Closure $next)
    {
        $query = collect($request->all())->except("q")->all();
        \Log::debug($request->method(), ["IP" => $request->ip(), "path" => $request->path(), "query" => http_build_query($query)]);
        return $next($request);
    }

Kernel.php の設定

Middleware を作成したら、 Kernel.php で読み込むよう 必ず追加する

    protected $middleware = [
        :
        \App\Http\Middleware\RequestLogging::class,
    ];

試しにローカルホストでサーバーを起動してリクエストすると、以下のようにログが出力される - リクエス

curl -X POST \
-F 'server=example.com' \
-F 'id=test' \
-F 'item=piyo' \
-F 'option=true' \
http://localhost:8000/path/to/api
  • ログ
[2019-06-17 00:10:20] localhost.DEBUG: POST {"IP":"127.0.0.1","path":"path/to/api","query":"server=example.com&id=test&item=piyo&option=1"}

まとめ

  • Laravel で全てのリクエストをログに出すように設定してみました
  • Middleware はartisanのコマンドで簡単に生成できるし、ログの出力もファサードを使うだけなのでとっても簡単
  • 今回はすべての環境でログが出力されるようにしているが、環境に合わせて出力の有無も切り替えられるので、必要に応じて実装できるようにしておく

参考サイト

先週の振り返り (2019年6月第3週)

前回に引き続き、今週も振り返りをブログに投稿してみようと思う。今週はあまり自分自身の成長を感じられなかったが、次週につなげていきたい。 ちょっとTrelloのリストを使って継続の仕組みを見直してみようと思う。

振り返り

  • ブログを1記事書いた: 振り返りの記事のみ
  • 毎日コミットした: Ruby on Rails 5 速習実践ガイド
  • RSpecで簡単なユニットテストとSystem Specを書いた
  • AWS Summit Tokyo 2019に参加した
  • AWSを使ったネットワーク構築について少しづつ勉強し始めた: Amazon Web Services エンタープライズ基盤設計の基本
  • 土日で読書した: 管理ゼロで成果はあがる ~「見直す・なくす・やめる」で組織を変えよう

反省点

  • ブログに先週の振り返りの記事しか投稿できなかった(技術的な記事が0)
  • やりたいことに対して目標値を決めていないものが多いので、定量的に振り返りができない
  • 勉強会参加の記事や、書評も書きたいが、文字数が多くなりすぎる
  • やりたいことの中で、できていないことがある(DB設計)

先週の自分より成長できているか

  • Yes
    • AWS Summit に参加して、基礎知識の体系的な復習ができた
    • 毎日1コミットして、Ruby on Railsに対する知識を身につけた

自分の目指すキャリアとズレが生じていないか

  • Yes
    • 個人的に学習していること中心にアウトプットをしているので、今の所ズレてはいない
    • 【継続】幅広いスキルを身に着けて一人前のプロフェッショナルになる: Rails, AWS, DB設計等々
    • 【継続】アウトプットを積極的に行って知識の定着を図る: GitHub, ブログ, LT

やること

  • Trello の「Doing」リストを以下のように分けてみる(WIP: 6に設定中)
    • 継続学習タスク1: Ruby on Rails
    • 継続学習タスク2: AWS クラウド設計
    • 継続学習タスク3: DB設計
    • ハンズオン系: 興味のあること
    • 読書系: 読みたい本を読む
    • その他
  • Trello の「Doing」リストにあるカードを、1日ずつ回していく
  • 引き続きRailsの基礎修得: 『Ruby on Rails 5 速習実践ガイド』
  • Amazon Web Serviceの設計・構築を勉強する: 『Amazon Web Services エンタープライズ基盤設計の基本』
  • DB設計についても、少しづつ学習していく: 『達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ』
  • LTの資料を作る: 来週の振り返りまでに完成を目標
  • 本を読む: 『管理ゼロで成果はあがる ~「見直す・なくす・やめる」で組織を変えよう』

参考図書

現場で使える Ruby on Rails 5速習実践ガイド

現場で使える Ruby on Rails 5速習実践ガイド

Amazon Web Services エンタープライズ基盤設計の基本

Amazon Web Services エンタープライズ基盤設計の基本

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

先週の振り返り (2019年6月第2週)

先週から無事にブログを再開することができたのと、Trelloで自分のアウトプットを管理するようになったので、遅くなってしまったが6月第2週の振り返りをしてみようと思う。

振り返り

  • ブログを1記事書いた: 「1日30分」を続けなさい!
  • 毎日コミットした: Ruby on Rails 5 速習実践ガイド
  • Trelloでやりたいことを管理するようになった
  • RSpecに初めて触れるようになった
  • Rails Security Guide読んだ

反省点

  • ブログに書評を書くときに、何度も見返して書いていた
  • Ruby以外にもやりたいことがあったけどできなかった
  • ブログの投稿が遅れてしまった

やること

  • Amazon Web Serviceの設計・構築も勉強する: Amazon Web Services エンタープライズ基盤設計の基本
  • 本を読む: 管理ゼロで成果はあがる ~「見直す・なくす・やめる」で組織を変えよう
  • LTの資料を作る

先週の自分より成長できているか

  • Yes
    • Railsを体系的に学ぶ中でテストコードの記述の方法を学んだ
    • 停滞していたブログ(アウトプット)を再開した
    • 人に伝わるように、LTでの発表の骨組みを考えた

自分の目指すキャリアとズレが生じていないか

  • Yes
    • 幅広いスキルを身に着けて一人前のプロフェッショナルになる: Rails, AWS, DB設計等々
    • アウトプットを積極的に行って知識の定着を図る: GitHub, ブログ, LT

参考図書

現場で使える Ruby on Rails 5速習実践ガイド

現場で使える Ruby on Rails 5速習実践ガイド

Amazon Web Services エンタープライズ基盤設計の基本

Amazon Web Services エンタープライズ基盤設計の基本