Posted on

平成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（の互換カード）の入手も今年の目標です。

Posted on

平成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系の修理のまとめを書きます。

Posted on

平成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回目はアーケード基板関係をまとめます。

Posted on

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 さんとなります。

Posted on

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

メガ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が増加す)る事を願うばかりだ。

Posted on

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!

Posted on

Welcome Rakuten Technology Conference 2015 (Fukuoka Location)

New seats where added and tickets registration is available. Please, register as soon as possible before is too late. 

ご盛況により当初想定よりお申し込みが多くなっていました。
新たに増席し、現在、申し込みが可能となっています。
ご興味がある方は、ぜひお早めにお申し込みください！

We are very proud to inform that this year Fukuoka Technology Conference has a lot of interesting presentations about the current trend on e-business from Rakuten Ichiba, Rakuten Travel and Rakuten Card in Fukuoka.

If you want to hear how our business are implementing the current technology, come to see our conference. We will be very happy in explain our services.

Also, come to talk with our employees in our Happy Hour. This is a place that you can enjoy food & drinks and talk with us. Please, feel free to have a nice conversation with us.

今年も福岡でやります!! 楽天テクノロジーカンファレンス2015です。

今年は、楽天市場、楽天トラベル、楽天カードなど、実際にドライブ中の最新トレンドについて、(東京からのサテライト込み込みですが) 福岡からも発信します! Web技術を中心として、主にJava EEやエンタープライズ系開発について、結構ディープにやっちゃいます。

また軽食・お飲物提供タイムも用意しました。現場で開発している社員も参加します。色々聞いてみて下さい。お気軽にご参加下さいませ。

2015110213312220151102133131

presentationBDF7C1B4-0509-407E-B8D0-5B9D49623535.jpg

FukuokaRTC

Date / 日時

Nov. 21st, 2015, Start 10:00

2015年11月21日（土）10:00〜：受付開始

Place/ 開催場所

Fukuoka Center Building 12F,
2-2-1 Hakataekimae, Hakata-ku, Fukuoka City,
Fukuoka, Japan

福岡県福岡市博多区博多駅前2丁目2番1号
福岡センタービル12F

http://tech.rakuten.co.jp/access.html#access-fukuoka

Registration / お申込み

https://www.eventbrite.com/e/rakuten-technology-conference-2015-tickets-18950765249

Procedure / お申込み手順

1. Push “REGISTER” button. / みどり色の「REGISTER」ボタンを押して・・・
2. Apply from “(Satellites) Fukuoka”. /「(Satellites) Fukuoka 福岡サテライト」からどうぞ!

20151102145410

 

Time Table /タイムテーブル

Time Location A
(Conference)		 Location B
(Cafeteria)
11:00 Java EE Applications for Transaction Services by Kota Fujita [Track A]
Talk by Yutaka Matsuo by Yutaka Matsuo
12:00 [Track A]
Fun Research in Computer Vision : from robots, sports, face to medicine by Takeo Kanade		 Lunch
13:00 [Track A]
Keynote by CEO by Hiroshi Mikitani		 [Track A]
Keynote by CEO by Hiroshi Mikitani
14:00 Better working framework for smart device service by Shimizu Yosuke [Track B]
Rakuten Ichiba by Yoshihisa Onoue
15:00 About JavaEE and DevOPS by Nakada Hiroaki [Track E]
Rakuten Travel by Kazuhisa Naoi and Shinoda Takeshi
16:00 [Track B]
Rakuten Card by Hirofumi Iwasaki and Ameen Arshal		 [Track B]
Rakuten Card by Hirofumi Iwasaki and Ameen Arshal
17:00 – Closing
17:30 – Lightning Talk & Happy Hour

 

Sessions in Fukuoka / 発表内容（福岡）

 

Java EE Applications for Transaction Services by Kota Fujita.

11:00〜    at Location A (Conference) in Fukuoka

Today’s e-businesses are changing very fast introducing new standards and new technologies every year. This session will explain why we selected Java EE as our platform and How we are implementing it to allow agile and safe transaction system.

 

Better working framework for smart device service by Yosuke Shimizu.

14:00〜    at Location A (Conference) in Fukuoka

We believe that promoting excellent synergy between business, development and operation; creating a working environment that support each area demands; and building multinational team; It is possible to have rapid and reliable development contributing for better user satisfaction and more revenue. Some of key concepts is to have 100% in house development on both the Client and Server side and to have high qualified engineers capable to do planning, development and operation. As a result, we could optimize our working framework providing better products with high quality and very good customer satisfaction.

 

About JavaEE and DevOPS by Hiroaki Nakada.

15:00〜    at Location A (Conference) in Fukuoka

Our system is continuing to grow and introducing new technologies is becoming our normal operation flow. This session will explain over view of our development and operation.

 

 

お申込みは、こちらから！

https://www.eventbrite.com/e/rakuten-technology-conference-2015-tickets-18950765249

Posted on

My JavaOne 2015 Session “Real-World Batch Processing with Java EE” CON3339

Thanks for joining our session with @aforarshal in great 20th anniversary of Java on JavaOne 2015. Fortunately we had many attendees in big hall in Parc55, with many feedbacks and Q&A times there. Also the session room had TV streaming and recoding system, now we can see whole session scene on YouTube as above.

The session slides are also available from SlideShare here.

I was very pleased to see the strong passions of every engineer for Java EE technologies same level as the beginning of the J2EE 16 years ago there. Each technology details were already changed but the core policies were not changed from the beginning. I want to say it’s a great forecast in late 1999, and still moving forward to our future.

The session is going to replay in next Rakuten Tech Conference 2015 in Tokyo, Japan on Nov 21, 2015, more deeply.

Posted on

Thanks for watching our JavaOne 2015 keynote speech

12049188_909422705793504_3388694351395045916_n

Thanks for watching today’s JavaOne 2015 keynote speech in Moscone North hall with Arshal. This was a secret project among very small team, and satisfied with the great achievement to us, for sharing our proactive working status in Fukuoka, Japan.

JavaOne 2015 Keynote Speech Full Length (see from about 1:25:00)

Fortunately the JavaOne was just started from today, I’m going to enjoy our own session on Wednesday Oct 28, 11:30 AM, as below.

Real-World Batch Processing with Java EE [CON3339]

Fortunately some sessions or keynotes are broadcasting online freely, so stay tuned to the greatest conference of programming language in the world. Happy 20th anniversary Java!

Posted on

My JavaOne 2015 Session: CON3339

Screen Shot 2015-09-26 at 10.50.10 AM

Happy programming weekend! I’m going to have a speaking session in JavaOne 2015 on Oct 28, 11:30 AM, with my colleague Arshal as below. See you on SF.

Real-World Batch Processing with Java EE [CON3339]

Arshal Ameen, Team Manager, Rakuten, Inc.
Hirofumi Iwasaki, Group Manager, Rakuten, Inc.

Batch processing plays a key role in most organizations, mainly because it doesn’t need much human intervention. This session explores various ways in which batch processing can implemented with Java EE. It includes SWOT analysis of batch implementation with JSR 352 and embedded EJB containers. By the end of the session, the attendees should be able to understand when to use JSR 352 and when not to, the benefits of using an embedded EJB container for batch processing, and the best practices to follow when designing batch processes.

Conference Session
Wednesday, Oct 28, 11:30 a.m. | Parc 55—Cyril Magnin II/III