2016いろいろな事例を見てると、一番でっかいコンデンサーを交換しない事例が多数見られたのですが、この電源の場合は例外なく全て交換しました。全て105°C品で統一しています。理想を言えば電源用の数個上のグレードが相応しいということを後で知ったのですが、まあそんなに88VAで長時間遊ぶことも無いと思うので一旦これで良いでしょう。そもそも対応ソフト少ないし。全部の電解コンデンサー交換完了。2016もちろん、電源修理は危険なので、特に半田付けを原因とする短絡事故には気をつけましょう。最悪、丸ごと燃えて火事になります。PC-88VA電源修理終わったけど、破裂炎上が怖いから庭でスイッチオン。無事ファンが回ったから最低限のとこはOK。残りを組み上げてみる。2016無事だったので組み上げて、V2モードで動作成功。2016V3モードも成功。88VA用に隠しスイッチを上へ。この配置を考えた人、凄い。あとは組み上げてV3ソフトを動かしてみよう。このあと出勤なので出来るところまで。2016ということで、何というか奇蹟というか、年末に絶対死んでると確信していたPC-88VAが動いてしまいました。気をつけたのは、電池漏れで緑色や茶色に表面が錆びている箇所を無理にIPA等で拭かず、そのままにした、ということです。将来サビが進行して死ぬかも知れませんが、元凶を取り去っているため進行は遅く、仮にパターンが切れたときにはそのときに都度ジャンパーを飛ばして対処するのが正しそうです。いうことで3回に渡ってまとめた平成28年(2016)のまとめ、一旦これで終わりにします。他にもジャンクのPS2とか家庭用機を修理したりしてるんですが、まあネタ的に面白そうなのはこの辺かなと思うのでこの辺で。見事にNEC機ばかりですね。普及してたという事もありますが、逆に壊れやすいということもあるかと思います(笑)。ひとこと言いたい点としては、内蔵電池と四級塩コンデンサーの二大元凶は想像以上に酷い、ということですね。今年平成29年(2017)は、手持ちの稼働中機体(NEC以外を含む)のメンテを前半に完了させ、万全の状態で遊ぶ、です。まとまった時間が取れないので難しいですが・・・おまけ。GeniusというAppleIIのゲームを海外から作者様に送ってもらいました。IIGSで音楽が聴きたいので、Mockingboard(の互換カード)の入手も今年の目標です。サイン入れてもらった。その1明けまして御目出度うございます。今年も宜しくお願い致します。去年を振り返ると、初の自分の書籍(というかインタビュー本)が出た目出度い年でしたが、丁度引っ越しが重なりドタバタしている間にあまり宣伝できず、という悲しい状況でした。このインタビューは2015年末に二子玉川にて行われたものですが、確か3時間近くかけていろいろな話をし、そのうちの大部分を掲載して頂きました。EEの開発経験から勉強方法、エンジニアの教育、この先日本は働く場所としてどうなるのか、等々、多岐にわたるものになっています。推敲にだいぶ時間が掛かり大変でしたが、過去の自分の雑誌連載とは違う緊張感が大変印象に残っています。翔泳社の電子書籍シリーズとして出して頂きましたが、Amazonではプリントオンデマンド版(要は紙印刷版)も入手可能ですので、気になった方はそちらか、もしくはKobo・Kindleにてどうぞ。2016丁度その頃引っ越しがあり、その直後熊本で震災発生。国道3号線と菊池電車の交差する橋。おかしいくらいズレてる。上を車で通ってみたけどあり得ない段差。高速が死んでる現状、ここ切れたら南北の物流が途切れるから止められないのわかるけど、平常時なら通行止めレベル。2016熊本市内にある実家と家族は無傷でしたが、食器棚がひっくり返り想い出の品が粉々に。その程度で済んで良かった話ではあります。近所の松崎八幡宮はほぼ無傷。鳥居が崩れそうだからつっかえ棒が入ってた。ここから南側断水状態とのこと。2016本Blogの名称を頂いた熊本城と、その石垣である「武者返し」が崩れ、大変悲しい思いをしました。悲しいというか衝撃でした。人生の中でこんな事がまさかあるのか、と。「こういう事は絶対に起きない」という人の勝手な不文律を木っ端微塵に打ち砕く出来事でした。テレビで見るのと実際見るのは衝撃度が違う。屋根がぼろぼろの熊本城と倒れた長塀。石垣が酷いことになってる。被害は京町方面続いてる。Yorkへ出張に行きました。いわゆる世界の中心地がこれほど凄まじい物量の広告を一箇所に投入しているとは、これも衝撃でした。日本に戻り、渋谷や新宿のネオンを見て、何と寂しく時代遅れなのか、という感想を抱いてしまうくらい。Forwardであります。2016でも登壇しました。2015講演を日本語で再演したものでした。2016にも参加しました。残念ながら今年は聴衆として。来年はスピーカーとして再チャレンジしたいと考えています。8も出る予定ですしね。2016にも出ました。これは毎年出ているのですが、今年は丁度二子玉川ライズにてハロウィンパーティーでしたので、ちょっとだけ仮装しての登壇となりました。神道なのでハロウィンとは個人的に何の関係もありませんが(笑)。2016と書いてきたら、全然収まらないくらいの長さになってきたので、3回に分けることにしました。2回目はアーケード基板関係をまとめます。今年はすっかり登録を失念しており、急いでこの日にねじ込みました。EEアプリケーションをOne-JAR化する」でした。いう感じの一年でした。EEの、企業システムの基盤としては正しい状況だと思います。一方で日進月歩のダイナミズムという観点だと、何となく物足りない感じもします。みんな麻痺してる気もします。余談ですが、実際の企業システムを開発・運用・管理している側からすると、ちょくちょく仕様が変更になるのは全く迷惑以外の何者でもありません。仕様追加ならば許容範囲内ですが、変わっちゃうと既存システムの互換性が問題になりますので。EE仕様の場合はよっぽど古いので無ければ切り捨てられる事も少ないですので、この点は良いですね。2016でありました。2016毎度ではありますが、国内報道はこの一部の側面しか流れませんので、参加されてない方は何が起きているのか理解不能なのではないかなとも感じます。参加しないと理解出来っこない、というのは仮に米国内に居たとしても同じ状況ではあると思いますので、永遠の課題ではあります。日本の場合、参加費用がカンファレンス参加費約20万円に加え、渡航滞在費が4-50万円くらい余計にかかる、しかも参加出来たとしても、英語が聞けて話せないと参加費約20万円をドブに捨てる形になってしまいます。EE愛好家の鏡とも言える行動かと思います。ひとつ一念発起して頑張って世界に出て行く方々を応援したいと考えております。今後頑張るとしても今年の状況は分からないと思いますので、私の見聞きした範囲を公開出来る範囲で記録として残しておきます。大人の事情で全部書けるわけでは無いので、そこはまあ、そういう話としてご理解を賜りますようお願い申し上げます。EE仕様策定は今後どうなるのか?ここらへんの話は英語の一次情報を得ている人は気付いてる人は気付いてると思いますが、あまり掘り返してもいいことは無いので、目先を変えて今後どうなるのか、という話です。EEの仕様策定は相変わらずOracleによって先導されます。これ自体は、強力にホスティングしている会社が居ないとグチャグチャに空中分解することになるので、全く問題無いと思います。Oracleが好きかどうか、というのは全く別問題なのでそれは別の機会に。そこへの意見としては、透明性を高めて欲しいという要望は当然ながら出ている訳でして、スペックリードへは諸々の要望が出ている状況です。それも正常なプロセスの一環であるため、特にこれと言って変わりはありません。JPE(はどうだったか正確には知らないですが)やJ2EEの昔からそういう意見が出て、諸々改善されてきました。改善されてないものもあります。面白くない(?)結論ですが、まあ、そういう状況である事には変わりないでしょう。少なくとも、何かが大きく変わることは無さそうです。EE仕様は今後どうなるのか?次。8仕様は元々もう少し早い時期に出る予定でしたが、ほぼ唐突に延期と仕様変更案がJavaOneで出てきました。2016JCP周りのプロセスで問題があるとすれば、この辺りが閉鎖的に見えてしまう点となるでしょう。EEの仕様自体が複数の仕様で構成される巨大仕様であるが故に、個別の話は個別の仕様内に閉じてしまう事と、その悪影響か全体仕様を見ている人があまり多くない印象です。いうことで、あくまで案ではありますが、仕様変更案が出て、それに伴う投票が10月に締め切られました。私も投票するようTwitterで繰り返し呟きました。これに対する文句がある場合は、もう遅いという状況のため、投票しなかった方は「後出しジャンケン」(=後で文句ダラダラ)は無しにて呉々もお願い致します。締め切りが10/21なので、それまで投票を。投票せずに後から文句言うのはルール違反。建設的に進めましょう。ここを履き違えると誰も幸せになれない。2016と、公開しようと作業をしていたら、続報が。投票結果が出ていました。今回外された3つは見事に最下位から3つでした。「結果は残酷」としか言いようが無いかなと。8が策定されることがほぼ既定路線となり、既にjcp.org内にてこの結果を受けての作業が進行中ですので、今度はその中身を見ていくことにしましょう。(revised)というのが通称ですが、まあ日本人に分かりやすく以下「改訂版」としときます。改訂版ではCloud対応に焦点が当たりまして、その観点で見直しが入ったという形になります。「という建前になっている」、と補足をしたほうがいいかもしれませんが・・・。EE規格策定が結構ノロノロであるため、その間に世の中の方がCloudバンザイの方向に行っちゃってしまいました、なので急ぎ対応させます、という感じで捉えると、然程間違いないかと思います。8仕様はこんなものを含んでました。2.0が、改訂版はこうなりました。(new!)私自身としては、脱落した仕様はほとんど使ってなく、使う予定も無かったため、ほぼ影響無しで済みそうです。これらを当てにしていた方々からすると、やり場の無い怒りをどうしてくれよう、という感じかもしれません。EE方面に熱を上げてる方面はかなり限定されるとは思いますが・・・まあ、そんな感情論はさておき、落ち着いて変更点をひとつずつ見ていきましょう。7のJMS仕様のまま、改定しない、という話になります。一部で廃止なのか!?と盛り上がりましたが、それは勘違いです。9に恐らく載ることになります。今回は仕様バグの小修正のみが取り込まれる模様です(バージョン番号は不変)。2.1での大きな追加要素は、非同期バッチ仕様が追加となり、アノテーション定義が拡張されて@JmsListernerが追加され、CDIでJMSが使えるようになる、等々というものでした。Beanが不要になる、という、CDI愛好家方面が狂喜しそうな内容が主だったところのため、微妙ちゃぁ微妙な更新でした。延期の理由を関係者に直接聞きましたが、要は「作業する人が少ないので、人員を別の重要な更新に集中させるため」となります。個人的にもこれはあんまり重要で無い気がするので、延期で良いかと。なんてことを書くと他の関係者の恨みを買いそうですが(笑)。(引き下げ)これは悲劇ですかね。1.0というのは要はStrutsの後継というか、Strutsを今どき風に格好良くして標準化したようなものだった、とざっくり考えれば良いかと思います。EE仕様のWeb標準フレームワークは、ページ駆動型のJSFです。これは紛れもない事実。要はASP.NETのASPXと同じようなものです。あるため、2000年代に流行したアクション駆動型のStrutsからの移行は「ほぼ作り直し」という非常に高いハードルを要求されます。これの救済策として急浮上したMVC仕様でした。Strutsを狙った多くのセキュリティーホールが出てきた頃に焦点が当たった経緯があるため、要はそういうトレンドに乗っかって出てきた感じではありました。ところが急にスポットライトを浴びたものは飽きられるのも早い訳でして、今年のJavaOneではいきなり無かったことになってました。2014年・2015年のJavaOneでの狂騒は一体何だったのか。延期の理由も関係者に聞いたところ「もはや重要ではないから」とバッサリ一刀両断でした。8仕様から落ちるのは大賛成です。実はこの仕様を期待していた日本国内のベンダーやら顧客は多かった、と風の便りに聞くわけでして、さてどうなることやら。「既存のStrutsコードが大量だから移行なんて無理無理」とかゴネるのも、もう限界だと思います。(引き下げ?)これはサーバー管理APIですね。JMXとかMBeanとか関連と思ってもらえれば。1.1′′で2006年改訂ですから、もはやカビが生えた感が強いですが、これをRESTベースに書き換えましょうというのがオリジナルプランでした。仕様から落ちるのは、「クラウド時代に注力するのはここじゃないよね」(意訳)というものなので、ある程度しょうがないかな。RESTベースに変更は既存のアプリケーションサーバーに膨大な仕様変更を強要する事になるので、そりゃぁ各方面が嫌がるでしょうね。EEに載るのかは不明です。更新されず将来廃止されるかもしれません。そっちが濃厚な気がします。(new)次は逆に追加されたものを見ていきましょう。