忍者ブログ

スイーツ(笑)と呼ばないで!!

NEW ENTRY
10 2024/11 1 23 4 5 6 7 8 910 11 12 13 14 15 1617 18 19 20 21 22 2324 25 26 27 28 29 30 12
<<< PREV     NEXT >>>

11/24/19:43  [PR]

×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

07/22/18:37  HTML5の本当のすごいところは!?

さぁ、このあと不定期で続くかもしれない、HTML5特集のPart1です。

皆さん、HTML5使っていますかー。

「ああ、DOCTYPEとかそれっぽく宣言してる」
「input要素でplaceholder使ってるぜぃ」
「input type=“date"とかするとカレンダー出たり新しいtypeが増えたよね」

とか、そんな返事が返ってくるかもしれませんね。

確かに、それらはHTML5の特徴的なところで、いろいろと語られているところでもあります。

ただ、私達ブログラマにとって地味にすごい拡張されているの、知ってます?

今日はそんな中から2つ程紹介しますね^^

これ知っているかしらないかで、JavaScript書く量がかなり変わります。

例えば、こんなシーンを思い浮かべてください。

◎例題1

なんかのデータの編集画面です。

ずらーってinput要素やらselect要素やらが並んでいます。

一番下に、「上書き保存」「名前をつけて保存」などのボタンが並んでいます。

【超初心者の回答】

「あ、あれ、ボタンが2つ・・formのactionは1つしか指定できないし・・どっちのボタンか区別できないし・・うーん」

とか言いながら、formの中にformをもう一つ作ったりして実装できず・・・経験者に助けを求める。

【経験者(=普通のプログラマ)の回答】

「こういうのはな、jQueryとか使ってやるんだよ。submitされたタイミングでイベントとって、どっちのボタンが押されたかはidを取得して、それでactionの先を動的に変更してだな、そうするとpost先(=action)を変更できるんだよ。やっぱ、時代はjavascriptだぜー」

とか言いながら、やりよる感を出します。

【HTML5の達人の回答】

「えっとー、次の例見てみてください」

<form id="form_id" action="/test" method="“POST"">
 <input type="text" name="test_id" value="123" >
 <input type="submit" value="test1" >
 <input type="submit" formaction="/test2" value="test2" >
 <input type="submit" formaction="/test3" value="test3" >
 <input type="submit" formaction="/test4" formmethod="“GET"" value="test4">
</form>

「HTML5だとー、formaction属性が追加されているんですよねー。なので、submitボタンのformaction属性に/overwriteとか/copyとかつければsubmitのタイミングでaction勝手に変わりますー。javascriptとかいらないですー。」

「ちなみに、formmethod属性でgetとかpostとかも変えられるんでー。Laravelとかmethod毎にroute書ける系は超便利ー」

とか言いますね、きっと。

これ、かなり便利です。他に「削除ボタン」だろうが「プレビュー」ボタンだろうが、つけ放題ですね。

(ちなみに、プレビューを別タブで開きたいならformtarget属性でtargetも書き換えられます)


◎例題2

ページの上部に基本的にform系の要素はまとまっているんだけど、
ページの中間に長い説明文とか一覧とかがあって、
ページの最下部にボタンが並んでいる仕様のページが作りたいんだけど・・

【超初心者の回答】

「うーん・・・formの中にsubmitボタンとか他のinput要素とかたくさん入れなきゃならないから・・ページの上部から下部まで、長ーいですけど全部formタグで囲っちゃえば良いですね。え・・・・途中に一覧の検索ボックスがある・・・formは入れ子にできないし・・・」

とか言いながら、実装できず。

【経験者(=普通のプログラマ)の回答】

「こういう時も、JavaScript最高だぜ。とりあえず、まとまっている部分はformタグで囲って、あとは離れたところのボタンのクリックイベントとって、JavaScriptでpostしてあげれば良いのさ。やっぱ、時代はjavascriptだぜー」

とか言いながら、やりよる感を出します。

【HTML5の達人の回答】

「えっとー、次の例見てみてください」

