おのたく日記 YouTubeも始めました→

■ JNDIのお勉強

JNDIホームページ http://java.sun.com/j2ee/ja/jndi/index.html

J2SEの入り口 http://java.sun.com/docs/

J2SE 1.4ドキュメント http://java.sun.com/j2se/1.4/ja/docs/ja/

J2SE 1.4 JNDIドキュメント http://java.sun.com/j2se/1.4/ja/docs/ja/guide/jndi/

J2SE 1.4 JNDI CosNamingプロバイダ http://java.sun.com/j2se/1.4/ja/docs/ja/guide/jndi/jndi-cos.html

Interoperable Naming Service (INS) 仕様 (99-12-03) ftp://ftp.omg.org/pub/docs/ptc/99-12-03.pdf

J2SE 1.4 JNDI概要 http://java.sun.com/j2se/1.4/ja/docs/ja/guide/jndi/spec/execsumm/jndiexecsumm.html

J2SE 1.4 JNDI API説明 http://java.sun.com/j2se/1.4/ja/docs/ja/guide/jndi/spec/jndi/index.html

J2SE 1.4 JNDI SPI説明 http://java.sun.com/j2se/1.4/ja/docs/ja/guide/jndi/spec/spi/spicover.frame.html

J2SE 1.4 JNDIパッケージ一覧 http://java.sun.com/j2se/1.4/ja/docs/ja/guide/jndi/reference.html

JNDI Tutorial http://java.sun.com/products/jndi/tutorial/index.html

■ [Blog] CNET Japan Blog - 梅田望夫・英語で読むITトレンド：続・100万行のソフトの作り方

石黒さんのゲストブログが好評だったので、石黒さんからのお返事が載っている。わんこ日記にもお返事を頂きリンクされてる♪

まずは、

「これってもうメディアかも」

[CNET Japan Blog - 梅田望夫・英語で読むITトレンド：続・100万行のソフトの作り方より引用]

そー、このようなプログラマとしてディープな多くの人の意見を聞けるのは、いままでなら滅多に無い事で、非常に勉強になっている。

梅田さんは、ビジネス的にも有意義な話を沢山後悔してくれているけど、わんこが反応できるのはテクニカル・ディープなものしかないけれどね。

■ 情報システム部門をITと呼ぶ海外

話は横道にそれるけれど、情報システム部門って、海外だとITって呼ばれていますよね。今日も、高校の先輩に飲みの席で「うちのITに来ないか」と誘われた。先輩の会社は、いつのまにか外資系になった会社なので、やはり、情報システム部門をITと読んでいたので、

実際にやった仕事はUNIXのシステム管理でした。シリコンバレーでは、会社によって呼び方が違うと思いますが、うちではITと呼ばれる人間がそうした仕事をやっていますね

[続・100万行のソフトの作り方より引用]

に、「ほー」と思ってしまった。

■ テストチームとQA

テストチームをQA(Quality Assurance)と呼んでいます。

-SNAP-

もしかすると、SEという職種の呪いがここにもあって、テストエンジニアという存在とQAという工程を隠してしまっているのかもしれませんね

[続・100万行のソフトの作り方より引用]

QA大国日本のQAって、SEの他に、ちゃんといるような気がします。

石黒さんのあげているような、ソースを書く開発チームの近くにいるテストチームではなくて、もう少しユーザに近くて、テスト&フィールドサポート部隊だと思っていました。SEの中にもテストチームはいるけど、そこはホワイトボックステストで、さらに後ろの工程にブラックボックステストのQAがいるのが、日本のQAだと思っていました。

二十代の頃には、請負のプログラム開発を受けて南武線沿線の各社に行きましたが、どこでも、こちらでのテスト完了後、検収としてブラックボックステストを行うQAの検査を受けた覚えがあるので、それが普通だと思っていたのですが、ちがうのかなぁ

■ 日本には天才プログラマ不要論

上のCNET Japan Blog - 梅田望夫・英語で読むITトレンド：続・100万行のソフトの作り方のトラックバックで、「ビジネス オン デマンド」を見つけた。「ビジネス〜」というだけあって、ちょっとスーツの香りがしたけど、なかなか、日本にも、すばらしい環境があるらしいので、書き留めちゃう。

まずは、これ

設計がよければコーディングで天才的なプログラミングは必要ないし

