読者です 読者をやめる 読者になる 読者になる

てくすた

ピクスタ株式会社のエンジニア・デザイナーがつづるよもやまテクニカルブログです

SQL アンチパターン読書会を終えて

2017年春アニメは『ロクでなし魔術講師と禁忌教典』、『エロマンガ先生』、『終末なにしてますか? 忙しいですか? 救ってもらっていいですか?』、『サクラクエスト』、『クロックワーク・プラネット』、『ソード・オラトリア』を見ている id:necojackarc です。

およそ半年前に開始した SQL アンチパターン読書会が無事最終回を迎えました。

texta.pixta.jp

そこで本エントリでは、読書会参加メンバーの感想の一部をご紹介します。

SQL アンチパターン読書会の開催を検討中の方の参考になれば幸いです。

参加者の声

D.K さん

第一部は DB に関わるエンジニアは必ず読んでおくべき内容だと思います。 受託の開発を10年ほどやってきましたが、アンチパターンの宝庫のような酷い DB をたまに目にしました。 ピクスタは中途採用が多く、DB 経験がある人がほとんどだったので理解できましたが、DB を初めて勉強する人にはピンとこないかもしれません。 今日、画像を DB に保存するケースはないと思いますので (11章 ファントムファイル)、SQL アンチパターン v2 の出版が待たれます。

K.I さん

全24+1のテーマが「やりたいこと→アンチパターンの解説 (何が・なぜ起きるのか、あるいは使用を認める例外について) →解決策の提示」という展開で構成されている。各章10ページ前後と程よいボリュームなため、サクサクと読み進められた。1コマ60分で行う読書会には適していた。 テーマによって馴染みのあり・なしがあったが、参加者内で議論できるものが多かった。印象に残っているテーマは第1章「ジェイウォーク」と第24章「マジックビーンズ」。前者はソフトウェア開発に携わるすべてのエンジニアが目を通すべき基本事項がまとめられている。後者はソフトウェアそのものの設計やアーキテクチャにも踏み込んでいる。

M.M さん

たまにつまみ読みで読み返していたけれど、しっかり読むのは2回目だった。みんなで読むと読み落としを見つけたり、新しい視点の意見も聞けたりして、いろいろな気づきがあって良かった。 「アンチパターンを用いても良い場合」の節が好きで、感覚で理解していたことが明文化されてて共通認識としてしっくりきたところでした。

N.O さん

入社時期の関係で途中からの参加でしたが、各アンチパターンの事例や、より良い設計に関する議論が一つ一つできて良かったです。 例示されているアンチパターンは、実装コストを優先するあまり、またはそれ以外の要素の考慮が足りずに、パフォーマンスやメンテナビリティを欠く例が多く、そのようなパターンに対して共通認識を持てると、チーム開発の精度が高まりそうです。

T.S さん

初回、和田さんに講演して頂けたおかげか、「この読書会には意味がある」と思ってもらえたのが最後まで走りきれた理由だと思う。 半年くらいかかったが、ほぼ全員が一通り「共通語としての SQL アンチパターン」に触れられて良かった。 これまで DB を専門として扱って来たメンバーが少ないので、かなりやる価値は大きかった。

Y.G さん

業務中に予習なしで参加できるお気軽設計のおかけで、最後まで参加できた。 SQL アンチパターンは各章の内容が独立しており、かつ分量が多くないので、このようなスタイルの読書会にとても向いていると思う。 内容もとても良くて、特に第I部の「データベース論理設計のアンチパターン」は Web アプリケーションを実装する全てのソフトウェアエンジニアが読むべきだと思った。

Y.I さん

途中までの参加(その後ベトナム駐在となったため)であったが、DB を扱う際の注意点とか観点とかが読書会を通して身につきました。 アプリケーションを触るにあたって、DB も同時に触れる機会があるので、数多くのメンバーに知識が入ったことは大きいと思います。

次の読書会

