hidekatsu-izuno 日々の記録

プログラミング、経済政策など伊津野英克が興味あることについて適当に語ります(旧サイト:A.R.N [日記])

nuxt-history-state という Nuxt.js 用モジュールをリリースした

仕事で Nuxt.js を使っている。戻るボタンの扱いについて聞かれたので調べてみたところ、これが予想外に難しい。

戻るボタン対応は、Struts を代表とするポストバック系のフレームワークでも鬼門だったけれど、SPAの時代になってもあいかわらず鬼門のようだ。

Backボタンを押した際のブラウザ動作としては、タブ切り替えと同じ挙動の方がありがたいのではと思うのだけど、残念ながらそうはならない。元々、静的ページを前提にした仕組みだから、以前訪れたページがリロードされるような動きとなる。ただし、HTMLにはフォームというものがあるから、そこだけは考慮されていて、キャッシュが残っていればフォームの値だけは復元、なければ完全リロードとなかなかに際どい動きとなる。

もちろん、この動作はJavaScript全盛の今となっては好ましいものではない。フォームの値だけ残されたところで JavaScript のメモリ状態と整合性が取れず中途半端になってしまう。とはいえ、onunload など既存仕様と整合性が取れないことやメモリ状態も含めてキャッシュに保管するのは現実的ではないなど様々な理由が考えられ、この動作が変わることはないだろう。

Nuxt.js に関して言うと、すべての状態が JavaScript 管理となるため、フォームの値だけが残されるという中途半端な状態にはならない。$router.push による画面遷移とさして変わらない動作をする。逆に言えば、一般の静的ページで期待される動作を再現するためには工夫が必要になる、ということでもある。

きっと誰かがプラグインを作っているだろうと高をくくっていたのだけれど、意外にもこれといったものがない。たしかに多くの Web サービスでは、状態保持が必要な画面遷移もあまりないし、細かいことを気にしなければ Vuex で十分かもしれない。

とはいえ、私が仕事で関わるような業務系アプリケーションの場合、状態を伴う画面遷移の方がむしろ一般的なため、何らかの対応が必要となる。本来、仕事の一環なのだから業務時間中に作ればいいとは思うのだが、開発に専念できない現状で片手間にできるような内容ではないし、今後、別案件や個人的な開発にも流用したいことから、プライベートな時間を使ってモジュールを作成した。*1

そうして出来上がったのがこの nuxt-history-state だ。

このモジュールを作るにあたっては、Vue-Router の scrollBehavior と「vue-routerでbackwardかforwardかを判定する - Qiita」が参考になった。

基本的な方針としては、各ページにページ番号を持ち、画面遷移時にインスタンスの$data をページ番号に紐付け保管するという対応になる。ページ番号はブラウザ内で管理される履歴と紐付ける必要があるため、URL のクエリパラメータか history.pushState のいずれかで保持する必要がある。

クエリパラメータで紐付ける方が簡単なのはわかっていたが、URLが汚れる点が気になった。だから、history.pushState で何とかならないかと努力してみたものの、リロード後に Back ボタンを押した場合、popstate イベントが発生しない場合があることが判明したため、デフォルト動作ではリロードをサポートせず、オプションを設定することでクエリパラメータを使ったリロード対応モードになるようにした。

 このモジュールを使うと、通常は難しい Back/Forward の判定やリロード後の Back/Forward 継続など、履歴管理が一通りできるようになる。まだ、開発して間もないので、こうした方が良いのではなど意見があれば、Issue に起票してほしい。

*1:最近、NGINXの開発者が当時在籍していた会社からの著作権侵害報告で強制捜査を受けたというニュースが出たこともあり、センシティブな話かもしれないので、プライベートな時間を使って開発されたことを強調しておこう。私が公開しているライブラリは、NGINXがそうであったように、いずれも業務時間で開発したものではなく、プライベートな時間で開発したものを公開し、職場からは一般のライブラリと同じ形で利用するようにしている。いやほんと、業務時間中にOSS開発できる会社が羨ましいよ!

JEF4J v0.9.0 をリリースした。そして謎の文字の話。

JEF4J を久々に更新した。

以前、「JEF4J をリリースしてみた。あるいは、メインフレームの文字コードの話。」というエントリを書いたが、その時点では JEF の最終仕様が掲載されている「FACOM JEF 文字コード索引辞書 (1987年/第三版)」が手に入らなかったため、第二版をベースに他資料を援用して作成していた。

