Chrome Developer Tools 入門を読んだ

Amazonレビュー的な何か

一言で言うと神本だった。

バックエンドの開発を主に担当しているが、フロントも触ることになった人。つまり、自分のような人にぴったりの一冊だ。

Developer ToolsのElementとConsole機能のみを利用したことない人に新たな世界を見せてくれる。

ちまちまElementのStyleでmarginやpaddingをいじる動作なんて辞めてしまうだろう。

個人サイトを開発してる人にとっては、Audits機能が!

Railsのconsoleで確認していたCacheが!とバックエンドの開発に活かされる部分も多い。

本当に初歩的な内容だが、Chrome Developer Tools の機能を使いこなせていないという人には、是非オススメしたい本だ。

1時間をあれば、さくっと読める良書に圧倒的感謝!!!

GraphQLのNewRelicTracingがテスト時のみエラーになる。

TL;DR

テストでのみ、NameError: uninitialized constant GraphQL::Tracing::NewRelicTracing::NewRelicとエラーが出た。

原因は、gem 'newrelic_rpm'をテスト環境で導入していなかった。

テスト環境で導入するか、Rails.env.test? でテスト時はuse(GraphQL::Tracing::NewRelicTracing) を含めないようにする。

詳細

GraphQLで生じるN+1問題を解決するために、Gemの導入を検討する必要がありました。

まずは、現時点でのGraphQLのアクセスをNewRelicで監視対象に追加したかったので、GraphQL - Tracingを見て調べてました。

すると、GraphQL::Tracingを継承して自作の監視機能を作る方法が紹介されていました。

よくドキュメントを見ると、NewRelicはGraphQL-rubyでサポートされていることがわかりました。

早速、ドキュメント通りスキーマに定義しました。

class MySchema < GraphQL::Schema
  ~~~
  query(Types::QueryType)
  use(GraphQL::Tracing::NewRelicTracing, set_transaction_name: true)
  ~~~
end

CircleCIが落ちているので、ローカルで再現するとGraphQL全テストにて NameError: uninitialized constant GraphQL::Tracing::NewRelicTracing::NewRelic というエラーメッセージが表示されました。

GraphQL - Tracingのドキュメントはシンプルで目ぼしい解決はありませんでした。グーグル先生もGraphQLの知見は、まだ溜まってないようです。

仕方ないので、初めてソースコードを読むことになりました。RefineryCMSというGemを覗いたことはあったのですが、Railsの使い方をために読んだのでRubyによったものは、未経験でした。

より詳細なAPI-Docには、ソースコードの位置情報も載っています。

とりあえず、それっぽいファイルがありました。

graphql-ruby/tracing.rb at master · rmosolgo/graphql-ruby · GitHub

graphql-ruby/platform_tracing.rb at master · rmosolgo/graphql-ruby · GitHub

graphql-ruby/new_relic_tracing.rb at master · rmosolgo/graphql-ruby · GitHub

PlatformTracingが親となって、各プラットフォームが定義されていることがわかりました。

さて、問題はGraphQL::Tracing::NewRelicTracingにNewRelicというClassがあるとかです。ソースコードを見るとありませんね。

ここで、かなり時間を使ってしまったのでメンターの方に質問するとテストだけ呼び出すことができないかを確認した方がよいというアドバイスをもらいました。

そこで、development環境でクエリを叩くとエラーは出ませんでした。

少し悩んだ後、そもそも外部依存のNewRelicがテスト環境で使えないのではないかと思い、Gemfileを探すとgem 'newrelic_rpm' がテスト環境にありませんでした。

追加して、bundle installするとテストが通りました。

デバックの低さが目立ちかなりの時間を使ってしまいましたが、use がRack関連であることやソースコードを読むことで自前のTraceも実装できそうという自信がついたのでよかったです。

ご静聴ありがとうございました。

RSpec stub_constで定数をスタブするとClassがModuleになる

タイトルのままですね。

特定の条件下で、stub_constを利用するとClassがModuleになってしまいます。

解決策としては、stub_constでクラスを式展開で先に宣言することで動くようになります。

stub_const('Model::CONST', 2) # ダメ

stub_const("#{Model}::CONST", 2) # 式展開で呼び出す

以下、該当Issueの要約です。

定数が定義されているClassを呼び出す前に、stub_constでスタブしてしまうとmoduleとなってしまう。

開発者であるMyron Marston さんは、この動作は理想的ではないが、RSpecが情報を制限されたさせた状態で動いている以上

この動作は仕方ないので、現状のところ修正する気はないようです。

Myron Marston さんは、require "model" のように先にClassを宣言してあげることを提案しています。

他のコメントにて、式展開という解決策が提案されています。

require "model" はstub_constと行が離れてしまうため、該当Issueのリンクをコメントとして残し、式展開することでテストを通しました。

