投稿日:

第10回 マイコン・インフィニット☆PRO-68K

こちらでの告知が遅くなりましてごめんなさい。今年はCOVID-19蔓延により状況が難しい状況ですので、MI68にはリアル出展ではなくバーチャル出展(URLを掲載してもらうのみ)とさせて頂きました。これにより会場では直接お会いできませんが、YouTubeに繋がる環境であれば世界中どこからでも、場所を問わず無料で参加頂けます。逆にそっちがいいですかね? ピンチがチャンス!!

マイコン・インフィニット☆PRO-68K
第10回 マイコン・インフィニット☆PRO-68K
・日時：2020/11/22(日) 10:30～17:00
・場所：秋葉原 UDX CONFERENCE 6F A+B / バーチャル出展

[10V-02] 武者返し.com
http://mi68.artstage.net/circle.html#vittuallist

視聴はこちらのランディングページからどうぞ!!

投稿日:

FM77AV修理マニュアル

https://hirofumiiwasaki.booth.pm/items/1201589

シリーズ丸ごとBlogに書くのをすっかり忘れていたのだが、思い出したのでこちらにも備忘録的に書いてみる。レトロPC修理シリーズも幸いご好評を頂きこれで8冊目になるのだが、コツコツ続けるとこうなるのか、という好例でもある。

FM77AVは個人的に好きな機種なのだが、実物で遊べたのは実際にリリースされた1985年よりもだいぶ後の1990年代であった。友人宅でシルフィードとルクソールとヴァリスを遊ばせてもらい、これは凄いな!! とひとしきり感心したものだった。その後中古をゲット、ソフトウェアもちょっとずつ揃えて遊んでいた。

今回修理マニュアルを書いたのは他でもなく、壊れたからだ。具体的にはFDDにフロッピーディスクを挿入しても噛まなくなった、というのと、外部音声出力から音が出なくなった、という二点だ。前者は一年前に修理していたのだが、後者は今回修理した。明らかに機構的な問題とアルミ電解コンデンサーの抜けによる障害だったため、グリスアップ及びアルミ電解コンデンサーの全交換で復活させた。特に困った箇所もなく、大変素直な機種だなと言うのが所感である。

二点、赤外線ユニットとFDDのアルミ電解コンデンサーの交換は行わなかった。前者はそもそも使わないという事と、後者は特に問題無く今でも動いているから、というのが理由である。前者はさておき、後者はそのうちダメになるかも知れないため、機会を見つけて追記したいと考えている。特にこの辺の追加リクエストがあれば是非お寄せ下さい。

投稿日:

SCSIデバイスエミュレーターRaSCSIの設定方法

最終更新: 2020/06/27 22:14 (執筆時最新のRaspberry Pi OS + RaSCSI 1.47で更新、ブリッジデバイス+RASDRVの項目も更新)

先日X68000初代の修理を終えたので、改めてGIMONSさんのRaSCSIの設定をいちからやり直してみた。なお、本設定の元に筆者はX68000XVIで常用している。

ちなみに、RaSCSI(ラスカジー)とは、要するにRaspberry Pi(ラズベリーパイ)をSCSIハードディスクみたいに使えちゃう、という古くて新しいナウなガジェットである。これを導入すると、何とX68000やらFM TOWNSやらPC-9801やらでSCSI起動ドライブをRaspberry Piで代替出来てしまうのである。しかもRaspberry Pi OS経由で動くのでHDDイメージをWi-Fi経由でいじくる事も可能。恐るべきレトロ未来感覚・・・(ごくり)

※SCSI(スカジー)って何ですか? と聞かれたら困るんですが、まあ要はSATAのご先祖様のIDEのもっと昔のご先祖様と考えてもらえれば。機種を超えたドライブ接続の標準規格として1980年後半から90年代前半に大流行しました。接続する各ドライブにはIDを0番から7番まで設定して接続します。7台まで数珠つなぎ(デイジーチェーン)できます。

RaSCSIはLinuxのディストリビューションであるRaspberry Pi OS(ラズベリーパイ・オーエス)の上で動くため、UNIX系の操作がある程度出来る事が前提となる。まあ、ここはしょうがないので諦めて慣れましょう。

念のため本記事の前提となっている我が家の環境も書いておく。

  • Raspberry Pi 3B + 秋月の3.0A microUSB電源
  • RaSCSIレベルコンバーターシールド(公式)
  • 30cmのSCSIケーブル(ハーフピッチD-Sub – フルピッチアンフェノール)
  • X68000XVI / PC-9821Ap / PC-9821Xs

1. Raspberry Pi 3 Model BとACアダプターとMicroSDカードを買ってくる

どこかで適当に。どこでもいいと思うけど、専門店の方がいいんじゃないかなと。近所にお店があればそちらで是非。ちなみに少し高いPi 3 Model B+や最新の4という高速モデルも出たのだが、3B, 3B+, 4どれでもOK。だが、3B+や4は発熱が強いため、安い3 Model Bの在庫があれば、総合的にそれが良いだろう。

合わせて、レベルコンバーターシールドで基板全体が覆われることになるため、放熱を考えて出来ればヒートシンクも付けておこう。

Raspberry Pi 3B/3B+ を使う場合は、3.0A USB出力のACアダプターも一緒に。出力が足りなくてちゃんと動作しないケースが多すぎるんで、最低限3.0Aは必須で是非。

Raspberry Pi 4の場合は、3.8AのUSB-Cモデルを買うこと。上記のmicro USB 3.0Aアダプターからの変換だと出力が出ないように制限されるため、正常に動作しない。必ず専用品を買うこと。これは絶対の約束。

  • http://akizukidenshi.com/catalog/g/gM-14935/

マイクロSDカードは16GB、Class 10辺りを選択すべし。遅くても動くと思うけど、余計な不安要素は最初に潰して置いた方がいいかと。もちろん、大容量のHDDを何台もぶら下げたい場合は、もっと大きいマイクロSDカードを選ぼう。

2. RaSCSIボードを買ってくる

何種類か出ている模様。筆者はは公式のfullspec版を使っているので、以下の説明もfullspec版をベースにしている。該当部分は赤字にしているので適宜読み替えを。

3. Raspberry Pi OSのインストールと設定

Raspberry PiはRaspberry Pi OS等のOSの上で動く。ので、OSを起動しないRaSCSIは動かない。まずOSの設定から。

※つまり、RaSCSIが動作するまでにはOSが起動するまでの10秒くらい待たねばならない、ということ。実際に使う際には先に電源を入れるように。

最初にRaspberry Pi OSイメージのダウンロード。Raspberry Pi OS (32-bit) Liteを選択。Lite版ではないものもあるが、GUI等余計なものが入っているし、RaSCSIの動作にはほぼ役に立たない(むしろ余計なプロセスが増えて良くない)ので、最小構成であるLite版を推奨。

イメージ書き込みはRaspberry Pi公式で推奨のソフトのEtcherをダウンロード。これでSDカードにイメージを書き込む。(もし書き込みで進捗が進まない場合は、一回マシンを再起動して再挑戦。多分それで治るかと)

書き込んだSDカードをRaspberry Piに差して起動。

  • HDMIケーブルでモニターに差す。
  • USBキーボードを差す。
  • マイクロUSB電源を差す。

マイクロUSB電源を差すと勝手に起動する。黒い画面でログオンプロンプトが出てきたら、ID: pi, Password: raspberry でログオン。

以下でWi-fi・タイムゾーン・言語の設定を行う。(“$”はコマンドプロンプトの文字なので、この文字が出ていたらコマンドを叩き、Enterキーを叩いて実行すると読んで欲しい)

$ sudo raspi-config

青い画面のメニューが出てくるので、そこから下記の設定を行う。

  • ホスト名の変更 (わかりやすい名前に変更しておこう)
    • 2 Network Options > N1 Host Name
      • (適当な名前。筆者はrascsixviとした) 
  •  Wi-Fiの設定
    • 2 Network Options > N2 Wi-Fi
      • Select the country: JP
      • SSID: <WIFI_SSID>
      • Password: <WIFI_PASSWORD>
  • 地域・エンコーディング設定
    • 4 Localization Options > I1 Change Locale
      • →ja_JP.UTF-8
      • →Default: C.UTF-8 (ja_JPを標準にするとメッセージが化けるので)
  • タイムゾーン設定
    • 4 Localization Options > I2 Change Timezone
      • →Asia/Tokyo
  • キーボードレイアウト
    • 4 Localization Options > I3 Change Keyboard Layout
      • →使っているもので。USキーボードなら変更不要。
  • 国設定
    • 4 Localization Options > I4 Change Wi-Fi Country
      • →JP
  • SSH有効化
    • 5 Interfacing Options > F2 SSH
      • →Yes
  • 更新
    • 8 Update
      • →Wi-Fi設定が合っていれば勝手にダウンロードを開始するので待つ。もしエラーが出たら上記のWi-Fi設定が間違っているので要再確認

上記が終わればFinishで完了。最後にRaspberry PiのIPアドレスを控えておく。確認する項目は”wlan0″で、IPアドレスは “inet”の項目。後ほどここに接続する。

$ /sbin/ifconfig -a

下記で手動にて再起動。

$ sudo shutdown -r now

実機での作業はここまで。以降はWindows/Mac/Linux機からSSHで接続して作業する。

4. RaSCSIのインストールと設定

Raspberry Pi OSを直接いじくるのはめんどくさいので、これ以降はリモートで作業。ここでRaspberry PiからHDMIケーブルとUSBキーボードは外してOK。電源ON状態でいきなり抜いてもOK。

まずSSHクライアントを入れる (WindowsだとPoderosa辺りで。macOSだと標準で入っているので、Terminalから”ssh -l pi <IP_ADDRESS>”で接続)。

次にSFTPクライアントを入れる (WindowsだとWinSCP辺りで。MacだとFileZillaやCyberduck辺りか)。

SSHで控えておいたIPアドレスに接続する。接続出来たら、まずOSを更新し、一旦最新にしておく。あと、時刻同期のためのNTPクライアントとしてchronyもついでに入れておこう。終わったら恐らくカーネルが最新に置き換わってる可能性大なので、一旦再起動。

$ sudo apt-get update;sudo apt-get -y upgrade
$ sudo apt-get install chrony
$ sudo shutdown -r now

10-20秒程度待って再度SSHよりログオン。

それでは本作業開始。外部マシンでRaSCSIをダウンロード。「RaSCSI version 1.47」を選択する。(バージョン番号は適宜読み替えて)

もしRaspberry Pi OS側で直接ダウンロードしたい場合は、curlというコマンドが使えるので、それで直接ダウンロードのURLを叩いてしまう。ダウンロードしたものはファイルとして保存する必要があるので、”-O”オプションを忘れずに。

$ curl <FILE_URL> -O

もしくは、リモート側でダウンロードして、RaspberryPiにSFTPで転送する。転送後、Raspberry Pi OS側でZIPを伸張する。

$ unzip rascsi147.zip

展開したファイル内の “bin/raspberrypi/rascsi.tar.gz” が本体。これを更に伸張する。

