2018/12(社内勉強会)|TechRacho(テックラッチョ)〜エンジニアの「?」を「!」に〜|BPS株式会社エンジニアの「?」を「!」に。2018/12(社内勉強会)hachi8833シェアツイートブックマークLINEこんにちは、hachi8833です。BPS社内勉強会でmorimorihogeさんが発表した「月刊Railsウォッチサマリー」の2018/12版を元にお送りします。反応がよければ月刊として定着させたいと思いますので、皆さまからのフィードバックやご要望を@morimorihogeまたは@hachi8833までぜひお寄せください?。hachi8833morimorihogeコメント:Railsウォッチを毎週やっている中では、時によっては半分以上がマニアックな話題に終始してしまうことがあり、普段のWeb開発業務に直接役立つ知識を追いかけている人にとってはノイズに思えてしまう部分も多いと思います(ノイズの中にも面白いネタが転がっているので意図的にやってるのですが)。「面白さ」を追求する週刊Railsウォッチに対して「実用性」を追求した月刊サマリーとでもご理解下さい?。※なお、ピックアップしているトピックや内容の重要度については多分に僕個人の価値観が含まれるため、業務でのご利用の際は皆様一次ソースをご確認の上自己責任でご利用下さい。LambdaがRubyに対応、JSはPromiseを最初に学べほかこの回は「公開つっつき会」の日でした。ES2015リライトに関連して、morimorihogeさんによるES2015やJavaScriptの今後の見通しについて以下が示されました。少なくとも「将来CoffeeScriptやSprocketに戻ることはないだろう」という見解です。・もう少しこなれてくれば使えるようになるかも・Webpacker本家のバージョンに完全追従していないなどはかなりつらい・Webpackerがつらいなら生Webpackにする手もmorimorihogeコメント:非Railsメインな方も読んでいるかもしれないので念のため補足しておくと、WebpackerはRailsでwebpackを簡単に扱えるライブラリです。new時のアセット管理のデフォルトツールになる予定なので、世のRailsエンジニアは追いかけておく必要があります。Webpackerにはかなりハマりどころも多く、本家webpack側のバージョンアップに追随するのが少し遅かったり、ちゃんと使おうとすると結局ある程度しっかりとしたwebpackの知識も必要になってくるということから、webpackを簡単に使うためにWebpackerを導入したのに結局勉強するものが増えてしまったという悲しい気持ちになることもあります。昨今ではフロントエンドエンジニアとバックエンドエンジニアが分業するスタイルが一般化してきましたが、フロントエンジニアにとってはWebpackをいつも通り使いたいだけなのに、なんでWebpacker使わないといけないんや!Rubyわからん!!というhateを生み出す要因になってしまうところもあると思います。いうわけで、フロントとバックエンドを開発するメンバーなりチームが明確に分かれていて、かつフロントエンジニアがRailsにそれほど慣れていない場合には素のwebpackの方がチーム間は仲良くできるのではないかなあ、と思っていたりします。お互い適切な距離感が大事。気が付きませんでした?。Recordの#update*系メソッドは要注意ActiveRecordの更新系メソッドには注意を要するものがあるという話題になりました。ここでいう更新系メソッドは、#saveや#updateや#update_attributesなどです。RailsだとActiveRecordに相当)を信頼してない)が、ORMを使ってしか開発したことがないような人が踏みがちなやつです。RDBMSから見ると整合性があるけど、アプリケーションから見ると不整合なデータというのはRailsだと割と作りがちで、かつ発生してしまった場合の障害も割合危険なものになることが多い(アプリケーションエラーになってしまうケースが多い)ため、コードレビューの際には注意してチェックしたいところです。カラムコメントをちゃんと書いておくと後で身を助ける話データベーステーブルのカラムを作成するときには、適切なカラムコメントを日本語で追加しておくと自分やチームを助けるという話題です。morimorihogeさんによる勉強会での説明の要点を以下にまとめました。中規模〜大規模なシステムでテーブル数やカラム数が増えてくると、英語のカラム名を見ただけでは日本語名をすぐに想像できなくなることがよくあります。XXX_atやXXX_keyのような類似の英語カラム名が増えてくると、確認の手間も増えてしまいます。Excel形式のスキーマ仕様書も納品する場合、データベースのスキーマ更新のたびに仕様書を手動で更新するのはまったく非効率です。一般的なRDBMSではスキーマ定義時にカラムにコメントを追加する機能があります。Mk-2などの整形ツールを援用してスキーマ仕様書を自動生成することもできます。4以前ではgemが必要でした)。morimorihogeコメント:SIerアレルギーの過激な人なんかは「Excel仕様書なんていらない。schema.rbのソース見ろ」みたいなことをいう人もたまにいるのですが、アプリケーションコードが何の言語で書かれていようが気にしないけどDBの中身がどうなっているかは外部連携やビジネスロジックの検討上知りたいというケースは多々あります。初期はRailsアプリのコードが読める身内メンバーだけで開発していたが、システムの運用拡大に伴い「DB仕様書見せて」というケースは比較的多いので、いざという時にチョロく生成できるための先行投資としては悪くないと思います。Rails」はRailsを中心に、Webアプリでセキュアなデータを扱うときの注意点を運用も含めてひととおり紹介しています。以下はこのトピックに関するmorimorihogeさんの説明のまとめです。Capistranoは今も優れものBPS社内の標準デプロイツールであるCapistranoは今も便利なツールであるという話題でした。Capistranoは既に空気のように当たり前に使われているので、その分最近Capistranoに関する新しい話題を見かけなくなっているという指摘になるほどと思いました。勉強会では、その他にCapistranoによるデプロイをインフラエンジニアとアプリエンジニアのどちらが設定すべきかという話題にも触れました。以下はmorimorihogeさんの説明のまとめです。Capistranoのデプロイ設定は、どちらかというとアプリエンジニアの仕事だと考えるアプリケーションの細かい設定は、インフラエンジニアだけではできないものであり、インフラエンジニアの作業範囲を超えると考えるインフラエンジニアは文字通りインフラを準備することが業務スムーズな連携作業のためにも、アプリエンジニアはCapistranoのデプロイ設定を書けるようになって欲しいmorimorihogeコメント:インフラエンジニアとアプリエンジニアの責任分界点は割と会社やプロジェクトチームによっても異なるケースを見かけますので、この辺りは唯一の正解があるわけではないと思います。弊社ではインフラエンジニアよりもアプリエンジニアの方が数が多いこともあり、なるべくアプリエンジニア側でできることはやってもらう運用にしています。Meetup」(Railsdm)というカンファレンスの特徴などについてmorimorihogeさんが解説しました。Railsを中心に据えていて、業務に直接役立つ発表が多いRubyKaigiほどマニアックではないRailsのベテラン開発者、経験の浅い開発者のどちらにもおすすめできる発表内容がバラエティに富んでいて、技術寄りでない発表もあり私(hachi8833)も、RailsdmはRailsの開発者にとって参加する価値が高いと思いました。2019は発売したその日にチケットが完売していました。url_forは慣れが要るRailsつっつき会と本勉強会の両方で、しきりに「#url_forは闇が深い」という話が出ました。以下はつっつきと勉強会でのmorimorihogeさんの説明をまとめたものです。RailsのURLHelperのメソッドである#url_forはルーティング形式の引数をURLに変換するためのもので、*_pathや*_url、link_to、form_forなどのビューヘルパーの内部で多用されている#url_forは単に奥が深いというより、後方互換性などによって闇が深くなっている面がある#url_forは実に多種多様なパターンで引数を受け取れる#url_forの挙動を理解しようとしても、少々実装を追いかけたぐらいでは理解できない#url_forを使いこなせるようになると引数を簡潔に書けるようになる勉強会では、#url_forの多種多様な引数の渡し方とどう取り組むかについてmorimorihogeさんから次のような話もありました。引数の渡し方は、参加するRailsプロジェクトによって異なることが多い(新しく実装するなら1つの書き方だけ覚えていれば済む)さまざまなプロジェクトに参加するには、引数の渡し方のパターンをある程度網羅的に知っておく必要があるそのためにも、さまざまな引数の渡し方を少しずつでも学んで慣れておくとよいmorimorihogeコメント:url_forの書き方は少なくとも同一プロジェクトの中ではある程度統一した方が良いと思います。書き方がばらばらだと単に読みにくいというのもありますが、ソースコード検索でも見落としが出やすくなってしまうため、Routingの見直し時に更新漏れが発生してエラー原因になったりする危険性もあります。この辺りは既に走っているプロジェクトであれば、既存ソースを見ながら郷に従うのが正義だと思います。コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。チュートリアル第2版の監修および半分程度を翻訳、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れて更新翻訳中。enno.jpを運営。実は最近Go言語が好きで、Goで書かれたRubyライクなGoby言語のメンテナーでもある。仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。Storageを使ってはいけない(翻訳)#Tags#会社紹介#自社サービス#勉強会#Rails#PHP#デザイン#実績#週刊RailsウオッチCONTACTお気軽にご相談ください。(翻訳)CONTACTTechRachoでは、パートナーシップをご検討いただける方からのご連絡をお待ちしております。お気軽にご意見・ご相談ください。