Symfony Advent Calendar 2018 7日目の記事（遅刻）です。 昨日も私の記事でした 巨大なプロジェクトの構成要素を小さなコンポーネントに分けて開発するようになると、バリデーションをSymfonyプロジェクト外で書くことも増えます。 こういうときSymfonyがコンポーネントごとに分かれていて、独立して使用することもできるのが生きてきます。 昔のsymfony1時代との大きな違いですね！ 実際にSymfony Validatorでバリデーションしてみる 下記のような Term クラスがあるとします。 <?php namespace Quartetcom\DecBlogDemo\Entity; class Term { /** * @var \DateTime */ private $from; /** * @var \DateTime */ private $to;

はじめに BEAR.SundayではAOPアライアンスのメソッドインターセプターAPIに準拠した強力なRay.AopというAOPフレームワークが利用可能です。 5年くらいBEAR.Sundayを使ってきた筆者が開発したInterceptorを駄作から良作？までご紹介します。 インフラ系 Basic認証 Basic認証をレスポンスします。Basic認証自体アレですが、アノテーションを一つ付ければ認証が出る手軽さは割と気に入っています。プロダクションで使う場合SSL必須です。用法用量を守って正しくご利用ください。 <?php namespace MyVendor\MyApp\Interceptor; use Ray\Aop\MethodInterceptor; use Ray\Aop\MethodInvocation; use Ray\Di\Di\Named; class BasicAuth

ってことで、例外のお話です。 どうも僕の知っている限りでは、チェック例外という言語機能をもっているのはJavaだけみたいです。 僕個人としては、すばらしい機能なんですが。 Javaで最初にチェック例外を学んだ時、「そうそう、これこれ、これが欲しかったのよ！」 って思ったあの頃の想いは今も色あせていません。 「ずっと好きだったんだぜ～♪」って斉藤和義の曲を口ずさむくらいに、今もチェック例外を愛しています。 しかし、このチェック例外、他の言語からdisられまくって、最近の言語には取り込まれないという悲しいお話になっています。 過去に様々な議論があった中で、結論としてチェック例外は役に立たないってことになったらしいです。 経緯は知らんがね、そんなん。僕には役立ってるんだから。 ってことで、僕の立場から見た、チェック例外についての考察と扱いを書きます。 反論したい方、自重をお願いします。 だって、