Railsにおける app/ とは app/はRailsのアプリケーション用ディレクトリで、普通のRailsアプリケーションでは、この下にmodels,controllers,viewsを含めた様々なディレクトリが作られます。 基本的には新しいディレクトリを追加する必要はないのですが、アプリケーションが複雑になると、Railsを拡張するべくここにアプリケーション固有のディレクトリを作って、その下に関連するファイルを置くことがあります。 中には、servicesやserializersのように、多くのRailsアプリケーションで見られるものもあれば、完全にアプリケーション独自のものが作られることもあります。また、アプリケーションによっては独自のディレクトリは一切作らないものもあれば、大量に作るものもあります。それぞれアプリケーションの開発方針によるものです。 本記事では、比較的有名なOSSの

「開発抽象化レイヤー」とは 「開発抽象化レイヤー」(Development Abstraction Layer)はご存知でしょうか。 これはJoel Spolskyが言い出した言葉で、彼の2006年のエッセイのタイトルにもなっています。このエッセイは大変おもしろいので必読です。ご存じなかった方はいますぐ読むことをおすすめします。 日本語訳もInternet Archiveから読めます。 ちなみに組込み方面では「HAL」という用語があります。これは「Hardware Abstraction Layer」の略です。HALはハードウェアの違いを吸収することで、プログラマにはハードウェアを意識させないよう「抽象化」するためのものです（が、実際には「抽象化の漏れ」が生じやすくて微妙な話が展開されるようなのですが、それはまた別の話になります）。 この「開発抽象化レイヤー」も、実際にはプログラマーが活動

『Sustainable Web Development with Ruby on Rails』はRails使ってるなら絶対面白いと思う David Bryant Copelandの『Sustainable Web Development with Ruby on Rails』を読んでいますが、この本めちゃめちゃ面白いですね。 Railsの設計で悩んだことのある人なら絶対読んで損はないというか、共感したり反発したりにやにやしたりで楽しめると思います。RailsというかWebアプリ開発の歴戦の勇士（正直あまり若くなく、つらい経験を重ねてきた生き残り的な人）が語るベストプラクティス感があります。 本書の構成 大きく3部構成です。 Introduction その名の通り導入です。本書の目的、Railsのアーキテクチャの紹介と、ビジネスロジックの話など。 「Sustainable」とは何か？　とい

（特にRubyに限った概念ではないですが、他の言語だと微妙に状況が違うかもしれないので、ここではRubyの例に限定しています。） 機能は追加・改修する際、すでにあるクラスだけでなんとかしようとすると、特定のクラスにあらゆる機能を持たせてしまったりしかねません。そうすると「神クラス」が誕生してしまいます。 典型的な症状 特定のクラスに、メソッドやインスタンス変数がやたらたくさんある状態になったりします ソースコードも当然のように長かったりします 機能追加・機能修正するのが困難なクラスがあったりします どんな機能の修正でもなぜか特定のクラスを修正しないといけなかったりします 生じる問題 壊れやすくなり、修正コストが激増します かんたんな修正であっても、（なぜか）他の機能が壊れたりします。 テストがあれば壊れたことに気づけるかもしれませんが、気づいたところで直すには手間がかかります。テストがなけ

ソフトウェアの内部では、データを様々な形に加工しつつ、あちこちに受け渡して再利用します。そのためのデータ構造として、RubyではHashクラスのオブジェクト（他の言語ではMapだったりDictionaryだったり連想配列だったりします）を使うことはよくあります。 単体の数値や文字列ではなく、それらを組み合わせたデータを扱う際には、Hashオブジェクトが便利です。 しかし、あらゆる場面でHashを駆使しようとすると、利便性よりも弊害が大きくなります。 典型的な症状 あちこちで同じだったりちょっと違ったりするHashオブジェクトを引き回していたりします インスタンス変数が少なく（あるいはまったくなく）、その代わりとしてメソッド引数のHashオブジェクトにいろんなデータを渡していたりします 1つのHashオブジェクトのキーとして、文字列やシンボル、さらにはそれ以外のクラスのオブジェクトが使われて

Tailwind CSS for Railsを使って、NodeをインストールせずにTailwind CSS 3を導入する みなさんこんにちは。この記事はRuby on Rails Advent Calendar 2021の20日目の記事です。 20日は誰も埋めていなかったようなので（と言いつつもう日付も変わってしまっているのですが）、Tailwind CSS for Railsというgemについて書きます。 Tailwind CSSとRails Tailwind CSSは最近流行のCSSフレームワークで、Utility-Firstと呼ばれている思想に基づいています。これはある意味、従来のCSS設計のベストプラクティスの真逆を行くようなもので、class="flex items-baseline mt-4 mb-6 pb-6 border-b border-gray-200"みたいなスタイル

きしださんが先日もたのしいお題を投下されていました。 出遅れましたがこのネタについて少し掘り下げてみます。 念のため個人的なスタンスをあらかじめ表明しておくと、オブジェクト指向に対してはそれなりに好意的ですが、別に時代の最先端だとかソフトウェア開発に必須の知識というほどではない（でも知っておくと便利というか、知らないと不便なこともあるかもしれないのでわざわざ避けるのはおすすめしない）というくらい温度感です。 オブジェクト指向 is 何 そもそも「オブジェクト指向」という言葉自体、座りの悪い言葉です。 意味が明確なのは「オブジェクト指向プログラミング(OOP)」、「オブジェクト指向プログラミング言語(OOPL)」、「オブジェクト指向設計(OOD)」「オブジェクト指向分析(OOA)」といった「オブジェクト指向なんとか」の方で、それらをふわっとまとめた（ような気がする）単語が「オブジェクト指向」

なんとなくパターン・ランゲージ（パターンカタログ）のスタイルが懐かしくなったので、あのスタイルを思い出しながら書いてみます。 目的 特定のアプリと完全に同期していますが、機能的には独立したライブラリをアプリ内のgemとして提供するものです。 動機 アプリで使いたい機能として、ある程度の独立した機能を実装したい 単独のクラスやモジュールとして実装できるものではなく、複数のクラス等が関連して動く程度の粒度を想定する（ので、個別のファイル単位よりはもう少し大きい粒度になる） 独立した機能とアプリが渾然一体となり、気がつくと境界を侵食したり侵食されたりしてしまうことは避けたい 適用可能性 いくつかのclassやmoduleがアプリケーションに依存せず、独立した機能になっている場合 特定のRailsアプリからしか使われる予定がない（共有する必要・予定がない）場合 一定期間しか利用せず、どこかのタイミ

なんかおすすめなテスト本ないですかねえ？ と、某所で（テストをメインの業務にするのではなく）普通に開発をされている方に聞かれたので、 プログラミングは普通にできる テストについては学んだことはない とはいえテストエンジニアになるわけではなく、開発者としてテストが知りたい という人向けに、2021年現在で普通に入手できる本をいくつか挙げてみます。