福岡大学の図書館に存在していることはわかっていたのだけれども、さすがに遠方で放置してたのだ。別件で福岡に旅行に来ているので、ついでにコピーを入手してきた。

いろんな文字が追加されているのではという予想を裏切り、JIS83 改正対応がほとんでだったようで、結果的に修正はほぼ必要なかった。

残る謎文字

ワープロ用途の特殊記号や同じ字母を持つものが登録済みの変体仮名を除くと Unicodeマッピングできない文字は次のものだけとなった。

JEF 字形 備考
71E0 武を字母とする変体仮名Unicode には存在せず。
71F7 変体仮名なのだが、字母すら不明。
72A8 得を字母とする変体仮名Unicode には存在せず。
72E1 女を字母とする変体仮名Unicode には存在せず。
73D5 富を字母とする変体仮名Unicode には存在せず。
74B9 変を字母とする変体仮名Unicode には存在せず。
75F2 雄を字母とする変体仮名Unicode には存在せず。
43C7 儲の異体字。違いが微妙すぎるのか、文字情報基盤にも同一字体なし。
6CF4 顛の異体字。違いが微妙すぎるのか、文字情報基盤にも同一字体なし。

マッピングして気づくのは、Unicode 登録の変体仮名はかなり中途半端な代物なのでは、という点だ。JEF が変体仮名をサポートしていたのなら、既存規格に合わせた方がまだ良かったように思える。とはいえ 71F7 の変体仮名については、それ系のサイトをいくつか調べてみたものの該当する文字すら見当たらず本当に謎なのではあるが。

儲、顛の異体字については、JEF79 で採用していた拡張漢字とJIS83 で採用された文字に微妙に差異があったため発生したもので、互換文字みたいなものだと思われる。

今後の予定

文字のマッピングアルゴリズムに多少改善の余地があるのと、Adobe Japan-1 対応を入れる可能性がある。ノー豆腐を目指した Noto Font を含め多くのフォントは Adobe Japan-1 の異体字セレクタはサポートしても、汎用電子の異体字セレクタはサポートしていない。

正直、あまりにもマイナーすぎてそんなに使われているとも思えないライブラリだけれども、今後発生するだろう公共系システムの移行に役立つ局面もあるとは思っているので、要望があればご連絡いただければと。

AWS 認定 Solution Architect - Professional に合格した

41歳で自動車免許を取ったというエントリを前回書いたけれども、実は並行して AWS の Solution Architect Professional の試験勉強をしていた。免許で長期休暇を取ったこともあり、受験のタイミングに難儀していたのだが、先日ようやく受けることができ、無事合格できた。点数はわりとギリギリだったけど、この試験は答えが明らかではない際どい問題が多いのでこんなもんかな、と。*1

AWS の試験は、AWS を理解するきっかけづくりに最適だと思う。特に Solution Architect - Associate は教本も増えてきており、一週間ほどで AWS の主要な要素が理解できるようになっているのでおすすめできる。Solution Architect - Professional は範囲が広いわりに教本らしい教本もなく、試験内容自体の難易度も高いが、こんな機能もあるんだという気付きに繋がり個人的には非常に役に立った。一点残念なのは、試験の模範解答が手に入らないところ。受験対策だから仕方ないとは思うものの、誤った理解を正す機会が得られないのは残念だ。

なお、勉強は Udemy で講義と模擬試験の英語版を購入して実施した。だいたい1万円強だったか。受験費用も模試含め 2万円ほどかかる*2ので、会社から合格後の報奨金が出なければ絶対に受験しなかったと思う。

仕事では AWSGCP、Azure、そしてオンプレと広く薄く雑多に関わっているのだが、使ってみると、それぞれ会社のカラーが出ていて面白い。

AWS は、質実剛健というか、マイクロサービス的な提供がされていて、簡単なことでも複数のサービスを組み合わせないと実現できないため、AWS特有の広範な知識を求められる難しさがある。一方で、組み合わせれば大抵のことはできるようになっているのも事実であり、痒いところに手が届くという感覚がある。ここは不便だなと感じると、すかさず新サービスでフォローされることが多く、そういう意味でも安心感がある。

