やっぱ慣れるしか無いんですね
メソッド名を1文字間違えてたときとか原因わかるまで結構時間かかってしまったんですが
とりあえず頑張ってみます

>>951
そういうのはLinterの出番
「PHPMD」でググると幸せになれるかもしれない

逆にマジックメソッドは正しくlintできるんだろうか
スコープとかミューテータとか
そのままの名前のメソッドは存在しないわけだけど

APIのルーティングはどこに書けばいいですか？
あと普通のルーティングと書き方って何か違いますか？
同じところに書くと何かまずいですか？

最新版ならapi.php
ただしweb.phpのルートとはセッションが繋がらないので要注意
単にajaxの受け口など自サイト専用のapiなら
web.php側に書くほうがなにかと楽だと思う
多分ベストプラクティスからは外れるんだろうけど

>>955
ありがとうございます！

モデルのリレーションで複数キーの場合どうやんの？
いちいちジョインするの面倒っすわ

>>957
複合キーでJOINする必要があるってこと？

>>958
そうっす

366 :nobodyさん 2017/05/29(月) 16:07:39.16 ID:6v4UcGhE
今回の民法改正、ソフトウェア受託開発の場合、(検収後ではなく)バグ発見後１年瑕疵担保責任があるということで、地獄かよ、と思ったが、
元々問題が起きがちな受託案件がビジネス的に成立しなくなることで強制的に業界再編につながるなら良いことかもと思うようになった。
一部で地獄を見ても。
http://twitter.com/yukihiro_matz/status/869061879389343744

367 :nobodyさん 2017/05/29(月) 16:28:06.55 ID:6v4UcGhE
ニュース - 改正民法が成立、「瑕疵担保責任」などシステム開発契約に影響大：ITpro
http://b.hatena.ne.jp/entry/itpro.nikkeibp.co.jp/atcl/news/17/052601508/

372 :nobodyさん2017/05/29(月) 19:10:37.12 ID:???
Railsでシステム作って納品する
↓
Railsはマイナー、メジャーのアップデートが半年以内に必ずある
↓
客がアップデートする。アップデートによるエラーやバグ、動作の不具合に気づく
↓
気づいてから1年以内に通知すれば、5年間無料保証ゲット
↓
つまりRailsがアップデートするたびに、無償の修正作業を発生するということかな

376 :nobodyさん2017/05/30(火) 09:20:20.09 ID:L5po86sS
>>380>>381>>377
客が瑕疵担保責任法の法改正を知ってくると思うから、今後5年無償保証をお願いされるだろう
営業がそれでも仕事を取ってこれるか？たぶん無理だろう。無限の直していたら赤字になる。
こういう保守に弱い言語、ころころ仕様が変わる言語は仕事として発生しなくなってくる。
これは変わり目だ。お前らも早く逃げたほうがいいぞ。RubyやPHPなど動的言語は確実に廃れる。
保守に強い言語のみ生き残れる。

勝手にアップデートしたなら動作保証対象外だろw

普通リリース後はバージョン固定だよな
「バージョン○○まで面倒見る。それ以降は知らね」と契約するもんだ

瑕疵担保責任（かしたんぽせきにん）

瑕疵担保責任のポイント

民法改正で事実上期限が「無制限」になった
バグや設計のミスなどは、瑕疵担保責任
納品物に不具合があれば損害賠償を請求される可能性もある

http://www.atmarkit.co.jp/ait/articles/1706/26/news014.html
http://itpro.nikkeibp.co.jp/atcl/news/17/052601508/?rt=nocnt

改正法では欠陥に気付いてから1年以内にITベンダーに通知すれば、
通知後5年以内は修正や報酬の減額などを求められるとしている

全ベンダーが泣いた民法改正案を解説しよう その1
http://www.atmarkit.co.jp/ait/articles/1609/14/news009.html
http://www.atmarkit.co.jp/ait/articles/1609/14/news009_2.html
http://www.atmarkit.co.jp/ait/articles/1609/14/news009_3.html

ポイント1：修補や損害賠償、契約解除の期限がなくなる

従来あった「瑕疵担保期間は引き渡しから1年」という考えはなくなる。
条文にある通り、注文者は成果物が契約の目的に適合しないことを発見したら、
その「発見したときから1年以内」ならさまざまな請求ができる。発見が10年後なら、
11年後まで請求可能なのだ。

もっとも、現実のユーザーとベンダーの関係でも、たとえ契約書に「瑕疵担保責任期間は納品から1年と」明記されていても、
「2年目以降は不具合の修正に対応しない」と主張するベンダーはまれだ。多くの場合は、納品から何年たっても、
バグが見つかればユーザーのところに飛んで行き、無償で改修するだろう。

>>962

ライバル社とのコンペで負けるな。ライバル社は無償保証を提案してくるだろうから

>>965
それはバージョンアップしない前提だろ
そりゃバグが出ればメンテするわな

laravelの「イベント」ってどういう意味なんでしょうか？
調べてもよくわかりません
どなたかわかりやすく解説してくれませんでしょうか？

何かが起きたときに自動で何か処理したいとする
その「きっかけ」となる何かのことをイベントと言う
一般的にね

