KDDIの高橋誠社長は11月2日の決算会見で、自動で文章などを作成する生成AIの基盤となる大規模言語モデルを、利用する業界や企業ごとにファインチューニング（最適化）するためのスタートアップとの連携などに数十億円規模の投資を行う考えを明らかにした。一方、ソフトバンクなどが取り組む汎用性の高い大規模言語モデルの開発については「1社だけで作るのは辛い」と否定的な考えを示した。
⇧ 個別の「最適化」で作りだしたモデルを最終的に1つに統合したりできるのかは分からないですが、複数のプロジェクトとして進めておいた方が、リスクヘッジとしては有効そう。
そもそも、「汎用性」を高くするには、様々な業界の要件を抽象化して汎用化できる部分を洗い出す必要がありそうな気がするんだけど、そんなレベルの話は既に対応済みってことかもしれんので、何とも言えませんな。
個人的には、
企業毎の最適化→業界毎の最適化→汎用性の高い大規模言語モデル
って流れで取り組んで欲しい気はしますかね。
どうしても、文系脳なので、
ヘーゲルの弁証法では、モノ（事物）やコト（命題）が「否定」を通じて、新たな・より高次のモノやコトへと再生成されるというプロセスを、「正（テーゼ）」「反（アンチテーゼ）」「合（ジンテーゼ）」という言葉を用いて説明します。
⇧ みたいな発想で考えたくなってしまうんよね...
Wikipediaさんによると、
彼によれば、我々の認識のみならず、全ての事物の発展は、単純化させると、矛盾を契機とするある命題と、それと矛盾するもしくはそれを否定する反対の命題、そしてそれらを本質的に統合した命題の三つからなる正・反・合の三段階の生成を実現する三肢構造として捉えられる。
正すなわち「定立」Theseは、あるひとつの立場を直接的に肯定する段階であり、矛盾・対立についての自覚はない。そして、反すなわち「反定立」Antithesisにおいて、あるひとつの立場が否定され、ふたつの立場が矛盾・対立する段階となる。更に合すなわち「綜合」Synthesisにおいて、相反する立場を否定しつつも互いに生かし、両者をより高い次元のレベルへと発展・収斂するべく「止揚」Aufheben（アウフヘーベン）が生じるとする論法である。
⇧ とあるので、何か、現状維持で停滞せず、どんどん変化させていくといった意味合い的な部分では、「アジャイル」の考え方に通じるものもあるような気がしますかね（個人的な見解）です。
まぁ、可能な限り「機械学習」とかのキャッチアップもしていかねばですかね...
Javaの開発環境でメジャーどころというと
規模の小さい開発であれば、メモ帳のようなテキストエディタの機能のみで進めるという猛者もいるのかもしれませんが、まぁ、大抵は何かしらの開発環境を整えてるとは思いますと。
- 統合開発環境（IDE：Integrated Development Environment）の場合
- 統合開発環境（IDE：Integrated Development Environment）ではない場合
⇧ あたりがメジャーどころになってくる感じなんかね？
自分は、いまのところ、
- 統合開発環境（IDE：Integrated Development Environment）の場合
- 統合開発環境（IDE：Integrated Development Environment）ではない場合
というケースの現場にしか参画できていないので、統計的に実際どれが利用されてるメジャーなものなのかが分からないのですが、
⇧ 上記サイト様によりますと、「IntelliJ IDEA」の市場シェアが伸びてるらしいのですが、根拠となる一次情報を公開していくれていないので、情報の真偽のほどは定かではないですと。
ちなみに、Wikipediaさんの情報が正しいとすると、
IDEの例
⇧ Javaの用途でのIDEとして「リファクタリング」機能を最初に導入したのは、「IntelliJ IDEA」らしいですな。
「IntelliJ IDEA」は、
Ver.9からはオープンソースのCommunity Editionを提供している。 有償のUltimate Editionに対しての、このCommunity Editionの違いは以下の通りである。
- 対応言語がJava、Scala、Groovy、Clojure、KotlinなどのJavaプラットフォーム上の言語のみ。PHP、Python、Rubyなどは非対応。
- Web系非対応。HTML、JavaScript、Webフレームワーク（Grailsなど）、Webサービスなどは非搭載
- エンタープライズ系非対応。Jakarta EE非対応。
- データベース系非対応。SQL非対応、データベースツールを搭載しない。
- UMLデザイナ非搭載
- モバイル系はAndroidのみ対応。Adobe AIR非対応。
- アジャイル開発系非対応。
Community Editionは比較的緩いライセンス形態である Apache License を採用している。これによりベンダーは独自機能を搭載して販売してもソースコードを公開する必要がない
⇧ オープンソース版もあるようですが、基本的には「有償版」を使う感じになるんかね？
一方、Eclipseはと言うと、
Eclipse ソフトウェア開発キット （SDK）はフリーでオープンソースのソフトウェアであり、 Eclipse Public Licenseの条件に基づいてリリースされているが、 GNU General Public Licenseとは互換性がない。 これは、GNU Classpathで実行される最初のIDEの1つであり、IcedTeaで問題なく実行される。
⇧「オープンソース」が基本的なスタンスっぽい。
市場シェアが、両方とも「オープンソース版」での比較であるかが分からんので何とも言えんけど、コストを出してくれるような開発現場であれば、「IntelliJ IDEA」が利用されることが多いんかね？
EclipseのエディターでJavaでコーディングする時の設定がいろいろ面倒な件
とは言え、Eclipseを使ってる現場なので、Eclipseの話です。
で、EclipseのエディターでJavaを使う時の設定がいろいろ面倒な件ということで、主に、以下の3点があるのかなと。
- 行の末尾の空白スペースの自動除去
- 不要と認識されたimport文の自動除去
- スペースの扱い
- 半角スペース
- Tab
■1.行の末尾の空白スペースの自動除去
⇧ このあたりは、Java以外のプログラミング言語でも、Eclipseあるあるらしい。
そもそも、行の末尾に空白なんて必要ないから、消してくれるんなら良いことじゃない？って思うんだけど、Gitとかで管理されてるソースコードで行の末尾に空白が含まれてしまっている場合は、行の末尾の空白を消してしまうと、本筋の修正箇所以外の差分となってしまうので、NGなんですな。
まぁ、プロジェクトの方針で、『行の末尾の空白は不要』、と決まって行の末尾の空白の除去を全てのソースコードに反映した後であれば、『行の末尾の空白スペースの自動除去』の設定を有効にしても良いとは思うけど。
■2.不要と認識されたimport文の自動除去
続いて、2点目の話。
で、Java以外のプログラミング言語でもある話なのかは分からんのですが、Javaだとimport文でライブラリを読み込むんですが、Eclipseのお節介設定なのか、
⇧ エディターでソースコードを保存時に、不要と認識されたimport文を勝手に消してくれるという謎の設定が有効になっているんだとか。
これについても、いくら、このimport文は使っていないだろうということが確定的と判断できたとしても、本筋の修正箇所以外の差分となってしまうので、NGなんですな。
1点目と同じで、プロジェクトの方針で、『不要と認識されたimport文は不要』、と決まって行の末尾の空白の除去を全てのソースコードに反映した後であれば、『不要と認識されたimport文の自動除去』の設定を有効にしても良いとは思うけど。
■3.スペースの扱い
最後の3点目は、スペースの扱いですな。
⇧ Eclipse側の設定で、期待した挙動にならない時があるようです。
インデントとかする時に、
- 半角スペース
- Tab
のどちらかに統一した方が良いとは思うので、設定しておいた方が良い気はするので、プロジェクトの方針を確認ですかね。
っていうか、こういう煩わしいことがあるから開発現場で環境を統一したくなるんよね...
まぁ、プロジェクト固有の手順などドキュメント化しておくのが、初見の人（プロジェクトに初めて参画する）にとっても良い気はしますかね。
開発の本筋に関係ないところで時間取られたくないですし。
何て言うか、開発環境は統一して欲しい気はするけど、
とかOS（Operation System）の違いで、上手く動かないから、
が混在するってこともあるあるだと思うので、難しいところですな...
Eclipseとかは対応版のバージョンがリリースされるまで、OS X（Mac）で動かないって時期もあったようなので...
ネットの情報だと、
Apple M1は、AppleがMacおよびiPad向けにARMアーキテクチャのライセンスを受けて設計したシステムオンチップ（SoC）である。TSMCの5nmプロセスで製造されている。
⇧ Apple独自の「システムオンチップ（SoC）」にEclipseが対応してない時期があったって話がありましたね。
なんか、Eclipseというよりは、
継承できるクラスを制限するSealed Classが追加されました（JEP 409）。また、Apple M1チップ（AArch64）のmacOS 11.0がサポート対象になり（JEP 391）、Apple Metalによる高速なレンダリングを提供するmacOSのAPIにも対応しました（JEP 382）。
⇧ Java側の問題なんかな？
何か、Javaのアプリケーションが、M1チップ搭載のOS X（Mac）で「Eclipse」で動かんけど、「VS Code（Visual Studio Code）」なら動くっていう開発現場に出くわしたことがあったので、何とも言えんけど...
話が脱線しましたが、というわけで、Eclipseの余計な親切心で苦しめられることがあるという話でした。
毎度モヤモヤ感が半端ない...
今回はこのへんで。