GCP は、シンプルで高品質な感じがある。3クラウドの中では一番わかりやすいし、ひとつひとつのサービスの出来が良いように感じる。一方でシンプルすぎて痒いところに手が届かない感じがある。例えば、CloudSQL と Spanner の中間がないところとか。Spanner はすごいけど、欲しいのは Amazon Aurora なんだけど的な。

Azure は、コンソールのインターフェイスはよくできている。さすがは UI の会社だけある*3。とはいえ、ひとつのサービスにいろんな機能がごちゃっと付いてきたり、サービス間の関連がわかりずらかったり、新機能にもとってつけた感があったりと。どこがとはっきり言えるわけではないのだが、やっつけ感を強く感じる。良くも悪くも Microsoft 製品っぽいというか。

まぁ、三者三様とは言っても、どのクラウドを採用するか迷っている会社があったら、個人的には AWS を押す。最安値での環境構築はできないかもしれないけど、やりたいことはだいたいできるという安心感は大きい。この機能以外はいらない、ということが確実なら GCP を使うのは全然ありだと思う。Azure は……多くを語るまい。

大企業の基幹系の仕事が多いから、いまだオンプレに触れる機会も多いけど、個人的にはもはやオンプレはリスク以外の何物でもないかな、と。好きな時にリソースを増減させられないということがいかに行動を制約するかを考えたら、一見金額が安く見えたとしてもオンプレにするという選択は難しいように思う。特にディスクについては、自由に増加可能なクラウドと事前購入が必須なオンプレでは見積り以上に差が出てくるのではと。

 

*1:実際、海外の対策サイトを見に行くと過去問の回答に対する意見が割れている場面をしばしば見かける。

*2:本当は 3万円以上かかるが、Associate を取得すると半額チケットが貰える

*3:というより AWS Console がわかりづらすぎなだけなんだけど

41歳にして自動車免許を取った

孔子曰く、「40歳にして惑わず」とは言うものの、40歳を超えたくらいで、そうそう人間変わらない。うんざりするほど子供っぽい(余談だが、仮面ライダージオウはやたら面白い)し、むしろ、大人にならなきゃ、という抑圧から解放され、より幼くなっているのではと思うこともある。

感覚的にはそんな感じなのだけど、一方で、せいぜい40年しか人生残っていない、という事実にも気付かずにはいられない。そんな感覚は30代にはなかった。今までは、いつかやればいいや、と思っていたのだが、もはや今やらないと一生やらないことが確定してしまうのだ。

そこで自動車免許だ。

正直、自動車免許が絶対に必要だと思ったことは一度もない。周りの話を聞くと、身分証明書として便利という声が多いのだけど、写真付きのマイナンバーカードで十分なので住基カードより前の知識で止まっているのだろう。*1

東京暮らしが人生の半分を過ぎた今、車に乗る必然性はまるでない。せいぜい、旅先で自動車乗れたら便利だろうな、と思うくらいか。とはいえ、このまま車を運転することなく死んでいくのか、と思うと怖くなってきた。車に乗る必然性はないとはいえ、子供の時はゴーカートが好きだったし、レースゲームも大好物だ。それ以上に、日本人の通過儀礼としての自動車免許を取らなかったことが、自分の幼さに繋がっているのかもしれないという思いもなくはない。

そこで関係各所と調整のうえ、なんとか2週間の休暇をもらい、6月~7月にかけて、福島の湯本自動車学校という場所に合宿免許に行ってきた。

