プロジェクトはマネジメントしませんと、されませんと

プロマネのスキルは。
勿論「プロマネになりたい」のであれば必要なのですが、「がっつり現場でがりごりとプログラム書きたい」人も、最低限くらいは踏まえておいたほうがよい、と思われるスキルでございます。

世界一わかりやすいプロジェクトマネジメント 第4版

「世界一わかりやすい」かどうかは知りませんが、読みやすくわかりやすい書籍だと思われます。
一つポイントなのは「実はこの本、"プロジェクトマネジメントの本"ではあるけれども"システム系のプロジェクトマネジメントの本"ではない」、って所。
読んでて9割がた普通に「あるある」な内容なので結構気づきにくいのですが、実はこの本「プロジェクトマネジメントの本」なので、別に「システム開発用」ではないんですよね。
どこも「同じような感じなんだなぁ」ってのを、切実に感じるところでございます。

もう一つ。
PMBOKはやっておいたほうが良いと思う、ってんで、この本をよく勧めます。

プロジェクトマネジメント標準 PMBOK入門: PMBOK 第6版対応版

割合とあっさりと読めるので、入り口用にオススメです。

PMBOKもまぁ色々と「……ちょっと」とか言われたりすることもあるみたいですが、それは「PMBOKをちゃんと踏まえたその先」のお話なので。
まずこの辺くらいは、しっかりと踏まえておきたいものでございます。

ドラッカー……を、ちょっと手加減して

一度は読んでおきたいドラッカー。
ただ、いきなり「マネジメント」から行くと少々歯ごたえがあるので。

図解で学ぶ ドラッカー入門

いや別にこの本でなくてもよいのですが、いわゆる「入門」とか「初心者向け」とか「ｎ日でわかる」とか「図解」とか、その手の「敷居の低い本」を読んでから本編(マネジメントとか)に行くと挫折しにくいので、オススメでございます。
ちな、「とりあえず入門書だけ読む」のであれば、「異なる著者の初心者本を、2～3冊」ってのをオススメしておりますので、合わせて覚えておいてもらえれば。

その後ですが、「実践するドラッカー」シリーズを読んでみると、割と「身近なお話」になりやすいので、身になりやすいか、と。

実践するドラッカー【行動編】

実践するドラッカー【チーム編】

とりあえずこの2冊を紹介しました。

ホスピタリティ

お次の話題は「ホスピタリティ」でございます。

リッツ・カールトン 超一流サービスの教科書 (日経ビジネス人文庫)

持っているのは文庫版ではないのですが、今、どうも絶版っぽいので、こちらで。
出た当初は、一瞬、バズってた書籍だったように記憶をしています。

帝国ホテルの不思議 (文春文庫)