しかし、あまり綺麗な実装方法とは言えないので実力をつけて解決方法を提案したい。

github.com

社会人の入門書 Team Geekを読んだ

Amazonレビュー的な何か

入社した初日にScramについて何かいい本がないかと偉い人に聞いた際、Team Geekをオススメされました。

他の書籍を読んでいて存在を忘れていたのですが、チームメンバーも社会人入門書としてTeam Geekを推していたので読んでみました。

まさに、社会人入門書。帯にあるように、「ギークでなくても本書のアドバイスは読む価値がある。」はその通りです。

最高のチームの基礎は、HRT文化があることです。Humility(謙虚)、Rspect(尊敬)、Trust(信頼)の3つです。

具体的なHRT文化の例として、コードレビューに所作についての言及がされています。

君は君の書いたコードではない。 私は、この意味に気づくのに入社して1ヶ月もかかりました。

当初、PRレビューの仕方がよくわかりませんでしたが、コードに全員が責任を持つという意識を持ち始めてコツを掴めたのです。

チームで開発する中で、PRレビューの仕方にだんだんと慣れてきましたが、もっと早く読んでいればという後悔があります。

ちなみに、今ではレビューしてくれる人がつまづかないように、どういう経緯でコードを書いたのか。レビューする時には、自分の中で学ぶなどをコメントに書いています。HRTレビューは、チームを強靭にする一つの方法ですね。

書籍を通して、一番印象に残ったのは ミッションステートメント(いや、マジで) です。いや、これはマジ同意しかないです。

ミッションステートメントとペルソナが明確な組織は強いと思いました。

ペルソナは、ソフトウェア開発をする意味と目標を与えます。ミッションステートメントは、ソフトウェアのイデアです。

二つの明確なゴールがしっかりとしていなければ、不幸なチームができてしまうのでは、ないでしょうか。

なぜ、ミッションステートメントが印象に残ったのか考えてみると過去に苦しみ、現在もまた苦しんでいるからです。

過去の苦しみとは、大学での学生同士の開発です。世の中に、単位のかかったソフトウェア開発ほど上手くいかないものはないのではないでしょうか?そう、ミッションステートメントが真逆だからです。ある学生は、単位がもらえる最低限度のソフトウェアを望みます。また、ある学生は学びが多くなるように技術的好奇心を満たすソフトウェアを開発しようとします。

「チーム開発を学ぶ講義は、チーム開発を嫌いにする」というぐらいミッションステートの方向性が異なる崩壊チームは、チーム開発への嫌悪感を抱かせます。私は、いまだに学生同士のソフトウェア開発を成功させる方法がわかりません。

現在でもミッションステートメントでつまづいていることが、印象に残った理由です。

社会人になり、チームでの開発が上手くいってもまだ満足な開発は、できないことに気がつきました。

自分の認識できる範囲だと、一つの事業部署単位でチームになる必要があります。そう、事業部全体でミッションステートメントを共有する必要があるのです。

最後の章でも述べられているように、エンジニア以外のチームとの共有です。書籍では、マーケターでした。

ソフトウェアを開発して届ける。その過程全体に関わる人、全員でチームにならなければならないのです。

勢いで、書き殴ってしまったので少し締めようと思います。

Team Geekは、チームをマネージメントするだけが読む本では、ありません。全ての人が読む価値のある本です。

楽しい職場にしたいと願う全ての人にオススメの本でした。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

@kakakakakkuさんのブログメンティーへ応募した

@kakakakakkuさんのブログメンティーに応募するためと、振り返るために文章を残しておく。

希望する理由

4月より新卒でRailsを主としたバックエンドエンジニアをしています。 研修を自分で考えながら、3ヶ月行うというものでした。業務の時間を半分使って研修を行っているため 十分なインプットをすることができました。また、業務でも自動送信メールの実装やCircle CIのversionアップなど 学びながらアプトプットをしています。しかし、その場しのぎで公式ドキュメントを読んで対応しているため 学んだことが定着していないという問題点があります。ブログのメンティ期間を通じて、学んだことを 自分の中で消化できるブログを書きたいと思い、希望しました。

好きな(これから好きになりたい)技術領域

チームと開発組織が楽しく開発できる技術領域に関心があります。

学生時代もインターンなどで開発、チームを組むことがありましたが、 地方出身ということも短期インターンにしか参加することが難しく、本格的なチーム開発を経験したことがありませんでした。 4月の入社した会社にて、本格的なScramで開発をしています。 そこで、チーム開発の楽しさを知りました。そして、チームメンバーのことが大好きになりました。 今まで特定の技術に対して、情熱的な思いを抱いたことがないのですが チームメンバーがもっとベロシティーを上げたり、人生が楽しくなる現場にする技術に興味を持ち始めました。 チームの心理的安全性を上げるために、何が必要かと考えた時、テストが堅牢であることが一つの要素となるのではないかと考えました。 また、リモートインターンRSpecを書いていた経験や英語が少しできるので、まだ翻訳されていない書籍などを読むことで 他人と差別化できるのではないかと思ったので、テストを好きになっていきたいです。