40代で自動車免許を取る人も珍しかろうから、どんな感じだったかを簡単に書いておこう。

  • 申し込みは「ローソンの運転免許」で行った。トラブルがあったとき大手の方が仲介に入ってもらいやすいかもしれない、という思いでそうしたが、申し込んで振り込みしたらすんなり終わった。資料が送られてくるので、その指示に従がえば良いだけで特に迷うようなところはなかった。
  • 費用的にはAT限定免許で20万円強だった。東京で免許を取ると、合宿でなくても30万円を超えるので、地方で合宿免許というのはとても経済的。宿舎は予想外に快適だったし、飯もうまかった(お昼の弁当はかなりいまいちだが)。お風呂は宿舎含め温泉で、日帰り入浴にもあちこち行った。湯本温泉は古いせいか露天風呂が少なくてそこが残念ではあった。
  • 半分は夏休み気分で行った(だから温泉地にした)のだが、休日なしの9:00~19:30でスケジュールが組まれているため、休暇感はまったくなかった(途中に空き時間はそこそこあるとはいえ)。特に仮免の見極めに落ちた辺りで、休暇の延長が必要になり、かなり焦ることになってしまった。
  • AT免許では、第一段階で技能教習が最短12時間となっているが、まったくの素人が乗れるようになるには短すぎるように感じたので、数日、日程が伸びることは覚悟した方がよいと思う(MTだと15時間だが、このくらいの時間が最低ラインではなかろうか)。
  • 車の運転が思っていたものとまったく違っていた。もっとシステマチックなものかと思っていたのだが、ありえないくらいメカニカルだ。ハンドルやアクセル/ブレーキの使い方もレースゲームとまったく違うので当初すごく戸惑った。
  • 昨今、ブレーキとアクセルの踏み間違い事故が話題になることが多いが、この UI なら起こって当然ではと思ってしまった。ブレーキも最大限押し込むと徐行速度になって、離せば止まるとかになっていれば、そんな事故起こらないのに。ほんと、テスラがんばれ、と言いたい。
  • 結局最後まで、適切な速度、安全確認の手順、車体間隔がわからなかった。ダメ出しばかりで何が正解なのか良くわからない挙げ句、教官によって言うことがぜんぜん違ったりするので、とても戸惑った。教育方針のすり合わせとかしないもんなのか? 速度に関しては、標識がないから60kmと言う教官もいたのだが、調べる限り、片側1車線なら50km、片側2車線なら60km が上限となっているそうだ*2。教科書にすら載っていないが。
  • 車体の間隔に関しては実際に降車して体験するなどの講習があった方がよいのではないか。感覚だけで覚えるには時間数が短すぎるように思う。本線合流に至ってはまったく事前説明がなく、いくらなんでも無理があるだろ、という感想しかない。
  • これだけ多くの人が免許持っている割に、合理的とは言い難い制度と仕組みで構成されており、世の中想像以上に適当なものだと実感した。
  • 正直、取得には大変苦労した。学科試験も決して簡単なものではなく、よくこんな大変な試験を世間の大半が通過してるもんだと思った。これに合格できるなら日商簿記とか情報処理試験とか余裕で合格するはずなので、みんなもっとまじめに資格試験受けた方がよいのではないか、という気持ちになった。

本当は40歳のうちに免許を取ってしまいたかったのだが、本免学科試験は居住地でないと駄目とのことで、最終的には誕生日を過ぎた7月後半に免許発行ということになった。とはいえ、免許の有効期限は誕生日が基準となるので、結果オーライと言えなくもない。

いまだ車線変更とバックでの駐車がうまくできないなど、まだまだ初心者を脱しきれていないので、しばらくは週に一度くらいは乗ろうかな、という感じ。

*1:マイナンバーカードはコピーできる条件に制限があり、そのせいで身分証明書としての使用を拒否するお店があるのがやや面倒ではある。専用ケースに入れた状態での表面ならば、身分証明書として使えることになっているのだけど。その意味で住基カードより利便性が落ちているのは残念だ。

*2:実際には交通量などによってもっと細かい規定がある。

老害の誕生

近年ラジオをよく聞くようになっていたから、ピエール瀧の逮捕には大変驚かされた。ここ数年、ピエール瀧リリー・フランキーが映画に出過ぎ問題がしばしば取り沙汰されていたが、こんな結末になるとは思いもよらなかった。

個人的には、逮捕されたとはいえ、麻薬で逮捕であり 20 代の頃からの常習者だったようだから、節度ある使い方をしていたわけで、役者や CM に引っ張りだこの状況で立場的にやっちゃだめだろ、とは思うものの、行為自体には特にどうも思わない。日本にもヒロポンが広く使われていた時代もあったし、ある種の宗教、音楽ジャンル、文化スタイルとは切っても切り離せないものでもある。スティーブ・ジョブズLSD に影響を受けた人だし、ついこの間はイーロン・マスクが番組で大麻を吸っていた。もちろん、素晴らしいものであると言いたいわけでもない。アルコール依存症がそうであるように、危険度の高い嗜好品であることには変わりない。リスクある嗜好品をどこまで許容するかは国民の総意が決めることだ。日本では一律 NG という判断がなされており、そこには合理性がある。だから、逮捕されるべきではなかったなどというつもりはない。