<form id="form_id" action="/test" method="“POST”">
 <input type="text" name="test_id" value="123">
 <input type="submit" value="test1">
</form>

(なが~い文章とか)

<input form="form_id" type="text" name="external_value" value=""456”" >


「HTML5だとー、form属性が追加されているんですよねー。そこにどんなに離れたformでもそのformのidを指定してあげれば、そのformの中にあるのと同じように扱ってくれるんですー。javascriptとかいらないですー。」

とか言いますね、きっと。

これ、かなり便利です。離れていようがないだろうか、お構いなしですね。デザインと構造は分離されています。


ということで、HTML5にきちんと対応しているブラウザ相手だとだいぶ工数が削減できることがわかりますね。

ここで、お客さんがプロジェクト後半になって「あー、やっぱりIE8も使いたいなー」とか言ってきたらどうでしょう。

そのためだけにたくさんの面倒なコードを書かないといけないですね。

「テストのブラウザが1つ増えて面倒だなー」とかってレベルではありません。

私もプロジェクトマネージャーを生業としていますが、やはりこのようなところはプロジェクトの最初できちんとお客さんと握っておくことが大事だな、と改めて思います。

ということで、HTML5を採用しているのにHTML5っぽく書いていないあなた、ちゃんと勉強してみると超楽になるかもしれないですよー^^

拍手[0回]

PR

07/22/14:22  PHPの実行環境を一番簡単に作る方法!?

Laravel4.2以降とかだと、必然的にPHPは5.4以降を使うことになる。

(ちなみに、Laravel5.1使うなら、PHPは5.6が必須)

PHP5.4・・・このバージョンで思い当たるのは、そうBuilt-inサーバーが使えるね、ということ。

会社によっていろんなスタイルで開発していると思う。

クラウド上や社内に共用の開発サーバー立てたり、
個人のPCの仮想環境上に仮想の開発サーバー立てたり。

そんな選択肢の中で、一番お手軽なのはPHP5.4以降で準備されているBuilt-inサーバー。

私はmacユーザーなので、以下macでの例だけど、例えばこんな感じでPHPで書いたプログラムが動かせる。


1.phpのインストール

まず、phpのインストール、これはmacユーザーならお馴染みのbrewコマンドで一発。

 #brew install php56

とかやれば良いね。

2.ソースのドキュメントルートになるディレクトリに移動して適当なポート指定して起動
 
 #php -S localhost:1234

以上、超簡単。これでブラウザでhttp://localhost:1234と打てばもうそのPHPアプリが動かせる。

1234の部分は、8888でも1111でもOK。このポート変えるだけでいくらでもいろんなソースを瞬時に何個でも起動できる。

linuxサーバーで必ず通るVirtualhostの設定とかhosts等DNS系の設定も不要。

ちなみに、余談だけど、brew search phpと打つと、php53とかphp54とかphp55とか出てくるね。好きなバージョンPHPを入れてください。

え? windowsの場合どうしたら良いかって・・・windows使いの先輩を捕まえて聞いてみてください^^

拍手[0回]

07/17/12:45  LaravelのSeederをどう使う?

たまに社内SNSでSeederについて話題にあがる。

Seederは、一般的には、テーブル定義が変わった時なんかに、
一度テーブルの中身をリフレッシュして再度テストデータを埋め込む、
こんな利用シーンが多いだろうか。

今日見かけたのは

 php artisan db:seed --class=DevelopmentSeeder

という1行。

—classとオプションを指定することで特定のSeederクラスを実行できる。

命名から開発環境のテストデータを作り直したいのだなと思う。

中を見てみると、複数のテーブルにinsertする記述がこの1つのファイルに書かれている。

みんないろんな使い方をしているようだ。
もちろん、使い方に正解があるわけではない。

今日は、自分だったらどうするかなー、というのを考えてみたいと思う。

前述の例の--classのオプションを指定しないでdb:seedを実行するとどうなるか。

デフォルトではLaravelが最初に用意しているDatabaseSeederというSeederが実行される仕様となっている。

Seederは別のSeederを呼び出すことができる。

