はてなキーワード: モジュールとは
コードを簡潔に保つにはモジュール化が必須である。しかし同じモジュールに関係のない機能が含まれていたりすると混乱の元になる。
一方で、関数というのは引数の細かな仕様に依存せずに、汎用的に呼び出せた方が何かと好都合だ。引数になんらかのオブジェクトを渡し、そのオブジェクトしか持ち得ないような特殊な情報で処理を行なったりすると、関数とオブジェクトが互いに依存しあってしまう。
これはモジュールの結合度と呼ぶ。
高い凝集度、低い結合度によってモジュールを作れば、保守性は上がる。
さらにモジュール内では、公開する必要のない関数はprotectedまたはprivateにするべきだ。
そのためにはモジュールが公開すべき関数についてインターフェイスを作り、公開関数に対するユニットテストを書いておくのが良いだろう。
phpの場合、<?php 処理 という具合に書くが、この中身にはhtmlやjavascriptも包含することができてしまう
MVCフレームワークを使わないにしろ、基本的にビューとバックエンド処理は分割しておくべき。
さらにDB処理、ビジネスロジック、プログラム処理と言ったものがあるが、
DB処理はdbhandler専用のモジュールに分けておき、さらにそのモジュールを処理するテーブルごとに分けておいた方が良い(MVCではモデルと言う)
特にビジネスロジックとプログラム処理の区別だが、「商品名にアダルト商品と思わしき文字列があった場合は登録を拒否する」という例外は「ビジネスの例外」であるのに対し、「商品名の文字列がDBで用意されたvarcharの可変文字範囲を超えた」という例外は「技術の例外」であるということを明確に区別するようにコードを書く。
module_name.pyみたいなモジュールごとにファイル分割して、インターフェイスだけ公開してその他はdef _funcみたいにprotected(or private)にしとく。
でも「共通性がありそうだから共通関数にする」はアンチパターンだな。たまたま共通してただけの場合は分岐コードが増えて共通関数の保守コストが上がる。
あとありがちなのは、php開発者が関数分割しないですべてメインコードにべた書きするケース。こういうのはやめないと保守が大変。
とっておきのクズがやりがちなのは、神オブジェクトを作るとかだな。Userクラスのフィールドに関係する機能が多いからといって、コンポジションなどによるクラス分割をせずにユーザークラスにあらゆるフィールドとメソッドを追加して、さらに進むとユーザーとは無関係な機能も含めすべてをユーザークラスに定義するアフォ。こうなってしまったら、後から修正するのが難しくなる。
先に手を打つことが、プログラマーの素質「怠惰」につながるのであり、面倒臭いといって後回しにするのは美徳でもなんでもない。
7年半を振り返ったのでメモ
WS-20エンジンも量産が始まり、中国軍の航空機エンジンの国産化はヘリなども含めてほぼ完了したと見て良さそうだ。
中国軍は、第3次台湾海峡危機の際に米海軍空母を前になす術がなかったという屈辱を糧に軍の近代化に励んできました。
今や中国軍は1996年当時とは比較にならないほど近代化されており、針ネズミのように配備されたミサイル群は、米空母でさえ迂闊に近付けば撃沈されかねない。
中国空母の直援艦は全部中華イージスになりましたね(別動で054A型はいますが)。
今や中華イージスの就役数は、055型6隻、052D型24隻、052C型6隻の36隻まで増えている。
052D型と055型は10年前には1隻も就役していなかった。
055 ×16
052D ×37
052C ×6
051C ×2
052B ×2
ソブレメンヌイ級 ×4
051B ×1
中国海軍2012年からの8年だけで以下の艦艇が進水してますからね、規格外の拡張と言って良い。
002型空母 1隻
075型強襲揚陸艦 3隻
055型駆逐艦 8隻
052D型駆逐艦 25隻
056型コルベット 72隻
渤海造船所に新設された世界最大規模の潜水艦建造施設で、初の建造中の原潜が確認されました。
存在が噂されてきた093B型、095型攻撃型原潜もしくは、096型戦略原潜である可能性が高い模様。
J-10CやJ-20もWS-10エンジンに切り替わったので中国の戦闘機エンジンの国産化は成功したと言えそうですね。
ただ、輸送機や爆撃機向けのWS-18やWS-20はまだ量産されておらず、中国軍用機のロシアからの自立はまだかかりそうです。
2000年代初頭に052B型、051C型、052C型、956EM型を2隻ずつ建造して、技術的に成熟してから大量建造に移行したというのは多少知識がある方なら知っているでしょうが、表にしてみると分かりやすいかと思います。
大連造船所で052DL型駆逐艦23番艦と055型駆逐艦6番艦が進水。
ひとつの国が1年間で駆逐艦を9隻進水させたのは1946年以来、73年ぶりです
駆逐艦工場と化している大連造船所と上海江南造船所について。1年間に最大で8隻の駆逐艦を進水させる能力があります。
jbbs.shitaraba.net/bbs/read.cgi/sports/37992/1533086155/963
中国の空母建造地である江南造船廠と大連造船廠は、どちらもドックの拡張や新ドックの建設、建造能力の強化を図っている。これは空母および護衛艦である055型駆逐艦の量産体制の確立を目指すものと見ている
>大連ではこの拡張工事が終われば、空母二隻の平行建造、そして055型五隻の同時建造が可能になると推測している。江南造船廠では、現在建造中の003型空母のために新たな船台を建設している。
>漢和では、今後両造船所が複数空母を並行して建造する可能性を示すものとして注目している
国産エンジンを搭載したJ-10CとJ-20の生産が始まり、戦闘機のエンジンをロシアに依存していた時代がいよいよ終わると。
jbbs.shitaraba.net/bbs/read.cgi/sports/37992/1533086155/783
>大連に到着したワリヤーグは海軍技術陣による調査を受け、主船体の状態は良好で船体の腐蝕も少なく新造船に近い状態で、今後40~50年間は問題ないと評価
>完成度は40%と判断し、建造を続行し就役させるための基礎には十分であると判断
>建造作業は2004年8月13日に着手。そこで遭遇したのは予想以上の困難であった。一つの例を挙げると、ワリヤーグの設計段階ではSu-33の制式化前だったので予定スペックに基づいた格納庫設計が為されていたことが判明した
>設計作業ではSu-33の折り畳み状態での翼幅は7.4mであるとして設計されていたがこれは実際には8.4mになっていた。Su-33の情報をもとに開発されたJ-15も折り畳み状態の翼幅は8.4mになるので、格納庫はそれに合わせた設計変更を余儀なくされた
>改装作業では、甲板や格納庫の調整、船体構造の設計合理化、失われたパイプ系統などの配置と各種方面で元々の設計の問題点があれば設計変更や換装を行っていった
>アレスティングワイヤを含む着艦拘束システムについても国内開発されたものが搭載
>全長65mに及ぶ艦橋があったが、それでも各種アンテナ、通信機器、電子戦装備を電子干渉を起こさずに搭載するには不十分
>ホイップ状の倒立アンテナを開発し、舷側の各部に配置することでこの問題を解決した。以後の空母では、中国のアンテナ集積技術の発展に伴い、アイランドの形状は簡潔化
>遼寧は2004年の再生工事着工から、8年の時間をかけて2012年9月25日に制式に部隊配備
>遼寧は、艦内のSSM用VLSを撤去して格納庫を拡大したのではないかと推測されてきましたが、最近になって面積拡大はなされていないという結論に達しています
>36機の搭載機数は6万トン級空母としては少ないと指摘されていますが、無理に搭載機を増やしてもSTOBAR式空母である遼寧ではその数を有効活用するには問題があり、36機というのが最も合理的な数字であるとなったのはよく理解できる話です
(終わり)
アメリカで空母を作れるのはニューポート・ニューズ造船所だけですが、中国は上海と大連の2ヶ所で建造可能なのですよね。
質問なんですけど中国って軍艦や大型船建造のドックがある造船所ってどれぐらいあるんでしょうか
>中国の主な造船所
>2、江南造船所(上海長興島):駆逐艦、空母、揚陸艦、通常動力型潜水艦、掃海艦など
>4、中華造船所(上海浦東):フリゲート、コルベット、揚陸艦、偵察艦、補給艦など
>5、黄埔造船所(広東広州):フリゲート、コルベット、公務船など
>6、武昌造船所(湖北武漢):コルベット、通常動力型潜水艦など
中国は8個の大型造船所を保持してて、空母建造可能造船所が2個ある・・・
やっぱ劉華清のおかげやな(造船所強化にも力を注いでたし)
中国の渤海造船所で建設されていた世界最大の原子力潜水艦建造施設はほぼ完成したようです
jbbs.shitaraba.net/bbs/read.cgi/sports/37992/1533086155/706
>大連と長興島だけで、055型6~7隻、052D/E型16隻+6を建造/建造中
>全世界に展開する米海軍に対し、中国は全艦艇を自国海域に投入できる点で有利であり、艦艇間の性能差もそこまで大きなものではなくなってきている
>空母艦隊の戦力、経験の蓄積、戦闘機や原潜の数や質、ASW能力の差などの面で、中国海軍が追い付いていない点も多い
>055型はアーレイ・バーク級を上回る戦闘力を備え、米タイコンデロガ級巡洋艦に近い立ち位置の艦。055型の増勢に対して米海軍のタイコンデロガ級は段階的に退役が進む
>今後10年以内に、大型水上戦闘艦艇の数で対米5割に達することは充分に考えられる
>11隻の空母を要する米海軍に対し、中国海軍は陸上航空機や弾道ミサイルの支援を受けることが可能な海域で対峙することになろう
>西太平洋での台湾有事など局地戦勃発に際して、台湾東岸を封鎖して、展開する米空母部隊に対峙する能力を獲得することになる。このほか、空母戦闘群を世界各地に展開し、洋上航路の安全や海域の封鎖、邦人保護や陸上施設の打撃など多様な任務に投入されることになろう。
>その際には、YJ-18巡航ミサイルの艦対地型による内陸打撃も想定される。2019年以降、水上艦艇の建造と並行して攻撃型原潜の大量建造も進められることになる。
渤海造船所に新設された世界最大の原子力潜水艦建造工場がすでに稼働しているらしい。同時に6隻が建造可能。
中国のジェットエンジンが世界水準から立ち遅れを生じた理由について、北京航空航天大学の劉大響教授の見解
jbbs.shitaraba.net/bbs/read.cgi/sports/37992/1533086155/566
>国家経済の相対的立ち遅れにより、研究開発費がはなはだしく不足していた(続く)
>開発リソースに対して、開発の規模が大きすぎ、リソースが分散し、低レベルでの重複が生じた
>管理モデルが時代遅れで、科学・民主的な政策決定機構と安定性に乏しく、権威ある中長期的な発展計画が欠けていた
>アメリカを例にとり、IHPTETやVAATEなどの予備研究に数百億ドルを投じたこと、両国の技術格差を示すものとして、F119エンジンの寿命が12,000時間に達するのに対して、WS-10は1,500時間に留まることを指摘、この差が生じる主な原因としては素材の高温環境における耐久性にあるとした
>中国のエンジン開発は、模倣―改造―自主開発と段階を経ており、2016年8月には中国航空発動機集団が成立し、「両機専項(ジェットエンジンとガスタービン事業)」が始動しており、中国の航空機エンジン開発は新段階に入った事を示す事例であるとしている
jbbs.shitaraba.net/bbs/read.cgi/sports/37992/1533086155/458
>052C型は「型號H/ZBJ-1」システムを初めて搭載。同システムは、高い自動性を有した先進的な戦場管理システムであり、この開発成功により中国は初めて「真のエリアディフェンス防空システム」を獲得(続く)
>052D型は052C型をベースに「プラットフォーム共通化、装備のモジュール化」を進め、防空能力を含む多用途性能改善を図ったタイプ。作戦システムは、先進国艦艇で採用される分散・開放式を取り入れており、高い分析処理能力を有すると共に、将来のアップグレードや新装備との統合も容易に行える
>米Link-16に相当する的「全軍綜合數據鏈系統(「聯合網路作戰系統」)」データリンクシステムを搭載しており、各軍種を超える情報連携を実現
>VLSが各種ミサイルの混載を可能とするタイプに変わったことも見逃せない
>055型駆逐艦は、抜本的に設計を改めた新型駆逐艦として開発された。これは米海軍がアーレイ・バーク級駆逐艦の改良を続けているのとは対照的
>055型の特徴は①COGAG機関の採用、②デュアルバンドフェイズド・アレイ・レーダーの採用、③統合マストの採用、④112セルのVLS搭載、にあると指摘
>055型は、中国海軍の駆逐艦能力を世界でもトップレベルに高めた画期的なものと評価。その能力や技術水準は米ズムウォルト級駆逐艦と比較しても遜色なく、優位に立つ所もあるとする。米専門家の「嘆息美國難以追趕(嘆息して、アメリカも追いかけるのは難しい)」というセリフを引用
>055型の発展潜在性は高く、今後は、統合電気推進システムの採用、電磁砲搭載などさらなる改良が施されるであろう
>055型は中国海軍の外洋化を象徴する兵器であり、台湾側への圧力はさらに増すことになり、厳重な警戒と深い分析が必要であるとまとめている
今年進水した中国海軍水上戦闘艦は駆逐艦6隻、フリゲート1隻、コルベット10隻、合計17隻。これはとんでもないペースですよ。
中国海軍は、052D型×22、055型×8の計30隻の中華イージス艦を建造しているようだ。052C型を合わせると中華イージスは36隻。
近代的な駆逐艦の総数は、052A型×2、051B型×1、現代級×2、052B型×2、051C型×2の計9隻を合わせた45隻になる。
かつて中国海軍は、2隻新型艦を建造して試験した後、さらなる新型艦2隻を建造するという工程(小歩快跑と呼ばれた)を繰り返して技術力の向上に勤め、052D型駆逐艦からようやく大量建造に踏み切りました。彼らは自分達の技術レベルを理解した上で相当先まで見据えて事を進めているんですよ。
上海江南造船所の空撮映像(別角度)。海上自衛隊が10年くらいかけて建造した数の艦を1つの造船所で同時に建造している。凄まじい光景ですね。しかも、大連など他の造船所でも大量に作っているのだから・・・。
江南造船所
・055型駆逐艦 ×3
・052D型駆逐艦 ×6
大連造船所
・055型駆逐艦 ×3
・052D型駆逐艦 ×5
002型空母 ×1
055型駆逐艦 ×6
合計 ×27
「浮」
今年は毎日やってくる地震に精神的に対抗するために、レビテーションガジェットが数多く発売され、浮遊ブームとなりました。
浮遊ベッドや浮游チェアーの生産が間に合わず、喜びと事故の両側面で人々に強い印象を残しました。
これらの開発を可能にしたのが、年初に発見された世紀の科学的発見、浮動次元です。
これまでダークマター、ダークエネルギーとされてきた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 | トコジラミ根絶方法 | 害虫・害鳥獣を安全に対策します|株式会社 オオヨドコーポレーション Pテックス社 | 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 | mRNAのひみつ | まんがひみつ文庫 | まんがでよくわかるシリーズ | 学研キッズネット | 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の吸い出し作業で間違えてブート領域を壊してしまったのかな?
彼はお金がない( )車を2台買った。
「ここが”ので”じゃなくて”けれども”になる理由が分かりません」
これについて「文脈がわからないから、どちらか決まらない」とか「文法的にはどちらも成立する」とか、全然文が読めていません
「本当は3台買うつもりだったけど、お金がないから2台にした」とか、問題なのだから書かれている情報以外の事は考えてはダメなんです
ここで考えるのは「~がない」というネガティブな状態 と 「~を買った」というそれに反する行動結果
という矛盾・対立の関係を考えたら、接続詞は「のに」「けれども」という逆説しか選択肢はないんです
でもそれがわからないというのは、文が読めていないんです
文を読むというのは
このプロセスのことです
「文脈がわからないから」というのは、入力の情報が少ないということです
これが多くなればもちろん正解する確率も上がりますが、それは大規模言語モデルであるChatGPTと同じレベルってことです
※参考
https://www.coelang.tufs.ac.jp/mt/ja/gmod/contents/card/082.html