むしろ関心は、ピエール瀧逮捕の結果、過去の出演作や音楽作品の販売・配信が一斉に停止してしまったことの方にある。ただ、一般に言われている「他人に迷惑かけたわけでもないのに配信停止は過剰反応では」という論点とは多少異なる。むしろ、ピエール瀧が連続レイプ殺人魔であったとしても、作品は切り離して扱うべきなのか、ということの方にある。

ぷらすと by Paravi という番組で、映画・音楽ジャーナリストの宇野維正氏がマイケル・ジャクソンという天才が生み出した偉大な芸術を過去のゴシップ程度で潰すべきではないという論陣を張っていたが、私も感情的にはまったく同意見だ。犯罪は犯罪、やはり憎むべきものであるが、天才の生み出したものはそれ以上の価値のある希少なものだと感じる。被害者がいるのに、彼・彼女らの感情は無視するのか、という批判がある。たしかにそうなのだが、天才の価値はそれらの犯罪行為すら過小に評価せざるを得ないくらい重要であると思いたい。

誤解を恐れずに言うならば、犯罪行為はある意味「現実の」出来事だ。下世話で、狭く、閉じた世界の一部の人々の話である。一方で、天才の為したことは、世界に広く影響力を及ぼす。犯罪はどこにでもあり、誰にでもできるが、天才の偉大な成果物は希少であり貴重だ。

人権無視の酷い発想のように思えるかもしれない。しかし、これはほんの数年前までは一般的な捉え方だった。スティーブ・ジョブズのひどい人間性も、ロマン・ポランスキーの悪行も皆知っていながら、それを許容してきたのだ。

私に限って言えば、今でも天才の為したことの方が、その犯罪行為より重要だという考えを捨てきれない。しかし、このような考え方自体が古臭いものになりつつあることはひしひしと感じる。今はまだ MeToo 運動が一過性の出来事に見えているから抵抗する人も出てくるが、時代が移っていけば「何を当たり前のことを言ってるの?」となる可能性は否定できない。

チンギスハーンが攻めてくるたびに村人全員が虐殺される時代と現代では、殺人に対する倫理的な観念が異なるように、あるいは、今ではオフィス内でタバコを吸うことが異常なことになったように、「天才性」よりも「社会規範を守ること」の方が重視される時代になりつつある。個人的にはそのことをとても寂しく感じるけれども、時代が変われば物事の捉え方、その基準も変わっていく。当時は人気があった人が、その後顧みられないこともよくある話だ。

なるほど、こうして老害は生まれるのだな(と地球最後の男的なオチ)

2018年に読んだおすすめのビジネス書5選

昨年、40歳を超えてからというもの、残りの人生どう過ごすべきか考えることが多くなった。いっそ、そのことを書くのも新年一発目としてはいいのではないか、と思ったのだが、あまりにも陰々滅々とした内容になるため、昨年読んだビジネス書の紹介をすることにしてみた。

過去の文章を読んだことがあれば、私がいかにビジネス書のことを快く思っていないか、ということがわかるかと思う。多くのビジネス書は根拠に欠け、成功譚を大きく取り上げる一方、失敗した事例は端から切り捨てられている。

しかし、その一方でいろいろなビジネス書を読むうちに、成功者がなぜそのような結論に至り、決断に至ったのか、というプロセスには意味があるのではないか、と思うようになった。経済政策も同様ではあるが、学術的結論を待つには人生は短すぎる。限られた時間の中で有効な手を打たなければならない時、何を理由に実行したのか、そこに興味を覚える。

 

1冊目:正垣泰彦著「サイゼリヤ おいしいから売れているのではない 売れているのがおいしい料理だ」

サイゼリヤ社長がノウハウを書いた本。冒頭から店を出したものの客は来ないわ、客同士の喧嘩が原因で火事になり店舗を消失するわ、とツカミも完璧なのだが、今のサイゼリヤになるまでに行った施策となぜそなければいけないのかという理屈が事細かに語られており、とても為になる。飲食店に限らず、この本で語られていることを自分の業種だとどうだろうかと置き換えて読むと、いろいろ気付かされることもあるのではないだろうか。

 

2冊目:大竹慎太郎著「起業3年目までの教科書」