LaravelというかEloquentのイベントはデータ作成や更新といった「きっかけ」で
何らかの処理を自動で行わせるために使う
会員が最低一つはメルマガを購読するとしたら
会員モデルのcreatedイベントにメルマガ購読モデルの作成を仕込んでおけば
あとは会員を作成するだけでいいというわけ
というかプログラムのどこで作成しても必ずメルマガ購読データも作られるようになる

まあ処理し忘れを防ぐ機能とも言える
マメな人なら必要ないとも言えるかもしれん

>>966
>そりゃバグが出ればメンテするわな

当たり前だ！ただでやれ。金は出さないよ。法律改正されたし、
アップデートごとにバグが出たら、何十年も無限無償でよろしく！
バックれたら瑕疵担保責任法で訴えるからな！
わかったか！

>>968
なるほど
最初はイベントなんか使わなくても対象の箇所に適当なメソッドを挟めばいいんでは？と思ってたんですが
もっと深い箇所に埋め込みたい場合はイベントの方がいいんですね
ありがとうございました

うむ
深いところ、というよりはデータ自身に付随させる
という考え方のほうがいいかも
Laravelというかこの手のフレームワーク全般に言えることでもある
ミューテータとかもそんな感じでしょ
めんどくさい処理はデータモデルに任せて表では楽しようという

>>971
なるほど！
大変わかりやすい解説ありがとうございました！

Laravel使ってるんですが
正直使いづらくて何がいいのかさっぱりわかりません
ルーティングは機能ごとに毎回追加しないといけないし
nameスペースもいちいち追加するのがめんどくさいし
吐き出されるエラー内容もわかりにくいし
ドキュメントも充実してないし
こんなフレームワーク使うよりは
Codeigniterの方が使いやすくていいと思うんですがどうでしょうか？

どうぞどうぞ

>>973

数人かそれ以下のPGで制作する場合は
Symfonyやその派生の巨大フレームワークは
却ってボトルネックとなると思う。
PG兼SE1人の制作環境では修行しているような気分になるはずだ。

しかし多数のPGを使って制作する場合は
リーダーが外枠（フレームワーク内のフレームワーク）をきっちり準備すれば
スムーズに事が運ぶと思われる。

俺は大人数での制作に関わる気は毛頭ないから
CodeIgniterの高速性を取るし（最近はCodeIgniterすら使わない）
Symfony系の巨大フレームワークは壮大な無駄にしか見えない。

ドキュメントが充実していないというのは誤解のような気がする。
Symfony系のフレームワークは色々な団体・個人が開発したソースの集合体であり
どこかが一括してドキュメントに責任を負っているわけではないのだろう。
Symfony系が粗大ゴミにしか見えない者にとってはどうでも良いことだが。

Laravelの良さはコマンド一つでサクサク環境作れることじゃない？
SQLインジェクション対策とか、ログイン関係のセキュリティ対策も完備しているし、
コマンドも自分で簡単に追加できるし、普通にフレームワークとしての機能は完備してる

解説は確かに昔少なかったけど、解説本も出たんだから買えば解決
ただ、公式の解説や、本体を翻訳してくれてる有志が居るし恵まれてる方でしょ

Laravelで数少ない不満はhasOne :throughを頑なに拒み続ける事

Laravelのどこがドキュメント恵まれてないんだ？
CodeIgniterの方が負の遺産抱えすぎて悲惨だろｗ
未だにアンダースコア区切りでやってんのかよ

Apacheできないってどういう意味だろ
設定できないってことかね

その書き方からすると全部怪しいｗ

Laravel使うようになって初めてcomposer使うようになって、未だによくわかってないけど問題ない
Apacheの設定もいじるのはDocumentRootぐらいだと思う、/以外にLaravel設置しようとしたら大変かもしれないが

vagrantさえ動かせれば何も考えんで済むよね
windowsだとなにかとトラブって動かせたことがないが
まあxampp入れれば環境はすぐできる

LaravelにはHomesteadがあるから
サーバの知識何もいらんよ

生涯Laravelならそれでもいいかもだけどそうも行かないだろうし
機会を見てサーバの知識は持っておいたほうが良いとは思うけどね

もちろんそうだ
vagrantさえ動けば何も考えんでいいと書いたのは
homesteadがあるから、という話だよ
vagrantを動かした上で色々設定の必要ありというのは
ことlaravelに関する限り当てはまらないということ

どのos imageを使うかにもよるが、サーバの知識無しではしんどいよ。
サラのimageだったらphpから入れる必要あるしね。
けっこう面倒。
でもやる価値はある。

サーバの知識皆無で本番サーバの設定どうやんのよ

レンタルサーバじゃあかんの？

いいけどまったく設定しないわけにもいかんだろ

とりあえずLaravelやりたいだけならxamppでいいべ。
作ってからアップロードするときにでもサバの勉強すりゃいいし。
なんでもかんでも手を出すと、結局何もできないことになる。

symfonyのBundleみたいにひとまとまりの汎用パッケージにするのってどうやるの？

失礼ドキュメントあったわ