結局PHPのフレームワークってどれがいいの?
■ このスレッドは過去ログ倉庫に格納されています
最近Cakephpの勉強始めたんだが
コードがダサくて嫌なんだけど
ていうかarrayうざい
そもそもcakephpって名前がダサくて嫌だ
どれ次に勉強すればいいかな?
laravel symfony2 zendFramework CodeIgniter Yii 一箇所直せば早くなるとかそういうのではなく、全体的に遅い もちろんSQLのスロークエリがあればそちらのほうが遅い。
だがそれらを直しきったあとどうようもなく遅い redisによりクエリキャッシュもやれるだけやった。今一番時間食ってるのはModel::__get()だ モデル層だけはSQL直で書いた方が速いってことよくあるな
外部連結とかあると特に マジかよ コアの部分でか
Cakeより遅いってこともあり得るのか、、 >>740
PHPの閉じカッコは不要
変数は数字のみは使えません 大規模システムとかでもなければ問題ない範囲だけどな
laravelで一番気に入らないのはミドルウェア Railsでもさんざん実行速度よりも開発速度!って言ってるからな
速度が欲しい段になればGoとかに変えればよろし phalconはphalconで生PHPに慣れてるといいFW nativeで速いってのを除いても好みだわ
なんでもかんでも揃ってます!ってやつ苦手
コード多すぎて改修する気なくす 好き嫌いを語れるのは趣味でやってる奴だけだな
仕事でやるなら、新人にも理解しやすくドキュメントが多いフレームワークを選ぶべき そこでcakeあたりを持ち出してロジック側でタグ生成しまくりんぐで改修で死ぬやつですね >>767
ロジック側にタグ生成しまくりって それ同じことReactに言えんの? reactはviewじゃん
ロジックはmiddlewareに書けよ Phalconを選べるような職場、まずPHPを選ぶ理由が少ないんじゃないか 誰かがアーリーアダプタになるしか。
正直codeigniterとかマジックメソッド使いまくりで、動的言語は嫌い。
ideで補完聞かないし。
この辺を解消してくんないかな。 366 :nobodyさん 2017/05/29(月) 16:07:39.16 ID:6v4UcGhE
今回の民法改正、ソフトウェア受託開発の場合、(検収後ではなく)バグ発見後1年瑕疵担保責任があるということで、地獄かよ、と思ったが、
元々問題が起きがちな受託案件がビジネス的に成立しなくなることで強制的に業界再編につながるなら良いことかもと思うようになった。
一部で地獄を見ても。
https://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
>>378>>379>>375
客が瑕疵担保責任法の法改正を知ってくると思うから、今後5年無償保証をお願いされるだろう
営業がそれでも仕事を取ってこれるか?たぶん無理だろう。無限の直していたら赤字になる。
こういう保守に弱い言語、ころころ仕様が変わる言語は仕事として発生しなくなってくる。
これは変わり目だ。お前らも早く逃げたほうがいいぞ。RubyやPHPなど動的言語は確実に廃れる。
保守に強い言語のみ生き残れる。 ポイント1:修補や損害賠償、契約解除の期限がなくなる
従来あった「瑕疵担保期間は引き渡しから1年」という考えはなくなる。
条文にある通り、注文者は成果物が契約の目的に適合しないことを発見したら、
その「発見したときから1年以内」ならさまざまな請求ができる。発見が10年後なら、
11年後まで請求可能なのだ。
もっとも、現実のユーザーとベンダーの関係でも、たとえ契約書に「瑕疵担保責任期間は納品から1年と」明記されていても、
「2年目以降は不具合の修正に対応しない」と主張するベンダーはまれだ。多くの場合は、納品から何年たっても、
バグが見つかればユーザーのところに飛んで行き、無償で改修するだろう。 「2年目以降は有償対応」は普通だろう。有償でも知らん顔という方が稀有。
「10年経っても無償で対応しなければならない」となると、そのリスク分を費用に盛り込まざるを得ず、発注・受託のどちらの利益にもならない。
だよな? >>776
コンペで保守の強い言語を提案したところが案件を持っていく
「10年経っても無償保守お受けしますよ」と提案されてしまう。 >>777
そんなコスト無視の提案を平気でする会社は10年後には存続してないだろ。
時々、社員に作業させればタダ、と豪語する無能経営者がいるが、
保守作業は人間が手を動かすところで100%人件費なわけで、
顧客に負担してもらえないならその原資はどこから来るのか、
ちょっと考えれば分かるはずだがな。 >>778
数年後に会社を破綻させれば無理な約束もなかったことになるってことかね。
営業が無茶有環境ってすごい 「10年経っても無償保守お受けしますよ」ただし機能追加は通常の3倍の価格だ >>779
一契約の瑕疵担保責任を回避するために倒産させることは考えにくいが、
契約の相手方が倒産や解散で消滅していたら連絡方法がなくなり、
補修の相談すらできない。 ない袖は振れぬ
保証が手厚いなら、保証金額が高くなるだけ。
3割ほど、バッファを積むだけ
個人なら夜逃げするとか、会社なら解散する手もある 日本語のCodeIgnitor 3入門本(電子書籍)が出てたの昨日知って即買いしたよ
著者いわく、執筆直後に4が発表されて一度心が折れたらしい
よくぞ書き切って下さった >>784
そりゃ折角書き切ったし
宣伝したくなるのもわかるけど恥ずかしいから止めとけよ
今更PHP、しかもCIな時点で買う奴おらんし >>783
laravelなんかと比べると、こんなこともできないのかよとなってしまうね。 あのクラス名にいまだにアンダースコア区切りの長ったらしい名前使ってる恥ずかしいフレームワークか >>788
これは100%純粋に混じりっけなくピュアな無垢の飾らない純朴且つ真摯でひた向きな好奇心から真面目に嘘偽りなく誠実で摯実たる熱意を持って真剣に聞くんだけど、どんな事が出来たら便利だと思ってるの? >>789
CIってネームスペース使ってないんだっけか
Larabelもいいものなん? >>791
MVC自体はほぼcakeとおんなじ
キャメルケースとかネームスペース拡張してつかう感じ
でもララベルおっそいんだよなぁ >>792
Cakeもそうだが、LarabelとかのSymfony系は、自分で書いたコードが実行されるまでのステップが膨大だから、そんなのに全体のパフォーマンスを求めちゃいけないわけ。
パフォーマンスを落としても得られるメリットの方が大きければ採用する意味はあるが、少人数で開発できるものにそういう長大重厚フレームワークを採用すると、足を引っ張られたと感じるだけだろう。
CIはそういうことをやってないから高速なのは当然で、逆にCIに長大重厚フレームワークらしいことを求めちゃいけない。
個人的な感想だが、CIほど自由なら、いっそのことオレオレフレームワークの方が効率良く開発できると思うし、実際そうしている。 >>793
君がいなくなったあと、そのオレオレをメンテする身にもなってくだされ。
「オレオレの方がいイイ!」という人って後のことまったく考えてないよね。 >>796
ポピュラーなフレームワークは経験者が多いからPGを探し易い、というのは重厚長大フレームワークを選択する理由として良く聞く理由付けだが、Myフレームワークはシンプルだからphpを“まともに”読み書きできる奴なら誰でもメンテできる。
そのメンテですら四苦八苦する奴はPGとして使い物にならないと言える。
また、そんな低レベルPGでも、SymfonyやCakeだと突然気の利いたコードを書けるとでも思っているのか?お笑いだ。
そんな素人紛いのPGがまともな成果物を残せると期待しているのは、>>796のような商業PGとしてコードを書いた経験のないSEとPMだろう。
類は友を呼ぶのはこの世の習わしなんだなとつくづく思うわ。 >>798
誰でもメンテできるか検証したの?そのオレオレフレームワーク。
例えばバグとかちゃんと潰してある?
セキュリティリスクはない?
妄想で語られてもね。 >>798 は人の書いたコードをメンテしたことないのかな。
先ず沢山の人のレビューを経たコードと
自分しか見てないコード。どっちを信頼する?
全部自分の目で確認するから問題ないって言うなよ。
そういう奴は、工数を考慮したことがない素人だから。 >>799
心配ご無用。
>>799がそれを目にする日は一生来ないだろうしなw
つかその前に、ポピュラーなフレームワークはバグとかちゃんと潰れててセキュリティリスクはない、とか思ってるわけじゃないよな? >>800
君らはオープンソースの怖さを知らないだけだよ。
SymfonyやCakeが高速で動作し且つ開発期間を短縮でき且つ学習コストが低いなら一目置かざるを得ないがな。実際は真逆だろ。 >>801
もちろんゼロだとは思ってない。
でもコードの信頼性の指標にはなる。
ユーザーが多いからバグを見つけるし修正される。
そのオレオレフレームワークはどのくらいの人が使ってるの?
結局初歩的なバグが潰されてる可能性があるだろ。まさか自分の書いたコードにバグはないとおもってないよな? >>800
他者が書いたコードのメンテなんか日常茶飯事。
低レベルPGが書いたコードも嫌というほど見た。
実際、そういう奴らが明けたセキュリティホールを塞ぐ仕事もしてるし、オープンソースの結構大きなバグも見つけてる。
脳内プログラマには理解できなくても無理はない。 オープンソースの怖さってなんだよ。
お前が使ってるphpとlinuxもオープンソースなんだが。 >>804
なんでオープンソースに貢献しているやつが
わざわざオレオレフレームワークつくるの。さっきから支離滅裂なんだけど。 > 個人的な感想だが、CIほど自由なら、いっそのことオレオレフレームワークの方が効率良く開発できると思うし、実際そうしている。
負債産み出してる戦犯が何か言ってる なんだ。そういうやついるのかと思ったけどそういう釣りなのか。
オレオレフレームワークがベストって言ってる開発者がいるのかと思った。
オレオレフレームワークで仕事してるやつと仕事したことあるけど
学習コストは結局既存のフレームワーク並みにあったくせに
結構簡単にバグが見つかるし、実行時エラーがでても原因が特定しづらいしキツかった。
結局他のユーザーに鍛えられてないからエラー処理系が貧弱なんだよね
作ってる本人は俺的最強だから本人にとっては分かりやすいんだろうけど。 まぁそうムキになるなよ。
人生の中で得られる教訓は人それぞれ違うんだし、そもそもフレームワーク教の信者に改宗を迫ってるわけじゃない。
君らはこれまで同様重厚長大フレームワークを重用し続けてれば良い。
オレは単に、学習コストが高い+動作が鈍い+工数短縮に寄与するわけじゃない、つう重厚長大フレームワークの欠点を指摘し、そんなもん好んで使わないよって言ってるだけだ。
実際、業務でそういうものと付き合わざるを得なくなった時には、嫌々ながらもやってる。
だからこそ、その短所が目に付き、それを十分に補うだけの長所が見つからない、つうことだ。 >>806
自称世界最高峰エンジニア様なんだよ
だったら、PHPに変わる言語を開発して欲しいところだがw ボトルネックになりそうな部分は全部拡張モジュールにしろよ ボトルのネックって皆が気にしてくれて良いなぁ
俺の肩コリなんて解消されないのに
あ、でもボトルの頭は直ぐに飛ばされるから
その辺は首チョンパされないぶんお気楽なのか、、、 >>811
残念ながら、そういう悲しい現実はフレームワークとは直接関係ない。
クソコードは低賃金PGの得意芸なのであり、有名フレームワークを使ったからと言って排除できるものではない。
フレームワークを使えばソースコード全体におけるクソコードの比率は下がるだろうがそれは見掛けの数字であり、フレームワークにさえクソコードを混入させていたら状況はより混沌とする。
そういう悲しい現実を減らすには、コードを書けない奴をSEやPMとして置かないこと、低賃金PGの作業領域をできるだけ減らし且つ低賃金PGの作業は上級者が必ずチェックして指導することしかない。
そういうことを知らない奴らが営業したり経営している限り状況は改善しないだろう。 そう、ホットスポットは出来るだけ局所化、極少化すべきであり、そのホットスポットさえもジェネレータなどで極力自動化すべきなんだよね laravel って「職人のためのフレームワーク」 なんだよな・・・
そこが最大の欠点だと思う お前らのくだらないプライドのために会社の利益を下げてることに気付け
シェアが高いものはとりあえず否定
↓
マイナーなフレームワークを使う
↓
他の社員がメンテできない
↓
派遣や契約に丸投げ
↓
無駄なコストがかかり、社内の技術も上がらない >>820
詳細を求む。具体的な欠点とかあげてほしいわ Laravelはsymfonyみたいにバンドルスタイルにしろよ
再利用性悪すぎてかなわんわ >>819
Laravelのドキュメントに書いてあるだろ >>822
> シェアが高いものはとりあえず否定
全然違うね。まず、シェアの高低なんか全く関係ない。利用数が少ないという理由だけでフレームワークを選択するのは不合理だ。
> マイナーなフレームワークを使う
そもそもフレームワークのシェアに関する正確な数字はないはずで、マイナーかメジャーかという切り口自体が幻想である。
ブログなどでフレームワークの人気度を測るバロメーターとなっているのは、Googleでの検索回数の多寡ではないか。
検索機会の多さは分かりにくさを示唆している可能性があり、使い方に悩んだ上での検索が多いのであれば、使わない方が無難かも知れないのだ。
> 他の社員がメンテできない
社員のプログラマとしての能力が低ければ、何を持って来ても同じ。
プログラマとしての能力が高く、且つ学習コストの低いフレームワークであれば、初物でもメンテは困難ではないだろう。
> 派遣や契約に丸投げ
> 無駄なコストがかかり、社内の技術も上がらない
仮にその会社ではSymfony系しか扱わず、そこの社員はSymfony系なら対応できるということであったとしても、それはその会社でしか通用しない。
現実社会は多様であり、転職したら未経験のフレームワークと向かい合うことになるのは火を見るより明らかだ。
そこで躓くようなら、それはつまり、前職で習得した技術が役に立たないことを意味する。
マイナーなフレームワークに触れていると社内の技術が上がらない、というのも幻想だ。
派遣や契約への依存=無駄なコストという考えも誤り。一時的に彼らへの依存を高めたとしても、そこから得らるものを得ようとしないから“無駄なコスト”に思えてしまう。
余程頑固な会社でない限り、未経験のフレームワークが要求される案件を請けることはいつでもあり得る。
だからこそ、学習コストの高いフレームワークは邪道だと思う。
そういうものを嗜好する人は宗教に似た思い込みに取り付かれているのではないか。
いわゆる洗脳である。 シェアの高さは 情報の多さに繋がり 学習コストを引き下げてくれるからな
「みんな使ってるから これにするわ」 ってのは 結構正しい選択なんよ つまり日本じゃCakePHPってことになるのけ?
たしかに日本語ドキュメントは圧倒的に多いみたいだけど >>829
肝心なシェアはどうやって知るの?
その数字は正確なの?
シェアの変化に追随するの?
そもそも>>829は自分でコード書いてるの? >>829
そうだね。
ググればいくらでも答えが出てくるならそれに越したことはない。
俺は小さな会社経営してるんだけど、たまに依頼あるのよ。
協力会社に作らせたサイトに手を入れられなくて困ってると。
そういうのは決まってオレオレか日本ではマイナーなフレームワーク。
ソースコード見ると、たしかに技術がある人が書いてそう。
でも、いかにも「このくらい分かるだろ」と言いたげな傲慢さも感じられる。
ソースコードでそれを読む人をねじ伏せようとしてるかのよう。
そうなっちゃダメだよね。
まあ、その手の困ったちゃんがいるから俺らも食いっぱぐれないんだが。 ってことでやっぱりLaravelか
海外の評価は正しいんだな
俺は自作フレームワークだけど phpはソース読めばわかるだろの姿勢がデフォだと思ってたわ。
いちいちドキュメントなんて書いてらんないし >>838
書いてらんない?w
本音はどう書けばいいかわからないんだろ? で、>>842は自分でドキュメントやソース書いてるのか? PHPとJavaほど、下手くそが書いたコードが読めない言語もそうそう無いような… フレームワーク初心者はどれ使えばいいんだ
書籍をあたるとCakeとLaravelくらいしかないみたいだけど
英語読めないんで日本語ドキュメントがないと使い方わからん laravelでいいんじゃね
日本語の入門書なら腐るほどあるよ
qiitaにもlaravelタグの投稿は1571もあるし、別に困らんと思うけどな 縁は大事だ、今から始めるならつい数十時間前にリリースされたばかりのLaravel 5.5 LTS使いなよ ■ このスレッドは過去ログ倉庫に格納されています