⇧ RedditのデータでGoogleのAIの性能が向上するんかな？
Reddit（レディット）はアメリカ合衆国の掲示板型ソーシャルニュースサイト。主に英語圏のユーザーを対象とする。ニュース記事、画像のリンクやテキストを投稿し、コメントをつけることが可能。カリフォルニア州サンフランシスコに拠点を置くReddit, Inc.が運営する。2021年1月時点の月間利用者数は4億3000万人。欧米ではTwitterユーザー数並び利用時間を超える。
⇧ なるほど、バイアスがかかりそうですな...
まぁ、人種の坩堝（Melting Pot）と言われるように、多様な人種・民族の集まるアメリカなら、バイアスが強くないのかな？
何やら、
⇧「人種のサラダボウル」に変わってるらしいですな。
アメリカの人種・民族の比率とアメリカでRedditを利用している人種・民族の割合が分からんけども、バイアスは避けられそうな気がしないけどなぁ...
とは言え、Googleがアメリカ発祥の企業だからして、AIの学習に使用するデータ取得先の選択肢が限られてたってことなんかな。
まぁ、Googleのことだから、リサーチして分析した結果で、Redditと提携拡大に至ったとは思うけども。
Javaで複数ある.javaファイルの全てにpackage文を一括で付与したい
かなり特殊なケースだと思うのだけど、前に、
⇧ package文が付いていない「.java」ファイルを扱う機会があるという話をしたのだけど、正直、Eclipseとかでgit cloneしてきた状態で、エラーになってコードで参照先とかも追えないし、そもそもビルドとかできないしで、地獄ですと...
一旦、仮でダミーのクラス（拡張子「.java」）を作ることで、「デフォルト・パッケージ」を作った後に、「デフォルト・パッケージ」配下に全ての「.java」ファイルを移動するという発狂しそうな運用をしていたんだけど、もう、Gitで管理するメリットを台無しにしてる点でも頭を抱えたくなる惨状ですと...
流石に、このような常軌を逸している開発体制は世の中に他に無いと信じたいですが...
と、まぁ、こういった背景がありつつの、表題の件に繋がりますと。
で、残念ながら、JDK（Java Development Kit）には良しなに対応してくれそうなコマンドは用意されていないようなので、もし、package文を一括で付与するならば、
のどちらかで頑張るしか無さそう。
で、今回は、「.java」ファイルが配置されているディレクトリ自体は分かれているので、『2.統合開発環境（IDE：Integrated Development Environment）の機能を利用する』の方法も利用できそう。
「統合開発環境（IDE：Integrated Development Environment）」としてEclipseを使っている場合は、
⇧「リファクタリング」>「名前変更」の機能でディレクトリ毎に、ディレクトリ配下の「.java」ファイルにpackage文を一括付与してくれそう。
おそらく、Eclipse以外の「統合開発環境（IDE：Integrated Development Environment）」でも同様の機能は用意されているとは思われる。
⇧ 2020年の5月頃にpackageを変更できる機能が導入されたっぽい。
おそらく、IntelliJ IDEAとかAndroid Studioとかでも同様の機能があるんじゃないかと。
クラスパスなど
ちなみに、Eclipseで「Java プロジェクト」の構成だと、Eclipseで用意されてる「.classpath」の内容で「.class」ファイルの配置先が決まっているっぽいのだけど、
「.java」ファイルで指定したパッケージ名のディレクトリが作成されていて、そのディレクトリ配下に「.class」ファイルが配置されている。
Eclipseで、Javaプロジェクトのプログラムを実行する際のクラスパスがどうなっているかというと、「パッケージ・エクスプローラー」上で該当のプロジェクトを選択した状態で右クリックし、「プロパティー(R)」を選択。
左サイドバーから「実行/デバッグ設定」を選択し、リソースを選択し、「編集(E)...」ボタン押下。（最後に実行したのがJUnitのテストコードなので、テストコードの方になってしまっているけど）
「クラスパス」タブを選択し、「ユーザー・エントリー」の「xxx（デフォルト・クラスパス）」を選択し、「コマンド・ラインの表示(W)」ボタン押下。
実行コマンドが確認できました。
クラスパスなどは、
C:\Eclipse-2023-06\java\8\bin\javaw.exe -ea -Dfile.encoding=UTF-8 -classpath "C:\Eclipse-2023-06\workspace\test-watchservice\bin;C:\Eclipse-2023-06\eclipse\plugins\org.junit_4.13.2.v20211018-1956.jar;C:\Eclipse-2023-06\eclipse\plugins\org.hamcrest.core_1.3.0.v20180420-1519.jar;C:\Eclipse-2023-06\eclipse\configuration\org.eclipse.osgi\312\0\.cp;C:\Eclipse-2023-06\eclipse\configuration\org.eclipse.osgi\311\0\.cp" org.eclipse.jdt.internal.junit.runner.RemoteTestRunner -version 3 -port 64792 -testLoaderClass org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader -loaderpluginname org.eclipse.jdt.junit4.runtime -classNames apps.TestEndPointApp
⇧ のようになっている。
「-classpath "C:\Eclipse-2023-06\workspace\test-watchservice\bin;」という部分で、ビルドされた「.class」ファイルに至るまでのディレクトリがクラスパスに追加されてますと。その他にもクラスパスにいろいろ追加されてますが。
で、ややこしいのが、デプロイ先がLinuxとかで「CLASSPATH」とかの環境変数を指定している場合に、Eclipseの方で「.java」ファイルに追加したpackage文をビルドして生成される「.class」ファイルとかが考慮されていないと、ビルドで生成された「.class」ファイルの配置先がわけ分からん感じになってくると。
あとは、シェルスクリプト（拡張子「.sh」）内で、javaコマンドを実行してるから、そのあたりのパスとかも考慮する必要があると...
何でこんなことに頭を使わにゃならんのか...
もう、こんな不毛なことで時間使いたくないのよ...
コーディング以外の部分は、MavenやGradleといったビルドツールとかにお任せしたいんだけどね...
どうして、このような状態になったのかは推測するしかないわけなのだけど、おそらく、『兎に角、動けば良い』で進めてしまったからかと。
ビジネス側の『利益を上げなきゃお話にならないので兎に角、動けば良い』って言い分は分かるんだが、その方針で開発した成果物のせいで、将来的に追加開発、保守・運用で工数が膨らんでいくことについては文句言わないでね、ってことですかね。
こういうシステムの状態を知らないから、顧客から、追加開発、保守・運用の費用を削減しろって話が出てくるんだろうな...
これこれの背景があって、システムの品質が良くないため、追加開発、保守・運用の工数の削減が難しいって話を顧客へ正直に説明した方が良い気はするけど...
俗に言う、
技術的負債（英語: technical debt）、設計負債、またはコード負債とは、ソフトウェア開発における概念であり、時間はかかるがより良いアプローチを選択する代わりに、簡単ではあるが限定的な解決策を選択することで生じる、将来的な手直しにかかる暗黙のコストを示すものである。
⇧「技術的負債」を抱えてるってことですね。
結果
「利子の支払い」は、ローカルで必要なメンテナンスと、プロジェクトの他のユーザーがメンテナンスを行わないことの両方によって発生する。上流のプロジェクトで継続的な開発を行うと、将来的に「負債を返済する」ためのコストが増加する。完結していない作業を完了させるだけで、負債を返済することになる。
技術的負債の蓄積は、プロジェクトが納期に間に合わなくなる大きな原因となる。技術的負債を返済するために必要な作業量を正確に見積もることは困難である。変更に着手するたびに、不確実な量の未完成の作業がプロジェクトにコミットされる。プロジェクトは、未完了の作業（負債）が完了するための時間よりも多いことに気付いたときに、期限を逃してしまう。予測可能なリリーススケジュールを実現するためには、開発チームは未完成の作業（または負債）の量を常に小さくするために、進行中の作業の量を制限する必要がある。
提出の障害にならない程度の作業が完了していれば、技術的な負債が相当量残っているプロジェクトがリリースされる。このソフトウェアが本番環境に到達した場合、技術的負債を解決するためのリファクタリングを実施するリスクは劇的に高まる。本番コードの修正には、サービス停止のリスク、実際の金銭的な損失、サービス水準合意（SLA）を伴う契約の場合には法的な影響を受ける可能性もある。このような理由から、技術的負債を本番環境に持ち込むことは、ほとんど金利の上昇と同じように考えることができ、この金利が下がるのは、デプロイメントが却下されてリタイアするときだけである。
⇧雪だるま式に状況が悪化していき、最終的には手に負えなくなると...
何やら、
バタフライ効果（バタフライこうか、英: butterfly effect）は、力学系の状態にわずかな変化を与えると、そのわずかな変化が無かった場合とは、その後の系の状態が大きく異なってしまうという現象。カオス理論で扱うカオス運動の予測困難性、初期値鋭敏性を意味する標語的、寓意的な表現である。
⇧「バタフライエフェクト」を彷彿とさせますな。
予算と納期と工数の兼ね合いから、選択肢が限られる状態において、技術的負債の状況になる事は避けられないとは思いますが、そのような状態が解消されていない状況において、システム障害が発生した場合に復旧に時間がかかったからといって非難される謂れは無いわな。
毎度モヤモヤ感が半端ない...
今回はこのへんで。
