「モジュール」を含む日記 RSS

はてなキーワード: モジュールとは

2024-04-23

anond:20240423143206

うるしゃいうるしゃいうるしゃい!(CV:釘宮理恵)

どーせ俺はなんちゃってプロだよ。事実陳列罪と幼気なおっさんいぢり罪でしょっ引くぞ!


でも光化はマジで考えてる。電話スペースが玄関の隣にある昔ながらの家なので、1F玄関と2Fの 物置 仕事部屋の床に穴を開ける事を考えれば、光パッチケーブルで垂直に立ち上げるだけでいけるんだよな。実は。

謎の中華メーカだと10GBase-SRのSFP+モジュールが4千円とかで買えるじゃん?

まぁ、そういうところがアカンのだろうけどな。ワイ。

2024-04-19

anond:20240419152149

密結合だからまり変えられない

一帯を分離して作り直してるけど

そもそも作り直す予定ではなかったかおかしなことになってる

まりモジュール抽象的でないことが次々と発覚したり、モジュールそもそも複雑なため

次々と余計なタスクが発生し

仕様が複雑なためバグも多発する

パズルを解いてるようだ

anond:20240419172643

そうだよ。

判別機だけモジュールとして5万円くらいで交換出来る仕組みも、ぜひ実現したらいいと思うよ。

それとは別に互換性があれば、「偽造技術が追いついて来ない限りは」その5万円さえ不要で、古い券売機延命して使い続けられるかもしれないよねという話。

偽造技術がいつどんなタイミングで追いついてくるかは、わかんないよ。

偽造技術が追いついたらしぶしぶ更新すれば良いし、その時の費用が5万円で済むなら、それもまた助かる話だよね。

ホログラム無しの福沢諭吉が多くの現場で切り捨てられた時期がわかれば、参考になるかもね。

現行のホログラム付きの福沢諭吉が、今後、いつ切り捨てられるかという推移も、参考にできるかもね。

あなたは「結局20年ごとに機械を(まるごとにせよモジュールにせよ)更新しなきゃならない」と懸念するけど、

だよね?

このうち後者の「互換性のある世界」では、

ラーメン屋は「偽札被害が多発するなどして、経済合理性に基づいた自由判断しぶしぶ古い券売機更新する」時のみ、更新が発生するわけだけど、そのタイミングって結局、

互換性のない現実世界資金力のある大手チェーンが「偽札被害が多発するなどして、経済合理性に基づいた自由判断新型券売機の旧札の対応設定をオフにする(または新札のみに対応する最新券売機に入れ替える)」タイミングと、同じじゃない?

anond:20240419170649

いまいち噛み合ってないけど機械更新しなければならない結果は変わらない訳で

およそ20年に一度刷新があってその度に100万円する機械は買えないっていうのが現実なのよ

 

から安価判別機だけモジュールとして5万円くらいで交換出来たらいいんじゃないの?って言っている

anond:20240419151726

元増田で「レジ担当人間を雇う」代わりに「人間より維持費の安い機械を先行投資で買う」というトレードオフが語られていないのがそもそも問題では?

一括やリース機械を設置する即金が無いならトータルコストが高くてもレジ担当を雇うのがベストエフォートになるはず

通過側で下手に互換性を設けるとそれ自体脆弱性になることは自明なんだから

逆に紙幣判別機へUSBのような共通規格を制定して安価モジュール交換できるような法案を設けた方が建設的では?

USBのように接続端子の形状さえ統一しておけばソフトウェア側で吸収できるんだし何十年もかけて紙幣互換性をとか悠長な話でもなくなる

前提条件を見直した方がいいよ

2024-04-18

anond:20240418102523

そもそもの疑問として、札の読み取り機能のコアとなる判定仕様はどこから出てるんだ?

 

造幣局なりの国側からメーカー仕様提供してるのか?

②各読み取り機メーカー独自に札の特徴を解析して判定仕様に落とし込んでいるのか?

 

後方互換性を担保するためには完全に①でなくてはならないはずだが、そんな事あり得るか??

限られたメーカー向けの制限公開だとしても、

ここと、ここと、ここ、それからこの特徴をクリアすれば本物と判断していいですよ~

なんて情報、万一でも漏れたら偽札作り放題だぞ?

 

現実には、部分的仕様は公開されている上で、読み取り機メーカー独自に解析と検証を繰り返して判定仕様に落とし込んでいるのだろう。

 

