旧アプリケーションをメンテナンスしなくなったわけ
サイトの更新情報を取得する場合、サイトごとに適切な処理を書く必要があるためどんなサイトでも自由に素早くというわけにはいかず、ひとつひとつ処理を書くという泥臭い開発が必要になります。かつてのコードはスクレイピングにしても、データベース登録にしても、RSS出力にしても多少ライブラリを使用していたものの自分で書いた処理が多く、またPHPフレームワーク（Symfony1.0系）を使用していたにもかかわらず全くといって良いほど活用出来ていなかったので、機能はシンプルなのに構成は複雑という最悪な状況でした。少し直すのにも手間が大きくて大変で……そんな成り行きもあって結局、メンテナンスを行わないまま放置ということになってしまいました。手元に旧アプリケーションのコードがまだありますが、大した量でもないのに無駄にLogicだServiceだDtoだDaoだと細分化されていて（しかもSymfonyの機能を使ってるわけでもなくオレオレフレームワークに近い）、その上特に再利用するわけでもなく、構成覚えてなかったら直すのは難しい。誰だこんなコード書いたヤツは。。
新アプリケーションで何を変えたか
今回の目標は極力自分で処理を書かない。スクレイピングはまあ仕方ないとしても、それ以外の部分は極力ライブラリに任せる。そもそも「DIY RSS」に限らず新サーバで開発しているアプリケーションは全て、フレームワークに採用した「Laravel」に極力頼り切って開発することに決めています。基本的に自分の知識や技術は信用していないので、何かをするときにはまずドキュメントを読んでから。結果、Laravelの基本機能と素晴らしいライブラリの数々のおかげで、自分で書くコードは極力少なく、シンプルな機能はそのままシンプルに、複雑な機能も極力シンプルに実装出来るようになりました。
また処理によってはいくつかの段階を踏むような処理もあるのですが（スクレイピングし、DBに登録し、RSSを出力し、ブログを更新する）、機能毎に分割した上で疎結合にして、テストしやすくしました。DBの構造も似たような感じで、極力リレーションは行わず、複雑なクエリを使わなければいけないような処理や、色んな用途に使うカラムをたくさん設定するテーブルを作る必要が出てきたときには、処理自体を見直すことにしました。業務で使うような複雑なシステムならともかく、僕が作っているのは個人の趣味程度の小さくて素朴なアプリケーションばかりなので、工夫すれば全てシンプルに出来るはずなんですよね。
採用したライブラリなど
「DIY RSS」のスクレイピングについて言うと、使っているのはGoutte（Guzzle、BrowserKit、CssSelector、DomCrawlerに依存）とCarbon、Laravelのモデル機能とORM（Eloquent ORM）だけです。サイトごとに必要な処理は20行から30行ぐらい。将来対象サイトが増えてコードが長くなったら分割を考えるべきですが、今のところは app/Console/Commands ディレクトリ内の1ファイルに収まっています。PHP_DOCなどを含めてもコードは200行ちょっと。これならすぐに手を入れられます。
