アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
くっきーはぐはぐ (スコア:1, 興味深い)
メーリングリストや質問板に見るユーザー層の質もそんな状態で、基礎理解が不足している上に解法でなく解答を求める人が大半。最近は素人に素人がリプライ付けてタコなコーディング技法が伝播していく有様。
関西圏だと仕事料の相場もかなり下落しており、二束三文のコーダー使って動けばいいだけのコードをかけば利益が出るけど、まともなテストや経験と知識を十分に備えた人間を割り当てると赤出るんじゃないの？と思ってしまう状態。
なんつーか、ストーリーのように啓発を促すか、きっちり監督してもらって品質の下落を食い止めれば少しはマシな状態になるかな～と期待していますけど、、
Re:くっきーはぐはぐ (スコア:1)
「できないこと（XSSできない、不正なSQLは投げられない、など）」も
機能に盛り込んでいかない限り、改善しないんだろうなぁ。
しかし、現状では「できないことは機能ではないし、払う金はない」なんて言われそうだな。
「できない機能を盛り込んでトラブルを抑え、運用費を削減しました！」
みたいな成功体験はないのかな…
そういうのがあれば管理職を説得しやすいと思うんだけど。
# mishimaは本田透先生を熱烈に応援しています
Re:くっきーはぐはぐ (スコア:0)
Re:くっきーはぐはぐ (スコア:0)
>機能に盛り込んでいかない限り、改善しないんだろうなぁ。
>しかし、現状では「できないことは機能ではないし、払う金はない」
>なんて言われそうだな。
そういうのは
Re:くっきーはぐはぐ (スコア:0)
「XSSできない」じゃなくて
「XSS攻撃に対する耐性がある」かな。
機能というより品質や安全性に関する要件だと思う。
最低限守るべきお約束みたいな。
そういうのを毎回お客さんが書くのって大変だから
汎用的な「ネット利用のアプリの安全性に関する要件」の文書を
どこぞの専門家さんに書いてもらって
それをGPLのように公開して御自由にお使いください
になるといい
品質への対価 (スコア:0)
そしたら、あとは、品質の低いものを買っていると後で面倒なことになるよという認識を、運営者に持ってもらうこと。
しかし、どうやって品質を評価するのか。
Re:品質への対価 (スコア:0)
建物の手抜き工事と同じで、結局キッチリやっても日の目を見ることは少ない、という状況では、なかなか自
Re:くっきーはぐはぐ (スコア:0)
Re:くっきーはぐはぐ (スコア:0)
この業界にとっての「セサミストリート」にあたる基礎教育ってなにがあるのかな？