$ cd rascsi147/bin/raspberrypi
$ tar xvzf rascsi.tar.gz

これでRaSCSI側の基本準備は完了。

次に、SCSI HDDイメージを作成する。作成はXM6で。XM6のインストールや操作方法は割愛。XM6を起動させ、メニューの”Tools > Make a new SCSI Fixed Disk”でSCSI HDDイメージを作成する。一旦XM6の最大値である4GB(4096MB)で作成しておいてもOK。

但し、SCSIとして利用する機種・OSによって最大値が決まっているのでそれに従う。例えば、X68000でSCSI利用であればブートパーティションは1GB以内であるべきだし、更にそこにXCをインストールする場合は768MB程度に抑えておかないと途中でエラーで止まる、等々の制約があるのでそれに倣うよう。PC-9801/PC-9821系であれば、544MBの壁等が機種やSCSIボード・OSごとにあるため、あらかじめ調べておこう。

作ったHDSファイル(以下ファイル名を”x68000scsi0.hds“とする。何でもOK)をSFTP等でRaspberry Pi OS側のrascsiディレクトリーへ転送する。転送が終わったら、基板に応じてバイナリーを選択し起動してみる。(ここではfullspec版の例)

$ sudo fullspec/rascsi -ID0 x68000scsi0.hds

正常に起動したら以下のメッセージが出る

SCSI Target Emulator RaSCSI(*^..^*) version 1.47(Apr 11 2020, 23:01:38)
Powered by XM6 TypeG Technology / Copyright (C) 2016-2020 GIMONS
Connect type : FULLSPEC

+----+----+------+-------------------------------------
| ID | UN | TYPE | DEVICE STATUS
+----+----+------+-------------------------------------
|  0 |  0 | SCHD | x68000scsi0.hds
+----+----+------+-------------------------------------

上記がうまく動いたら、起動しっぱなしで停止する。そのままではどうしようもないので、一旦Ctrl+Cで停止させる。

5. RaSCSIの自動起動設定

一旦うまく動いたらしめたもの 。が、このままではRaspberry Piの電源をOFFにしたらプロセスが未起動状態となり、また上記の起動を手動で行わねばならなくなる。自動で全部Ready状態にするために、下記の作業を最後に行う。

まず、HDDイメージファイルであるHDSファイルをOS上適切な位置に配置する。SysV以降の習わしとしては、可変ファイル(variable files)は /var 配下に置くことが決まっているため、RaSCSIもそれに従おう。/var/rascsi ディレクトリーを作成し、そこに移動する。

$ sudo mkdir /var/rascsi
$ sudo mv x68000scsi0.hds /var/rascsi

次に、RaSCSIをRaspberry Pi OS上の適切な場所へ移動する。apt等で管理されない所謂「オプショナルパッケージ (optional packages)」は/optに置くのが同じくSysV以降の習わしなのでまず移動。複数のバージョンを管理したいのと、バージョンアップ時に楽をしたいので、バージョン番号付きのディレクトリーにリネームしながら移動して、シンボリックリンクを張っておく。これで新しいバージョンが出てもシンボリックリンクの作り直しだけでOK。

$ cd rascsi147/bin
$ sudo mv raspberrypi /opt/rascsi-1.47
$ sudo ln -s rascis-1.47 rascsi

※もし、RaSCSIが将来バージョンアップした場合は、シンボリックリンクを張り直してやろう。下記は1.48(執筆時点ではまだ出てない)が出た場合の例。RaSCSIのデーモンを停止し、”rascsi”のシンボリックを最新のディレクトリーに張り替えて、デーモン再開、という処理となる。

$ sudo systemctl stop rascsi
$ sudo mv raspberry /opt/rascsi-1.48
$ cd /opt
$ sudo rm rascsi
$ sudo ln -s rascis-1.48 rascsi
$ sudo systemctl start rascsi

次にRaSCSIの起動スクリプトを作る。

$ cd /etc/systemd/system/
$ sudo nano rascsi.service

テキストエディターnanoで新規作成された「rascsi.service」に対し、下記をコピペする。(もちろんvimが使える方はそちらでも)

[Unit]
Description=RaSCSI
After=syslog.target

[Service]
Type=simple
WorkingDirectory=/opt/rascsi
ExecStart=/usr/bin/sudo fullspec/rascsi -ID0 /var/rascsi/x68000scsi0.hds
TimeoutStopSec=5
StandardOutput=null

[Install]
WantedBy = multi-user.target

上記をCtrl+X → [Enter]で保存する。systemctlに認識されるようになるので、rascsiプロセスを自動起動に設定する。

$ sudo systemctl enable rascsi

Created symlink /etc/systemd/system/multi-user.target.wants/rascsi.service → /etc/systemd/system/rascsi.service.

設定が終わった。自動起動するように変更されているはずなので、念のため再起動してみる。

$ sudo shutdown -r now

再起動後にプロセスが自動起動しているか確認する。SSHで再接続し、下記を叩いて表示が出ることを確認する。出ない場合は正常起動していないので、上記設定を再確認。

$ cd /opt/rascsi
$ fullspec/rasctl -l

+----+----+------+-------------------------------------
| ID | UN | TYPE | DEVICE STATUS
+----+----+------+-------------------------------------
|  0 |  0 | SCHD | /var/rascsi/x68000scsi0.hds
+----+----+------+-------------------------------------

6. X68000等にSCSI接続してみる

ここから先はFM TOWNSだったりPC-9801だったりと各者各様で良いかと思うので具体的には割愛。SCSIコネクターに接続し、先にRaspberry Piの電源を入れて10秒くらい待って、マシンを起動すれば、(ある場合は)RaSCSIボード上のランプが光ってマシン上でDevice ID: 0として認識する。あとはOSのインストール等々、通常のSCSI HDDとして煮るなり焼くなり好きにするが良い。

更に、X68000だけの特別追加機能として、イーサネット機能及びホストファイルシステム(ホスト機でSCSIドライブをネットワークドライブとしてマウントできる機能)等がある。詳しくは付属ドキュメントの”doc/x68k.txt”を参照のこと。多分ここで書くよりそちらを参照した方が良い。というかこの2019年に実機でSCSI使える人ならそんなこと書かなくても分かるでしょ! (が、あとで書くかも)→下に書きました

7. X68000からRaspberryPiのファイルシステムを丸見えにする

結局書いてしまった・・・ということで続き。RaSCSIにはX68000専用に二つの機能が提供されている。ひとつがRaspberryPiのEthernet機能を使わせてもらうネットワークデバイスドライバー”RASETHER.SYS”、もうひとつがRaspberryPiのファイルシステムを直接参照できるファイルシステムドライバー”RASDRV.SYS”。

前者は実際問題としてクライアントソフトとして古くさいtelnetソフトウェア等を使うことになりセキュリティー的に疑問なのでここでは取り扱わず、安全な後者の解説に留める。

この後者”RASDRV.SYS”であるが、下記の設定でX68000からRaspberry Pi OSの中身を参照できる。ので、あとはRaspberry Pi OS側とWindowsやらMacやらとSFTP辺りでファイルをやりとりできれば、何と稼働中のX68000とリアルタイムでファイル連携が出来るのである。何という万能感。X68000とのファイルのやりとりのためにSCSIのMOドライブを繋いでおく時代は遂に終わったのです(いや、とはいえ便利なのでMO環境は残しておいた方がいい気もする・・・)。

まず、RaSCSIの配布パッケージに含まれている “bin/x68k/RASDRIVER.HDS”のHDDイメージにRASDRV.SYSが含まれている。これをRaSCSIにマウントさせるだけでX68000からRASDRV.SYSを操作できるようになる。まずはここからだ。

手順としては下記となる。

  1. RASDRIVER.HDSをコピーする
  2. ブリッジデバイスとRASDRIVER.HDSをマウントさせる記述を追加、RaSCSIデーモンを再起動させRASDRIVER.HDSを認識させる
  3. X68000を再起動してRASDRIVER.HDSのドライブを認識させ、RASDRV.SYSをAドライブにコピーしてCONFIG.SYSを書き換える
  4. あと片づけ

では順番に見ていこう。

7-1. RASDRIVER.HDSをコピーする

RASDRIVER.HDSはRaSCSIの配布イメージの中に含まれている。これを/var/rascsiにコピーしよう。

$ sudo cp bin/x68k/RASDRIVER.HDS /var/rascsi

7-2. ブリッジデバイスとRASDRIVER.HDSをマウントさせる記述を追加する

これは上記で記述したスタートアップ設定ファイルに追記するだけだ。

$ sudo vi /etc/systemd/system/rascsi.service

中身をこのように変更しよう。緑色の箇所が追記したポイントだ。-ID1が仮想ドライブ用のブリッジデバイス名、-ID2がRASDRIVER.HDS用だ。この「ExecStart=」から「.HDS」までは一行で記載しよう。

[Unit]
Description=RaSCSI
After=syslog.target

[Service]
Type=simple
WorkingDirectory=/opt/rascsi
ExecStart=/usr/bin/sudo fullspec/rascsi -ID0 /var/rascsi/x68000scsi0.hds -ID1 BRIDGE -ID2 /var/rascsi/RASDRIVER.HDS
TimeoutStopSec=5
StandardOutput=null

[Install]
WantedBy=multi-user.target

これで再認識&再起動させる。きちんと認識しているかどうかまでrasctlを起動して確認を入れておこう。緑色の行が出ていれば成功。

$ sudo systemctl daemon-reload
$ sudo systemctl restart rascsi
$ /opt/rascsi/fullspec/rasctl -l

+----+----+------+-------------------------------------
| ID | UN | TYPE | DEVICE STATUS
+----+----+------+-------------------------------------
|  0 |  0 | SCHD | /var/rascsi/x68000scsi0.hds
|  1 |  0 | SCBR | HOST BRIDGE
|  2 |  0 | SCHD | /var/rascsi/RASDRIVER.HDS
+----+----+------+-------------------------------------

7-3. X68000を再起動してRASDRIVER.HDSのドライブを認識させ、RASDRV.SYSをAドライブにコピーしてCONFIG.SYSを書き換える

X68000を再起動させる。RASDRIVER.SYSはDドライブに登録されている筈である。中身にあるRASDRV.SYSをAドライブのどこかにコピーする(下記ではA:\SYS。どこでもよい)

>b:
>copy RASDRV.SYS a:\SYS

 “A:\config.sys” を開いて、RASDRVを登録してやる。

A:\> ed config.sys

下記の行を “DEVICE=” の最後の行に追加する。

DEVICE = \SYS\RASDRV.SYS

書き終わったら “ESC → E”で保存。その後にX68000のリセットボタンを押して再起動。起動時のログにD:ドライブが追加された、という下記のようなメッセージが出れば成功。

RaSCSI FileSystem Driver version 1.42
ドライブE:を登録しました

あとは起動完了後にEドライブを覗いてみれば・・・あら不思議、X68000からRaspberryPiの全てが見える!!

あとは、RaspberryPiに向けてSFTPでファイルを “/home/pi” 辺りに転送してやれば、X68000からは “E:\home\pi” で参照出来る訳です。無線でX68000とファイルのやりとりが出来るなんて21世紀は何て素晴らしいんでしょう!!!