[ビジネス オン デマンドより引用]

すばらしい。確かに、完璧な基本・概要設計になっている開発であり。詳細設計は基本設計の解像度をあげると、手にとるように分かり。その詳細設計に基づいて、そのままコーディングできるようだったら、天才的なプログラミングなんていらないですからね。

しかし、いまやっているような「オープン系」と言われるような開発をしていると、利用するOSを含めて周りが怪しい「オープンな」ものなので、トライ・アンド・エラーや、実験が必要であり。さらには、良い設計が出来るには、プロトタイプの作成など、十分な期間が必要なのにかかわらず、開発コスト削減圧力が高くて、十分な開発期間もなく「設計が良い」なんて、ここ十年とか有った事が無いです。(煙の臭いが好きなわけではないけど、いつも火事場の仕事ばかりだし)

と言っても、最近は、この話の中でも例外とされているソフトウェア製品の開発しかやったことなく、個別業務システム開発について、自分が知っているのは5年以上も前にC++とか使っていた時代を思い出しながら書いているので、いまはマルチプラットフォームなJavaで、さらには素晴らしいCASEツール等があるから、現在の個別業務システム開発は、「普通は設計が良い」なのかもしれないですけれど…

さらに、うらやましかったのは、

いざとなれば人的リソースの大量投入による製作が当たり前

[ビジネス オン デマンドより引用]

という、コスト度外視のリソース投入。夢だぁ〜

でも、

質は良いが言葉が通じにくい海外と、質は最悪だが教えれば何とかなる国内ではどちらが良いのか？というところに行き着いてしまうのも事故が多発する原因ではないかと筆者は思うのです。

[ビジネス オン デマンドより引用]

ってことで、「設計は良い」プロジェクトだけど、

・海外に出すと言葉が通じなくてダメ。

・国内だと、プログラマの質が悪くてダメ。

あり、良い設計というのは、概要の設計のことで、もしかして、詳細設計・実装設計など、コーディングにより近いレベルの設計が入っていなかったのかな?　コード一歩手前まで設計してあれば、言葉の問題も、コーダの質も関係ないと思うのだけれど。

あ、もしかしてコーディングに近いレベルの設計は、プログラマがやるもの? でも、だとしたら、概要設計から、詳細設計に落とせる天才的なプログラマが必要になってしまうから、「日本には天才プログラマ不要論」にならないし、文章読解力が甘い、わんこは、どこかで話を、ねじ曲げてしまったか。

■ 情報公開の恐怖

梅田さんのblogの中でこんな言葉が有った。

むろん「情報の共有」によって全体としての生産性がおそろしく高まることに気づき始めている人は少なくない。でもそのメリットを打ち消すほど大きな不安が存在する。情報はオープンになった瞬間に価値を失うのではないのか? いや価値を失うどころか、とんでもない災厄がわが身に降りかかってくるのではないのか? そういう不安だ。

[[コラム] 次の10年はどういう時代か(3)より引用]

情報の共有により複数の脳が連係する事によりより大きな力を産む事は確かにあると思う。

ただ、情報共有の手段が未熟だった時代の人々は、情報を寡占することにより力を得ていたりするので、「情報の共有」に対して恐怖をいだくらしい。

この恐怖のために折角、インターネットやコンピュータなどという情報共有ツールが生かされず人類が得れるべき利益を得られないということは大変ざんねんだと思う。

■ [gwt] Google Web ToolkitをDebian amd64 etchにインストール

■ 新モスバーガー

今週はずっと体調が悪くて熱が出ていたんだけど、やっと熱がさがってきたので、何か栄養があるものを食べることにした。

そんな時に、モスバーガーのレシピか変わったそうで、新聞の広告に割引券が入っていたので、さっそく食べに行った。

新モスバーガーと新テリヤキバーガーを食べてみました。新モスバーガーは、ちょっと、ミートソースの色がうすくなって、さっぱりした感じになってました。やっぱり前の味の方がモスらしいですが、こってり感が減った方がイマ風なのかなぁ〜

新テリヤキバーガーは、従来のものの味を忘れてしまっているので、どうなったか分かりません(-_-);

※割引券はWebでも5/18から二週間の限定でダウンロードできます。「MOS BURGER/News 2007/05/18【本日より14日間限定】「得！モス！HPクーポン2」ご好評につき、第2弾クーポン！ダウンロード開始。」

