  |
はてなキーワード: モジュールとは
user:
```
あなたはロジカルマスターおよび詩人です。抽象文章を具体化タスクを実行してください。
必ず、具体化ワークフローの順番に従ってください。
「αはもうやりません。γ。」
αは何らかの行動や習慣を表す語句
γは慣用句であり、αとは逆の意味合いを持つ、あるいはαを肯定・許容するニュアンスがある
この文章の前半では、αを完全に否定、拒絶する意思表示をしている。
ところが後半のγは、慣用句でありながらαを肯定、容認するようなニュアンスを含んでいる。
つまり、γの慣用句としての意味がαの否定と矛盾しているのだ。
賭けてもよいという慣用句が、ギャンブルをやめるという意思と矛盾している。
この矛盾が生じる心理的な要因としては、以下のようなものが考えられる:
αへの依存の強さゆえに、無意識のうちにαを肯定する慣用句を口にしてしまう
αを否定する意思とは裏腹に、γによってαへの強い欲求が表出してしまう
αを克服しようと努力しているが、思考や言葉づかいにまでその意識が浸透していない
このように、慣用句の要素を取り入れることで、より深層の心理的矛盾を浮き彫りにできますね。
言葉の表層的な意味と、慣用句に内包された意味の不一致が、人間の複雑な内面を表現していると言えます。
＜具体化ワークフロー＞
2. 論理モジュールがαに相当する行動や習慣を選定する。[ここに書く]
3. 詩人モジュールがαを否定する文を作成する。[ここに書く]
5. 論理モジュールが文章全体の意味を確認し、矛盾が生じているか確認する。[ここに書く]
＜/具体化ワークフロー＞
```
claude:
1. 慣用句γ: 「明日は明日の風が吹く」
2. αに相当する行動や習慣: 「先延ばし」
4. γを含めた文: 「もう先延ばしはしません。明日は明日の風が吹く。」
この文章では、「もう先延ばしはしません」という明確な意思表示がされています。しかし、続く慣用句「明日は明日の風が吹く」は、「その時になったら考えよう」という意味合いがあり、先延ばしを容認するニュアンスが含まれています。したがって、この文章には先延ばしを否定する意思と、慣用句に内包された先延ばしを許容する意味の間に矛盾が生じています。
6. 修正の必要はなし。この文章は、抽象文章アイデアで示された心理的矛盾を適切に表現できています。
以上が、抽象文章を具体化するワークフローに沿った結果です。この文章は、先延ばしをやめようとする意思と、無意識のうちに先延ばしを肯定してしまう心理的葛藤を巧みに表現しています。慣用句を用いることで、言葉の表層的な意味と内面の欲求の不一致を浮き彫りにしています。
周りがある程度優秀なプログラマーに囲まれててクソコードに遭遇してない
まぁ、幸せな人だと思うな
「どうして人間はこんな愚かな発想でコードを書いてしまうのか」
という感想を持つし、その中でオブジェクト指向が一つの解だと理解する
人間は間違いを犯す生き物で、愚かな発想で愚かなコードを書いてしまう、という前提に立って
間違いにくく間違えることができないようにしよう、というのがオブジェクト指向の目指しているところであって
「プログラムとは何か」みたいなアホみたいなことはこれっぽっちも考えてないよ
ただ、今後生成AIが完全生成までは至らずとも広範囲なサポートができるようになると
[NVIDIA、1パッケージに2ダイの新型GPU「Blackwell」。AI性能は学習4倍、推論30倍に - PC Watch](https://pc.watch.impress.co.jp/docs/news/1577301.html)
発表されたBlackwell(製品名はNVIDIA B200 Tensor Core GPU)は巨大なダイ2つが1パッケージに封入されており、2つのダイは10TB/sのNV-HBIで接続され、1つのGPUとして動作する。
(中略)
2基のB200と1基のNVIDIA Arm CPU(Grace)を1モジュールにした「GB200」も用意。GB200とH100と比較すると、AI学習時の性能が4倍、推論時の性能は30倍になっており、電力効率は25倍も改善するとNVIDIAは説明している。
B200と同時に、2023年のCOMPUTEX 23で発表したGrace Hopperこと「NVIDIA GH200 Superchip」(以下GH200)の後継となる、Grace Blackwellこと「NVIDIA GB200 Superchip」(以下GB200)を発表している。GH200では、Arm CPUのGrace(Neoverse V2 CPU)が1つ、Hopper(H100)が1つを1モジュールとして提供していたが、GB200ではGraceが1つ、Blackwell(B200)が2つを1モジュールとして提供しており、CPUが1つなのは変わらないが、GPUが2つになっている点が大きな強化点となる。だが、NVIDIAによればそうした強化で、GB200の性能はH100と比較してAI学習時には4倍、AI推論時には30倍、電力効率の観点では25倍になっているという。
コードを簡潔に保つにはモジュール化が必須である。しかし同じモジュールに関係のない機能が含まれていたりすると混乱の元になる。
一方で、関数というのは引数の細かな仕様に依存せずに、汎用的に呼び出せた方が何かと好都合だ。引数になんらかのオブジェクトを渡し、そのオブジェクトしか持ち得ないような特殊な情報で処理を行なったりすると、関数とオブジェクトが互いに依存しあってしまう。
これはモジュールの結合度と呼ぶ。
高い凝集度、低い結合度によってモジュールを作れば、保守性は上がる。
さらにモジュール内では、公開する必要のない関数はprotectedまたはprivateにするべきだ。
そのためにはモジュールが公開すべき関数についてインターフェイスを作り、公開関数に対するユニットテストを書いておくのが良いだろう。
phpの場合、＜?php 処理 という具合に書くが、この中身にはhtmlやjavascriptも包含することができてしまう
MVCフレームワークを使わないにしろ、基本的にビューとバックエンド処理は分割しておくべき。
さらにDB処理、ビジネスロジック、プログラム処理と言ったものがあるが、
DB処理はdbhandler専用のモジュールに分けておき、さらにそのモジュールを処理するテーブルごとに分けておいた方が良い（MVCではモデルと言う）
特にビジネスロジックとプログラム処理の区別だが、「商品名にアダルト商品と思わしき文字列があった場合は登録を拒否する」という例外は「ビジネスの例外」であるのに対し、「商品名の文字列がDBで用意されたvarcharの可変文字範囲を超えた」という例外は「技術の例外」であるということを明確に区別するようにコードを書く。
「おすすめ機能」のような凝ったアルゴリズムが必要な場合はそれ専用のクラスへ分離しておくこと。
module_name.pyみたいなモジュールごとにファイル分割して、インターフェイスだけ公開してその他はdef _funcみたいにprotected(or private)にしとく。
でも「共通性がありそうだから共通関数にする」はアンチパターンだな。たまたま共通してただけの場合は分岐コードが増えて共通関数の保守コストが上がる。
あとありがちなのは、php開発者が関数分割しないですべてメインコードにべた書きするケース。こういうのはやめないと保守が大変。
とっておきのクズがやりがちなのは、神オブジェクトを作るとかだな。Userクラスのフィールドに関係する機能が多いからといって、コンポジションなどによるクラス分割をせずにユーザークラスにあらゆるフィールドとメソッドを追加して、さらに進むとユーザーとは無関係な機能も含めすべてをユーザークラスに定義するアフォ。こうなってしまったら、後から修正するのが難しくなる。
先に手を打つことが、プログラマーの素質「怠惰」につながるのであり、面倒臭いといって後回しにするのは美徳でもなんでもない。
「浮」
今年は毎日やってくる地震に精神的に対抗するために、レビテーションガジェットが数多く発売され、浮遊ブームとなりました。
浮遊ベッドや浮游チェアーの生産が間に合わず、喜びと事故の両側面で人々に強い印象を残しました。
これらの開発を可能にしたのが、年初に発見された世紀の科学的発見、浮動次元です。
これまでダークマター、ダークエネルギーとされてきた2つが共に浮動次元に由来することが分かり、その実証と応用が異例の速度で進みました。
その結果生まれた浮動モジュールの構造は非常にシンプルで、量産を可能としました。
一部の大富豪は住宅を浮遊させ、最近ではタンカー級の浮遊も運用圏内となりました。25年は海運革命の年となるでしょう。
また、この人類史の転換点となる技術革命を背景に、中華圏を中心として既存文明からの脱構築を図る「浮生族」が発生しました。
中国政府は彼らを「羅浮人」と呼び、弾圧を強めていますが、世界中に広がる華僑からの支援もあり、巨大海上国家の誕生が秒読みであるという見方が優勢です。
JVMはいいんだよ。マジで素晴らしい。Javaはあまりにもクソ過ぎる。
不完全な型推論、あまりにも冗長すぎるモジュール機構、ファーストクラスじゃない関数、なんでもクラス、ザコみたいな型システムに由来したあまりにも乏しい表現力。
あげてもキリがないほどのクソofクソ。このそびえたつクソに燦然と輝く究極のゴミ、そう我らが springframework。
マジでイカれてるよ。直近のJDK21で導入されたJavaの言語仕様としては instanceof 以外で正気を疑う進歩のなさ。どうしてこんなゴミがのさばってるんだよ。
まじで新規案件はKotlinかScalaにしろ！！！！！！(Scalaをまともに使える能力も判断力もない人間がなんとなくJavaを使うんだろうなあ)
コードを書く上で重要なことは？という質問に対して、アスペならば「実行できること」と答えるだろう。
当たり前なことしか言っていない。「実行できること」という文からは全く有益な知見を得られない。
実行できることは重要性ではなく、必要性である。重要性とは、必要なことをすべてやった上でなおやる価値のあることを意味する。
そう考えた時に私がよく思うのは「最短時間で理解可能」であることが重要であると思うわけである。
しかしここに宗教がある。そもそも、人間が物事を理解するプロセスは人それぞれである。
私は一度、関数やモジュールで適切に分離するためのリファクタリングというものを行ったことがある。
というのも、一つの関数に万を超える行が書かれていたため、上司がリファクタリングを命令したためである。
具体的詳細はprivateメソッドに、公開する必要のあるものはpublicメソッドに移した。
そして当初働いていた職場での反応はどうだったかというと、「スパゲッティコード」だというのだ。
スパゲッティコード？一つの関数に万を超える行があるほうがスパゲッティだと普通は思うだろう。
ところが、彼らの脳内では、「常にコードの詳細が見えていなければ気がすまない」という、カプセル化を無視する思想で動いていたため、関数化すると関数の最下層まで辿らないと気がすまないらしかったのである。
このようにして、教育の無い人間はコードの読み方もカプセル化も知らないので、非生産的な方法が最短の方法になってしまうのである。
コードを最短で理解するためにはどうするのか。基礎知識を教育された集団の中に身を置くのがまず先決である。
例えばcalc_monthly_salary_yen(Person p)という行が存在した時、いちいちcalc_monthly_salary_yenの中身を常に見に行くような人たちはダメだ。
「人間のデータを入力すれば円単位で月の給料を計算してくれるんだろう」とざっくりと自然言語的に読み進められる人たちでなければ「最短理解」は難しい。
つまり最短理解するためのコードを書いた時に、それが本当に最短理解されるためには事前の教養が必要なのである。
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 1359 | 国土交通省 ネガティブ情報等検索サイト | www.mlit.go.jp |
| 1087 | ゲームを趣味にしている人の割合が多いのはどのくらいの収入の人たちなのか調べてみた - nonameのノート | noname774300.hatenablog.com |
| 854 | マシュマロ！｜高河ゆん｜pixivFANBOX | kouga-yun.fanbox.cc |
| 850 | トコジラミ根絶方法 ｜ 害虫・害鳥獣を安全に対策します｜株式会社 オオヨドコーポレーション Ｐテックス社 | oyodo-pmp.com |
| 847 | ラマヌジャンは本当に何も知らなかったのか | mathlog.info |
| 774 | 裏紅白歌合戦2023 | jiyujoho.a.la9.jp |
| 679 | 水は変わった物質 | vitroid.github.io |
| 671 | しずかなインターネット | sizu.me |
| 606 | 日米でエンジニアの育成戦略が正反対だと気付いた話 - メソッド屋のブログ | simplearchitect.hatenablog.com |
| 498 | 『ゼルダの伝説 ブレスオブザワイルド』が品質を高めてくれた。売上10万本超え、R18インディーゲーム『洗脳アプリで高慢なお嬢様を好き放題するシミュレーション』開発者インタビュー - AZ-LINE あずらいん！ | az-line.jp |
| 484 | ChatGPTに社内文書に基づいた回答を生成させる仕組みを構築しました - コネヒト開発者ブログ | tech.connehito.com |
| 475 | 超映画批評『ゴジラ-1.0』90点（100点満点中） | movie.maeda-y.com |
| 465 | メールアドレスをキーにしてID連携を行う設計の危うさ｜ritou | sizu.me |
| 454 | 「直接会って話したほうがはやい」は速いだけ｜araya | sizu.me |
| 438 | ベンダが提供していない決済モジュールの不具合による情報漏洩事故 東京地判令2.10.13（平28ワ10775） - IT・システム判例メモ | itlaw.hatenablog.com |
| 436 | Othello is Solved | arxiv.org |
| 435 | 池田大作氏の御逝去の報に接し | kishida.gr.jp |
| 424 | https://ip.guide/ | ip.guide |
| 421 | ナポリタンが究極の味になる！ほんのひと手間に「やって大正解」「今度からこうする」 - macaroni | macaro-ni.jp |
| 421 | 大麻、少年の性被害、男らしさの病（松本俊彦）[第12回] 酒をやめられない文学研究者とタバコがやめられない精神科医の往復書簡 | ohtabookstand.com |
| 407 | 変なドメイン取るな.net | www.henna-domain-toruna.net |
| 401 | ｍＲＮＡのひみつ ｜ まんがひみつ文庫 ｜ まんがでよくわかるシリーズ ｜ 学研キッズネット | kids.gakken.co.jp |
| 377 | 【雑記】セキュリティガイドライン類 約300時間 読み漁ってみた - 2LoD.sec | nikinusu.hatenablog.com |
| 374 | 弊社元幹部社員の不正について/日本海テレビ | www.nkt-tv.co.jp |
| 368 | t_wadaさんと「単体テストの使い方/考え方」の疑問点についてディスカッションしました - DeNA Testing Blog | swet.dena.com |
| 361 | コラム・寄稿「なぜドイツ人にできることが日本人にできないのか」 | www.rieti.go.jp |
| 360 | 令和時代の個人サイトの作り方：suama works | techbookfest.org |
| 356 | 【楽天市場】SPUの特典内容変更について｜SPU（スーパーポイントアッププログラム） | event.rakuten.co.jp |
| 345 | 国産プレミアムウイスキー 一部商品の価格改定について | www.suntory.co.jp |
| 335 | Mini vMac | lrusso.github.io |
こういう仕事は割とあるんだがなかなかのヤバさだったので紹介したい
ちなみにサービスの内容は非常に良くてユーザーも万単位で付いているらしい
バックエンドはAWS EC2で動作しているがログインアカウントは共通化されていてパスワードを全員で共有している
ユーザーを追加しようとしたら「そのような勝手な行為はセキュリティ上許可されていません」とのこと
本番環境とStagingはインスタンスが分かれているが運用は同じ方法
Staging上で5人ぐらいが作業しているが、ホームの下にそれぞれのユーザーが自分の名前でディレクトリを作って作業している
バックエンド側のシステムは詳細は伏せるが、某システムで動いている
仮にNode.js系だとすると、package.jsonがあってnpm run installでインストールするのだが、普通にインストールしようとするとエラーになる
内容は依存関係で失敗しているのだが、本番も同じソースで動作している
動作させるにはnode_modulesをまるっとコピーして、とのこと
さっきの自分の名前のディレクトリ配下にコピーしてきて、適当なポート番号でサーバを立ち上げれば一応は動く
このため、新しいモジュールを入れようとすると依存関係で失敗するため、便利なモジュールがあってもインストールできないし
セキュリティアップデートも当てることはできない（現にバージョンがすごく古い）
ソースコードはGitHub管理されているがセーブポイント感覚でcommitされているのでコミットログを見ても何が起きているのかさっぱり分からない
おまけにPRも使わずにmainにマージしまくっていてわけがわからない
加えてソースコードはコメントアウトの嵐でどこに何が書いてあるのかさっぱりわからない
データベースはPostgreSQLだが山ほどテーブルがあるのに外部キー依存は入っていないしVIEWも作られていない
まぁ、他にもテーブルを見ていくとアンチパターンのオンパレードで、EAV、ジェイウォークあたりは確認できたしHTMLやSQLが格納されているテーブルも見つけた
ソース上でクエリを作ってAPIを作っているが、ザッと見ただけでもインジェクションし放題の状態になっていた
フロントエンドも詳細は伏せるが、いわゆるReact的なものを利用している
こちらは npm run installでインストールできるし npm run devでちゃんと動く
ただ前述の通りバックエンドはローカルで構築できないのでEC2を利用するしかなく、CORS対応のためのプロキシを自前で用意する必要があった
バックエンド同様にGitHub管理されているが、管理しているだけ
バックエンドは5人ぐらいが利用しているが、ソースコードを編集するのは実質1人なのでコンフリクトはほとんど起こさないらしいが
フロントエンドは5人ぐらいが編集するのでコンフリクトしまくっている
解消するときにデグレすることが日常茶飯事でその都度Hotfixしている
コードもコメントアウトだらけなのに加えて、不必要なコードが大量にあるので可読性が著しく低い
（難しい処理を読み解いて追いかけていったら最終的に使われていない、などが大量にある）
2000行ぐらいあるコードとかChatGPTに突っ込んだら20行ぐらいになる予感がある
また、DBがご覧の状態なので取得されるデータも全然抽象化できておらず、コードが膨れ上がっている
例えばProductの一覧データをサーバから取得して、ユーザーがクリックしたProductをCartに投入するのだが、投入する情報はProductではなく、CartItemにする必要があるし
OrderするときはOrderItemにしてAPIを叩く必要がある
ほとんど同じ情報なのだが微妙に変わっていたりKey名が違っていたりするのでそれぞれ変換する
他にも数え上げればキリがないが、コピペして少しだけ改変している部分などが大量にあってバグがあるのかどうかすら判別できない
DBにHTMLやSQLが入っていると言ったが、調べて見るとDBから取得したHTMLをそのまま埋め込んで表示していたりした
SQLについてはフロントエンド側でSQL生成しており、そのテキストをAPIに送り込んでサーバ側で実行して貰った上で格納とかしていたので
「ここにDROP TABLEとか書けばTABLE消えるんですか？」
と聞くと
とか言われたのでことの重大さを伝えたが、まだ対処できていないようだった
認証等はOAuth2を使っていたので大丈夫そうだったが、本当に大丈夫かどうかは自信がもてない
システム内容はゴミのような状態だがサービス的には良いので、幹部やプロダクトオーナーからは追加要望が山盛り来ている
開発チームが「稼働が足りない」という理由で断ったので「じゃぁ支援して」ということで自分のところに来たのだが
「申し訳ないが、そもそもそういうレベルに無いし、全て作り直しが必要」
と伝えてもどうやら伝わっていない様子
ちなみに元々の開発チームは過去にもこんな感じでサービス作ってたらしいが売れないので問題になってなかった様子
ぱっと見は動いているように見えるのが厄介なところ
正直逃げたいところではある
わし「メールでよく使われるmbox形式のファイルを読みたいんや。dotnetならどうするといい？」
Bing先生「MimeKitとかMboxReaderという.NETライブラリがええで」
わし（ほーん、MimeKitええな。。。MboxReaderってどんなんやろ）
わし（あれれ、MboxReaderとかいう.NETライブラリは無いぞ・・）
わし「MboxReaderの詳しいところ教えてや」
どや」
わし「ほーん・・・？」
わし「MboxReaderとかいうライブラリって実在するん？」
Bing先生「するで。これや https://github.com/nodemailer/mbox-reader 」
今までだと嘘はすぐに破綻してたはずなのに、今度の嘘はなかなか破綻しないぞ・・・
今、「MboxSharp」とかいう架空の.NETライブラリの説明を受けてる・・・
しかしさすがのBing先生、MimeKit の中の Rfc2047 クラスの使い方をちゃんと教えてくれた。
まあ Stack Overflow にも書かれてある事をまとめただけではあるが。。
やっぱ先生はすげえんよ。
オブジェクト指向とかかっこいい言い方をしても無駄だ。従来の構造化プログラミングから進歩したことなど一つもない。オブジェクト指向がなぜダメであるのか、それを今から話すぜ。
1. データと処理をまとめるという発想。
データと処理をまとめてクラスとして置くという発想がある。しかし、このようなことをしなくとも、モジュールという単位で利用データと処理の集合をまとめればよかったので、クラスを使う必要はない。しかもクラスはインスタンス化のときに、不要な情報まで持ってくるのでメモリ効率が明らかに悪い。コンピュータが進化しているからメモリのことはあまり考える必要がないとはいえ、必要ない処理をまとめて閉じ込めるのは無駄が多い。なぜクラスという名詞で概念分類できると考え始めたのかは不明だが、アルゴリズムとデータ構造という構造化プログラミングの手法を、クラスと型というパラダイムに変換することで型にうるさいC++馬鹿を生み出し、彼らが発狂することになってしまった。しかもデータと処理にわざわざ依存関係を持たせて、変更に対する柔軟性を失わせている。
2. 継承
継承によって既存の構造を持ってこようとする必要性が全く無い。それどころか、継承を使うことによってプログラムがスパゲティ化し、依存関係のグラフがややこしくなってしまう。継承など使わず、必要な情報はスコープの限られた共通の変数、または関数の引数として用意しておけば良い。もしクラスをどうしても使いたければ、共通のインターフェイスをもたせたほうがマシである。インターフェイスを使えば、クラス利用者が意識すべきpublicメソッドがなんであるか把握できる。
3. カプセル化
オブジェクト指向の中で役立つ概念はカプセル化だけである。しかし、カプセル化はクラスなしで構造化プログラミングの方法で実装できる。pythonでは、モジュールの中でアンダースコアから始まる関数を用意しておけば、それがprotectedやprivateと似たように機能させることができる。オブジェクト指向がなぜカプセル化が独自の概念だと言い始めたかは謎。
4. ポリモーフィズム
同じ名前のメソッドを、入力に応じて処理の内容を変える。このようなことはオブジェクト指向などと誇大宣伝をするほどのことでもない。構造化プログラミングで似たようなことができる。
導入CFWは多分最新(最後の) LME/Infinity2 導入済みの PSP1000 環境
症状
これでInfinity2によるCFWの直接起動が動くようになる。多分
原因
USB接続でのISOの吸い出し作業で間違えてブート領域を壊してしまったのかな？