ちなみに、Raspberry Pi OSのルートから公開したくない場合は、”config.sys” の設定で下記のように記載すれば “/home/pi” の直下が “E:” ドライブの直下として見えるので、そのようにしても良いだろう。いやむしろそうした方が良いかもしれない。お好み・用途に応じて。

DEVICE  = \SYS\RASDRV.SYS /home/pi

7-4. あと片づけ

このまま使ってもらっても良いのだが、RASDRIVER.HDMのBドライブへの登録が残った状態になっている。最後に外してやろう。Raspberry Pi OS側に戻り、登録を外す。

$ sudo nano /etc/systemd/system/rascsi.service

サービス定義からRASDRIVER.SYSを外す。

[Unit]
Description=RaSCSI
After=syslog.target

[Service]
Type=simple
WorkingDirectory=/opt/rascsi
ExecStart=/usr/bin/sudo fullspec/rascsi -ID0 /var/rascsi/x68000scsi0.hds -ID1 BRIDGE
TimeoutStopSec=5
StandardOutput=null

[Install]
WantedBy=multi-user.target

リロードし、念のためドライブ状況を確認しておこう。RASDRIVERの行が無くなってれば成功。

$ sudo systemctl daemon-reload
$ sudo systemctl restart rascsi
$ /opt/rascsi/fullspec/rasctl -l

+----+----+------+-------------------------------------
| ID | UN | TYPE | DEVICE STATUS
+----+----+------+-------------------------------------
|  0 |  0 | SCHD | /var/rascsi/x68000scsi0.hds
|  1 |  0 | SCBR | HOST BRIDGE
+----+----+------+-------------------------------------

最後にX68000を再起動させる。RASDRVがDドライブに変更されたはずである。前記「E:」で書いた箇所は全てD:に変更されているので読み替えを。もちろん、HDSイメージを何個もマウントするとこのドライブ名が後ろにどんどんズレていくことになるのでご注意を(これは恐らくHuman68Kの仕様)。

RaSCSI FileSystem Driver version 1.42
ドライブD:を登録しました

 

それではお宅のレトロマシンの幸せなSCSIライフを!!!

投稿日:

Java EE 8で何が変わったのか?

Java EE Advent Calendar 2017の23日目です。昨日は@suke_masaさんの「Java EEにMVCはなぜ必要なのか」でした

はじめに

今年はJavaOne 2017で1枠、Oracle OpenWorld 2017で1枠、Japan Sessionで1枠と、3枠の公演をしてきました。その共有会を福岡で12月に実施したのですが、そこで取り扱ったJava EE 8での差分について、改めてこちらにまとめておきます。

なお、類似の話は恐らく各所にあると思うので、読み込んでいるプロな方には今更感が満載だと思います。が、Advent Calendarはそういう趣旨では無いと思いますので、まあこういう記事があってもいいじゃないですかね。という感じで。

Java EE 8仕様が出ました

まず、今年のJavaOne 2017 (のちょっと前に)でJava EE 8がリリースされました。Java EEは特定の製品でも何でもなく「アプリケーションサーバーの標準仕様」となります。

※なので軽い気持ちで「Java EEは品質が悪い」とか「遅い」とか放言すると、周りの技術者から冷酷な目で見られるので注意しましょう(笑)

そのため、Java EE 8仕様に準拠したアプリケーションサーバーはこれから登場します。Java EE仕様策定に参加している会社・コミュニティー間で合意が取れ、標準仕様が決まったばかりですので。現時点ではとりあえず参照実装の位置づけであるGlassfish 5がリリースされています。また、商用製品としては、製品版以前の状態としては、Payara 5 Beta 1がリリースされています。

※当然ですが、実稼働システムを検討する場合、Glassfishは絶対に選ばないで下さい。セキュリティーパッチが出ません。 これは旧4系でも同じです。速やかに商用版であるPayaraもしくは別の製品に移行しましょう。

なお、Java EEの開発はこのあとEE4Jというプロジェクトに移管されることになっていますが、この件は本記事とあまり関係ないので飛ばします。Java EE 8より先の話です。

Java EE 8の差分について

Java EE 8仕様は、1999年末に出たJ2EE 1.2仕様から数えて6回目のメジャーバージョンアップとなります。メジャーバージョンアップなので各種の改善と非互換が出ています。本記事の要旨はここになります。

なお、Java EE仕様の暗黙のルールとしては、「過去の技術は二つ前の仕様までサポートする」となります。例えば「Java EE 8仕様に準拠したアプリケーションサーバーは、Java EE 6仕様に準拠したアプリケーションを動かすことが出来る 」というものです。Java EE 6は2009年末に出ていますので、約8年間以上は大丈夫、という実績があります。まあ、古いアプリケーションサーバーを使えばもっと行けるので、10年ちょいは間違いなく大丈夫でしょう。Java EE仕様でアプリケーションを作成する場合は、できるだけ最新仕様を使うようにしましょう。

これは裏を返せば、Java EE 8仕様のアプリケーションサーバーは遂にJava EE 5仕様のアプリケーションが動かなくなります。Java EE 5仕様自体は2010年頃まで普通に使われていましたので、移行を検討しましょう。商用アプリケーションサーバーによっては、ひょっとしたらサポートしてくれるものがあるかも知れませんが分かりません。もしくは、Java EE 5が動くアプリケーションサーバーを後生大事に取っておくか、です。EOLの後でも数百万～数億となる大量のお金を投入すれば可能でしょう。この領域には余り興味がありませんが・・・

※ちなみにWikipediaのJava EEの項目を見たところ壮絶に古い記載で今となっては不適切だったりするので、そのうち書き換えます。

さて、そんなJava EE 8ですが、EE 7との差分がどれだけあるかというと、然程ありません。それだけEE 7仕様が優れていたということでもあるのですが、要は明らかに足りなかった機能を追加しました、という感じのメンテナンスリリースと捉えてもらえれば間違いないかなと思います。なのでエンプラ界隈が「Java EE 8が出た! これからはEE 8で未来が変わる!」というような感じになっていないのは正しい反応です。

ちなみにJava EE 8は本来、去年のJavaOne 2016で発表予定だったのですが、急遽延期になってしまった経緯があります。その影響か、Java EE 8ネタでJavaOne 2016のCall for Proposalに応募していた末席の私はもちろん、その界隈で著名な方々(Oracle社員除く)も丸ごと落とされてしまい、人知れず枕を涙で濡らしたのでした。そんな遺恨もあり、界隈のJava EE 8への視線は更に厳しいものになったのですが、実に余談なのでこれ以上は止めておきましょう。

さて、次からは技術記事らしく、中身を見ていきましょう。

Java EE 8の変更点1: Deployment Descriptorの変更

Deployment Descriptor (DD)と書くとEJB 2系以前に必須であったDDであるejb-jar.xmlを思い出して拒絶反応を示す人が未だに多いですが、それだけではなくWARの中にあるweb.xmlも、JPAで使うpersistence.xmlも立派なDDなので、混同しないようにしましょう。ちなみに、ejb-jar.xmlはEJB用としてまだ使えますが、アノテーションで代替出来るため不要となりました。もしあれば、アノテーションより優先して扱われるものとなっています。

さてこのDDですが、XMLであるため冒頭にXML SchemaのXSDを指定するようになっています。こんなのどうでもいいじゃん、と思いがちですが、実はアプリケーションサーバーはこのXSDを参照して「このアプリケーションはどのJava EE仕様に則って作られているのか」を判断しています。例えばweb.xmlを古いまま使い回しているWARであれば、古いままのJava EE仕様で動作してしまうということです。新機能を使おうと思ったんだけど呼び出されない、等々で何日も悩む羽目に陥らないよう、まず最初に書き換えましょう。

例:  web.xml

[code lang=”xml”]
<web-app xmlns=http://xmlns.jcp.org/xml/ns/javaee
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
version="4.0" metadata-complete="true">
…
</web-app>
[/code]

例えば上記のような感じです。一覧はこちらにありますのでどうぞ。 http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html

Java EE 8の変更点2: Security APIの追加

これは大きい変更です。Webシステムでログオン有無の管理は従来自前で処理するものでしたが、他のプラットフォームではあって当たり前な感じにもなっています。何で無いのよ、と訝しげに思う人も居たと思いますが、遂に追加されましたよ!

[code lang=”java”]
UsernamePasswordCredential cred
= new UsernamePasswordCredential(
entity.getUserName(), entity.getPassword());
AuthenticationParameters params
= AuthenticationParameters.withParams().credential(cred);
AuthenticationStatus status
= securityContext.authenticate(httpServletRequest,
httpServletResponse,params);
[/code]

プログラム上のAPIを呼び出すコードは上記の感じで簡単ですが、問題はこのコードがどう動くべきか、をカスタマイズなり設定なりが必要となります。そりゃぁ、企業システムのID管理なんて千差万別な訳ですよ。Active Directoryだったり生LDAPだったりデータベース+JSONだったりと。対象が社員だったり顧客だったりするとまあ更にバリエーション豊かになります。そういうのを吸収するAPIとして制定されているようです。

例えばデータベースへ問い合わせする場合は、このようなアノテーションをAppliationConfig.java辺りに書く感じです。これなら分かりやすいかな?

[code lang=”java”]
@DatabaseIdentityStoreDefinition(
dataSourceLookup="java:global/MyDS",
callerQuery="select password from user where user_name = ?",
groupsQuery="select group_name from user_groups where user_name = ?"
)
@ApplicationScoped
@Named
public class ApplicationConfig {
…
}
[/code]

なお、標準機能としてはLDAP接続とデータベース接続辺りがサポートされていて、更にカスタムで接続を実装することが可能となっています。なのでどんな認証でもこのAPIで吸収することが理論的に可能と考えられます。恐らくこのあと実装例が多々出てくると思いますので、それを待っててもいいかもですね。

詳しくは@kodukiさんの「Java EE Security APIが街にやってきた！」でもっと詳しくありますので、気になる方はそちらへどうぞ。

Java EE 8の変更点3: JSON-Bの追加

つぎ、JSONとJavaプログラムを相互に変換するAPI、通称JSON-Bが追加されました。これ、慣れてる人だと、Java EE 7でCDIがREST対応した際にもJSONは使えたので、何を今更? という感じではあるかもですが、正式な単独仕様として追加されました。JavaオブジェクトからJSONへの変換は特にRESTの呼出し元側で必要となったりするので、この仕様は特にJavaFXや単独Javaアプリケーション辺りで特に使えるのではと感じます。

たとえばこんなJavaのクラスに値が詰まってたとして

[code lang=”java”]
public class Dog {
public String name;
public int age;
public boolean bitable;
}
[/code]

これをこんなJSONに変換したい、となると、

[code lang=”json”]
{
"name": "Falco",
"age": 4,
"bitable": false
}
[/code]

こんなコードだけで行けちゃいます。

[code lang=”java”]
// Serialize. Java to JSON
Jsonb jsonb = JsonbBuilder.create();
String dogJsonResult = jsonb.toJson(dog);