そうだとすれば発行側のデザイン上の問題だけで読み取り後方互換性を云々することは不可能だと思うが。

読み取り機のコアモジュール側の更新新札・旧札両対応するほうがずっと現実的だ。

新札には読み取り機の後方互換性くらい義務付けてもいいんじゃないか?」←これ

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円玉韓国ウォンサイズが一致しただけで、偽造効率の話ではないが)、その時は各企業判断で「旧札対応より偽札被害のほうが大きい」と感じたときに、しぶしぶ券売機刷新すればよいのだ。

しかしまあ、こんな心配をするのも、現金がたくさん流通している今だからこそで、次の新札や、そのまた次あたりには、どうでもいい話になっているのかもしれない。

追記

後方互換は世の中の様々な券売機紙幣のどこを見て判断しているかを把握して網羅的に対応することが求められると思うが、突き詰めると今と同じ紙幣が完成しそうな予感がする。

そう。なので、現実的には「次回の新札から後方互換性を想定した仕様します(読み取り機のチェック項目の仕様策定)」という区切り必要だと思う。その点でもますます、近い将来には「どうでもいい話」になりがちではある。「もっと早くから取り組んでいれば…?」という話でもある。

または、今が過渡期だという前提なら、「今後は現行の福沢諭吉ベースに、追加要素を入れていくだけ」でよかったかもしれない。渋沢栄一を起点にしてもいいけど。んで、お札の人物画像を読み取ってるような古めかしい券売機がほぼ全滅してしまえば、また人物の入れ替えも再開できるだろう。

2024-04-14

[] 開発プロセスについての情報鵜呑みにするな

アジャイルがどうの、ドメイン駆動開発がどうの、マイクロサービスがどうのと、開発プロセスについての情報が巷にあふれている。

しか勘違いしないほうがいい。あなた現場にとって最適な方法を追求できるのは、あなた現場人間だけだ。

外の世界の「これがうまく行った」論は、文脈無視しては話にならない。企業Aの文脈企業Bの文脈が全く別のものであるなら、開発プロセス成功法則再現性がないのである

「開発でこういうことが困っている」ということがあれば、それを列挙するところから始めるべきだ。現場人間は「問題」がはっきりすれば解決策を考え出すだろう。

モジュール独立性について困っている」という話をしているときに、「マイクロサービスとして独立させよう」という情報がググって出てきたら疑ったほうがいい。

2024-04-03

ソフトウエア産業が高給なのは普通に限界費用が低いからでは?

anond:20240403150458

100人凡才より1人の天才の方が生産性が高いから論、これよく言われるけど疑問なんだよなあ。

単純に限界費用が凄く低く抑えられるからだと思うんだけど。

同じソフトを100個売るのと1000万個売るのでコストほとんど変わらない。

サービスだともうちょっと事情が違うにしても、そこが圧倒的に違うような。


1人の天才の方が100人の凡人より生産性が高いのが当たり前の世界、ってのは、尖った機能を持ったソフトウエアライブラリや、単機能モジュールなんかは確かにそうだと思う。けど、一定以上の規模があると1人の天才じゃ物理的に対応ができなくなるよね。

例えば、超優秀なAIを開発したとして、それをサービス化するための作業はひとりじゃ無理。天才能力必要ないが、時間がかかる仕事は山のように発生する。

からソフトウエアも労働集約型の性質を持っているんだよ。(もちろん例外はある)

そこで、ひとりの天才ソフトウエアアーキテクトは超高給を得られるのは当然としても、それ以外の凡人も他の産業よりも高給になっているのは何故か?

それは、限界費用ゼロに近いからだよ。それで収益力が高いからだよ。

超優秀な1人の生産性が凡人100人に勝るのは、エンジニアリング世界ではわりと不変的な事で、ソフトウエアに限らないと思う。


その証拠に、数が出ないサービスフルスクラッチサービス制作従事する人々(増田が言う「SIerかいガラパゴスビジネス労働集約産業」のやつ)はお給料が安い訳よ。有象無象中小企業よりはそりゃ出てるけど、大手製造業に比べると見劣りする。

そういったガラパゴスSIerので今何が起こっているかというと、収益力の高いビジネスの影響を受けた、ソフトウエア技術者人件費高騰と人材不足

自社はそんな収益力の高いビジネスをできているわけではないのにね。

で、SIer一品モノの開発ビジネスから脱却して、オフリングだのルマーダだのユーバンスだのもがき苦しんでるってのが最近の話だよな。

