スイーツ（笑）と呼ばないで!!
|
| |||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
11/24/23:46 [PR] |
05/04/13:06 Laravel5で迷いが消える! Form Request ValidationLaravelは柔軟性のあるフレームワークだ。
しかし、それゆえに、迷いが生じることもある。 例えば、View Composer、機能はわかってもそれをいったいどこに書いたら良いの？とか、そんな迷いが生じる。 そんな迷いの中の一つがvalidationだ。 Laravel4系を使っているとvalidationの書き方や、書く場所なんかで迷ったりする。 Modelで書く、Controllerで書く、別のValidationクラスを作る、あるいはJeffreyの作成したForm Validationのバッケージを使う、どれもある意味正解でどれも絶対的な正解ではなかったりする。 そんな中で、ある一つの明確な解答を打ち出したのがLaravel5で登場するForm Request Validationだ。 これはRequestクラスを継承したものであるが、artisanコマンドで簡単にgenerateすることができる。 php artisan make:request CreateArticleRequest こんな感じだ。 そうするとCreateArticleRequestクラスが自動生成され、そこにrulesというメソッドスタブが生成される。 そこで例えば下記のようなvalidationルールを書けばvalidationは終了だ。 public function rules() { return [ ‘title’ => ‘required|between:3,100’, ‘body’ => ‘required|min:10’, 'url' => 'required|url' ]; } しかも、これを実行するためには、controllerのactionでタイプヒンティングするだけでOK。 public function store(CreateArticleRequest $request) { } という感じ。 Laravel4までは、constructor injectionしか利用できなかったが、 Laravel5では、method injectionが利用できるようになった。 これはその恩恵の一つだ。 これらの機能が使えるようになっただけでも、Laravel5に移行する十分な理由となると思う。 Laravel5へ移行する学習コストに比べて、移行することで将来的に節約できる実装コストの割合は大きい。
PR
|
04/30/10:08 @forelseを使おう!!Laravelで書かれたソースコードを読んでいると
@if (count($rows) !== 0) @foreach ($rows as $row) {{{$row}}} @endforeach @else データがありません @endif こんなソースコードを見かけます。 これは一覧出力などでよく見かける 1. データがあれば、ループしながらそのデータを出力し、 2.データがなければ、「データがありません」と出力する、 という処理です。 Laravelのテンプレートエンジンであるbladeは、 確かにPHPの構文をそのまま「@」をつけることで使えるという特徴があり、 上記のソースコードに行き着くのは当然かもしれません。 しかしながら、ここはせっかくLaravelを使っているのですから、 以下のように書きたいところです。 @forelse($rows as $row) {{{$row}}} @empty データがありません @endforelse これで同じ意味になります。 だいぶスッキリしますね。 調べてみると、最近の弊社のLaravel案件(JやM等)でもforelseは使われていないので、 意外とマイナーな機能かもしれません。 時間がないと知っている書き方で済ませてしまうことも多いと思いますが、 フレームワークで便利なものが用意されていることもあるので、 たまには時間をとって「何か自分が知らない便利機能ないかな」と調べてみるのも良いかもしれませんね。
|
03/27/12:15 システム大量消費の時代Windowsも9を飛ばして10になるように、 PHPも6を飛ばして今年の10月には7になります。 Laravelも既に5が出ています。 Macも半年に1回のペースでOSがアップデートされます。 IEも消えて別のブラウザになります。 もはや、新しいものを拒絶して生き残れる時代は過去のものとなりました。 硬派な私たちは、いままで、枯れた技術を使うことにある種の職人としてのプライドを持ってやってきました。ミーハーな感じで流行りには流されない、ということで。 しかしながら、今後は枯れる前に、フレッシュでないというだけで廃棄処分されるようになっていくと思います。 そうすると、システムのリニューアルのスピードも早まるでしょう。 構築したシステムをずっと使い続けるのは今以上に減り、 2年くらいでリニューアルあるいは乗り換えするのが普通になるかもしれません。 パソコン業界でそれが起きた時、低価格化の波が押し寄せました。 マウスコンピュータの「パソコンは3年経てばただのハコ。(だから安いので良いでしょ)」というようなキャッチフレーズは衝撃でした。 早くて安いファーストフード的なシステム大量消費の時代は既に始まっています。 そんな中で、自分たちがどのような立ち位置でビジネスをするのか、考えなければならない。 どんな高級な本格フレンチレストランでも、注文から5時間後に料理を出すお店はないでしょう。 でも、4時間半を仕込みに使って準備万端であれば、30分でホンモノの料理をお届けできるかもしれない。 スポーツでもそうですが、試合中の頑張りで覆せる勝負は本当に実力が均衡している場合だけ。 試合までにどれだけ頑張ったかで実は試合前にほとんど勝負は決しています。 継続して勝利をおさめるために何が必要なのかやることが見えているなら、やるしかない、です。
|
02/25/12:41 RFCを読もう!!普段やっている業務がプロジェクトマネジメントなので、
ブログの話題もどうしてもそれに偏ってしまう。 技術ネタを書きたいなと思っても、 このブログのほんわかフォーマットだとなんだか適さない。 そんな中、今日はちょっとだけ技術よりの話題を。 インターネットを当たり前に利用する現代においては、 いろんな情報が世の中には溢れている。 親切な人が、難しい技術情報を優しく解説してくれるサイトなんかも多い。 そう言った情報を利用していくのも効率的な学習にはとても良いと思う。 でも、慣れてきたら、やっぱり一次情報に触れないとね、と思う。 RFCは、Request for Commentsの略で、IETF（Internet Engineering Task Force）という組織がまとめて公開しているもの。 普段私たちが見聞きするプロトコルや技術仕様なんかはたいがい発見することができる。 http://www.rfc-editor.org/search/rfc_search_detail.php ここのフォームに番号やキーワードを入れるとRFCが検索できます。 試しに「HTTP」と入れると こんな感じになります。 かの有名なT. Berners-Leeさんの名前とか出てきますね。 暇な時にいろいろと検索して読んでみると楽しいですよ。 ではでは、今日はこんなところで。
|
01/29/01:23 一口にSEとは言うけれど・・私の仕事はプロジェクト・マネジメント。 でも、自己紹介の時に、プロジェクト・マネージャーと名乗ることはほぼない。 なぜならば、自己紹介の時に、その相手と関係するプロジエクトが始まっていることはまずないから。 だから、自己紹介の時は、「システムエンジニア」、いわゆるSEと名乗ることがほとんどだ。 ただ、このSEという言葉、和製英語とは言わないまでも、非常に幅広い意味を持つ言葉だ。 会社によってかなり意味合いが違うといえる。 そして、仮に与えられている役割が同じようなものだとしても、 その仕事の進め方やポリシーは千差万別である。 私にはSEになって以来、ずっと思っている理想のSE像というのがある。 それは、一言でいうと ウエディングプランナーのようなSE だ。 たいていの人は一生に一回しか結婚はしない。 その一生に一回の晴れ舞台を演出するのがウエディングプランナーだ。 新郎新婦の希望や予算などを聞き、 数ある選択肢や組み合わせの中から最高のプランを提案する。 私たちが今仕事として多く手がけている業務システムの開発も、 実はその会社にとっては一世一代のイベントであることがほとんどだ。 業務システムなんて、一度作ったらそうそう作りなおすものではない。 そんな大事な機会に、自分たちの会社を選び発注してくれたわけだ。 その気持に応えられるSEになりたい。 ユーザーに喜ばれて、ユーザーを幸せにするシステムを作りたい。 そんなことを考えて日々仕事に向き合ってはいるけれど、 なかなか、思ったようにうまくはできないなーと思う今日この頃。 もっと、もっと、頑張っていきたい。
|