// Deserialize. JSON to Java
String dogJson = "{\"name\":\"Falco\",\"age\":4,\"bitable\":false}";
Dog deserializedDog = jsonb.fromJson(dogJson, Dog.class);}
[/code]

便利ですねぇ。便利すぎてアホになっちゃいそうです。入出力の細かい制御をしたければ更に色々出来ますが、通信相手側のの謎仕様JSONに合わせねばならない場合以外にはあまり使い道が無さそうではあります。

Java EE 8の変更点4: CDI 2.0

CDI (Contexts and Dependency Injection)がメジャーバージョンアップしました。要は昔流行ったDI(依存性注入)やアスペクト指向です。まあ、バズワードの一種ではありましたが、一部便利になったことは間違いないでしょう。Java EE内の位置づけとしてはポストEJBという感じで徐々にEJBの機能を絶賛移植中です。もっとドバーと一気に移植しちゃえばいいのにと思わなくも無いですが、そこまで重量級のものも要らないよね、ってことなのかも知れません。

まず追加されたのが、非同期イベントが使えるようになりました。EJBの@Asynchronous相当と思えばいいですが、もうちょっとややこしい感じです。EJBのように呼ばれ側で書くんじゃなくて、呼び元で書くという感じで、逆になってます。event.fireAsync() というメソッドを使います。

次に、EJBTimerに相当するスケジューラーをCDIからも使えるようになりました。ついでにEJBの@Startupも使えるようになりました。これはCDIコンテナーが初期化するタイミングで最初に呼ばれるメソッドです。初期化処理はここでやりましょう。

最後に、これが一番大きいのですが、Java SE環境でCDIが使えるよう仕様として公式にサポートされました。これまでも実装側で対応してたと思いますが、公式サポートは大きい。これで大手を振ってJava SE環境、特にJava SE環境で自己起動するような軽量なバッチ処理や、クライアント系アプリケーション、例えばJavaFX環境などでCDIを思う存分使いこなせるでしょう。

とりあえず動かしたい場合は、Mavenにこれを追加して・・・

[code lang=”xml”]
<dependency>
<groupId>org.jboss.weld.se</groupId>
<artifactId>weld-se-core</artifactId>
<version>3.0.2.Final</version>
</dependency>
[/code]

こんな空のMETA-INF/beans.xmlを追加して・・・

[code lang=”xml”]
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
bean-discovery-mode="annotated">
</beans>
[/code]

こんなコードで動きます。

[code lang=”java”]
public static void main(String… args) {
try (SeContainer container
= SeContainerInitializer.newInstance().initialize()) {
MyBean myBean = container.select(MyBean.class).get();

myBean.doWork(); // DO SOMETHING.
}
}
[/code]

一回CDIを呼び出しちゃえばその先はCDIワールドなので@Injectでインジェクションしまくっちゃって良い感じかと。上記のコードだと、myBean.doWork()の先からめくるめくCDIワールドです。CDIにはとりあえず@Dependentもしくはスコープのアノテーションを必ず付けましょう(CDI 1.1以降の約束)。

Java EE 8の変更点5: Servlet 4.0

これは純粋にベース技術の更新であるHTTP/2にやっと追随しました、というものですね。他のプラットフォームは早々と対応していたので、「今頃!?」という感じでもあります。周回遅れ感が辛いところではありますが、もっと早く仕様が決まるような新体制になってくれればなぁと祈念致します。

[code lang=”java”]
@WebServlet(value = {"/http2"})
public class Http2Servlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) {
req.newPushBuilder()
.path("images/file.png")
.addHeader("content-type", "image/png")
.push();
try (PrintWriter respWriter = resp.getWriter()) {
respWriter.write("<html><img src=’images/file.png’></html>");
}
}
}
[/code]

Java EE 8の変更点6: JSF 2.3

これは最もデカい更新です。書くのが多すぎてどれから書くべきか悩むくらいありますが、順番に。

まず、Java EE 5時代の懐かしのJSF Managed Beanが遂にDeprecatedになりました。実にめでたい話です。今や何のメリットも無いので、それらはCDIに書き換えましょう。一対一で書き換えられるので、特に悩むこともないですし、一気にスクリプトで書き換えるのもありかも知れません。ただ、JSFのイベント内やFacesServletの前にFilterを置いて、仕様に無いようなハッキングに近い処理をやっていた場合は、その部分の全面書き直しになります。いずれにせよ、移行には充分なテストを行うようにしましょう。

次に、<f:event type=”postRenderView/> が追加され、遂に最後のイベントが拾えるようになりました。これは画面描画が終わった後のイベントなので、何か後処理が必要だったりする場合限定です。なくても困らないですが、ないより有る方が良いですね。

細かな改善系だと、セッション周りとの相性が最悪だったAjax関連機能の改善があります。壮絶に頭の悪い仕様だったラジオボタンもレイアウティングに対応し、やっと使えるようになってくれました。他にもInjectできる数が増えたという嬉しい話があります。特に使用頻度の高いと思われるExternalContext辺りがこんなコードで拾えるようになりました。遅いよ・・・

[code lang=”java”]
@Inject private ExternalContext context;
[/code]

 

Artefact EL name Qualifier Type
Application #{application} – java.lang.Object (javax.servlet.ServletContext)
ApplicationMap #{applicationScope} @ApplicationMap java.util.Map<String, Object>
CompositeComponent #{cc} (Not injectable) javax.faces.component.UIComponent
Component #{component} (Not injectable) javax.faces.component.UIComponent
RequestCookieMap #{cookie} @RequestCookieMap java.util.Map<String, Object>
FacesContext #{facesContext} – javax.faces.context.FacesContext
Flash #{flash} – javax.faces.context.Flash
FlowMap #{flowScope} @FlowMap java.util.Map<Object, Object>
HeaderMap #{header} @HeaderMap java.util.Map<String, String>
HeaderValuesMap #{headerValues} @HeaderValuesMap java.util.Map<String, String[]>
InitParameterMap #{initParam} @InitParameterMap java.util.Map<String, String>
RequestParameterMap #{param} @RequestParameterMap java.util.Map<String, String>
RequestParameterValuesMap #{paramValues} @RequestParameterValuesMap java.util.Map<String, String[]>
Request #{request} (Not injectable) java.lang.Object (javax.servlet.http.HttpServletRequest)
RequestMap #{requestScope} @RequestMap java.util.Map<String, Object>
ResourceHandler #{“resource”} – javax.faces.application.ResourceHandler
Session #{session} (Not injectable) java.lang.Object (javax.servlet.http.HttpSession)
SessionMap #{sessionScope} @SessionMap java.util.Map<String, Object>
View #{view} – javax.faces.component.UIViewRoot
ViewMap #{viewScope} @ViewMap java.util.Map<String, Object>
ExternalContext #{externalContext} (new) – javax.faces.context.ExternalContext

あと、新しい技術への対応としては、WebSocket対応 (<f:websocket>、PushContextあたり)もあります。

また、基礎技術面ではJava SE 8にもようやく対応しました。例えばNew date time APIに対応した、何故か対応していなかったExternalContext#getInitialParameterMapやらConverterやらValidatorやら。

そんなこんなで大量改善があったJSFで、これだけで1冊本が書けそうです。Web系は動きが速いので、この調子でガンガン更新していって欲しいものです。もっと激しくてもいいくらい。

Java EE 8の変更点7: JPA 2.2

さて、最後にJava Persistence API 2.2、つまりデータベースとのやりとりの場所です。ちょっとした改良に止まっています。

まず、Java SE 8対応、それに伴ってNew date time APIに対応しました。ので、やっとJDK 1.1~1.2頃に整備されたカビの生えたようなjava.sql.Dateやjava.util.Timestamp辺りともおさらばです。新たにLocalDate, LocalTime, LocalDateTime, OffsetTime, OffsetDateTime辺りが日付型カラムとの自動マッピング先として使えるようになりました。

また、Java SE 8関連として、Repeatable annotationに対応しています。これはひとつのメソッドに同じアノテーションを複数書けるようにしました、というちょっとした小改良に追随したものです。プチ改良。

あとはAttribute ConverterでCDIがインジェクト出来るようになったとか、ちょっとしたメソッドが追加されたとか、その程度です。

まとめ

さて、ここまでざーっと見てきました。華々しいJSFの改良と比較して、それ以外は実質的に小改良に留まっています。要は今Java EE 7で開発を進めている方はそんなに心配せずとも、後でゆるりとEE 8対応、でもいいんじゃないかな、と思います。そもそもまだ商用アプリケーションサーバーがひとつもEE 8対応していません。代表的なJava EE対応IDEであるNetBeansも本稿記述時点で未対応です(Githubからの要自前clone & ビルド)。

元々、Java EEの最新版はリリース後1年くらい経過してから採用を、という流れですので、ここは慌てず、Glassfish 5やPayara 5 Beta辺りを使って、じっくりとバージョンアップのためのプロトタイピングを進めておくのが得策でしょう。来年のJavaOne 2018 (があれば) で商用サーバーがひととおり揃うのではないかと推測します。楽しみですね。

 

明日は@khasunumaさんの「これから Java EE を始める方へ」です。

投稿日:

平成28年の振り返り その3 ビンテージPC篇

長くなったので3分割した3つ目です。ビンテージPC系をまとめました。