次に、開発組織を支える技術としてデータベースとAPI設計に興味があります。

バックエンドエンジニアの仕事として、API開発があります。近年、マイクロサービス化が進む中でAPIの重要性が高まっているように思います。

とりあえず、JSONを投げてみました。というやっつけのAPI設計でフロントやアプリチーム困らせ 組織自体の雰囲気が悪くならないように他のチームに優しいエンジニアになるべく設計に強くなっていく必要があります。 このAPI設計から生じる影響は、APIの重要性が高まる中でより大きくなっているのでは、ないかと思います。

コンピューターサイエンスの世界では、アルゴリズムとデータ構造。 どうコンピュータが動くのかが重要です。また、多くのエンジニアもアルゴリズムとデータ構造の重要性を説きます。

しかしながら、まだ社会経験が浅く技術レベルも幼稚ですが、GAFAミドルウェアを開発するような会社を除く一般的な企業において もっとも重要な技術は、データベース周辺の技術だと思っています。自分が好きなこととして抽象化があり、これはデータのモデル化と似ていると思い、学んでいて楽しいです。

開発組織全体が気持ちよく開発できることを可能し、学んでいて楽しいので、データベース技術が好きな技術領域です。

以上の2点、つまりテストとデータ周辺技術が好きな技術領域です。

ブログ URL(もしあれば)

https://imaharu-blog.hatenadiary.jp/

熱意/モチベーション/アピール

fukabori.fmで、仕事よりブログが大事、ブログは自分の子供 を拝聴しました。

その中で、Trelloでタスクを管理しネタを細分化、週に一度ありたい自分とのギャップを考えているいう話が印象に残りました。

私も、個人Trelloにてタスクを管理してやりたいことと、今月やることを管理しています。しかしながら、内省がしっかりできていないため効率が悪くなっています。 メンティーとなったら、上記のような自分管理方法を学ばせて頂ければと考えています。

大学の誕生から研究としての大学再生までの歴史 - ストロングゼロは睡眠薬

教育に関する記事ですが、このように特定テーマに関して多くの書籍を見比べて文章を書くことに苦手意識はないのですが、

一つのページに関して、学びをどのように伝えるかに苦手意識を持っています。

現在、Railsガイド、MySQL、GraphQLドキュメントを読む活動をしています。公式ドキュメントを読むことで得た知識を上手く伝えるスキルを今は持っていません。 特に、GraphQLに関しては日本語情報が少ないことから、公式ドキュメントから得た知識を共有することは価値が高いと思っているため、メンティー期間で伝えるスキルを磨いて、多くの人にGraphQLの素晴らしさを伝えていきたいです。

MySQLで遊ぶためのDocker構築

MySQL :: MySQL 5.6 リファレンスマニュアルの読んでいく活動をしています。

ローカルでゴニョゴニョすると、エラーで時間を取られることになるのでDocker環境を作りました。

$ docker pull mysql:5.7
$ docker run -v mydb:/var/lib/mysql --name Doc-MySQL -e MYSQL_ROOT_PASSWORD=password -d mysql:5.7

$ docker exec -it container-ID bash -c 'mysql -u root -p'
> Enter password: MYSQL_ROOT_PASSWORDで設定したパスワード
> create database test;
> exit

$ docker stop container-ID
$ docker start container-ID
$ docker exec -it container-ID bash -c 'mysql -u root -p'
> Enter password: MYSQL_ROOT_PASSWORDで設定したパスワード
> show databases;

ローカルデータからInsertするなど改良を続けると思いますが、困った時に別途対応していきます。

どんどんこの記事にTipsをためていきます。目指せMySQL完全に理解マン。

Active Job の基礎を読んだ

Railsが全然理解できないので、Railsガイドを隅から隅まで読んでいく活動をしています

今回は、Active Job の基礎です。

学んだこと

  • Active Jobは、非同期処理をラップしたフレームワーク

  • デフォルトでは、Railsを再起動するとキューに溜まったJobは失われる。

  • setメソッドで実行した時間を指定できる。

  • Rails自身が提供するのは、ジョブをメモリに保持するインプロセスのキューイングシステムだけ。

このため、バックエンドとしてSidekiq、Resqueなどが組み合わせて利用される。

config/application.rbにバックエンドのアダプターを設定する。

class Application < Rails::Application
  config.active_job.queue_name_prefix = Rails.env
end

のように、キューにprefixを指定できる。

  • コールバックでJobの実行前後にトリガーを挟める。ログなど
before_enqueue
around_enqueue
after_enqueue
before_perform
around_perform
after_perform