runメソッドの中で

 $this->call(’Seederのクラス名’);

という感じだ。

おそらくLaravelのSeederの設計思想としては、
DatabaseSeederのrunメソッドの中に複数のSeederをcallするような想定でいるのではないかと思える。

Laravelの公式ドキュメントのサンプルでも

public function run()
{
 Model::unguard();

 $this->call(UserTableSeeder::class);
 $this->call(PostsTableSeeder::class);
 $this->call(CommentsTableSeeder::class);
}
なんて記述がある。

ここからもう一つわかることは、Seederはやっぱり基本はテーブル単位で作る想定よね、ということ。

さて、ここで少し話がズレるが、テーブル定義をリフレッシュする際に同時にSeederを実行したい時どのようなコマンドを打っているだろうか。

Laravelでは、実はmigrationと同時にSeederを実行する機能がある。

 php artisan migrate:refresh --seed

このように--seedオプションをつければ一発で実行できる。
この際呼ばれるSeederはデフォルトのDatabaseSeederだ。

こんなことからも、Laravelとしては、DatabaseSeederを親としてrunの中で子Seederを呼んで欲しいんじゃないかな、と思ったりする。

え、developmentとかproductionとか環境ごとにSeederが変わる場合はどうしたら良いかって?

私が考える正解は、

DatabaseSeederの中で環境毎のSeeder(例えば、LocalSeeder、ProductionSeeder等の「環境名」+Seeder)をcallし、その環境毎のSeederの中で、その環境必要に応じて各テーブルのSeederをcallしてあげればよい、

というもの。(本番では呼びたくないとかあるもんね)

もちろん、if文で分けるなんてかっこ悪いことはせずに、環境の名称からクラスを特定するか、
より柔軟にするならLaravelのconfigは環境ごとに設定を記述できる仕組みになっているので、そこでその環境の親Seederのクラス名を書けば設定が上書きできるようにすると良いと思う。

ちなみに、artisanコマンドで環境を指定するには--envオプションを使えば良いね。

例えば
 php artisan migrate --env=local
こんな感じで環境を指定できる。

ということで、いろいろ書いてきたけど、これはあくまで私ならこうするかも、というもの。

皆、それぞれ使いたいように使えば良いさー (沖縄風)

拍手[0回]

06/03/00:21  Route::controllerって本当に便利?

laravelにはいろんなroutingの書き方がありますね。

その中の一つにImpicit Controller(暗黙的なコントローラー)というものがあります。

どの辺が「暗黙的」か例を挙げましょう。


Route::controller(‘articles’,’ArticlesController’);

とroutes.phpに書きます。

そして、ArticlesControllerの中に、

public function getAbc(){

}

というアクションを定義するとします。

そうすると、このアクションは自動的に/articles/abcに対するgetリクエストにマッピングされます。
postAbc()と書けば、postリクエストにマッピングされたりしますね。

つまり、

httpメソッド名(get,post等) + アクション名

という形で自動でマッピングされるわけですね。

これが1つ目の暗黙のルールです。

なるほど、これは便利ですね。


ただ、この暗黙的なコントローラー、実は一部の人たちにはとても不人気です。

なぜでしょうか?

その理由の一つをご説明しましょう。

まず、ターミナルで
php artisan route
と打ってみましょう。

そのアプリケーションで定義されているroutingの一覧が表示されますね。
そこで先ほどの暗黙的なコントローラーについて見てみましょう。

GET|HEAD articles/abc/{one?}/{two?}/{three?}/{four?}/{five?}
というURIが
ArticlesController@getAbc
というアクションにマッピングされていますね。

さてURIの最後についている
/{one?}/{two?}/{three?}/{four?}/{five?}
これなんでしょうか?

URIからスラッシュ区切りで5つのパラメータの値を取得できる、という意味ですね。
暗黙的なコントローラーは自動で5つのパラメータの値を取得するroutingを作成するのです。

これが2つ目の暗黙のルールです。

これが嫌で暗黙的なコントローラーを使わない人は結構いますね。

例えば、下記のケースを考えてみましょう。

