今となっては割と普通になってきた感のある「なんで人はがちゃで散財をするのか？(極論)」というお話ですが。
比較的初期の頃に、この手のお話を大変に丁寧に書かれたこの書籍を、今日は紹介。
一方で「経済学の准教授」という側面と、もう一方で「かなりギリギリのゲーム廃人」という側面が大変にナイスに融合した、素晴らしい論調の内容です(笑
ただ、ものすごく残念な事に、書かれている方はすでにお亡くなりになっています。
gallu.hatenadiary.jp
この本も「一読の価値はまちがいなくある」ので。
残念ながら、電子書籍になっていない上に新刊がないので中古オンリーになってしまいますが、是非、手に取って読んでみてください。
失敗学、ってぇのがありまして、端的には「失敗に学ぼう」というものでございます。
成功は、とかく「運や偶然やまぐれ」が介在しやすいのと、また成功した時に「どこが本当の"成功の要因"だったか」の検証は、なかなかに難しいものなのですが。
一方で失敗は「これをやったら、運がよっぽどヨクナイ限りは同じような目に遭うよねぇ」と考えやすく、他人の失敗から学ぶのは、とても大切なものでございます。
この手のお話で、まずトップに出てくるのがこちら。
「超」入門 失敗の本質 日本軍と現代日本に共通する23の組織的ジレンマ
また、失敗学自体について、読みやすい書籍を1～2冊読んでおくとよいか、と思います。
「これでなければ」ではないのですが、おいちゃんの手元にはこれがあり、そこそこ読みやすかったと思います。
また、同じ方が書いているこの書籍も面白かったので、合わせて。
こういった「失敗」という切り口をどれくらい活用できるか？ は、割と死活問題な気がするんですよねぇ。
プロマネのスキルは。
勿論「プロマネになりたい」のであれば必要なのですが、「がっつり現場でがりごりとプログラム書きたい」人も、最低限くらいは踏まえておいたほうがよい、と思われるスキルでございます。
もう一つ。
PMBOKはやっておいたほうが良いと思う、ってんで、この本をよく勧めます。
プロジェクトマネジメント標準 PMBOK入門: PMBOK 第6版対応版
PMBOKもまぁ色々と「……ちょっと」とか言われたりすることもあるみたいですが、それは「PMBOKをちゃんと踏まえたその先」のお話なので。
まずこの辺くらいは、しっかりと踏まえておきたいものでございます。
一度は読んでおきたいドラッカー。
ただ、いきなり「マネジメント」から行くと少々歯ごたえがあるので。
いや別にこの本でなくてもよいのですが、いわゆる「入門」とか「初心者向け」とか「ｎ日でわかる」とか「図解」とか、その手の「敷居の低い本」を読んでから本編(マネジメントとか)に行くと挫折しにくいので、オススメでございます。
ちな、「とりあえず入門書だけ読む」のであれば、「異なる著者の初心者本を、2～3冊」ってのをオススメしておりますので、合わせて覚えておいてもらえれば。
その後ですが、「実践するドラッカー」シリーズを読んでみると、割と「身近なお話」になりやすいので、身になりやすいか、と。
とりあえずこの2冊を紹介しました。
お次の話題は「ホスピタリティ」でございます。
リッツ・カールトン 超一流サービスの教科書 (日経ビジネス人文庫)
2つのホテルの方法論は、びっくりするくらい「違う」のですが、「お客様のために」って方向性は一緒なんですよね。
勿論、システム開発なので「全く同じ」ではないのですが。
それでも、システム開発の向こう側には「お客様」がいて、開発の中であっても(おいちゃんはプログラムが多いので一端プログラマベースの目線でいくと)インフラ屋さんやDB屋さん、デザイナーさんや営業さんやマーケティング屋さんがいて。
そういう人達と「いかに協業するのか」ってのはとても大切なので。
その方法論の一端を考える上で、とても面白い書籍なんじゃないか、と思っています。
＆
と言うわけでセキュリティ。
プログラム側のお話が多めですが、「それ以外」も少し。
何はともあれ、まず「Webアプリケーションでプログラムを組む」人が、何を置いても読まにゃならんのが、こちら。
体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践
とりあえず「何をか言わんや」。
一つだけ言えることがあるとすると「書籍名覚えてませんごめんなさい」(笑
いや、Googleでも「徳丸本」で引っかかるからなぁ(笑
ちょっと角度を変えて、「クラック」というものの別側面を知るのに興味深いのが、こちら。
いかに「弱いところからほころびる」か、が、ふんだんに見て取れます。
後は。書籍ではないのですが、 安全なウェブサイトの作り方：IPA 独立行政法人 情報処理推進機構 こちらも、割と必読。
セキュリティ実装 チェックリストは、割と本当に重宝します*1。
「どこまでセキュリティをしっかりやるか？」ってのは、勿論、あるのですが。
「実装する人間が事前にちゃんと学んでいれば、設計や実装そのものにはそんなにコストがかからない」レベルのセキュリティであれば、それを実装していないのは「エンジニアの怠慢」だとしか思わないんですが、ど～なんですかねぇ？
……って突っ込まれないようにするためにも、しっかり、事前学習くらいはしておきたいものでございます。
*1:……………ちょっと最近、吐血しそうな事があったりしましてねぇ……………
「について考えてみる」三部作(って今決めたｗ)、最後の項目。
内容は「validation、をどこに実装するか？」てなお話です。
一旦、Webアプリケーションのお話で展開します。。
前提として、Modelのお話が出てくるんで https://gallu.hatenadiary.jp/entry/2019/05/13/213612 のあたりを一読しておいていただければ幸い。
以下では「Model ≒ ORM」なModelを想定します。
違う場合は「データの塊を扱う箇所 ≒ Model」って読み替えていただければ*1。
前提として。
「validationはやるよねぇ」ってのは、一端そこは合意前提で。
いやまぁ「どれくらいがっつりやるのか」ってのはありますし、そもそもとして「valid(有効)ってなに？」ってのもありまして。
具体的には「日付のvalidation」は、その日付がグレゴリウス暦であれば比較的簡単かと思うのですが、それが「誕生日」だとすると「どこまでがvalidなんだろう？」というあたりでちょっとした議論くらいは巻き起こせる感じではあるのですが*2。
とはいえまぁ「ある程度の落としどころ」を加減した上での「明らかにinvalidなデータくらいはブロックしたいよねぇ」くらいの感じ、を、一端想定していきたいと思います。
さて。
昔々であれば、こんな事を考える必要は(多分)無くて。
つまり
// 入力を受け取って // validationして // DBにinsertしたりupdateしたりして // HTMLを出力する
的に、立て板に水の如く「書き流せば」よかったのですが。
昨今、これらを「1ファイルで一気に書く」事は比較的レアケースとなりつつあり。多くの場合は、いくつかのクラスを「有機的につないで」1つの機能にしているので。
そうすると「どこに書くの？」というのは、とても重要なんじゃないかなぁ、と、個人的には思うところでございます*3。
いやまぁおいちゃんの中では(今のところ)大体決まっていて。
「データ保存の直前で、テーブル*4のレコード単位」って考えてます。
一般的なPHPのフレームワークだと「Model」ですかねぇ。MagicWeaponだとdata_clump派生クラス。
理由は簡単で「validateは、一塊の"データ"*5に紐付く処理」だと考えているから。
なんだけど、そこで終わるようならわざわざこんな文章は書かない訳で、そのあたりから詳しく。
初手に気づいたのはLaravelが「Controllerに入ってくる前にvalidateを片付けておく( https://readouble.com/laravel/5.5/ja/validation.html )」って思想を見て*6……「あぁそういえばこーゆー思考、以前にも見たなぁ」と思いまして。
その後、CodeIgniter 3でもやはり、validatinoは「form validation( https://codeigniter.jp/user_guide/3/libraries/form_validation.html )」という名前で、controllerに紐付いていて。
ちぃと興味がわいたんで、あちこち、調べてみました。
CakePHP3。
https://book.cakephp.org/3.0/ja/core-libraries/validation.html
Validatorクラスが完全に独立していて、Controllerに書いてもModelに書いても「どちらでもどんぞ」的に見えます。
FuelPHP
http://fuelphp.jp/docs/1.8/classes/validation/validation.html
CakePHP3と同様「Validationが独立」しているので以下略
Symfony
https://symfony.com/doc/current/validation.html
どうも2種類あるっぽいですが、「The Basics of Validation」がEntity(Model)に書くような書き方であることから、「どちらかというとModelに書いて欲しい」雰囲気である事を想起させます。
Zend Framework
https://docs.zendframework.com/zend-validator/
今ひとつつかめないのですが、Validatorクラスが独立しているので以下略、と思われます。
Phalcon
https://phalcon-docs-ja.readthedocs.io/ja/stable/reference/validation.html
Validationクラスが独立しているので以下略。
………ところで、今、Phalconってどれくらい使われてるんですかねぇ？
Slim
http://www.slimframework.com/docs/
そもそも色々と「シンプル」なフレームワークなので、Validationも「自分で実装しましょう」(笑
なので、URIも「ドキュメントのTop」ですvalidateを書いてあるPageじゃないです(笑
さて。
大雑把にまとめますと
・Controller：2
・どちらかというとModel：1
・どっちでも：3
こんな感じですかねぇ。
いやまぁ別に「多数決でナニカを決めたい」わけではないのですが、とりあえず実態くらいは把握しておきましょう、と。
んで。
たまたま別件で知って、いやまぁ色々と思うところも多々あるフレームワークではあるのですが。
他言語になりますが、RoR(Ruby on Rails)において、いわゆるModelに近しい位置にいるActive Recordが https://railsguides.jp/active_record_validations.html で、こんな記述がありました。
データをデータベースに保存する前にバリデーションを実行する方法は、他にもデータベースネイティブの制約機能、クライアント側でのバリデーション、コントローラレベルのバリデーションなど、さまざまです。それぞれのメリットとデメリットは以下のとおりです。
・「データベース制約」や「ストアドプロシージャ」を使うと、バリデーションのメカニズムがデータベースに依存してしまい、テストや保守がその分面倒になります。ただし、データベースが (Rails以外の) 他のアプリケーションからも使われるのであれば、データベースレベルである程度のバリデーションを行なっておくのはよい方法です。また、データベースレベルのバリデーションの中には、使用頻度がきわめて高いテーブルの一意性バリデーションなど、他の方法では実装が困難なものもあります。
・「クライアント側でのバリデーション」は扱いやすく便利ですが、一般に単独では信頼性が不足します。JavaScriptを使ってバリデーションを実装する場合、ユーザーがJavaScriptをオフにしてしまえばバイパスされてしまいます。ただし、他の方法と併用するのであれば、クライアント側でのバリデーションはユーザーに即座にフィードバックを返すための便利な方法となるでしょう。
・「コントローラレベルのバリデーション」は一度はやってみたくなるものですが、たいてい手に負えなくなり、テストも保守も困難になりがちです。アプリケーションの寿命を永らえ、保守作業を苦痛なものにしないようにするためには、コントローラのコード量は可能な限り減らすべきです。上で紹介したその他のバリデーションについては、特定の状況に応じて適宜追加してください。Railsチームは、ほとんどの場合モデルレベルのバリデーションが最も適切であると考えています。
このように書かれているのが、大変に興味深いかなぁ、と。
端的には「非常に近い見解を持っている」あたりで、興味がわきました。
さて。
ちぃと切り口を変えてみますと。
概ね「Controllerにvalidationを置きたい」というお話は「validationをformに紐付けたい」と考えているように見受けられ、同様に「Modelにvalidationを置きたい」というお話は「validationをテーブル(レコード)に紐付けたい」と考えているように見受けられます。
んで。
form側のお話がわからんでもなくて、つまり
・同じテーブルでも、formの入り口によって項目が違ったりする(常に全項目とは限らない)
などの揺れがあるので「formに紐付けたい」んじゃなかろうかなぁ、と。
あとはまぁ「エラーメッセージが出しやすい」って発想はありそうに思われるんですがね。
ただ、一方で
・同じテーブル/カラムにいれる情報なのに、入る口によって「文字だったり数字だったり」とか「最大長が100だったり200だったり」って変わるんだろうか？
って思うんですよねぇ。
「変わる」のであれば、確かにそれは「formに紐付けたほうがよい」かもしれないと思うのですが、おいちゃんが今まで経験している限りで「それを必須要件として持っている」案件って、出会った事がないんですよ。
少なくとも「同じ項目」であれば、そこのvalidateは基本「変わらない」。
せいぜいが「ここの入り口からだとこのカラムは変更禁止」てな感じくらいなので、ただ「変更禁止」は、validateではなく、別の責務なんじゃないか、って思うんですよねぇ。
そうすると。
個人的には
・「データ」を管理しているところでvalidationする
のが、一番「素直」なんじゃないかなぁ、と思うわけです。
なんか、カラムの追加があっても変更があっても「対象になるModelクラスを修正」すればよいだけ、なので、DRYになるじゃないですか。
で、次点としてどうしても(フレームワークとかの都合で)Controllerでせざるを得ないのであれば、せめて「そこに渡すルールは、Model側で管理して一意に管理」にしてはどうかなぁ？ と。これならまぁDRYになる……かもしれない。「カラムの追加」とかがあるとDRYにはならなさそうな気もいっぱいしますが、まぁ「書き方次第」でもありましょうから、「ちゃんとDRYになるように書く」前提、って事で。
とはいえ一方で、寺子屋のメンバーから「Active Record(model)にあんまり責務が集中するのも如何なものだろう？」という議題提起をもらいまして、それはそれで興味深いところかなぁ、と。
おいちゃん個人としては「素直に考えた結果、どこかのクラス(の責務)が集中するのは、ある程度仕方がないんじゃないかなぁ」という雑な思想を持っているので(そのあたりは、 https://gallu.hatenadiary.jp/entry/2019/05/13/213612 でファットコントローラーへの言及で似たようなお話をしてます)、もうちょっと丁寧な議論を聞いてみたい気も満々でございます。
この辺は、なかなかに興味深いところかなぁ、と思われるのですが。
どこかで「アンサーブログ」とか、出てこないですかねぇ？ｗ
*1:なので、万が一MagicWeaponを想定する場合、以下のModelはdata_clumpに相当します
*2:この辺、面白いっちゃぁ面白い所なので、要望があったら別途
*3:もちろん「ちゃんと動けばどこに書いたっていいじゃない」という主張がある事も存じ上げてはおりますが、個人的にはそういった御仁とは「適切な距離をおいて、穏便に恙なく平和裏に節度をもって形式上のお付き合いをしていきたいものだなぁ」と感じたりする所でございます
*4:ファイルだったりドキュメントだったりしてもよいんだけど
*5:もうちょっと端的には「1テーブル の 1レコード」
*6:5.5なのは「最近、お仕事で使ってたバージョン」だから。LTSだからってのもあります
