LaravelのEloquentモデルのプロパティアクセスをCamelにしてみる

久しぶりの投稿が技術ネタ

SlackのPHPユーザーズ(日本語)のLaravelチャンネルで変数の命名規則をどうしているかという議論がちょっとだけあった。
もう結論も出てるのでSlack上で蒸し返してもしかたないし、モデルのプロパティに関してはスネークケースで妥協すると言うことで落ち着いてるのであえてなにも言うつもりもないしそれでいいと思う。

ことの発端はEloquentモデルはDBのテーブルのカラム名でプロパティアクセス出来るように作られてる。
とはいえLaravelのFramework自体は変数はキャメルケースとなっている。
つまりDBのテーブルカラムがスネークケースの場合はプロパティアクセスはどうしてもスネークケースにならざる得ない。
DBのカラム名はPostgresだとキャメルケースで定義しても全部小文字になったりするものだから、こっちをキャメルケースに変えるということもできればしたくない。

1つの解としては、Eloquentモデルのaccessorとmutatorを使って各モデルごとにすべてのプロパティに対して定義すれば、プロパティアクセスもキャメルケースでアクセス可能だ。
これはSlack上でもこーすればできるという例で上げられていた。
しかし、プロパティアクセスをキャメルケースしたいだけで、各モデルにカラムすべてにaccessorとmutatorを定義するとか、拷問でしかない気がする。

この議論を見たときに思いついたのはこれ

Eloquentモデルを継承して、getAttribute($key)とsetAttribute($key, $value)をオーバーライドする。
$keyをスネークケースに変換して親のget/setAttributeを呼べばaccessorやmutatorを個々に定義しなくてもいいんじゃないか。
あとはすべてのモデルは作成したCamelModelを継承すればプロパティアクセスをキャメルケースで書くことができる。
これくらいの手間ならやってもいい気がする。
しかも、個別にaccessorやmutatorをLaravelのお作法通りに定義してもちゃんと動く。

まぁこれやっちゃうと、必ずスネークケースに変換されてしまうのでDBのカラムがスネークケースじゃないものが含まれてたときにプロパティが取れなくなるけど。
そんときはDBのカラムの命名規則違反だからカラム名を修正すべきだろう。

LambdaでS3にアップロードされが画像をサムネイルにしてみた。

S3に画像をアップロードしたらLambdaでサムネイルを生成する(node-imagemagick)を参考にして作ってみた。
こっちはバケット2つ用意してたんだけどバケット1個でやりたかったので試行錯誤してみた。

コードは↓

S3のバケットのoriginフォルダにアップロードされたら、imagesフォルダにリサイズした画像を保存する。

手順は「Create a Lambda function」のボタンから作成。
1つもLambdaファクションがない場合は「Get Started Now」のボタンがあるからそれを押す。
そしたら予め作られてるテンプレートがあるからそれを選択するか、空の状態からやるなら下に「Skip」がある。

スクリーンショット 2015-11-12 18.23.44
関数名を決めて、説明文はあってもなくてもいい。
関数を作成するときの言語を決める。
スクリーンショット 2015-11-12 18.26.03
関数はエディタでその場で作成するか、ファイルをアップロードするか、S3にあるファイルを使うか選べる。
とりあえず今回はエディタで作ってみた。

スクリーンショット 2015-11-12 18.26.18
Handerの設定は基本的にテンプレートを使うなら変更しないでも良い。
Roleは作ってないならcreate new roleからlambda_s3_exec_roleを選択するとIAM Management Consoleに飛ばされる。
基本このままで作成。
そしたら自動的に作成したRoleが割り当てられる。
メモリはアップロードする画像サイズにもよると思うけど、スマホの画像とかをアップロードするなら192MBぐらいはほしいかな。
実行時間も画像サイズに影響するのでサイズによって調整する。
後でメモリと実行時間の変更も可能なのでとりあえず適当に設定しても大丈夫。

Nextボタンおしたらプレビューが表示されるのでそのまま作成ボタン押せば完成。

あとは、Event sourcesタブでAdd event sourceからS3の条件を指定すればアップロードされた時にLambda関数が実行されてサムネイルが作成される。

Event sourcesは別関数作っても同じ条件だと設定できないらしく、リサイズするサイズを変えた複数のlambda関数を作ってもダメだった。
一個の関数内で複数のリサイズを実行するか、リサイズごとにフォルダ分けしたらいけるかもしれない。
まぁそのへんはまたやってみようと思う。

技術ネタ書くなんて久しぶりじゃないんだろうか

バリデーションの種類とエラー表示は対じゃない。

タイトルのとおりです。
バリデーションチェックには、いくつか種類があります。
入力が必須とか英数字のみとか。
そして1個のデータに対して複数の制約が存在することはよくある。
だけど、バリデージョンパターンごとにエラーメッセージを表示するのは違うと思う。

例えばパスワードのバリデーション。
・必須なので、入力されていなければならない。(not empty)
・パスワードは8文字以上。
と、あったとする。

そうすると多くの場合以下の2種類のエラーメッセージを表示している。
未入力(empty)だったら「パスワードを入力してください」
8文字未満の入力だったら「パスワードは8文字以上で入力してください」

でも、8文字未満が禁止されているのであれば、未入力(0文字)も8文字未満である。
つまり、エラーチェックは8文字以上あるかチェックすればよくて、空文字だったかは調べる必要がない。

包含するバリデーションチェックがある場合でも律儀に個別にチェックするのは無駄だと思う。

PHPでSQL Serverに接続してみた。

故あってSQL Server(Windows Server)にLinuxOSから接続しなきゃいけなくなったので、とりあえずいろいろ試したメモ。

試した環境は
Windows8.1 SQL Server2014
CentOS7

どちらもMac上でParallels Desktopの仮想環境で立ち上げた。

以下のサイトを参考にSQL Serverを設定。
SQL Server 2014 Expressの外部接続を許可する手順
基本的にリモート接続の許可はデフォルトでチェックが入ってた。
TCP/IPは無効になってたので有効化して、SQL Serverの設定は完了。

ODBCデータソース アドミニストレータを使って確認してもいいし、sqlcmdでIP接続できてればOK。

CentOSのほうにFreeTDSとunixODBCをインストール。
同じことやってる人がちらほらいたけど、ほとんどがソースビルドしてた。
けど、EPELのリポジトリを登録すればFreeTDSもyumでインストールできた。

EPELのリポジトリ追加はこちら
CentOS6はこっち

以下のコマンドでunixODBCとFreeTDSをインストール


#sudo yum -y install unixODBC-devel freetds-devel

インストールが完了したら、以下を参考にしてドライバとデータソースの設定
unixODBCにODBC用のFreeTDSドライバーを登録

あとはPHPのODBC関数を使えばSQL Serverに接続することができた。

問題は、ODBC対応のPHPフレームワークが思い当たらないことか

追記
探してみたらCodeIgniterがODBCサポートしてた。
使うかどうかはまだ検討中だけども

node.jsでIPアドレスを取得する(2)

もう半年以上前にNode.jsでクライアントのIPアドレスを取得するを書いた。
まぁ別にあれでもちゃんと動いてるんだけど、もうちょっとコードがコンパクトにならないかなぁっとちょっとだけ頑張ってみた。

三項演算子のネストでコードをコンパクトにしてみた。
人によっては、大嫌いな書き方なんだろうけど、ある程度可読性があるようにちゃんと改行してワンライナーにはしてない。

ブログ内にコード書いてもいいんだけど、改変したりとかするんだったらGitHubにコード載せたほうがいいかと思ってGistに書いた。