先ほども申し上げたように、日本人は「みんなのため」と言われるとおとなしく従う傾向がある。しかも、「組織のルール」にも従順だ。つまり、「みんなのためにクマ駆除に協力してください。報酬は日当8500円。これは町で決めたルールなのでご了承ください」と高圧的に要求をすれば、ハンターの皆さんも「安いな」「やってられねえよ」と愚痴りながらも従ってくれる、と踏んだのだ。
なぜヒグマ駆除が「日当8500円」なのか 背景に、働く人の責任感に甘えすぎる問題：スピン経済の歩き方（4/7 ページ） - ITmedia ビジネスオンライン
⇧ 殺されるかもしないリスクの高い作業に見合う報酬とは程遠い気はしますな...
挙句の果て、
ヒグマ駆除をめぐっては、北海道砂川市で’18年8月に市職員と警察官の立ち会いのもと、市に依頼されてヒグマを駆除したハンターの男性が、“銃弾が住宅に届く恐れがあった”として道公安委員会から猟銃所持の許可を取り消された。これによって同市で30年以上、保護や駆除を担ってきたベテランハンターは、引き金を引けなくなった。
⇧ 善意を踏み躙るような扱いを受けるんだから、協力する義理はないという結論になるのは至極真っ当で、猟友会側が行政の要請を受け付けない判断に至るのは当然ですな。
普通に考えて、住民を退避させたりして、ハンターが作業に集中できる環境を用意するのは、行政側の責任ですべきことの気がしますけどね。
「万里の長城」じゃないですが、ヒグマを隔離する「防壁」を行政側の負担で構築すれば良いんじゃないですかね。
「ゼロトラスト・セキュリティモデル」のように「決して信用せず、常に検証せよ」的な対応は不可能だと思いますし、居住エリアに侵入させない方針で検討するしかないんじゃないですかね？
以下についての正確な統計が無いので、何とも言えませんが、
- 羆（ヒグマ）
- 総生息数の推移
- 年齢層でグループした数の推移
- ハンター
- 総数の推移
- 年齢層でグループした数の推移
- 経験年数でグループした数の推移
「羆（ヒグマ）」が「人間」の居住エリアに侵入する頻度が増えていくのであれば、「羆（ヒグマ）」と「人間」の活動エリアを分断するしか無く、「羆（ヒグマ）」と「人間」は話し合いができない以上、「羆（ヒグマ）」が「人間」側の居住エリアに侵入できないように「人間」側が物理的に「防壁」を構築するしか無さそうなんよね...
仮に、「防壁」を構築する場合、「防壁」には、
- 「羆（ヒグマ）」の攻撃で摩耗しない
- 経年劣化しにくい
「耐久性」が求められるわけですが、2012年頃の情報に、
先週の発表によると、遺跡の集落周辺から、高さ3メートル、厚さ1.8メートルの石壁が見つかったという。
⇧ という6500年前のものとされる遺跡の発見の話があり、長期的に機能させるには、シンプルに石壁とかが良いんですかね？
工期やコストがどれぐらいになるのか分かりませんが、環境破壊にならないように計画をして、公共事業として進めたりできれば、雇用も生まれるし良い気はしますが。
「羆（ヒグマ）」は立ち上がると、3mぐらいになるらしいので、「防壁」の高さは10mぐらいにしておけば良いのかね。
まぁ、「資源」を「お金」の力でどうにかできる状況である前提ではありますが、結局のところ「お金」の問題に行き着くと...
OWSAPのWeb Applicationのチェックリストでも「Validate All Inputs」とあるので
「OWSAP」とは？
The Open Worldwide Application Security Project(OWASP) is an online community that produces freely available articles, methodologies, documentation, tools, and technologies in the fields of IoT, system software and web application security.
The OWASP provides free and open resources. It is led by a non-profit called The OWASP Foundation. The OWASP Top 10 - 2021 is the published result of recent research based on comprehensive data compiled from over 40 partner organizations.
⇧ ソフトウェア開発におけるセキュリティを啓蒙する組織といった感じかと。
で、「Web Application」について、
⇧ 10個のチェックリストを提唱しているのだが、その内の1つが、
『Validate All Inputs』
ということで、『全ての入力について検証しろ。絶対にだ。』と。
まぁ、ニュアンスが難しいのですが、By the way、
絶対に家族の敵の側になんか立つな。絶対にだ。
⇧ エンターテインメントの世界でも、言語が異なると解釈に困ることが多いと。
そして、IT技術に関するのドキュメントの多くは、欧米圏の言語で発信されていることが多いからして、解釈が困難になるのは必然といった感じでしょうかね。
言葉を読み解くというのは難しいということですな。
Pythonのdecorator（デコレータ）とは
公式のドキュメントによりますと、
⇧ とあるように、「@」が付いているものが「デコレータ」になるんかね？
「Java」で言うところの「アノテーション」のようなものか？
ネットの情報を漁っていたところ、
⇧ 上記サイト様が解説して下さっておりました。
Pythonのメソッドの引数のチェックはdecorator（デコレータ）を使うのが良さそうか
で、ソフトウェア開発において、Webアプリケーションとかで身近な入力というと、
- メソッドの引数
が挙げられるとかと。
アプリケーションで、メソッドが1つも無いということは無いと思いますし...
で、
SOLID（ソリッド）は、ソフトウェア工学の用語であり、特にオブジェクト指向で用いられる五つの原則の頭字語である。ソフトウェア設計をより平易かつ柔軟にして保守しやすくすることを目的にしている。その特徴はインターフェースを仲介にしての機能の使用と、インターフェースによる機能の注入である。
五つの原則
SOLIDは、次の5つの原則からなる。
⇧とあり、可能な限り、処理は分割される傾向にあるので、当然のことながらメソッドの数も増えていくことになりますと。
そうなってくると、メソッドの数だけ、「引数のチェック処理」が必要になりますと。
で、愚直に「引数のチェック処理」を実装していくと、所謂、「ボイラーテンプレート」と言われる問題が出てきてしまうと。
ボイラープレートコード (英: boilerplate code、または単にボイラープレート) は、コンピュータプログラミングでは、殆ど、または全く変化することなく、複数の場所で繰り返される定型コードのセクションのこと。冗長な言語を使用する場合、プログラマーはコードを少しだけ書くだけでも多くのコードを作成する必要がある。このような定型コードはボイラープレートと呼ばれる。
とは言え、プログラミング言語によっては、「ボイラーテンプレート」不可避となることも致し方ないとは思うのだけど、「Python」においては、
⇧「decorator（デコレータ）」という仕組みを利用する感じにすれば、「ボイラーテンプレート」を回避できると。
「decorator（デコレータ）」を適用した場合の処理順序は、
⇧ 上記サイト様の説明がイメージし易いかと。
「インターセプト」してるような感じなんかね？
上図で言うところの「decorator（デコレータ）」内の「5」の「func()」の実行した以降に処理を追加すると「myFunc()」実行後に処理を実行できると。
「戻り値」のあるメソッドに対して、「戻り値」に対してチェックしたいのであれば、「decorator（デコレータ）」内で、「5」の「func()」の実行した以降にreturnする前に処理を追加すれば良いと。
ちなみに、
⇧ 型のチェックの話が盛り上がっているが、引数がnullの場合とかの考慮については言及がされていないように見えてしまうんだが、Pythonにおいては、『Validate All Inputs』は厳密に気にしなくても構わないような些細なことなんだろうか？
「Pydantic」とかでは、
⇧「decorator（デコレータ）」使ってはいるみたいですけど...
*argsと**kwargsは、Pythonにおける可変長引数ということらしい
で、「引数のチェック」の処理を「decorator（デコレータ）」に委譲させた場合に、「decorator（デコレータ）」の実装に出てくる、
- *args
- **kwargs
は何者なのか？
Pythonプログラミングにおいて、*argsと**kwargsは非常に強力かつ柔軟な機能です。これらを使用することで、関数やメソッドに可変長の引数を渡すことができ、より汎用的で再利用可能なコードを書くことができます。
Python *args と **kwargs の正体：可変長引数を使いこなして柔軟な関数を作ろう #Python - Qiita
⇧ 上記サイト様がまとめて下さっておりますが、Pythonにおける「可変長引数」のことらしい。
公式のドキュメントによると、
⇧「可変長引数」という言葉は出て来ないのだが、忖度しろということっぽいですな。
で、名前も
- *args
- **kwargs
にする必要は無いらしく、重要なのは引数の順番だけっぽい。
つまり、名前は、
- *＊＊＊＊＊
- **＊＊＊＊＊
⇧ のように「＊」の部分は何でも良いということかと。
引数の順番については、「**＊＊＊＊＊」は引数の最後に指定し、「*＊＊＊＊＊」は最後から2番目に指定となる感じになると。
勿論、「**＊＊＊＊＊」を利用しない場合は、「*＊＊＊＊＊」が最後になるということだと思われる。
整理すると、
| No | 一般的な命名 | 命名規則 | 引数の位置 | 備考 |
|---|---|---|---|---|
| 1 | *args | 先頭に*が付いていれば何でも良い※1 | ※2 | 実行時に引数名は渡せない |
| 2 | **kwargs | 先頭に**が付いていれば何でも良い※1 | 最後 | 実行時に引数名を渡せる |
※1 ただし、Pythonの「予約語」とかには被らない方が良いと思われる、多分...
※2 「**kwargs」と併用の場合は、最後から2番目。「**kwargs」を利用していない場合は最後に位置する。
⇧ このあたりの用語になる模様。
で、「**＊＊＊＊＊」の方については、
⇧ Pythonのバージョン3.11以前でバグが存在したらしい...
う～む、Python 3.12を利用しておけば心配ないのだろうか？
それとも、まだ不具合が残存しているのだろうか？
とは言え、「メソッドの引数チェック」の処理は「decorator（デコレータ）」で済ませてしまいたいんだが...
汎用的にチェックできる部分となると、
- Noneで無いかのチェック
- str型の場合に空文字じゃないか
ぐらいになるのかね？
ただ、「空文字」については、許容したいとか、そもそも、条件付きでnullを許容したいとか、って要件が出てくると、面倒くさいことになってくるのよね...
まぁ、メソッドの数が減ることよりも増えていくことの方が多い気がするので、「decorator（デコレータ）」で解決できるのであれば、「decorator（デコレータ）」を採用したいというのが素直なお気持ちでしょうかね。
「メソッドの引数チェック」の領域においては、問答無用で、「null」や「空文字」は許容しないにさせて欲しいのだけど、外部からのリクエストのボディ部で非必須な項目については、何も設定されないことが有り得るので、辛いところですな...
かと言って、リクエストのボディ部で非必須な項目について、キー自体を削除すると、「JSON」からオブジェクトに変換する際などにおいてややこしいことになってくるので、頭を抱えたくなる...
ちなみに、「OWSAP」によると、
⇧「ライブラリ」や「フレームワーク」の機能に任せてしまえ、とありますな...
そして、個別対応を頑張ってね、ということらしい...
まぁ、結局、煩雑にならざるを得ないってことね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