/articles/list?sort=1&page=3&category_id=3
こんなURIの一覧画面を想像してみましょう。
Webアプリではよく見るURIですね。

さて、本来、暗黙的なコントローラーを使用するなら、上のケースは
/articles/list/1/3/3/
という形式で表現するのが正しいかもしれませんね。
5つまではパラメータをURIから取得するのを予定したルーティングなのですから。

でも、別にInputのFacadeを使ってパラメータを取得してコントロールする分には、
最初に書いたURI前提でも一応動いたりしますね。

でも、前々回のブログ(クエリストリングの回)で書いたような
Redirect::action(‘ArticlesController@list’,パラメータの配列)
という形で楽々laravelの機能を使おうとすると、どうなるでしょうか?

暗黙のコントローラーは、5つのパラメータをスラッシュ区切りで受け取ることを予定しているので、
実はこれ、受け取った連想配列のうち最初の5つのパラメータだけはスラッシュ区切りのURIに展開されてしまうのです。

つまり、
/articles/list/value1/value2/value3/value4/value5?param6=value6&param7=value7…
という形で、最初の5つのパラメータだけはスラッシュ区切りのURIに展開され、
6つのパラメータから、いつものparam6=value6&param7=value7…という感じのクエリストリングに展開されるんですね。

先の例の後者のパターン
/articles/list/1/3/3/
という形で動くように書いてあれば何の問題もありませんが、そうでなければ、そこでアプリはクラッシュですね。


ということで、皆さん、暗黙のコントローラーを使用する際には、暗黙のルールをきちんと理解して使いましょう。

そして、暗黙のルールが嫌なら、暗黙的なコントローラーは使わない、というのは多くの人が選んできた一つの正解だと私は思います。

人それぞれですけどね^^

綺麗なバラにはトゲがある
一見便利な機能には罠がある

拍手[1回]

05/27/16:21  compactを使おう!!

最近、ある部下と一緒にソースを読んでいて、
そうかcompactってあまり知られていないのか・・と知ったので今日はcompactのご紹介。
PHPでコード書いていると連想配列というのをたくさん扱いますね。
[‘key1’=>’value1’,’key2’=>’value2’]
みたいな。

laravelでもいろんなところでこの連想配列登場します。

例えば、viewにデータを渡しでviewの中で参照したいときどうしていますか?

人によっては、

return View::make(‘articles.detail’)
 ->with(‘data1’,$data1)
 ->with(‘data2’,$data2’)
 ->with(‘data3’,$data3)
 ->with(‘data4’,$data4’);

という感じでwithで渡している人もいますね。

laravelでは

return View::make(‘articles.detail’)
 ->withData1($data1)
 ->withData2($data2)
 ->withData3($data3)
 ->withData4($data4);

こんな渡し方もできますね。ちょっとマジカルな感じですね^^

でも、View:makeの第二引数で連想配列受け取れることを知っている人は、

return View::make(‘articles.deatil’,[
 ‘data1’=>$data1,
 ’data2’=>’$data2,
 ’data3’=>’$data3,
 ’data4’=>’$data4]);

こんな感じで書くかもしれないですね。少し良くなった気がしますね。

それをさらに簡単にやるのがcompact。

key名と同じ変数名をセットした連想配列を作成します。

return View::make(‘articles.deatil’,compact(‘data1’,’data2’,‘data3’,’data4’));

laravel5だとさらにviewというヘルパー関数があるので

return view(‘articles.deatil’,compact(‘data1’,’data2’,‘data3’,’data4’));

うん。無駄がないですね。

compact自体はもしかする知識として知っている人はいるかもしれないですね。

でも使ったことがない、使い道を知らない、という人が多いのかもしれません。

このcompact、laravelのフレームワーク内のソースでも多用していますね。

例えば、クエリビルダーのwhereメソッドのソースコードの中でも、

$this->wheres[] = compact('type', 'column', 'operator', 'value', 'boolean’);

こんな感じで使っています。

是非、compactを適材適所で使って無駄なコードを減らしましょう。

拍手[0回]

<<< PREV     NEXT >>>