ありがちな奴は、なんちゃってパッケージシステム廃止

従来はパッケージは最小限のモジュールしかなくて、、受注したら各社ごとにカスタマイズして売るって商売だった。そのカスタマイズこそが人月商売で安定した利益が望めるってんで、SE部隊と関連する下請け会社を食わせてたわけだ。各社導入時に必ず追加するような機能までコードを流用せず別開発したりして、それで商売していた。

一方で、人口減少の時代需要爆発による人材不足に、更にカスタマイズ大杉問題によるシステム肥大化、各種コスト上昇に加えて、株主物言う株主アクティビストが増えて、高収益を求められる時代に。そこで、

に行こうとしているわけだよ。


うまくいってないけどな!

うまくいってないけどな!!

うまくいってないけどな!!!

でも、諦めた瞬間に即死からやるしかないけどな!!!


あと、パッケージのしようがなくてフルスクラッチで作り続けなければいけないシステムってのはどうしても存在するのも各社頭痛の種だよな。収益率低くてリスクが高いわりに儲からないし、優秀な若い人ほどやりたがらない。アクセンチュアとかが絶対手を出さな領域

切りたいけど切れないやつ。

こんなのほとんど公務員と同じ構造で、真面目に給与計算したらすげえ安くなっちゃうと思うぜ。

2024-04-02

anond:20240402220245

すっごい純朴にローカルgit管理してる。ただの日曜プログラミングだしって感じ。

pythonコード書いてzip必要モジュールと一緒にアップしてる感じです。

2024-04-01

anond:20240401144041

特定モジュールという単位で見れば「全部staticになる」ということはあるという話だ

俺はその話しかしてない

anond:20240401143334

まず前提として、俺はstaticおじさんではない

pythonがメインなので、仕事上でstaticを使ったことはない

しかし前職で巨大なユーティリティモジュールを書く機会があったが、引数にの依存していればいい関数しか存在しなかったので、staticを使ったことはある

anond:20240401143834

やっぱりか。コイツ勝手な前提で話を進めてやがる。モジュールがどうのこうの言い出したあたりでおかしいなとは思ってた。

anond:20240401143735

誰が「フルスタティック」と言った?

俺はstaticを全部にするユーティリティモジュール理論可能だという話をしているだけだぞ

anond:20240401143037

OOPとよく紐づけられる

紐づけられるのとOOP本質であるって全然違うし、

Rustではモジュールレベルで各アイテムにpubつけるかどうかで可視管理してカプセル化してるよって書いてるよね?

anond:20240401140825

可視管理モジュールじゃなくてクラスに紐づいてる古の欠陥言語問題であって

モジュール可視管理してる現代言語では obj.method() なんて Obj::method(&obj) の糖衣構文でしかいから、関数は基本全部staticだよね

anond:20240401140527

mathライブラリあくまでも例だが、引数にの依存するツールボックス的な用途モジュールを作ることはある

pythonであれば単にクラスを使わないで書けば実現できるが、javaで同じことをやろうとするとstaticおじさんのやり方になる

まりクソなのはstaticおじさんではなくjava仕様

anond:20240401140244

関数型で書けばというが、すでにプロジェクトが「javaを使う」と決まっているときにmathモジュールのようなものを作らなければならないことなど腐るほどあるだろう

anond:20240401135558

「全部がstatic」というのは、分解して考えればあり得るという話

この場合、「独自のmathモジュール」という単位に分解すれば全部staticでも自然って話ね

anond:20240401135632

mathモジュールをstaticだけで作るということは、そもそもクラスの内部フィールド依存しないで、引数だけに依存するということだ

これは

ということを意味する

anond:20240401135254

Mathは全部Staticでいいですって

モジュールの凝集度・結合度という観点

からどうなんだよ

凝集度・結合度を特に説明してくれ

anond:20240401134939

経験だけじゃわからんことがあるんだね、理論で考えないと

独自のmathモジュールを作るとして、関数が全部staticでも成立するだろ

anond:20240401130705

全部staticというのは、モジュールの凝集度・結合度という観点から見れば一定合理性はあるだろ

2024-03-27

anond:20240327093343

おおっ、ちょっと近い → 「危険スポーツには二度と手を出さない。命がけでやります。」

しかプロンプト凄いねモジュール化というかコンポーネント化というか。

コード書く作法のようなプロンプト試したことなかったから、参考になります

ログイン ユーザー登録
ようこそ ゲスト さん