起業3年目までの教科書 はじめてのキャッシュエンジン経営

起業3年目までの教科書 はじめてのキャッシュエンジン経営

 

起業を確実に成功させる驚きの方法が書いてある。一般にこういうのは眉唾だと思うのだけど、この本の結論にはおおいに納得させられた。結局のところ、起業を成功させたければ、情熱とコミュニケーション力だけあればよく、ビジネスモデルなんてものはビジネスの拡大期にでも考えればいいのだ、という身も蓋もない話。

 

3冊目:島田潤一郎著「あしたから出版」

あしたから出版社 (就職しないで生きるには21)

あしたから出版社 (就職しないで生きるには21)

 

資産も実績も人脈も何もない著者が、情熱だけで翻訳権を得て、和田誠高橋和枝に挿絵を頼み、出版社を立ち上げた経緯を記した本。情熱の力は何物にも勝る!

 

4冊目:パティ・マッコード著「NETFLIXの最強人事戦略」

NETFLIXの最強人事戦略 自由と責任の文化を築く

NETFLIXの最強人事戦略 自由と責任の文化を築く

 

この本で書かれているノウハウは基本的に気が狂っているので、普通の日本企業が真似するのはやめた方がいいだろう。トヨタかんばん方式同様に、NETFLIXの会社の仕組み、培ってきた文化に最適化されただけかもしれず、あまり一般化するような話ではないように思える。

ただ一方で、世間と常識とされている組織運営のノウハウが本当に意味のあることなのか考え直す一助にはなるように思う。最近、ホラクラシーという組織論も出てきているが、従来型の組織運営スタイルが本当に効率的なのか、問い直されるフェイズに来ているのは確かだ。

 

5冊目:オースティン・クレオン著「クリエイティブの授業」

クリエイティブの授業 STEAL LIKE AN ARTIST

クリエイティブの授業 STEAL LIKE AN ARTIST "君がつくるべきもの"をつくれるようになるために

 

ビジネス書というより自己啓発書に近いものだが、クリエイティブなことを始めるためのガイドとして素晴らしいと感じたので紹介したい。この本の良いところは、「100%のオリジナリティなんてない」、「まずは好きなアーティストから盗め」などアドバイスがいちいち実践的という点。「定職を持とう」「平凡に生きよう」みたいなアドバイスもある。

悩んだとき、人生に躓いたときに読み返したくなる一冊。

AWS Lambda が AppEngine になった日

11/30 の発表で、AWS Lambd が ALB のバックエンドとして使えるようになったという発表があった。

話題としては、同時に発表されたLambda の COBOL サポート(なんでや)に完全に隠れてしまったが、これはものすごく画期的なサービスだ。

前回「サーバーレス・コンピューティングの終着点」という記事を書いたが、データベース以外の部分についてはこれが実現したと言っていい内容となっている。

GCP には大昔から従量課金のアプリケーション・サーバーとして AppEngine が用意されていたが、AWS には Elastic Beanstalk という単に実行環境がプリセットされた EC2 や使い勝手が悪い API Gateway しかなかった。

今回のリリースで、AWS Lambda が ALB のバックエンドとして使えるようになったことで、Tomcat や Express にあたる部分として Lambda がその役割を担えるようになった。しかも、Lambda の起動時間の遅さを ALB のヘルスチェック機能を使うことでウォームアップ可能というおまけ付きだ。

実際、簡単なプログラムを使って確かめてみたが、ウォームアップ後であれば、1リクエストあたり 60ms で返答がある。十分なレスポンスタイムだ。しかも AppEngine とは異なり、1リクエスト15分までは待つことができる(お金はかかるが)。時間のかかる作票処理にも対応できる。

現在の Web アプリケーションは、仮想DOM を使ったクライアント部分とサービス呼び出しのAPIを分離するのが一般的となっているが、前者については S3 など完全に static なアプリとして提供し、後者については Lambda を用いて処理を行う、というのがベストプラクティスになるだろう。

残念ながら現時点では RDBMS までサーバーレスにするのは難しい(Aurora サーバーレスはあるものの、起動時間の問題で Web アプリの要件には適さない)。当面は DynamoDB のような NoSQL で、という話になるだろうが、やはり使い勝手や管理面で問題になる。リクエスト起動可能な RDBMS というのが次のホットトピックになるのではないかと思われる。