こちらも同じく「持っているのは文庫版ではないのですが以下略」です(苦笑

2つのホテルの方法論は、びっくりするくらい「違う」のですが、「お客様のために」って方向性は一緒なんですよね。
勿論、システム開発なので「全く同じ」ではないのですが。
それでも、システム開発の向こう側には「お客様」がいて、開発の中であっても(おいちゃんはプログラムが多いので一端プログラマベースの目線でいくと)インフラ屋さんやDB屋さん、デザイナーさんや営業さんやマーケティング屋さんがいて。

そういう人達と「いかに協業するのか」ってのはとても大切なので。
その方法論の一端を考える上で、とても面白い書籍なんじゃないか、と思っています。

＆

リッツ・カールトン一瞬で心が通う「言葉がけ」の習慣

をはじめとする「リッツの名を冠してる書籍」は割と色々出ているので、いくつか読んでみても面白いかもしれません。

セキュリティは大事だよねぇ

と言うわけでセキュリティ。
プログラム側のお話が多めですが、「それ以外」も少し。

何はともあれ、まず「Webアプリケーションでプログラムを組む」人が、何を置いても読まにゃならんのが、こちら。

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践

とりあえず「何をか言わんや」。
一つだけ言えることがあるとすると「書籍名覚えてませんごめんなさい」(笑
いや、Googleでも「徳丸本」で引っかかるからなぁ(笑

ちょっと角度を変えて、「クラック」というものの別側面を知るのに興味深いのが、こちら。

欺術（ぎじゅつ）―史上最強のハッカーが明かす禁断の技法

いかに「弱いところからほころびる」か、が、ふんだんに見て取れます。

後は。書籍ではないのですが、 安全なウェブサイトの作り方：IPA 独立行政法人 情報処理推進機構 こちらも、割と必読。
セキュリティ実装 チェックリストは、割と本当に重宝します*1。

「どこまでセキュリティをしっかりやるか？」ってのは、勿論、あるのですが。
「実装する人間が事前にちゃんと学んでいれば、設計や実装そのものにはそんなにコストがかからない」レベルのセキュリティであれば、それを実装していないのは「エンジニアの怠慢」だとしか思わないんですが、ど～なんですかねぇ？

……って突っ込まれないようにするためにも、しっかり、事前学習くらいはしておきたいものでございます。

*1:……………ちょっと最近、吐血しそうな事があったりしましてねぇ……………

validationについて考えてみる

「について考えてみる」三部作(って今決めたｗ)、最後の項目。
内容は「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だからってのもあります

お次はインフラ

インフラ系の入門を、いくつか。

小悪魔女子大生のサーバエンジニア日記 ――インターネットやサーバのしくみが楽しくわかる

全体を見たい場合に非常によい本かなぁ、と。
初学者向きでもありとても丁寧なのですが、イラストと手書き文字の賛否がわりとキッパリと二分しているので、その辺の好き嫌い次第、ってのは、多少。
ただ、とはいえ「書いてある内容を十全に把握していると言い切れる」初学者はあんまりいないと思うので、ちぃとくらいなら、苦手意識取っ払って読んでみてもよいと思う。

改訂4版 図解でよくわかる ネットワークの重要用語解説

まぁ技術の世界はどこでもそうなのですが、インフラ系も「色々な用語」が飛び交います。
そんな用語をざっくりと幅広く解説してくれる書籍なので。
「通読」するのもよいですが「わからなくなったら開いてみる」のもよいかなぁ、と。
とはいえまぁ、一度は、脳内目次を作るために「通読」しておくと、効率がよいってぇもんです。

ポートとソケットがわかればインターネットがわかる――TCP/IP・ネットワーク技術を学びたいあなたのために (Software Design plus)

ピンクベースで可愛らしい感じの表紙の、とても「初心者フレンドリー」に"見える"本です。
基礎から丁寧に解説してくれる良書………なのですが、後半に、そのなだらかな雰囲気のまま「(C言語で)ネットワークプログラムを書いてみよう！」とか(笑
是非、雰囲気と流れにごまかされて、「これくらいは普通なのかなぁ？」って思いながら実習してみてくださいｗｗｗ

Modelについて考えてみる

あちこちで「MVC」と言われつつ、なんか気がつくとMVPとかMVVMとか色々出てきて。
一方でじゃぁ「Model、って単語自体はは大体共通認識なのか？」と問うと、これがまた………。

というあたりで。
ちぃとごみごみと混雑しているように思われるので、一端、考察してみたいかなぁ、と。

以前に全く別の所でも書いたのですが。
大雑把に、フレームワーク(WAF)は
・ルーティングに従ってディスパッチして
・ビジネスロジック呼んで処理して
・出力
ってな流れが、ものすごく大雑把なあたりで、主だった処理の流れだと思われまして。

んで、この「ビジネスロジック」の所が、実際には
・DBとやりとりをするところ
・データをごにょごにょする所
の2つがあると思うのですだす。

んで。
「Modelってなに？」って聞いたときに、確実に紛糾するのが、あるいは分離するのが、この聞き方。

・「Model ≒ ORM」は、true？ false？

この判定式のboolean値によって、以降の内容が決まってくるわけでございます。
端的に「Modelの1インスタンスが、(大体)1テーブルの1レコードを意味している」のであれば、上述はtrueになる感じ。
とはいえ……昨今のフレームワークの多くは「true」なのではないかなぁ、と思うので、そのルートを前提に。

上述が概ねtrueだとすると、次の質問が

・「ビジネスロジック」は、どこに書くの？

というあたり。
これが「コントローラー」になるんなら、まぁ「トップハム・ハット卿*1になる」事は仕方が無いんじゃないかなぁ、と思うですよ基本的には。
勿論「ほかの場所に切り出してコントローラーをスリムにする」のはよいのですが、結局それって「コントローラーが抱え込む脂肪をほかのclassに押しつけている」だけ、なので、ほかのどこかがファットになるだけかなぁ、と。
で「んじゃぁ山盛りでclass作ってどこもスリムにする」と、今度はファイルの全体量とかクラスの数とかメソッドの数とかが半端なくなくなって可読性が落ちるので、個人的にはそっちの方が「よりお好まないかなぁ」と。
なので「必要な流れを必要な程度に書く」のは必要で、それが「特に分割するメリットがない」のであれば、ある程度長くなるのも、状況によっては「やむを得ない」と思うんですよ。

ただまぁ実際には「共通化」とか「テスタビリティ」とかの観点もあるかなぁ、と思うので。
「Model ≒ ORM」なのであれば、ビジネスロジックは「どこかにそれようのディレクトリとか名前空間とか掘って、そこに入れる」とよいんじゃないかなぁ、と。
おいちゃんは「Libs」とかよく使います。

つまり
・Contriollerは、基本的には「Libs」を呼ぶ
・Libsの中で、必要なテーブルに紐付いているModel(群)を呼ぶ
・「ORM使ったりSQL書いたり」は、Modelの中に閉じ込める
ってな感じ。

いやまぁ「ちょっとした処理くらいならControllerに直接書く」でもよいと思うのですが。
さじ加減が出来ない人がいると判断が面倒なので、その辺はチームメンバー(のレベル)とかコードレビューの文化の浸透具合とかと相談しつつ、適宜よしなに。

あと。
「Model ≒ ORM」の場合、Modelの1インスタンスは「1レコード」、1メソッドは「1レコードに対する処理」、1 staticメソッドは「1テーブルに対する処理」的に書いておくと、割と平和でございます。
まぁそうすると「JOINするようなモンはどこに書くのん？」ってなお話になるのですが、主従がはっきりしている関係であれば、主の側に書いておくと割と平和かなぁ、と。

んで。
「Model ≒ ORM がtrue」の時に「ビジネスロジックをModelに実装する」のは、思いっきりお勧めしません。
端的に、例えば「2つとか3つのテーブルを横断的に使うビジネスロジック」があったとして、それ、どのクラスに実装します？ ってなお話になるので。
勿論「無理くり実装」は出来ますが、お勧めは、全くできないかなぁ、と思われます。

次。
「Model ≠ ORM」ってフレームワークは、あんまりないと思うのですが*2。
その場合は「ビジネスロジックをModelに書く」のがコレクトかと思われまして、どちらかというと「んじゃ、データを扱うORM的な立ち位置をどうするの？」ってなお話になって、それを「Modelとは別のクラスに書いた方がいいんじゃね？」とかいうお話になります*3。

あと。ORM自体については https://gallu.hatenadiary.jp/entry/2019/05/08/001034 で書いたので省略(っつかこのために書いたんだしｗ)。

最後に。
時々「ModelがただのSQL置き場になっている」ような実装を見かけまして、個人的には「一番お好まない」かなぁ、と。
本質的には「Modelの1インスタンスは"何を"表してますか？」ってな質問に、20文字以内で帰ってこないんなら「そのクラス設計、間違えてない？」ってとりあえず質問をしたくなる。
あと、基本的には
・ModelでSQL発行している(Model ≒ ORM)んなら、Modelの1インスタンスは「1レコード」であって欲しい
・基本的なSQLくらいは「基底クラスでメソッドが用意されていて、簡単に1行で記述できる」くらいの実装は欲しい
・「「Model ≠ ORM」なら、そもそも「ModelでSQL発行すんな」って思う
ってのがあるかなぁ、と。

おまけ。
・1つのModelクラスで、全然関係ないいろいろなテーブルへのSQLを渾然一体に発行している
のを見た事が数度ありまして、アレについては、殺意しか覚えませんでしたねぇ(苦笑
なので、番外。

ってなわけで。
いやまぁ「どんな実装しようが個人の自由だよねぇ」は勿論あるのですが。
とはいえ現実的に「メンテが厄介な実装」ってのは「後で、他人様の足を引っ張る」ので、おいちゃんとしては大変に「お好まない」かなぁ、と。

その辺を考えた時に、例えばModelであれば「Modelとはなんなのか？ なにを書いて、なにを"書かない*4"クラスなのか？」ってのくらいは、現場毎に違って良いので、せめて「クリアな回答が欲しい」なぁ、とか思うですだす。

んでまぁその一方で「このフレームワークだから、ベースはこんな感じだよねぇ」ってのはあると思うので。
だとするとせめて「ビジネスロジックとORMが渾然一体と混ざり合った「もったりとしてコクがなく*5」な状態のクラスにならなきゃいいなぁ、とか、思ってみたりするです。

*1:「テレビシリーズでの英国版では原作と同様、基本的に「Fat Controller」と呼ばれる」……説明が必要なネタをやるな

*2:MagicWeaponが ≠ でございますちなみに

*3:MagicWeaponだと、data_clumpというクラスが「別のクラス」に相当します

*4:ここ大事

*5: (C)スレイヤーズ