去年後半は、それまで確保してきたPCをひたすら修理する事に明け暮れました。引っ越しを機に棚卸しができ、丁度壊れ始めた頃だったPCを修理しつつ、これまで持ってなかった機種にも幸運に巡り会えたため、それもまた修理するという地獄絵図でした(笑）。

そもそも1980年代のビンテージPCを遊ぼうとすると、その大半は壊れているのが普通であり、ごく希に修理済みのものが大変高値で取引されていたりします。ただ、趣味にはあまりお金を掛けない主義の私としては、自分で修理出来てこそ長く遊べるだろう、とう信念の下、ついでに自分で修理する技術を獲得していこう、と決め、実行してきました。

お陰様で失敗も多々ありましたが、年末に修理したPC-88VAをはじめ、多くの成功事例も重ねることが出来ました。TwitterのレトロPCクラスターの方々にも多く助言をいただき、修理スキルとしては格段にレベルアップできた一年でした。勿論、PCの動作原理も更に深く理解出来た気がします。1980年代の、という枕詞が付きますが(笑）。まあ、最新のPCとかIoTも根っこの部分は大して変わってないので、勉強と思えば安いものです。

まずドツボにはまったのは、間違いなくこの辺から・・・

このボロボロのPC-6001mkIIを修理すべく奮闘するのですが、どうも動かない。まずはタンタルコンデンサーの総取っ替えから。

が、動かず。RFユニットがダメ？

途中で海外出張等を経て、頭を冷やしてもう一度やり直し。

結局ビデオ出力で動きました。修理成功。うっかり間違いは良くないですね。

その直後西田ラジオさんからスプライト機能拡張付PC-6001mkII用VGAアダプターが届き、中間色を含めた16色表示環境が完全復活。

その後ばくてんさんの所から戦士のカートリッジver.2.0が届き、いろいろ便利になりました。

このP6版Ys-IIは実機動作させると衝撃度が凄いです。

そしてベルーガの本物も。この突き抜けたクオリティが素晴らしい。それもこれもP6を修理出来た上にあるわけで、ここで味をしめていろいろ手を出す（＝沼にはまる）のでした。

平行で福岡FM爆音会で見たしらけんさんのPC-9821Ltがいいな、と思って数千円でこれを入手。これは乾電池漏れで中身が死んでいて、修理してるうちに液晶の同期が合わなくなり死んでしまいました。残念無念。

あまりにも奮闘が長すぎるので結論へ。動きませんでした。残念ー。修理してる最中に熊本の震災が起き、それどころじゃなくなりました、ということもあります。まあ、集積度の高い98ノート修理は鬼門ですね・・・

その後、懲りずに九州電遊博で大量にゲット。PC-8801mkIIMR、PC-9801UV21、PC-9821Ap2/M2の3台。これを修理しはじめる訳です。書いててうんざりします(笑）

そしてその前に死蔵してた初代X68000を修理。

これは成功。電池交換だけで済みました。初代は情報が少なく、特に電源周りではいろいろ手間取りましたが、何とかクリア。

電源は綺麗で特に死んでませんでした。いろいろ聞くところによると、初代機は比較的丈夫だそうです。環境にも依るかな。下記Tweetで書いてる「電解液」は、単なるホットボンドの白でした。

そしてゲームは動く。成功。

これで勢いを増して修理開始。まずは簡単そうなPC-9801UV21より。FDD含め分解清掃したらあっさり動きました。

ただし、ビデオ周りでエラー音が出て、縦線が出る状態。ROMの足の接触か、電解コンデンサーもしくはタンタルコンデンサー死亡でノイズが除去出来てない状況か、どちらかと考えられます。

どっちにしても面倒くさいので一旦放置で次。時間を作ってROM周りを綺麗にしてみます。それで治らなかったら、タンタル＆アルミ電解コンデンサー全交換コース。実に面倒です。

次、PC-9821Ap2/M2。非常に珍しい5.25インチドライブ版。表面実装電解コンデンサーの死亡率が極めて高い凶悪な機体として悪名をとどろかせています。

電解コンデンサーがかなり酷い状況、というか全滅状態なので全部交換することに。

が、案の定動かず。原因として考えられるのは(1)電解コンデンサー漏れが激しい箇所で見えない所のパターンが朽ち果てている、(2)電源の5Vか12Vが不安定でシステムが起動しきれない、辺りかと。前者は特定がかなり難しいが、後者であれば(今であれば)電源修理でなんとかなる。

ということで最後のPC-8801mkIIMRへ。

いきなり難所。背面ネジが錆びて朽ち果てている。開けられない。強引にネジザウルスで頭を破壊しながら回転。無事抜き取った。

何とそのまま動いた。FDDがやばそうな感じ。

Twitterに書くのを忘れてたけど、ドライブ1側のノブシャフトが強い力で折れ曲がっていたので、力任せにまっすぐに伸ばし、芋ネジで位置を調整して分解清掃。これで治った。

結果修理大成功。我が家にSRに続き2台目のPC-88SR以降4Mhz機が。

プロテクトのお陰で起動タイミングがシビアすぎるドラゴンスレイヤーも無事起動。完全復活の名に相応しい。

この後、FM爆音会に持っていって大活躍しました。持って行くに当たって、掃除機並みの爆音ファンを静音ファンに交換しました。風量はそこそこ確保出来ているため、問題無さそう。ただ、夏場や8Mhz機に究極静音型はちょっと考えた方がいいかもです。

FM音源も完璧。SSG音とのバランスもおかしくない。

ということで大活躍でした。

今年はこれで終わりかな、と思ってたら最後に伏兵が。何と、ひょんなことからPC-88VA(初代）をゲット。だってお店にある、って言うもんだから・・・

で、開腹したら壮絶なゴミの山。人生で一番汚いPCに出会った感じ。これは幾ら何でも生きてないだろうとこの時点で覚悟しました。

ところが、何とこの機体、かなりレアなPC-88VA専用サウンドボードIIを内蔵していることが判明。ぶつくさ文句言いながら作業してたらUME-3に教えてもらいました(笑）

で、綺麗にして周りを見廻すと、やっぱり電源のコンデンサーの防爆弁が膨らんでいるのが気になったので、人生初の電源修理に挑戦。もちろん、事前に数年間Webでかなりの事例を見て調べてます。元々X68000の電源を修理するつもりが何の因果か当時のライバル機側を修理する事になるとは。しかも両方初代機。

いろいろな事例を見てると、一番でっかいコンデンサーを交換しない事例が多数見られたのですが、この電源の場合は例外なく全て交換しました。全て105℃品で統一しています。理想を言えば電源用の数個上のグレードが相応しいということを後で知ったのですが、まあそんなに88VAで長時間遊ぶことも無いと思うので一旦これで良いでしょう。そもそも対応ソフト少ないし。

もちろん、電源修理は危険なので、特に半田付けを原因とする短絡事故には気をつけましょう。最悪、丸ごと燃えて火事になります。

無事だったので組み上げて、V2モードで動作成功。

V3モードも成功。

ということで、何というか奇蹟というか、年末に絶対死んでると確信していたPC-88VAが動いてしまいました。気をつけたのは、電池漏れで緑色や茶色に表面が錆びている箇所を無理にIPA等で拭かず、そのままにした、ということです。将来サビが進行して死ぬかも知れませんが、元凶を取り去っているため進行は遅く、仮にパターンが切れたときにはそのときに都度ジャンパーを飛ばして対処するのが正しそうです。

ということで3回に渡ってまとめた平成28年（2016）のまとめ、一旦これで終わりにします。他にもジャンクのPS2とか家庭用機を修理したりしてるんですが、まあネタ的に面白そうなのはこの辺かなと思うのでこの辺で。しかし、見事にNEC機ばかりですね。かなり普及してたという事もありますが、逆に壊れやすいということもあるかと思います(笑）。ひとこと言いたい点としては、内蔵電池と四級塩コンデンサーの二大元凶は想像以上に酷い、ということですね。

今年平成29年(2017)は、手持ちの稼働中機体（NEC以外を含む）のメンテを前半に完了させ、万全の状態で遊ぶ、です。なかなかまとまった時間が取れないので難しいですが・・・

おまけ。GeniusというAppleIIのゲームを海外から作者様に送ってもらいました。我が家のApple IIGSで音楽が聴きたいので、Mockingboard（の互換カード）の入手も今年の目標です。

投稿日:

平成28年の振り返り その2 アーケード基板篇

長くなったので、振り返りその2、アーケード基板篇、としてまとめました。

去年はKTB-1入手に伴い、アーケード基板にも初挑戦しました。が、様々のものが高騰しているので、ほぼ全て数千円で買えるものばかりです。オリジナル版である事が多い基板に手を出すと、コンシューマー機の移植ものを遊ぶ気力が一気に萎えるくらい、本物には力があります。

まずSEGA SYSTEM Cのコラムス。メガドライブ版とだいぶ違い高品質の音と画面を楽しめます。ただ、大半の人が「メガドラ版は完全移植」であると勘違いしているので、時間を見つけて違いを纏めたいと考えています。

次にMVS。「ネオジオ基板」と書けば良いか。電池が切れてたので半田付けで修理しての利用です。MVSカートリッジも1000円前後の激安のものを多く買いました。もはや高騰著しいNEO GEOカートリッジや、その移植版を買う理由が無くなりました。本物万歳。

メタルスラッグ2と3も来ました。2は処理オチが激しいですが、その分簡単な気がします。改良されたXはさすがに高いですね。未入手です。

初代パズルボブルも我が家に来ました。これは当時結構遊んだので地味に嬉しいです。

餓狼伝説SPECIALはボロボロのを1000円でゲットしたのですが、普通に動きました。MVSカートリッジは丈夫ですね。

最後に1枚だけ高価なものを買ってしまいました。タイトー/東亜プランの名作、TATSUJINです。運良く結構安く買えました。今ではまた更に値上がりしてる模様ですが、そもそもマトモな移植版が出てないので、これぞ買うべき基板の上位にランクする名作かと思います。いや、好きならば、ですけど（笑）。私はTATSUJINがやりたくてメガドライブを買ったのですが、ゲーム性が変わってしまうくらいのアレンジ移植にガッカリした記憶がありまして、やはり本物は良いということで。

そして長年の懸案であった液晶ディスプレイも、IPS史上最速の反応速度と覚しきIO DATAのLCD-RDT272XPBを導入して改善しました。縦画面で使うことを考えると、VA型液晶でないと右目で見たときの色味と左目で見たときの色味が違い、頭が痛くなります。IPSだと概ね同じなので大丈夫です。

RDT272XPBは大変優秀で、ほぼ遅延を感じさせない品質で動いてくれています。これで無理ならブラウン管を導入するしかないと思いますが、今のところ必要性を感じていません。ちなみに縦回転する台座も導入しています。

マイコンソフトのXRGB-MINI FRAMEMEISTERも我が家に来ました。これでブラウン管に頼らない近代環境が揃いました。

年末には衝撃のアナウンスもありました。そのFRAMEMEISTERが生産中止になるとのこと。来年一杯くらいまでは買えるようですが。内部で使っているスケーラーチップが廃番になる影響でとのことのようです。欲しい人はすぐ予約を入れて置いた方が良いでしょう。もう数ヶ月先まで一杯とも聞きます。慌ててAmazonの転売ヤーから買うのはやめましょう。

SYSTEM C2の初代ぷよぷよも激安入手出来ちゃいました。後期版Rev.Bです。メガドライブ版は前期版Rev.Aをベースに移植されているので、バグ修正版として。アルルのボイスが割れておらず、音楽も止まらず普通に喋ってくれるので遊んでいて大変愉しいです。

NAMCO SYSTEM 12のミスタードリラーも数千円にて。駿河屋のアーケード基板管理のコスト管理徹底力（笑）が分かったのが面白かったのですが、高騰著しいアーケード基板の価格が段々落ち着いてきたのもこちらの影響かとも思いますので、激安品にばかり手を出している私としては特に文句を言う気も無く。本物で安く遊べるのが一番です（笑）

他にもいろいろあるのですが、まあアーケード基板系のまとめとしてはこの辺りでしょうか。次回はビンテージPC系の修理のまとめを書きます。

投稿日:

平成28年の振り返り その1

明けまして御目出度うございます。今年も宜しくお願い致します。

去年を振り返ると、初の自分の書籍（というかインタビュー本）が出た目出度い年でしたが、丁度引っ越しが重なりドタバタしている間にあまり宣伝できず、という悲しい状況でした。このインタビューは2015年末に二子玉川にて行われたものですが、確か3時間近くかけていろいろな話をし、そのうちの大部分を掲載して頂きました。話題はJava EEの開発経験から勉強方法、エンジニアの教育、この先日本は働く場所としてどうなるのか、等々、多岐にわたるものになっています。推敲にだいぶ時間が掛かり大変でしたが、過去の自分の雑誌連載とは違う緊張感が大変印象に残っています。翔泳社の電子書籍シリーズとして出して頂きましたが、Amazonではプリントオンデマンド版（要は紙印刷版）も入手可能ですので、気になった方はそちらか、もしくはKobo・Kindleにてどうぞ。

丁度その頃引っ越しがあり、その直後熊本で震災発生。

熊本市内にある実家と家族は無傷でしたが、食器棚がひっくり返り想い出の品が粉々に。まあその程度で済んで良かった話ではあります。

本Blogの名称を頂いた熊本城と、その石垣である「武者返し」が崩れ、大変悲しい思いをしました。悲しいというか衝撃でした。人生の中でこんな事がまさかあるのか、と。「こういう事は絶対に起きない」という人の勝手な不文律を木っ端微塵に打ち砕く出来事でした。

熊本の方が気になりつつ、その後初めてNew Yorkへ出張に行きました。敢えて地元民が使うような電車と地下鉄を乗り継ぎ、Times Squareへ。いわゆる世界の中心地がこれほど凄まじい物量の広告を一箇所に投入しているとは、これも衝撃でした。日本に戻り、渋谷や新宿のネオンを見て、何と寂しく時代遅れなのか、という感想を抱いてしまうくらい。日本が足踏みしてる間に、世界はどんどんMoving Forwardであります。

そういえば、Java Day Tokyo 2016でも登壇しました。これは2015年のJavaOne 2015講演を日本語で再演したものでした。

海外と言えば、その後にJavaOne 2016にも参加しました。残念ながら今年は聴衆として。来年はスピーカーとして再チャレンジしたいと考えています。Java EE 8も出る予定ですしね。

最後に、Rakuten Technology Conference 2016にも出ました。これは毎年出ているのですが、今年は丁度二子玉川ライズにてハロウィンパーティーでしたので、ちょっとだけ仮装しての登壇となりました。神道なのでハロウィンとは個人的に何の関係もありませんが（笑）。

と書いてきたら、全然収まらないくらいの長さになってきたので、3回に分けることにしました。2回目はアーケード基板関係をまとめます。

投稿日:

Java EE 8 (revised) & JavaOne 2016 – Java EE Advent Calendar


Java EE Advent Calendar 2016 の 12/22 分となります。今年はすっかり登録を失念しており、急いでこの日にねじ込みました。昨日分は @TTakakiyo さんの「WebSphere LibertyでJava EEアプリケーションをOne-JAR化する」でした。

さて、Java EEの今年の動きは予想通りさほど大きくなく、どちらかと言うとJava EE 7が着実に企業システムに拡がっていったのかな? という感じの一年でした。それはそれで実業務を担うべく誕生したJava EEの、企業システムの基盤としては正しい状況だと思います。ただ、一方で日進月歩のダイナミズムという観点だと、何となく物足りない感じもします。みんな麻痺してる気もします。

余談ですが、実際の企業システムを開発・運用・管理している側からすると、ちょくちょく仕様が変更になるのは全く迷惑以外の何者でもありません。仕様追加ならば許容範囲内ですが、変わっちゃうと既存システムの互換性が問題になりますので。Java EE仕様の場合はよっぽど古いので無ければ切り捨てられる事も少ないですので、この点は良いですね。

話を元に戻しまして、ダイナミズムの観点では次期仕様であるJava EE 8について、数多くの動きが今年のJavaOne 2016でありました。

毎度ではありますが、国内報道はこの一部の側面しか流れませんので、参加されてない方は何が起きているのか理解不能なのではないかなとも感じます。参加しないと理解出来っこない、というのは仮に米国内に居たとしても同じ状況ではあると思いますので、永遠の課題ではあります。

日本の場合、参加費用がカンファレンス参加費約20万円に加え、渡航滞在費が4-50万円くらい余計にかかる、しかも参加出来たとしても、英語が聞けて話せないと参加費約20万円をドブに捨てる形になってしまいます。大変高いハードルです。

とはいえ、ここは仕様策定している有名人達と仲良くなるために頑張って英会話とライティングを習得し、あらゆる手段を使ってJavaOneに参加する、そして仕様策定に影響を及ぼす、というのがJava EE愛好家の鏡とも言える行動かと思います。ひとつ一念発起して頑張って世界に出て行く方々を応援したいと考えております。

ただ、今後頑張るとしても今年の状況は分からないと思いますので、私の見聞きした範囲を公開出来る範囲で記録として残しておきます。勿論大人の事情で全部書けるわけでは無いので、そこはまあ、そういう話としてご理解を賜りますようお願い申し上げます。

1. Java EE仕様策定は今後どうなるのか?

ここらへんの話は英語の一次情報を得ている人は気付いてる人は気付いてると思いますが、あまり掘り返してもいいことは無いので、目先を変えて今後どうなるのか、という話です。

Java EEの仕様策定は相変わらずOracleによって先導されます。これ自体は、強力にホスティングしている会社が居ないとグチャグチャに空中分解することになるので、全く問題無いと思います。Oracleが好きかどうか、というのは全く別問題なのでそれは別の機会に。

そこへの意見としては、透明性を高めて欲しいという要望は当然ながら出ている訳でして、スペックリードへは諸々の要望が出ている状況です。が、それも正常なプロセスの一環であるため、特にこれと言って変わりはありません。Project JPE(はどうだったか正確には知らないですが)やJ2EEの昔からそういう意見が出て、諸々改善されてきました。改善されてないものもあります。普通です。

面白くない(?)結論ですが、まあ、そういう状況である事には変わりないでしょう。少なくとも、何かが大きく変わることは無さそうです。

2. Java EE仕様は今後どうなるのか?

次。問題はここです。オリジナルのJava EE 8仕様は元々もう少し早い時期に出る予定でしたが、ほぼ唐突に延期と仕様変更案がJavaOneで出てきました。

JCP周りのプロセスで問題があるとすれば、この辺りが閉鎖的に見えてしまう点となるでしょう。Java EEの仕様自体が複数の仕様で構成される巨大仕様であるが故に、個別の話は個別の仕様内に閉じてしまう事と、その悪影響か全体仕様を見ている人があまり多くない印象です。

ということで、あくまで案ではありますが、仕様変更案が出て、それに伴う投票が10月に締め切られました。私も投票するようTwitterで繰り返し呟きました。これに対する文句がある場合は、もう遅いという状況のため、投票しなかった方は「後出しジャンケン」(=後で文句ダラダラ)は無しにて呉々もお願い致します。

と、公開しようと作業をしていたら、続報が。投票結果が出ていました。今回外された3つは見事に最下位から3つでした。まあ「結果は残酷」としか言いようが無いかなと。

いずれにせよ、この改定仕様にてJava EE 8が策定されることがほぼ既定路線となり、既にjcp.org内にてこの結果を受けての作業が進行中ですので、今度はその中身を見ていくことにしましょう。

3. 改訂版Java EE 8では何が変更になったのか?

Java EE 8 (revised)というのが通称ですが、まあ日本人に分かりやすく以下「改訂版」としときます。改訂版ではCloud対応に焦点が当たりまして、その観点で見直しが入ったという形になります。「という建前になっている」、と補足をしたほうがいいかもしれませんが・・・。

いずれにせよ、Java EE規格策定が結構ノロノロであるため、その間に世の中の方がCloudバンザイの方向に行っちゃってしまいました、なので急ぎ対応させます、という感じで捉えると、然程間違いないかと思います。

オリジナルのJava EE 8仕様はこんなものを含んでました。

  • JMS 2.1
  • JCache 1.0
  • JAX-RS 2.1
  • JSON-B 1.0
  • JSF 2.3
  • MVC 1.0
  • CDI 2.0
  • Java EE Security 1.0
  • JSON-P 1.1
  • Servlet 4.0
  • Java EE Management 2.0

が、改訂版はこうなりました。

  • JMS 2.1 (延期)
  • JCache 1.0
  • JAX-RS 2.1
  • JSON-B 1.0
  • JSF 2.3
  • MVC 1.0 (脱落)
  • CDI 2.0
  • Java EE Security 1.0
  • JSON-P 1.1
  • Servlet 4.0
  • Java EE Management 2.0 (脱落)
  • Health Checking (new!)
  • Configuration (new!)

私自身としては、脱落した仕様はほとんど使ってなく、使う予定も無かったため、ほぼ影響無しで済みそうです。が、これらを当てにしていた方々からすると、やり場の無い怒りをどうしてくれよう、という感じかもしれません。そんなにJava EE方面に熱を上げてる方面はかなり限定されるとは思いますが・・・

まあ、そんな感情論はさておき、落ち着いて変更点をひとつずつ見ていきましょう。

3-1. JMS 2.1 → JMS 2.0 (延期)

これはJMSが廃止になるとかそういう話でも何でも無くて、Java EE 7のJMS仕様のまま、改定しない、という話になります。一部で廃止なのか!?と盛り上がりましたが、それは勘違いです。ただの延期。JMS 2.1はJava EE 9に恐らく載ることになります。今回は仕様バグの小修正のみが取り込まれる模様です(バージョン番号は不変)。

JMS 2.1での大きな追加要素は、非同期バッチ仕様が追加となり、アノテーション定義が拡張されて@JmsListernerが追加され、CDIでJMSが使えるようになる、等々というものでした。これによりEJB Message-Driven Beanが不要になる、という、CDI愛好家方面が狂喜しそうな内容が主だったところのため、微妙ちゃぁ微妙な更新でした。

延期の理由を関係者に直接聞きましたが、要は「作業する人が少ないので、人員を別の重要な更新に集中させるため」となります。個人的にもこれはあんまり重要で無い気がするので、延期で良いかと。なんてことを書くと他の関係者の恨みを買いそうですが(笑)。

3-2. MVC 1.0 (引き下げ)

これは悲劇ですかね。MVC 1.0というのは要はStrutsの後継というか、Strutsを今どき風に格好良くして標準化したようなものだった、とざっくり考えれば良いかと思います。

Java EE仕様のWeb標準フレームワークは、ページ駆動型のJSFです。これは紛れもない事実。要はASP.NETのASPXと同じようなものです。であるため、2000年代に流行したアクション駆動型のStrutsからの移行は「ほぼ作り直し」という非常に高いハードルを要求されます。これの救済策として急浮上したMVC仕様でした。主にStrutsを狙った多くのセキュリティーホールが出てきた頃に焦点が当たった経緯があるため、要はそういうトレンドに乗っかって出てきた感じではありました。

ところが急にスポットライトを浴びたものは飽きられるのも早い訳でして、今年のJavaOneではいきなり無かったことになってました。2014年・2015年のJavaOneでの狂騒は一体何だったのか。

延期の理由も関係者に聞いたところ「もはや重要ではないから」とバッサリ一刀両断でした。個人的にも、元々古くさいMVC仕様がこのタイミングで何故出てきたのかさっぱり理解出来なかったので、誤解を恐れずに言えば、EE 8仕様から落ちるのは大賛成です。

実はこの仕様を期待していた日本国内のベンダーやら顧客は多かった、と風の便りに聞くわけでして、さてどうなることやら。「既存のStrutsコードが大量だから移行なんて無理無理」とかゴネるのも、もう限界だと思います。もう諦めて、現代的なJSFで作り直す方がいいと思いますよ・・・

3-3. Java EE Management 2.0 → J2EE Management 1.1 (引き下げ?)

これはサーバー管理APIですね。JMXとかMBeanとか関連と思ってもらえれば。旧仕様が”J2EE Management 1.1″で2006年改訂ですから、もはやカビが生えた感が強いですが、これをRESTベースに書き換えましょうというのがオリジナルプランでした。

仕様から落ちるのは、「クラウド時代に注力するのはここじゃないよね」(意訳)というものなので、ある程度しょうがないかな。RESTベースに変更は既存のアプリケーションサーバーに膨大な仕様変更を強要する事になるので、そりゃぁ各方面が嫌がるでしょうね。これは次のJava EEに載るのかは不明です。更新されず将来廃止されるかもしれません。そっちが濃厚な気がします。

3-4. Health Checking (new)

次は逆に追加されたものを見ていきましょう。二つです。

まずは監視。これは上記3-3のJava EE Management 2.0の代替としての位置づけ感が強いですね。強烈に違うポイントとしては、こちらはマイクロサービス(自走JARアプリケーション)を前提にした新APIである点です。マイクロサービス仕様はJava EE 9で登場する予定と聞いていますので、完全にそれを狙ってるのでしょう。

いずれにせよ、これ以上細かい情報が出てない気がするので、これはちょっと判断待ち状態かと思います。どこかに出てるのかな。知ってる人居たら教えて下さい。

3-5. Configuration (new)

次に設定系の新APIです。これは完全にクラウド環境における可搬性を向上させる目的で、設定を読んだり更新したりできるものでしょう。

Java EEでは、初版であるJ2EE 1.2から設定は読み取り専用でXMLファイルで定義するものでした。いわゆるDeployment Descriptor。これがJSON等に対応し、動的に更新出来るようになるものなのか、それとも凶悪に旧式のPropertiesクラスを置換する目的になるのか、いまいちよく分かりませんが、いずれにせよこの辺りのものを置換するものと考えるのが良いでしょう。

ここら辺の周辺系改善は個人的に大賛成なので、どんどん新しいものを導入して現場の管理スタイルを洗練させて欲しい所であります。管理コストも下がるでしょうし、精神衛生上も良くなります。何より、不要なプロジェクト内共通ライブラリーを作らずに済みます。

4. JavaOne 2016について

最後にJavaOne 2016について纏めておきましょう。

2014年・2015年とスピーカーとして参加しましたが、今年は上記の混乱からか選考から外れてしまいました。私だけ?と思っていたら、あらあらあの人もあの人も・・・と。要はJava EE 8を狙ったセッションは悉く外されてしまった模様です。残念。去年のJavaOne 2015ではJava EEでのBatch設計・実装の話をしました。

このため、JavaOne 2016のJava EEセッションの多くは、上記の改訂版Java EE 8の中身を説明するものに多くが費やされていた感触を得ました。まあ、それはそれで良いでしょうと、今年は久しぶりにリスナーとして参加することになりました。自分が話すための準備が無かったので、だいぶのんびりと参加させてもらいました。

とはいえ、個別に多くの方と個別ミーティングを持たせてもらったことと、普通にフラフラ歩いてたら「あららこんにちは」系の脱線も多くあり、網羅的にセッションに参加出来た訳ではありません。勿論、そこから全然別の話に繋がったりと、むしろそこがJavaOne等海外カンファレンス参加の醍醐味なのでありまして、当然ながらそういう嬉しいハプニングを優先させています。

※なので、英語を聞けて喋れないとお金と時間をドブに捨てることになるのです。内容を見聞きするだけなら、YouTubeの中継を見とけばいいですしね。

現場で感じたこととしては、Java EE 8が延期されたのでイマイチ盛り上がりに欠ける状況ではあり、スペックリードが登壇するセッションも人が少な目、という微妙さ・余所余所しさが昨年以上あり。恐らくUS在住の方も日本以外在住の方も、今回はネタが少ないため参加を見送った方が多数あったのではないかと思います。

ただ、その分「一見さん」は減った感じがあり、何が何でも参加する方面の方々の毎年見る顔が揃いに揃った、という、Java EEマニアからするとレア度満点な感じも受けました。そこで会話される内容が久しぶりに濃く、私としては満足な参加となりました。

あまり難易度の高い話とメンバー固定化はオープン環境としてはイマイチかとは思いますが、そもそも取り扱っている題材が高難度のものであるが故、それに相応しい議論が行われるべきですし、ここはある程度許容範囲かと思います。そんなにマニアックなこと、誰でも込み入って会話出来る訳でも無いですしね。

ここは参加したセッションによって感触が左右されると思いますので、あくまで私個人が受けとった感触ということにて。来年のJavaOne 2017が待ち遠しいですね! 来年はこれら改訂版Java EE 8に則った、リファレンス実装であるGlassfish 5をダウンロード出来るようになっていることでしょう(勿論出ます)。

明日の回は @gishi_yama さんとなります。

投稿日:

復活のメガドライブ+メガCD 電解コンデンサー交換(3度目)

※2020-08-12追記

本稿のウルトラパワーアップ版として『メガCD(初代)修理マニュアル』をBOOTHでリリースしました。2種類のメイン基板、3種類のコネクト基板、CD-ROMドライブユニットのメンテナンスやアルミ電解コンデンサーの交換等まで網羅した徹底版になります。ご参考まで。

https://hirofumiiwasaki.booth.pm/items/2291597

メガCDがまたもや動かなくなり早数年。そろそろ修理しようと情報を集めると、最初に引っかかるのが2007年に自分で書いたBlog記事だったりする現状に衝撃を憶えたので、9年後のいま、続編なので日本語で続きを書くことにする。英語じゃなくてごめんね。

復活のメガドライブ+メガCD 電解コンデンサー交換

まず症状。我が家のメガCDは元々発売当時に買った超初期版と、ジャンクで買ったちょい新しめのものの2台ある状態。こいつらをどうにかしないと、メガCD版シルフィードが遊べないのだ。

■1台目(超初期版)の症状:

  1. 起動はする状態だが、音が一切出ない。
  2. メニューに入り、トレイをイジェクトしてCD-ROMを乗せ、トレイを閉めてもCD-ROMがスピンアップしない。つまりメニューに「CD-ROM」の文字が出ずゲームができない。

■2台目(ジャンク)の症状:

  1. そもそも起動しない。電源を入れても画面真っ黒で、メガCD本体のランプも点灯しない。

まず1台目から修理に取りかかる。メガCDの分解方法は至って簡単で、下記手順を守れば筐体を割ることは無いだろう。中もスカスカだし。

ドライブ修理の注意点としては、CD-ROMトレイを出した状態で分解を開始しないと、トレイを抜けない、ということ。メニューでイジェクトさせてから電源を切り、開始しましょう。

  1. 底面ビス6本を抜く
    IMG_0436
  2. メガドライブとの接続コネクターの上の黒いビス2本を抜く
    IMG_0435
  3. 接続コネクターの手前のビスを抜いたプラスチック部分を上にゆっくり持ち上げる (画像はトレイを閉じているけど、もしCD-ROM側の修理が必要であればこの時点でトレイを出しておかないとトレイが抜けない)
    IMG_0433
  4. 反対側(ケーブル押さえがある側)をゆっくり持ち上げる
    IMG_0434

さてこのあと、銀のカバーをビス3本で外して、CD-ROMドライブを露出させる。ここで必要なのはまずCD-ROMトレイを横切っている上蓋押さえのビス2本を抜き、トレイの右上にある、爪で押さえてあるT字型のプラスチックを抜く。このT字型のプラスチックを抜かないと、トレイを全部引き抜くことができない。つまり引っかかりになっている(しかもイジェクト済みのセンサーに当たるようになっている)ので、抜かないといけない。爪で押さえて細いマイナスドライバーでちょいと上に持ち上げれば簡単に取れる。

IMG_0423

で、そのあトレイをいっぱいいっぱいに引き出したあと、トレイを引っこ抜く。割れないように慎重に。そうすれば取り外したトレイの下にベルトが露出する。ローディングがダメな場合、だいたいこいつがユルユルでガビガビになってスリップしているから、必ず新品に交換する。薬剤でどうにかしようと思っても、一瞬動くかもだがすぐ駄目になるので、諦めて交換すべし。

代替品は「角ベルト 25mm x 1.6mm 径約39mm」。うちは近くのカホパーツセンターにて調達した。我が家のは案の定ユルユルになっていて、見るからにスリップしそうな感じになっていた。

IMG_0381

張り替えたらこのくらい張りが出る。上の画像と比較しても一目瞭然である。これでトレイを戻して動かしてみたところ、一発でロードするようになった。ローディング部分はこれで修理完了。

IMG_0382

IMG_0383IMG_0384

さて、次に1号機の音が出ない点の修理。これもメガCDで頻発する四級塩コンデンサー問題なので、多分現在発症していない個体もいずれ発症する病気と考えたほうがいいだろう。

IMG_0388

この問題点はまずメガCDが3つの基板から構成されていることを理解してから作業をするのが早い。まずCDドライブの正面から見て右横の最も大きな基板が「メインボード」(と書いてある)。ここにCPU・ROM・RAM等が積載されている。音が出ないけど動作はする、という場合、ここは無傷のことが大半。

IMG_0405IMG_0409

が、このメインボードの表面実装コンデンサーが大量死して腐食が進んでいたので、辛うじて動いているものの全量交換することにした。16V 10μF x 12個、10V 100μF x1個の新品105℃の一般的なアルミ電解コンデンサーを調達し、表面実装型のランドに無理矢理はんだ付けしていく。非常に格好が悪いのだが、結局は同じだし、別に売り物にするわけでもないのでこれで良い。

注意点としては、作業しやすいように半田付けしていく順番を考えること、取り付けの際に穴に引っかからないように配置するためにコンデンサー側の足の切り方を工夫すること、くらいだろうか。また腐食が進んでいる場合一向にはんだが乗らない事が多いため、はんだごてで軽く基板側をグリグリしてやるとくっつく事も多い(がやり過ぎると焦げる)。まあとにかくくっつけるのだ。

IMG_0411

なおこのメインボード基板は時期により数バージョンある。2号機の基板は完全にデザインが異なるもの。部品配置がそもそも違う(下の画像)。実はこれに加えて1号機と2号機の間のデザインのものが存在する(1号機の基板にEPROMではなくカスタムROMが載ってるタイプ)ことをtwitterでしらけんさんに教えてもらったため、少なくとも3バージョン以上は存在すると考えてよいだろう。

IMG_0415

ふたつめの基板が、メインボードが刺さっている通称「コネクトボード」(と書いてある)。これも二バージョン確認済みで、1号機のメインボードにジャンパー線があり、表面実装型コンデンサーが2個あるものと、2号機の両者が無いもの。ジャンパー線の有無があるので互換性は無いと考えた方がいいだろう。

ここの表面実装コンデンサーも液漏れしていたため、通常の電解コンデンサーで張り替えた。16V 10μF x 1個、6.3V 47μF x 1個である。

IMG_0390

三つ目の基板が、ACアダプタージャックや音声ジャックがくっついている、背面側にある細長い通称「サブボード」(と書いてある)。音声が出ない場合、十中八九こいつが元凶と考えて良いだろう。我が家の1号機の場合、9年前に交換した電解コンデンサーが確か5年くらい前に死んでいたのを確認して再度交換したものの、音が出ず一度断念している。この際に交換したものとは別のコンデンサーが死んでいる可能性大なので、こいつらを全交換である。

IMG_0392

交換に際しては、16V 10μF x 10個、16V 100μF x 1個、6.3V 100μF x 2個の105℃品の新品を調達すべし。耐圧(V)はこれより上であればぶっちゃけ何でもOKだが、あんまり大きいと入りきれないので、そこそこ近いやつにしたほうがいい。福岡のカホパーツセンターでは16V 10μFが全くなかったので、50V 10μFで代替した。

だが、結果は音声復活ならず。作業中、半田付けの際に腐臭が漂っていたため、明らかに小さな16V 10μFのコンデンサーが漏れており、漏洩後どこかが腐食していると考えられる。が、不明なので一旦保留。恐らく腐食でパターン断線、IC故障、辺りだろう。

なお2号機の電源が入らない問題も、ここサブボードの「16V 100μF x 1個、6.3V 100μF x 2個」のどれかが死んでる最も良くあるパターンではないかと考えられたため、交換したところ電源及び音声が復活した。

ここで1号機のメインボード+コネクトボード+2号機のサブボードで、一旦正常稼働状態のメガCDができあがった。

メガCDの故障は上記の他にCD-ROMトレイが経年劣化で歪んで正常にトレイが動作しない(引っかかる)というものがあり、我が家の2号機がその状態である。この場合、修理不能なので他のジャンクからパーツを拾ってくるしかない。

IMG_0413

メガCDの良くある故障パターンは大凡上記のうちに該当する気がしている。今回は1号機メインボードの表面実装型コンデンサーが全量液漏れ死亡していたのが衝撃だった。2号機のものは漏れていなかったため経年の違いかもしれないが、初期型は恐らくどれも同じような四級塩を使ったものであろう、と考えると、単に時間の問題となることは明らかだろう。

ともあれ、私を含む実機維持派は簡単な電子工作技術が必須となる(か大量のお金が必須となる)時代に突入したと考えて良いだろう。慣れれば簡単なので、ダメ元で挑戦してみる方々が少しでも増え(て復活したメガCDが増加す)る事を願うばかりだ。

投稿日:

Good-bye EJB, Hello CDI – Java EE Advent Calendar 2015

This is for the “Java EE Advent Calendar 2016” event material among Japan. Thanks for using auto translator for English. 

Java EE アドベントカレンダー2015の12月23日分です。寺田さんの記事からの続きになります。

※注: 内容がエンタープライズ開発の中核方面に寄っているので難度高かなという気がします。

今年のJavaOne 2015ではキーノート発表に日本人として超久しぶりに登壇させてもらったり去年に引き続きセッションを一枠喋ったりとなかなかのプレッシャーでしたが、なんとか無事終わりほっと一息、なんて余裕が全くないのですが、そんなことより個人的にショックなことがあったのでそれを書きます。

こういう記事が雑誌(そもそも消えてしまった)や日本語商用技術サイトに載らなくなったってのが、多分日本全体の技術力の低下&乗り遅れの証なんだろうなと思いつつ、日本語で情報発信しなくなった私も元凶の一人かもしれないですね。が、個人的に日本語で発信する意味が全くない(私はSIerでもベンダーでもない)ので、逆に来年のAdvent Calendarは多分英語で書いてる気がしています。

さよならIIOP

ショックだったのがこれ。JCPに加入しているので仕様策定の状況を見てた訳ですが、IIOPが遂にJava EE 8からオプショナル扱いになるかもしれない、という話題が急遽入ってきた訳です。で、最近使ってないからいいんじゃねパーフェクト、みたいなノリでガンガン話が進んでいくわけです。

で、Java EEを丸17年間ほぼフルで使ってる私としては、おいおいちょっと待った、と。使ってない輩が勝手に仕様を削るなよと。使ってる側の話を聞いたのかよと。とまあそんな感じをまとめて私も投稿するわけですが焼け石に水。一人で世界は変えられないのでした。

で、多分IIOP (アイアイオーピー)って何よ?とほぼ10人に9人が謎に思うと思うので改めて。ざっくり言うとIIOPはCORBA仕様の通信部分のGIOPをTCP/IP互換にしたものなんですが、それはどうでも良くて、最も重要な部分はXAに対応してるJava EE内唯一の汎用通信プロトコルなわけです。RMIとの互換性を持たせてるのでRMI-IIOP (アールエムアイ・オーバー・アイアイオーピー)という仕様になってます。WebLogicではそれを更にラップしてT3 (ティースリー)という高機能プロトコルが提供されてます

で、次にXAって何よ?の回答なんですが、JDBCにXA対応、ってのがあるのでそれで気付く人が居たら嬉しいのですが、分散トランザクションの標準プロトコル、ってのがざっくり回答でしょうか。要は、複数のシステムに跨がってACIDトランザクションを制御できるってものです(ACIDはぐぐってね)。複数システムで処理する内容があったとして、どこかでエラーが起きたら複数台丸ごとロールバックできるという素敵仕様です。金融系処理には欠かせない処理、と言えばなんとなく想像付くでしょうか。お金情報が壊れたら嫌ですよね。ある日突然増えてたりとか減ってたりとか。

このXAはTuxedoや日立のOpenTP1などで1990年代後半に一世を風靡するのですが、まあそれをWebLogicがサポートして、J2EE 1.2の標準仕様に盛り込まれ、金融系システムに2000年代前半に広まっていくというサクセスストーリーな訳です。私もだいぶお手伝いさせて頂きました。

で、IIOPをオプショナルにするとなると、アプリケーションサーバーとしては標準としてサポートしなくても良くなるわけで、三大Java EE商用アプリケーションサーバーであるWebLogic, WebSphere, JBossのどれかが将来にサポートを外してくる恐れがあるわけですね。こいつぁ困った。ということでJavaOneで直談判に行ってきました。

さよならEJB

でまあいろんな偉い人とディスカッションしていくわけですが(仔細は割愛。言えないこととかも沢山出てきた気がするので)、そこで追加で分かったのは、やっぱりEJBも将来無くなりそう、ということでした。あーやっぱり・・・時代はCDIなのです。

個人的にはEJBこそがJ2EE–>Java EEの華であり中核であり、WebLogic 3.0からEJBを使ってきた身からすると大変寂しい話ではあります。が、やはりEJBは機能がてんこもり過ぎて、必用な分だけ能動的に選択できるCDIは時代の要請でもあります。

で、Java EE 7のCDI仕様を見ると、EJBでサポートされてるけどCDIでサポートされてない機能がまあ沢山あります。どこからEJBでどこからCDIかさっぱり分からんというところもありますが、両方で使えるもの、という意味だとざっと考えて・・・

  • 既にサポートされてるもの(両方で使える)
    • 自動トランザクション制御 (@Transactional)
    • SOAP通信 (@WebServices)
    • REST通信 (@GET, @PUT)
    • JPA系制御
  • まだサポートされてないもの(EJBでしか使えない)
    • インスタンスプーリング
    • セキュリティー制御
    • 呼出のJNDI登録・参照
    • Message-Driven Bean (みたいなJMSサーバー側簡易機能)
    • Singleton Bean (みたいなSingletonパターン機能)
    • EJB Timer (みたいな時間制御)
    • IIOP通信 (EJB Remote) + XA制御 (with IIOP)

※Entity Beanは?とか聞かないで下さいね・・・もう無いです

と見ていくと、「まだサポートされてない」ものの中で落とされていくものがなんとなく色分けされていきます。どれが落とされるか分かりませんけど、少なくともIIOP+XAは当確な感じになって参りました。あーあ。

でまあ、そんなに後ろ向きだと生きるのが辛くなるし代替技術も無いので、しゃーないですなと気持ちを切り替え、XA使わないアーキテクチャーに変えていけばいいんじゃね?という方向にシフトしていく訳です。そもそもXAは完璧ではない(in-doubt windowとかあるし)ので、この方向もアリはアリです。

但し、現在動いているシステム群は一体どうするのよ?という疑問も当然あります。Webスタートアップ系の単一システムならまだしも、例えば金融系はアホみたいにシステムがある(数百から数千規模)のが普通なので、それをひとつにしていくというのも何となく無謀な感じもします。書いてると絶望感しか沸いてこない・・・で、唯一の方策というのは、製品利用企業が正しく声を上げてベンダーにIIOPをサポートさせ続けるということでしょう。プレッシャーかけていきましょう。

こんにちはCDI

さて、悩み深いリアル金融系システムはさておき、大半の利用側はCDIバンザイな気がします。配備時に実装クラスを自動生成&コンパイルして動作するEJBに対して、単純に機能がインジェクトされて動作するCDIの方が、エラー発生時も分かりやすいですし、何せテストがやりやすい。

あとは現在EJBから移行されてない機能が恐らくJava EE 8〜9で追加されていくはずなので、それを待てばEJBがこの世から消える算段ができ、初学者はCDIだけ勉強すればあとはJSFもJPAもOKな幸せな世界になると思います。そう考えてCDIに仕様を移してきているので当然です。

CDIそのものの説明は既に大量にあるので省きますが、EJB特にSession BeanからCDIに移行するために何が必用か、というところだけ補足しておきます。

Session BeanからCDIへの移行はアノテーションの一括置換で概ね行けます。ざっくりとこんな感じと考えればいいでしょうか。

EJB Session Bean CDI
Class宣言箇所 @Stateless @Named
@Dependent
@Transactional
EJB呼出し箇所 @EJB @Inject

他を言い出すとあれやこれやありますし、EJB Remoteどうすんの(=移行先が無いので削ってアーキテクチャー変更)とか沢山有りますけど、こんな感じでの基本移行パターンを考えておく必要があるかと思います。

さてそろそろ長くなってきたので結論ですが、次の世代のEJB (特にSession Bean)は以下の書き方になっていくことでしょう。ただ、現在のJava EE 7だと機能が足りなさすぎる気もするので、ご自身のソフトウェア特性に応じて使いこなしましょう。ツールに踊らされるのは本末転倒です。

@Named
@Dependent
@Transactional
@Path
public class AnBusinessLogic {

    @Inject
    private NextBusinessLogic theLogic;

    @Inject
    private ThirdBusinessLogic thirdLogic;

    @POST
    @Consumes("application/json")
    @Produces("application/json")
    public AnReturnValue theMethod(AnParam param) throws BusinessException {
        // Check param values.
        AnReturnValue result = new AnReturnValue();

        // Call other logics to operate.
        result.theResult = this.theLogic.businessMethod(param);

        result.thirdResult = this.thirdLogic.otherBusinessMethod(param);

        return result;
    }

    ....
}

明日12/24の回はhondaYoshitakaさんの番です。Merry christmas and a happy new year!