■ [VirtualBox][Debian]VirtualBox 3.2がリリースされた

SunがOracleになってキーが変わったようなので

# gpg --recv-keys 0x98AB5139
gpg: 鍵98AB5139をhkpからサーバーsubkeys.pgp.netに要求
gpg: 鍵98AB5139: 公開鍵“Oracle Corporation (VirtualBox archive signing key) ”を読み込みました
gpg:     処理数の合計: 1
gpg:           読込み: 1
# gpg --armor --export 0x98AB5139|apt-key add -
OK

とした。

■ [Debian] で、ゲームコントローラーGamesir T1sを使う

ミニドローンのTelloのコントール用に買ったゲームコントローラーのGamesir T1sだけど、Telloが何故か充電できなくなってから使わなくなってしまっていたのだけど、mameをやってみたくなり、使ってみることにした。

Windows 10では、USBケーブルでつないで、Gamesir T1sを「home」+「X」で起動すると、自動的にドライバーが入って、Windows 10の設定では、なぜかマウスと並んでBloutooth一覧に出てくるけど、Joystickとして認識されて、普通にmameからも使えた。

Debianでは、 「ゲームパッド - ArchWiki」を参考にして、「mame」「xdoxdrv」パッケージを入れて、Windows 10と同様に、USBケーブルでつないで、Gamesir T1sを「home」+「X」で起動すると

usb 1-1.2.1: new full-speed USB device number 80 using xhci_hcd
usb 1-1.2.1: New USB device found, idVendor=045e, idProduct=028e, bcdDevice= 1.10
usb 1-1.2.1: New USB device strings: Mfr=6, Product=7, SerialNumber=8
usb 1-1.2.1: Product: Controller
usb 1-1.2.1: Manufacturer: xiaoji
usb 1-1.2.1: SerialNumber: 0152793
input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.2/1-1.2.1/1-1.2.1:1.0/input/input154
usbcore: registered new interface driver xpad

と、XBoxのコントローラーとしてエミュレートされて認識されて、mameでも普通につかえた。

JoystickとかゲームコントローラーもDebianで簡単に認識される時代なんだなぁ

■ GitLab 17.0へのアップグレード時のOmnibus Dockerイメージのエラー解決

概要:

GitLab Omnibus Dockerイメージで、ci_pipelinesテーブルの制約ci_pipelines_pkeyを削除できないというエラーが発生しました。この問題は、他のオブジェクトがこの制約に依存しているため削除できなかったことに起因します。

gitlab-ce-1 | PG::DependentObjectsStillExist: ERROR: cannot drop constraint ci_pipelines_pkey on table ci_pipelines because other objects depend on it
gitlab-ce-1 | DETAIL: constraint fk_rails_a2141b1522 on table ci_builds depends on index ci_pipelines_pkey
gitlab-ce-1 | constraint fk_rails_a2141b1522 on table p_ci_builds depends on index ci_pipelines_pkey
gitlab-ce-1 | HINT: Use DROP ... CASCADE to drop the dependent objects too.

解決方法:

従属オブジェクト（外部キー）を特定し、削除しました。具体的には、以下の手順を踏みました。

1. docker compose gitlab-ce gitlab-psqlコマンドでPostgreSQLコンテナに接続しました。

2. 以下のSQLコマンドを実行し、従属制約を削除しました。

SQL
ALTER TABLE ci_builds DROP CONSTRAINT fk_rails_a2141b1522;
ALTER TABLE p_ci_builds DROP CONSTRAINT fk_rails_a2141b1522;

結果:

上記手順によりエラーを解決し、GitLab Omnibus Dockerイメージを正常に起動できました。

教訓:

今回の経験から、以下の教訓を得ました。

- GitLab Omnibus Dockerイメージでエラーが発生した場合、公式ドキュメントやフォーラムスレッドを参照することで解決策を見つけられることが多い

- データベースに重大な変更を加える前には、必ずデータのバックアップを取る

- 問題が発生した場合は、慌てず原因を特定し、適切な解決策を講じることが重要である

実は、解決方法をGemini 1.5 Proに聞いて、日記も書いてもらい。GPT-4でこの日記を構成してもらったんだけどね。