元スレ【php】fuelphpについて語ろうぜ

php覧 / PC版 /

みんなの評価 :

前へ 1 2 3 4 5 6 7 8 9 10 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

401 = :

ディスってんのか

402 = :

>>401
これってなんだよ日本語使えやボケが

403 = :

新しい職場で上司(現役PG)と一緒に画面見ながら不具合調べてたとき
expireってどういう意味ですか？
って聞かれてショックでした。

まぁ世の中そういうもんということでｗマターリいきましょうｗ

404 = :

expireの対義語が即座に出てこないなら、お前も同レベルだろう

405 = :

>>404
valid？

406 :

あまり流行らないなぁ

407 = :

終わったフレームワークだし新規で使う人はいないだろうね

408 = :

cakeに比べればだいぶマシな状況と思うよ

409 :

仕事で
これから絶対流行ります！
って説明してこのフレームワークにしたわけだが
あんまり流行ってないな(´д｀;)
どうしようかしら。

410 = :

>>409
別にいいじゃん

おれは逆に、この先どんだけ廃れても
その気になればなんとか自分でもメンテ出来る
というのを基準にfuelを選んだぞ

411 = :

ぜんぜんOK問題なし。

いろんな束縛や反対意見があっても、自分の好きな開発環境に
して仕事をすすめるのもエンジニアの技量のうち。

412 = :

fuelは初めから流行る気がしなかった。パッとしなさすぎ。

413 = :

当初は幾つかのレンサバでFuelphpを持て囃してた記憶がうっすらある

414 = :

パッとしなくても、流行らなくてもいい。

安心して長く使えるのが一番。

415 = :

>>414
んだね

416 = :

fuelは安心して長く使えるの？

417 = :

ドキュメントが充実しているから長く使えると思う。

長く使えば、バグは枯れてくるし
同じスキルを長く保持すれば開発品質が上がり開発者の評価も上がるし、
会社としてもスキル統一ができてスキルの高位平準化ができるし。
いいことずくめ。

頻繁にV.UPを繰り返すフレームワークを採用するのは、開発者としても組織としても、損だと思う。

418 = :

>>416
コード小さいし、最悪でも自力でなんとかなんだろ

419 = :

質問です。
DBクラスを使用してMySqlからデータを引いてきますが、
複数DBのテーブルをJoinしてデータを取得することはできますか？
Sqlとしては同サーバにある場合はDB名.テーブル名でJoinできそうですが、
fuelのDBクラスでそれはできますか？
executeの引数にDB名指定することはできるみたいですが、複数の場合は…？

420 = :

>>419
自分でなんとかするしかないね
標準のDBクラスではできない

421 = :

>>420
無理だとしたら、両方からとってきて自力でガッチャンコするしかないってことですね。
嫌だなーそれ

423 = :

スマン、見逃してた、複数テーブルじゃなくて複数DBね、、、

424 = :

>>421
標準の機能ではできないだけだし
手で普通にクエリーを書けばよかろう

425 = :

>>424
手で普通にって、joinしたあとgroupbyもしたいわけで、
二回にわけてとってきて、自力でマージしながら重複省くのってすごく嫌です…

426 = :

>>419
標準のDBクラスのqueryメソッドからjoinできるよ？

できないって言ってる人って、マッパーのこと言ってるの？

427 = :

>>425
だいたいのことはクエリ一発でできるじゃんという話なんだけど
まあfuelphp関係なくなるからどうでもいいか

428 = :

>>426
別DBのテーブルでもjoinできますか？
executeメソッドの引数のDB名は指定なしでOKなんですか？
他に設定しなきゃいけないものとかあるんでしょうか？
ちなみに同サーバの別DBです。
sqlでは普通にできることですね。
fuelのDBクラスを使ってできますか？

431 = :

>>429
DB::expr使ってはどうだろう？

432 = :

>>431
なるほど、sql直書きですか。
そうすればいいんですね。
ありがとう。

433 = :

>>432
どういたしまして

434 = :

>>417
それで言ったらStrutsとか安全で最強のはずだが、
現実はセキュリティホールは放置されたまま誰も手を入れようとせず、
なのにいまだに使い続けられクラッキングの温床になってるよな

435 = :

Viewで画面を表示するとき、アドレスも変更したい。

なんかできそうな気がするけど、やり方がわからない。

436 = :

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
>>383 >>384 >>380
客が瑕疵担保責任法の法改正を知ってくると思うから、今後5年無償保証をお願いされるだろう
営業がそれでも仕事を取ってこれるか？たぶん無理だろう。無限の直していたら赤字になる。
こういう保守に弱い言語、ころころ仕様が変わる言語は仕事として発生しなくなってくる。
これは変わり目だ。お前らも早く逃げたほうがいいぞ。RubyやPHPなど動的言語は確実に廃れる。
保守に強い言語のみ生き残れる。

437 = :

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

瑕疵担保責任のポイント

民法改正で事実上期限が「無制限」になった
バグや設計のミスなどは、瑕疵担保責任
納品物に不具合があれば損害賠償を請求される可能性もある
不具合を指摘されたらすぐに行動をとるべし
軽微なミスでも先延ばししない

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年目以降は不具合の修正に対応しない」と主張するベンダーはまれだ。多くの場合は、納品から何年たっても、
バグが見つかればユーザーのところに飛んで行き、無償で改修するだろう。

438 = :

サーバー変えたら動かなくなりました。
OSアップデートしたら動かなくなりました。
OS変えたら動かなくなりました。
WEBサーバー変えたら動かなくなりました。
WEBサーバーにパッチプログラムをあてたら動かなくなりました。
DB変えたら動かなくなりました。
DBをアップデートしたら動かなくなりました。
PHPのアップデートプログラムを更新したら動かなくなりました。
PEARのバージョン変えたら動かなくなりました。
PEARのアップデートプログラムを更新したら動かなくなりました。
WordPressのバージョン変えたら動かなくなりました。
WordPressのプラグインのアップデートプログラムを更新したら動かなくなりました。
Railsアップデートプログラムを更新したら動かなくなりました。
Rubyアップデートプログラムを更新したら動かなくなりました。
高負荷になったら動かなくなりました。無償で修理してください。損害も請求します。
しばらく放置していて、最近動かしたら動かないです。原因はわかりません。これは御社の不具合なので無償で修理してください。

5年後ごとに起こるであろうこと　PHPバージョン変えたら動かなくなりました。無償で修理よろしく
3年後ごとに起こるであろうこと　Railsバージョン変えたら動かなくなりました。無償で修理よろしく
1年後ごとに起こるであろうこと　Rubyバージョン変えたら動かなくなりました。無償で修理よろしく

無償で修理してください。損害賠償も請求します。無視するなら瑕疵担保責任法で訴えるぞ！

納品先の会社　10社から同時に

重大な脆弱性が現バージョンから発見されました。こちらでアップデートしたところ、起動ができなくなりました。
至急弊社に来て修正作業をお願いします。なおお金は払わない。また営業に損失が出たので損害請求もします。