業務時間内に行う読書会として、次は「プリンシプル オブ プログラミング」に取り組んでみようかと考えています。

選定理由としては、

  • 既に読んだメンバーからの強い推薦がある
  • 原理原則集のため、途中参加がしやすい

といった点です。

業務時間内を利用した、エンジニア全体の技術力を向上させる取り組みは、ぜひ今後も続けていきたいと思います。

WE ARE HIRING!

browserify から webpack に移行した話

はじめまして、技術推進チームの id:yszk0123 です。

ピクスタではアプリケーション開発に Ruby on Rails (以下 Rails と表記) をメインで使っていますが、最近 JavaScript (以下 JS と表記) 周りのビルドツールを browserify から webpack に移行しました。本エントリでは、webpack に移行した理由や、Sprockets との兼ね合い、最近登場した webpacker との比較について話したいと思います。具体的な導入方法については Qiita のエントリをご参照ください。

qiita.com

次のような読者が対象です。

  • Rails エンジニア
  • モダンなフロントエンド環境を Rails で使いたい人
  • webpack と Sprockets を共存させたい人
  • webpacker を導入できない・導入に迷っている人

背景

Rails では、JS をはじめとした assets ファイルの管理にはデフォルトで Sprockets が使われます。ピクスタでも Sprockets を使っており、それに加えて Yarn と browserify を使って依存関係の管理やビルドを行っていましたが、問題がいくつかありました。

まず、Sprockets を使っていると JS 周りのエコシステムを最大限に活用できないという問題があります。また、browserify によるビルドとの相性が良いとは言えませんでした1

とは言っても、Sprockets を全く使用しないというのは難しいです。すでに多くの箇所で使われている javascript_include_tag のようなパス解決のためのヘルパーメソッドはそのまま利用したいと考えました。

また、browserify は webpack よりもシンプルで扱いやすいですが、最近登場した開発ツールは webpack 向けに実装されることが多く、browserify では対応できない場面が増えてきました2

もう1つ、Rails5.1 から導入された webpacker を使えば JS 周りの開発フローが大幅に簡略化できますが、Rails5.1 以前では使えない、結合が密でいざという時に捨てにくい、といった問題があります3

このような理由から、ピクスタでは browserify や webpacker を使わず、webpack と Sprockets を適度に共存させる構成を採用しました。

導入

Sprockets によるビルド過程をすべて webpack で行うようにして、javascript_include_tag と stylesheet_link_tag のパス解決にのみ Sprockets を利用するようにしました (下図参照)。

f:id:yszk0123:20170509173551p:plain

表向きの機能は変わりませんが、全てのページのJSに影響するため、少しずつリリースすることで影響範囲を狭めるようにしました。

結果

webpack を基本とした構成にすることで、柔軟な設定ができるようになり、今後の改善の土台が整ったと思います。 Rails のレールから大きく外れないように配慮したため、大きな変更も必要ありませんでした。

一方で、難しかった点もあります。 ファイルの圧縮やダイジェスト値の付与といった Sprockets の挙動を理解し、それを再現する webpack の設定を考える必要がありました。 また、browserify に比べると webpack の仕組みはかなり複雑なため、開発チーム内に使い方を普及させる必要がありました。

おわりに

このようにして、主要なサービスに webpack を導入することができましたが、本当に行いたい改善はこれからです。 今後は計測の仕組み化や設定のチューニングを行っていきたいと思います。

ピクスタでは、より良い開発環境を作るのが好きなエンジニアを募集しています!


  1. 例えば uglify-js のバージョン管理や圧縮をフロントエンド側で行いたい。source maps が上手く動かない。等々

  2. 例えば CSS Module を扱うためのプラグイン。browserify にも同様のプラグインがありますが、まだ試験段階のようです。

  3. grunt や gulp のプラグインのようにバージョンアップに追従できない問題や、rollup のような新たなツールが登場する中で、webpack がいつまで生き残るかと言った不安もあります。似たような理由で grunt や gulp の使用も避けています。