  |
はてなキーワード: モジュールとは
一帯を分離して作り直してるけど
つまりモジュールが抽象的でないことが次々と発覚したり、モジュールがそもそも複雑なため
次々と余計なタスクが発生し
パズルを解いてるようだ
そうだよ。
判別機だけモジュールとして5万円くらいで交換出来る仕組みも、ぜひ実現したらいいと思うよ。
それとは別に、互換性があれば、「偽造技術が追いついて来ない限りは」その5万円さえ不要で、古い券売機を延命して使い続けられるかもしれないよねという話。
偽造技術がいつどんなタイミングで追いついてくるかは、わかんないよ。
偽造技術が追いついたらしぶしぶ更新すれば良いし、その時の費用が5万円で済むなら、それもまた助かる話だよね。
ホログラム無しの福沢諭吉が多くの現場で切り捨てられた時期がわかれば、参考になるかもね。
現行のホログラム付きの福沢諭吉が、今後、いつ切り捨てられるかという推移も、参考にできるかもね。
あなたは「結局20年ごとに機械を(まるごとにせよモジュールにせよ)更新しなきゃならない」と懸念するけど、
だよね？
ラーメン屋は「偽札被害が多発するなどして、経済合理性に基づいた自由な判断でしぶしぶ古い券売機を更新する」時のみ、更新が発生するわけだけど、そのタイミングって結局、
互換性のない現実世界で資金力のある大手チェーンが「偽札被害が多発するなどして、経済合理性に基づいた自由な判断で新型券売機の旧札の対応設定をオフにする(または新札のみに対応する最新券売機に入れ替える)」タイミングと、同じじゃない？
いまいち噛み合ってないけど機械を更新しなければならない結果は変わらない訳で
およそ20年に一度刷新があってその度に100万円する機械は買えないっていうのが現実なのよ
元増田で「レジ担当の人間を雇う」代わりに「人間より維持費の安い機械を先行投資で買う」というトレードオフが語られていないのがそもそもの問題では？
一括やリースで機械を設置する即金が無いならトータルコストが高くてもレジ担当を雇うのがベストエフォートになるはず
通過側で下手に互換性を設けるとそれ自体が脆弱性になることは自明なんだから
逆に紙幣判別機へUSBのような共通規格を制定して安価にモジュール交換できるような法案を設けた方が建設的では？
USBのように接続端子の形状さえ統一しておけばソフトウェア側で吸収できるんだし何十年もかけて紙幣に互換性をとか悠長な話でもなくなる
前提条件を見直した方がいいよ
そもそもの疑問として、札の読み取り機能のコアとなる判定仕様はどこから出てるんだ？
②各読み取り機メーカーが独自に札の特徴を解析して判定仕様に落とし込んでいるのか？
後方互換性を担保するためには完全に①でなくてはならないはずだが、そんな事あり得るか？？
ここと、ここと、ここ、それからこの特徴をクリアすれば本物と判断していいですよ～
現実には、部分的な仕様は公開されている上で、読み取り機メーカーが独自に解析と検証を繰り返して判定仕様に落とし込んでいるのだろう。
そうだとすれば発行側のデザイン上の問題だけで読み取り後方互換性を云々することは不可能だと思うが。
https://b.hatena.ne.jp/entry/4752198473835976704/comment/Knoa
偽札防止の新技術に対応できないのは甘受するとして、新札には読み取り機の後方互換性くらい義務付けてもいいんじゃないか？毎回読み取り機側の特需を経済効果に加算して推進するの悪辣過ぎでしょ。
説明しよう！
まずここで述べている後方互換性というのは、たとえば
こういう仕様にしておいて、スーパーセキュリティチップVer.1にしか対応していない古い券売機でも、スーパーセキュリティチップVer.1だけしかチェックできないものの、新しい1万円札Ver.2もいちおう扱えるという意味だ。一般的な「後方互換性」は「新型機械が古いメディアにも対応する」という意味だが、それとは概念が真逆で、ここでは「新しいメディアが旧型機械にも対応する」という意味だ。この点が誤解を招いたとしたら申し訳ない。
追記: よく考えたら、「ホログラム無しの福沢諭吉から、ホログラムありの福沢諭吉へ(2004年)」って、実質的にここで言う後方互換性を維持した更新だったのでは。あの時は、1000円や5000円は肖像ごと変更になったんで券売機の問題は結局存在していたと思うけど、1000円や5000円もホログラム追加だけに留めておけば、多くの券売機は2004年の刷新を生きのびていたのではないかな。
もちろん、スーパーセキュリティチップなんて仕組みに頼らずとも、もっと簡単な工夫があるかもしれない。あくまで一例だ。それと、旧機械による新札の読み取りを妨げない限り、人間が見分けるための新しい工夫は、いくら追加してくれていてもかまわない。
また、背景にある大きな考えは「新札のたびに機械を入れ替えるなんて、経済資源の無駄遣いだ」と、「それを経済効果としてプラス面だけアピールするのは悪辣だ」という2点である。そういう意味では、たとえば安価なモジュール交換だけで新札対応が済む世の中になるなら、それも好ましい。(既にそうなってるとするブコメもあるのでそれはそうなんだろう。かといって、記事のように高く付く理由もそれなりにあるんだろう(善意の解釈主義)。また、何年も前から予告されていたことだろううんぬんの話も、結局のところ経済資源の無駄遣いの話が前提になる。「いまさら慌てふためく」のがけしからんという話は理解できるが、そもそも機械の入れ替えに無駄な部分があり、もっと効率化できないかという話は、モジュール交換の効率性に置き換えてもらえればわかりやすいが、恒久的に訴え続けてもよいだろう)
ところで、「偽札防止」の観点から後方互換性に懐疑的な意見のブコメもあるが、現状はどうなっているか、もう一度考えてみてほしい。
スーパーセキュリティチップでも、ホログラムでも、透かしでも、なんでもよいのだが、新技術による偽札防止が効果を発揮するのは、あくまで「この券売機は旧紙幣には対応しません」が許されるようになった後の話。当面は、旧札もほとんどの場面で使える。券売機メーカーも、新札発行後にすぐ「旧札に対応した券売機はもう売りません」なんてことにはならない。
もちろん、新札への対応準備は完璧で、券売機も刷新しているだろう。しかし、みすみす旧札のお客さんを切り捨てたくはないので、当面は、旧札にも新札にも対応していくはずだ。じゃあ旧札への対応をやめるのはいつか？それは多くの場合、新規に導入する券売機の最新機種が旧札に非対応になったころだろう。それ以外に旧札を切り捨てる動機と言えば、偽札が横行して、その企業自身が経済合理性に基づいて「旧札対応より偽札被害のほうが大きい」と感じたときだ。(そんな事態が既に起きていて、実はラーメン店も既に相応の被害を出している、という話は聞いたことがない)
スーパーセキュリティチップVer.1しかチェックしない旧券売機さえ騙せればよいので、新しい1万円札Ver.2が流通するようになってからも、「スーパーセキュリティチップVer.1を埋め込んだ、1万円札Ver.1そっくりな偽札」を製造しまくることだろう。
しかし先も述べたように、その偽札は、結局のところ、世の中の券売機が旧札への対応を続ける限り、後方互換性が実現しようがしていまいが、使えてしまうのである。
後方互換性なんて実現してない、現実のこの世の中でも、いまあなたが持っている福沢諭吉の1万円札は、来年も再来年も、新札と旧札の両方に対応した最新型を含む多くの券売機で、使い続けることができるだろう。いまあなたが持っている福沢諭吉の1万円札が、精巧に作られた偽札だったとしても、だ！
ちなみに、ラーメン店に限れば、1000円札にしか対応しない券売機も多く、偽造側の効率面から言っても、現実的な偽札リスクはもともと小さいと言えるだろう。その上で仮に将来500円玉のように偽物が横行すれば(500円玉は韓国ウォンとサイズが一致しただけで、偽造効率の話ではないが)、その時は各企業の判断で「旧札対応より偽札被害のほうが大きい」と感じたときに、しぶしぶ券売機を刷新すればよいのだ。
しかしまあ、こんな心配をするのも、現金がたくさん流通している今だからこそで、次の新札や、そのまた次あたりには、どうでもいい話になっているのかもしれない。
後方互換は世の中の様々な券売機が紙幣のどこを見て判断しているかを把握して網羅的に対応することが求められると思うが、突き詰めると今と同じ紙幣が完成しそうな予感がする。
そう。なので、現実的には「次回の新札から、後方互換性を想定した仕様にします(読み取り機のチェック項目の仕様策定)」という区切りが必要だと思う。その点でもますます、近い将来には「どうでもいい話」になりがちではある。「もっと早くから取り組んでいれば…？」という話でもある。
または、今が過渡期だという前提なら、「今後は現行の福沢諭吉をベースに、追加要素を入れていくだけ」でよかったかもしれない。渋沢栄一を起点にしてもいいけど。んで、お札の人物画像を読み取ってるような古めかしい券売機がほぼ全滅してしまえば、また人物の入れ替えも再開できるだろう。
アジャイルがどうの、ドメイン駆動開発がどうの、マイクロサービスがどうのと、開発プロセスについての情報が巷にあふれている。
しかし勘違いしないほうがいい。あなたの現場にとって最適な方法を追求できるのは、あなたの現場の人間だけだ。
外の世界の「これがうまく行った」論は、文脈を無視しては話にならない。企業Aの文脈と企業Bの文脈が全く別のものであるなら、開発プロセスの成功法則に再現性がないのである。
「開発でこういうことが困っている」ということがあれば、それを列挙するところから始めるべきだ。現場の人間は「問題」がはっきりすれば解決策を考え出すだろう。
「モジュールの独立性について困っている」という話をしているときに、「マイクロサービスとして独立させよう」という情報がググって出てきたら疑ったほうがいい。
100人の凡才より1人の天才の方が生産性が高いから論、これよく言われるけど疑問なんだよなあ。
同じソフトを100個売るのと1000万個売るのでコストがほとんど変わらない。
サービスだともうちょっと事情が違うにしても、そこが圧倒的に違うような。
1人の天才の方が100人の凡人より生産性が高いのが当たり前の世界、ってのは、尖った機能を持ったソフトウエアライブラリや、単機能モジュールなんかは確かにそうだと思う。けど、一定以上の規模があると1人の天才じゃ物理的に対応ができなくなるよね。
例えば、超優秀なAIを開発したとして、それをサービス化するための作業はひとりじゃ無理。天才的能力は必要ないが、時間がかかる仕事は山のように発生する。
だから、ソフトウエアも労働集約型の性質を持っているんだよ。（もちろん例外はある）
そこで、ひとりの天才はソフトウエアアーキテクトは超高給を得られるのは当然としても、それ以外の凡人も他の産業よりも高給になっているのは何故か？
それは、限界費用がゼロに近いからだよ。それで収益力が高いからだよ。
超優秀な1人の生産性が凡人100人に勝るのは、エンジニアリングの世界ではわりと不変的な事で、ソフトウエアに限らないと思う。
その証拠に、数が出ないサービス、フルスクラッチのサービスの制作に従事する人々（増田が言う「SIerとかいうガラパゴスビジネスは労働集約型産業」のやつ）はお給料が安い訳よ。有象無象の中小企業よりはそりゃ出てるけど、大手製造業に比べると見劣りする。
そういったガラパゴスSIerので今何が起こっているかというと、収益力の高いビジネスの影響を受けた、ソフトウエア技術者の人件費高騰と人材不足。
自社はそんな収益力の高いビジネスをできているわけではないのにね。
で、SIerが一品モノの開発ビジネスから脱却して、オファリングだのルマーダだのユーバンスだのもがき苦しんでるってのが最近の話だよな。
従来はパッケージは最小限のモジュールしかなくて、、受注したら各社ごとにカスタマイズして売るって商売だった。そのカスタマイズこそが人月商売で安定した利益が望めるってんで、SE部隊と関連する下請け会社を食わせてたわけだ。各社導入時に必ず追加するような機能までコードを流用せず別開発したりして、それで商売していた。
一方で、人口減少の時代と需要爆発による人材不足に、更にカスタマイズ大杉問題によるシステムの肥大化、各種コスト上昇に加えて、株主に物言う株主、アクティビストが増えて、高収益を求められる時代に。そこで、
に行こうとしているわけだよ。
うまくいってないけどな！
うまくいってないけどな！！
うまくいってないけどな！！！
あと、パッケージ化のしようがなくてフルスクラッチで作り続けなければいけないシステムってのはどうしても存在するのも各社頭痛の種だよな。収益率低くてリスクが高いわりに儲からないし、優秀な若い人ほどやりたがらない。アクセンチュアとかが絶対手を出さない領域。
切りたいけど切れないやつ。
まず前提として、俺はstaticおじさんではない
pythonがメインなので、仕事上でstaticを使ったことはない
しかし前職で巨大なユーティリティモジュールを書く機会があったが、引数にのみ依存していればいい関数しか存在しなかったので、staticを使ったことはある
可視性管理がモジュールじゃなくてクラスに紐づいてる古の欠陥言語の問題であって
モジュールで可視性管理してる現代の言語では obj.method() なんて Obj::method(&obj) の糖衣構文でしかないから、関数は基本全部staticだよね
mathライブラリはあくまでも例だが、引数にのみ依存するツールボックス的な用途でモジュールを作ることはある
pythonであれば単にクラスを使わないで書けば実現できるが、javaで同じことをやろうとするとstaticおじさんのやり方になる
関数型で書けばというが、すでにプロジェクトが「javaを使う」と決まっているときにmathモジュールのようなものを作らなければならないことなど腐るほどあるだろう
「全部がstatic」というのは、分解して考えればあり得るという話
周りがある程度優秀なプログラマーに囲まれててクソコードに遭遇してない
まぁ、幸せな人だと思うな
「どうして人間はこんな愚かな発想でコードを書いてしまうのか」
という感想を持つし、その中でオブジェクト指向が一つの解だと理解する
人間は間違いを犯す生き物で、愚かな発想で愚かなコードを書いてしまう、という前提に立って
間違いにくく間違えることができないようにしよう、というのがオブジェクト指向の目指しているところであって
「プログラムとは何か」みたいなアホみたいなことはこれっぽっちも考えてないよ
ただ、今後生成AIが完全生成までは至らずとも広範囲なサポートができるようになると
コードを簡潔に保つにはモジュール化が必須である。しかし同じモジュールに関係のない機能が含まれていたりすると混乱の元になる。
一方で、関数というのは引数の細かな仕様に依存せずに、汎用的に呼び出せた方が何かと好都合だ。引数になんらかのオブジェクトを渡し、そのオブジェクトしか持ち得ないような特殊な情報で処理を行なったりすると、関数とオブジェクトが互いに依存しあってしまう。
これはモジュールの結合度と呼ぶ。
高い凝集度、低い結合度によってモジュールを作れば、保守性は上がる。
さらにモジュール内では、公開する必要のない関数はprotectedまたはprivateにするべきだ。
そのためにはモジュールが公開すべき関数についてインターフェイスを作り、公開関数に対するユニットテストを書いておくのが良いだろう。
