主夫ときどきプログラマ

プログラミング、Webエンジニアリング、etc

MySQL8.0のJSON型における正規化について

blockchain-kyoto.connpass.com

Blockchain勉強会 in Kyoto #05でMySQL8.0 使いたいからブロックチェーン実装してみたというタイトルで発表してきました。 MySQLを使いたいというモチベーションだったので、ブロックチェーンの話はこじつけではありましたが、発表できてよかったと思います。

スライドはこちら

JSON型のCanonicalizeってどうなんですか?という質問

発表の中でJSON型に保存したカラムの値からMD5のHash値を計算する部分があります。それについて勉強会後に質問されました。 「Oracleが開発してるんできっとちゃんとしてますよねー。」と話していましたが、実際のところはわからなかったので調べることにしました。

Canonicalize とは

データの標準化や正規化を意味する言葉です。例えばJSONの場合同じデータ構造でも文字列にしたときに別のものになってしまうことがあります。

a = {
  "name": "zorori", "skill": "c++"
}

b = {
  "skill": "c++", "name": "zorori"
}

aとbは同じname, skill というキーを持ちそれぞれ同じ値を保持しています。 そのためデータの表現としては同じものですが、定義されている順序が異なるため文字列化した時に異なった結果になってしまいます。

// on nodojs

// 文字列化しても同じ文字列にならない
> JSON.stringify(a)
'{"name":"zorori","skill":"c++"}'

> JSON.stringify(b)
'{"skill":"c++","name":"zorori"}'

// オブジェクトの比較も一致しない
> a == b
false
> a === b
false

厳密には JavaScriptJSON ではないので注意が必要ですが、JSONを文字列として表現する時、ルールに則って文字列化することで同じデータが異なる文字列にならないようにする必要があります。 これをCanonicalizeといいます。

JavaScriptJSONの関係についてはこちらを御覧ください。JSON: The JavaScript subset that isn't — Timeless

MySQL8.0 で動作確認する

JSON_OBJECT() 関数の挙動

動作を確認してみましょう。まずは JSON_OBJECT() 関数の動作をみてみます。ドキュメントはこちら。 引数にKey, Value を交互に与えることでJSONオブジェクトを作成します。

mysql> select JSON_OBJECT('name', 'ishishi', 'skill', 'melon-pan');
+------------------------------------------------------+
| JSON_OBJECT('name', 'ishishi', 'skill', 'melon-pan') |
+------------------------------------------------------+
| {"name": "ishishi", "skill": "melon-pan"}            |
+------------------------------------------------------+

mysql> select JSON_OBJECT('skill', 'melon-pan', 'name', 'ishishi');
+------------------------------------------------------+
| JSON_OBJECT('skill', 'melon-pan', 'name', 'ishishi') |
+------------------------------------------------------+
| {"name": "ishishi", "skill": "melon-pan"}            |
+------------------------------------------------------+

mysql> select JSON_OBJECT('skill', 'melon-pan', 'name', 'ishishi')  = JSON_OBJECT('name', 'ishishi', 'skill', 'melon-pan') as result;
+--------+
| result |
+--------+
|      1 |
+--------+

MD5ハッシュ値も比較してみましょう。

mysql> select md5(JSON_OBJECT('skill', 'melon-pan', 'name', 'ishishi')) md5
    -> union all
    -> select md5(JSON_OBJECT('name', 'ishishi', 'skill', 'melon-pan')) md5;
+----------------------------------+
| md5                              |
+----------------------------------+
| 72e1a15793042e2a7b9f250c7b37f750 |
| 72e1a15793042e2a7b9f250c7b37f750 |
+----------------------------------+

JSON_OBJECT() の戻り値は入力の順序によらず同じ表現のデータが作成されています。

JSON型での挙動

まずJSON型のカラムをもつTableを用意します。

CREATE TABLE `jdoc` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `doc` json DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

データを挿入します。

mysql> insert into jdoc set doc = '{"name":"noshishi", "skill":"onigiri"}';
Query OK, 1 row affected (0.10 sec)

mysql> insert into jdoc set doc = '{"skill":"onigiri", "name":"noshishi"}';
Query OK, 1 row affected (0.02 sec)

mysql> insert into jdoc set doc = JSON_OBJECT('name', 'noshishi', 'skill', 'onigiri');
Query OK, 1 row affected (0.01 sec)

挿入したデータはそれぞれ違う入力方法です。Tableにはどのように保持されているかを確認します。

mysql> select * from jdoc;
+----+------------------------------------------+
| id | doc                                      |
+----+------------------------------------------+
|  1 | {"name": "noshishi", "skill": "onigiri"} |
|  2 | {"name": "noshishi", "skill": "onigiri"} |
|  3 | {"name": "noshishi", "skill": "onigiri"} |
+----+------------------------------------------+

どの行も同じ形式のデータのようです。 MD5ハッシュ値も比較してみましょう。

mysql> select id, md5(doc) from jdoc;
+----+----------------------------------+
| id | md5(doc)                         |
+----+----------------------------------+
|  1 | 275aceba7931ad3e345e31d48a949e9b |
|  2 | 275aceba7931ad3e345e31d48a949e9b |
|  3 | 275aceba7931ad3e345e31d48a949e9b |
+----+----------------------------------+

ハッシュ値も同じなのでTableに保持されているデータは同じものといえます。

公式ドキュメントに記述がある

Normalization, Merging, and Autowrapping of JSON Values
ドキュメントには以下のように記述されています。

When a string is parsed and found to be a valid JSON document, it is also normalized. https://dev.mysql.com/doc/refman/8.0/en/json.html#json-normalization

Normalize と表現されていますが、MySQLではJSONは正規化された値が利用されるという記述があります。 また以下に記述されているようにJSON関数は正規化された値を返すようです。

MySQL functions that produce JSON values (see Section 12.16.2, “Functions That Create JSON Values”) always return normalized values.

結論

MySQL8.0でJSONを扱う場合「JSON型を使うことでMySQLが正規化してくれる」ということになるので安心して使えそうです。 めでたし、めでたし。

生存戦略の追記

前回投稿した記事 向こう2年くらいまでの生存戦略 - 主夫ときどきプログラマ を書くに当たり、影響を受けないように読むのを控えていた記事があります。

こちらの記事です。

blog.jnito.com

無事投稿できたので読んでみたら、自分の戦略には発注者視点というものが抜けいました。 これについては働きながら意識している部分がいくつかあるので、せっかくだから書いておこうと思います。 僕の場合は対等に1つのブロジェクトを進めていくという感じでやっているので、パートナーと呼んだほうがしっくりくるのでそうします。

パートナー視点での成果を提供する

不十分な仕様を開発者視点で補強する

いつも一緒に仕事をするマネージャーさんは開発をするにあたり仕様書をつくってくれます。 けれど、時間的な部分やクライアントの問題もあり抜けや考慮漏れが発生します。

それは仕方のないことだし、それでも開発できないこともないので必要な部分を一つ一つ埋めていく作業をこちらでしてあげると、たいがい喜んでくれます。 ドキュメントがGoogleDocsで作られている場合はこちらで加筆・修正してあげるとなおさら喜んでくれます。

相手が十分なスキルを持つマネージャーやエンジニアの場合、漏れがある原因はだいたいリソース(時間)不足なので、それを補ってあげることを重視します。

不足しがちなリソースを補強する

一方、相手が若かったり経験が少ない場合は、こちらで補いつつ、叱責し正しい方法などを示してあげます。 これは教育・指導すべき人たちのリソース(時間)不足が原因であることが多いので、そこを補ってあげます。

中小企業と一緒に仕事をしているとリソース不足がよく発生するので、そのへんを補ってあげられるような動きをするとだいたい喜んでくれていい関係を築けます。

その現場に不足してるスキルを示す

プログラミング経験の少ないメンバーが多いチームでは、オブジェクト指向であったりアプリケーションアーキテクチャの部分を担当したり、 データベースの扱いに長けてないチームではDB設計・構築・管理などを担当します。 モダン開発への理解が乏しいチームでは、スクラム、スプリント、CIなどの基盤を作るサポートをします。 それぞれのチーム・現場で不足していたり、最後の1ピースとなるようなスキルセットで参画すれば 長く良好な関係を築いていくことができます。

評価してくれる人のところへ流れていく

僕のことをよく思わない人ももちろんいるし、「いいね!」って言ってくれる人もいます。 「いいね!」って言ってる人の方へ流れていけばとりあえずいい気分で仕事はできます。

同じことをやっても、良い評価をする人も悪い評価をする人もいるので、良い評価をしてくれる場所へ行くのがWin-Winの関係になりやすいですよね。

評価してくれない現場や人たちと一緒に働いてもいいことないですから。

技術だけじゃないよ

エンジニアリングだけで仕事をするわけじゃありません。 お金を払ってくれる人が喜ぶことをしてあげることがビジネスの基本なので、エンジニアリング意外の部分で何が貢献できるかを考えると良いと思います。

向こう2年くらいまでの生存戦略

5年後、10年後の自分を想像してそれを実現するために必要なことをトップダウンして、、、っていう自己実現の方法論みたいなものがあるけど、僕にはそんなことできません。

10年前に自分がフリーランスになってると思っていなかったし、主夫とか言っちゃってるとも思っていなかったもの。せいぜい1,2年先くらいまでを想像してその時はこうしたいな、こうなっていたいな、を考えるのが精一杯でその先のことはさっぱりわかりません。

なのでこのエントリーは年始くらいから考えていることを「2年後くらいまではこんな感じで生きていこう」という軸で整理したものです。

戦略1 妻に働いてもらおう

僕は主夫なので普段は家事をしながらパートでエンジニアをしています。つまり妻はフルタイムで働いているということです。とても頑張ってくれています。妻が働いてくれている限り飢えてしまうことはありません。なので僕にとっての最も堅実な生存戦略は「妻に働いてもらう」ことなのです。

戦術1 規則正しい生活をサポートする

仕事を続けるには心身共に健康でなければなりません。体の健康を作るには規則正しい生活と食事が重要です。子供は21時には寝かしつけるので、妻にはそのまま一緒に寝てもらいます。そうすれば十分な睡眠時間を確保でき、生活リズムもよくなります。僕の健康のためにもできるだけ全員で一緒に寝るようにします。

でも家族が寝静まった後に飲むお酒はとても美味しい。

戦術2 健康的な食事に気を使う

毎日の食事を用意するのも主夫の仕事です。食事は肉か魚を主菜し、副菜を野菜中心で2,3品ほどつくります。料理は比較的シンプルなもので煮物、焼物、炒めも、サラダ、和え物にします。 和食を基本にしておけば、だいたいバランスの良い食事になります。和食バンザイ。 手間のかかる料理はあまり作りません。素材の味を活かしましょう。 8割がた妻も子供も食べてくれます。

手のこんだ料理は外食で美味しくいただきましょう。

戦術3 ストレスを減らすためにゆとりを持つ

会社員の労働時間は会社によって設定されます。ゆとりが欲しい時に仕事を減らしたり労働時間を短くしたりすることは簡単ではありません。夫婦ふたりが会社員の場合は1日のほとんどの時間を会社によって拘束されてしまうので、夫婦や家族の時間を作ることは難しくそれがストレスになる場合があります。

そうならないためにはゆとりを持つ必要があります。フリーランスは仕事量を自分で調整できるのであまり働かないという選択肢がとれます。時間的なゆとりを持つことで家族の時間を確保し、ストレスを軽減することができます。

戦略2 商品価値を高めよう

フリーランスとしてやっていくってことは、自分自身が商品になってそれを自分で売る、ということだと思っています。 商品を売る方法はいろいろあります、僕はセールスマンではないから、良い売り方を知りません。 でも商品の売り方に力を注ぐ以前に「良い商品」である必要があることは知っています。 つまり自分の商品価値を高めて「良い商品」になることが大事なのです。

戦術1 希少価値を上げる

フリーランスの働きなんてのはちっぽけなものなので、大衆受けする必要はありません。 ニッチな分野で自分を売っていくことが大切です。 そのためには自然と希少価値を高めて差別化しよう、という事になります。

複数のほどほどエキスパートになる

特定の技術のエキスパート(専門家)になれればそれが一番良いと思います。 ただエキスパートを目指して勉強してると、本物のエキスパートしか目に入ってこなくなります。 すると、いつまでたってもエキスパートになれる気がしないしいつまでたっても自分が偽物の気がしてなりません。これは精神衛生的に良くないし、自分にはそこまでのストイックさは残念ながらありあません。

なので本物のエキスパートが判別できる程度になれば、ほどほどのスキルを持っていると思われるので、 そういう分野を複数持つことを目指します。 もうそれはエキスパートじゃないんですけどね。

コミュニティの主催者になる

エンジニアは一生勉強が必要だ、と言われています。 しかしみんな勉強しているかというと、実際はそうでもありません。 エンジニアの中でも勉強会などのコミュニティに参加する人はけっして多くありません。 コミュニティに参加する人よりも発表する人のほうが少なく、 発表する人よりもコミュニティを運営する人のほうが多分少ないでしょう。 コミュニティの主催者になることは希少価値を上げる手助けになります。

わかりやすい資格を持つ

資格なんて意味ないよ、という意見があります。でも僕はどちらかといえばMatz派です。

やはり資格はアウトプットの1つの形として意味がありますし、試験をパスするという一定の能力を示したことになります。 評価する側もわかりやすいと思うので、僕はIPAでやってるいくつかのスペシャリスト資格をとろうと思っています。 合格率も15%くらいなので、複数持っていれば希少価値は高いといえます。

OSS開発に参加する

OSS開発に参加してます、というとたいがい「すっげー」となりますしそう思っていました。でも、ホントのところはたいしたことありません。 OSSのコアメンバーでコードにコミットしている人たちはホントのホントに「すっげー」のですけど、もっと簡単にOSS開発には参加できます。 それを知ってからは積極的にプルリク送るようになりました、今後も継続していきたいと思います。

これも希少価値が高く、コスパがとても良いです。

戦術2 仕事を減らしてインプット/アウトプットを増やす

先にも触れているように、生活にゆとりを持つためには仕事を減らす必要があります。 またほどほどのエキスパートになるためにも勉強する時間も確保しなければなりません。 そのためには仕事を減らして時間を作る必要があります。

フルタイム勤務のように週40時間+αを労働に使っていたら時間なんてあっという間になくなってしまいます。 仕事は週25〜30時間くらいに減らします。

仕事とは別に勉強枠で時間を設定し、その中でインプットとアウトプットを行っていきます。 アウトプットはブログ、勉強会での発表、OSS開発への参加などがありますが、見える形で残すことが大事です。

戦術3 コネを増やす

コミュニティや勉強会に参加してコネを増やします。 発表して注目してもらってコネを増やします。 他になにかあるかなぁ。

[追記] パートナー視点での成果を提供する

別記事で追記しました。

masayuki14.hatenablog.com

OSS Gate 京都ワークショップを開催しました

OSSGateワークショップ京都を開催しました。今回も進行役として参加しました。

oss-gate.doorkeeper.jp

当日の様子

今回はビギナー、サポーターそれぞれ4人ずつの参加でした。サポーターのうち3人は過去にビギナーとして参加してくれた方々で、大阪メンバーからの助け無しで開催できたので、京都開催としては前進したなぁというところです。 サポーターもビギナーもそれぞれ初めての人が多い会でしたが、1対1で取り組めたおかげか、一緒に困ったり悩んだりしながら、それでも楽しそうに作業に取り組んでいたように思います。

懇親会で「進行役はサポートする人がいれば自分でもやれそう」っていうアンケートの選択肢についての話になり、「結局一人でやらないといけないよね」という意見が出ました。 サポートってなんだろう、みたいな話になって、二人体制でやって足りない部分の説明をもうひとりがやるとか、パートごとに進行役を変えたりすれば負担が減ってできるかも、とかいう意見がでたので次回はそのへんを試してみたいと思います。

f:id:masayuki14:20180624151211j:plain
当日の様子

進行役について

進行役は4回目だったので、直近の1週間の間は準備としてOSS Gateワークショップの動画を仕事中に流していました。 スライドは1度だけ通して見て進行のイメトレをやった程度で、今までで一番準備が少ない回でした。

4回目ということで油断したせいか、ワークショップを通してうまく進行ができた手応えがありませんでしたが、アンケートによれば皆さんに満足してもらえたようです。

初めて進行役をやったときの記事を見ると同じように進行に手応えがなくても参加者には満足してもらえていたようなので、このワークショップはパッケージとして良くできているんだと思います。携わっているコミュニティの皆さんのおかげですね。

進行役で参加するとなるとハードルが高そうですが、スライドもしっかりできているしスライドどおりに進めていけばだいたい満足してもらえそうなので、サポーターで参加したことある人は進行役での参加にもチャレンジしてほしいと思います。

今後のこと

そろそろ誰か進行役をやってくれる人が出てきてほしい。 ということで、次回は開催場所の新規開拓と新しい進行役の二本立てのチャンレンジかな。 少しずつではあるけれど京都の人たちが増えてきたので細く長く継続していきたいです。

「本書けますよ」を具体的に考えた結果「連載の仕事を取りに行け」という結論に至った

f:id:masayuki14:20180518093625j:plain

連載の仕事をください。小さくてもいいので。

きっかけ

はんなりPython#5の懇親会で「本書けますよ」ってなことを言われた。(コミュニティに参加することで見えてくるもの - 主夫ときどきプログラマ

「いやいや、そんなのむりですよ。」であったり「そうですね、書いちゃいましょうか。」みたいなことを社交辞令のように話して、普通はその場限りの話題になるだろう。

でも「本書けますよ」なんてのは自分の発想に無いところからの意見だったので、具体的に考えてみた。

本の種類

本といってもいろいろ種類がある。 エンジニアなので技術書っていうのが1番憧れるところではある。 たとえばRubyist伊藤さんプロを目指す人のためのRuby入門を出版している。(Ruby界隈の有名人) でも自分には技術書を出版できるほど精通した分野なんて無いし、実績もないので無理だ。

次に思い浮かぶのが新書でありそうな「フリーランスになる方法」のようなもの。 これもフリーランスをやっていてこそのノウハウなんかを書くんだろうけど、 そもそもフリーランスになりたくてなったわけではないし、 いままで自分がフリーランスであるということを体系的に考えたことがないのでこれも無理そう。

そこで目についたのが「エッセイ集」。これならできるかもしれない。ということで手元にあるエッセイ集のような本を調べることにした。

エッセイ集を分析する

手元にあるエッセイ集をいくつか並べた。

これらは本を書くために描き下ろしたエッセイが集められているのではなく、ブログや雑誌で書かれたものを集めたものになっている。 なので「本を書くぞ!!」っていうモチベーションは不要で、「1つ1つの記事を丁寧に書こう」というモチベーションで続けられそうだ。

ブログで1つ1つの記事を積み上げていけば何とかなるかもしれない。

書籍としての一貫性

Joel on Softwareであればソフトウェア開発について、社会人大学人見知り学部 卒業見込であれば芸人らしくオチのある文章、開店休業であれば食に関するエッセイという具合に書籍には一貫性がある。

自分がエッセイを書く場合も一貫性を持たせたほうが良さそうだ。とりわけ働き方改革なんて言葉が世間を賑わせているのでフリーランスのライフスタイル、ワークスタイルをテーマにするのがいいかもしれない。

エッセイの数は30〜40本

それぞれの本にはエッセイの他に、まえがき、あとがきがあったり書き下ろしの文章があったりするが、 メインであるエッセイは30〜40本ある。月刊連載とすると約3年分の仕事がまとめられていることになる。

同じようなペースでエッセイを書いていくと最低3年はブログを続ける必要があるし、その時々の渾身の文章を書かないといけない。 継続することは大事なのだ。

1つのエッセイあたりの文字数は2000字前後

Joel on Software 以外の本はどれも雑誌の連載をまとめたものになっている。 本によって多少異なるけれど、どのエッセイも3ページほどで同じような文章量だ。 ざっと数えたところ2000字前後で1つのエッセイになっている。

子供の頃は原稿用紙5枚の作文なんて苦行でしかなかったけど、今ならいけそうな気がする。

文章とセットの写真やイラスト

雑誌連載というのも関係しそうだが、それぞれのエッセイには必ず写真やイラストが一緒に載せられている。 イラストはおそらく作家の直筆だろう。写真は風景が多かった。

イラストを書くことに関しては可もなく不可もなく、という程度だが、PCに取り込んで加工するスキルが無いのでまずは写真ではじめるのが無難そうだ。 そのうち直筆のイラストにしていきたい。イラストのほうが人間味がでそうじゃん!!

作家のユニーク性

各作家はそれぞれの分野の一流であるし、ユニークであったりする。そして長く活躍している。 そういう人物には必ず固定のファンがいるもので、自分もこれら作家のファンであると言える。

自分はエンジニアとして一流ってわけではないけど、ユニーク性っていう部分に絞れば悪くないと思う。 だって主夫でフリーランスでコミュニティのオーガナイザーなんだぜ!! そしてユニーク性をアピールしてファンを作っていく必要もありそうだ。

まとめ

まとめると

  • 記事に一貫性をもたせる
  • エッセイ数は30〜40本
  • 1エッセイあたり2000字
  • 写真やイラストとセットにする
  • ユニーク性を演出する

を実現できえれば、本を作る上での最低限の体裁は整いそうだ。

実現するには

2000字程度のエッセイを30本書く必要がある。 毎月1本書いたとして2年半かかる計算だ。これが最低条件。 一番手軽なのはブログでエッセイを書くことだ。

しかし、文章を書くことを仕事にしたことがない人間が、はたして良い文章など書けるのだろうか。 今まで意識してエッセイを書いたこと無いが、そもそもエッセイとは何なのだ?

リングに上がろう

ブログは趣味の延長でしか無いし、そこに責任は発生しない。 文章を書いてそれを評価してもらいお金をもらう、というリングに立たないといけない。 仕事として文章を書くことで責任も生まれるし、その厳しさにさらされる。

文章のプロでない以上、まずはプロになるためのリングに上がらないといけないだろう。 それで読者、編集者にボコボコにされることで、やっと「本書けますよ」を真に受けられるんじゃないだろうか。 そのためには知り合いのツテを辿ってでも自分から仕事を取りに行かないといけない。

私をリングに上げてください。

これからのこと

  • 毎月1本、渾身のフリーランスエッセイをブログで書く(2000字)
  • 小さくていいので文章を書く仕事を取りに行く

の2本立てで行動しようと思う。そうすれば、3年後に本が出版出来るはずだ。

MySQL InnoDB Clusterを動かしてみた成果を発表してきた

MySQL InnoDB Cluster を使って運用を手抜きしようというタイトルでテクテクTech #2で発表してきました。MySQL InnoDB Cluster は先月Oracle主催のセミナーで初めて知って気になったので、その時のセミナー資料をみながら実際に動かしてみました。

masayuki14.hatenablog.com

発表ではMySQL InnoDB Cluster の概要を説明してからデモをやって、実際の動きをみなさんに見てもらいました。デモ自体はわりとスムーズにできましたが予想以上に時間がかかってしまい、発表時間25分のところを40分もかかってしまいました。デモをやるのは時間かかりますね。

speakerdeck.com

懇親会でフリーランス集めて仕事のやり方や1日の過ごし方を発表する会をしたいね、という話になったので次はその時にでも発表しようと思います。

コミュニティに参加することで見えてくるもの

f:id:masayuki14:20180502113511j:plain

はんなりPython#5の懇親会にて。

主催者ということで、コミュニティの説明をしたり発表したりで毎回人前にたっている。 自己紹介は「主夫」業がメインで、パートタイムでエンジニア(フリーランス)してます、という流れ。 少しずつ認知されてきた感じがする。

今回の懇親会でそういう自分の経歴を話す機会があった。

視点が変わると見えるものが変わる

務めていた会社が解散になって、他の会社をいろいろ見てみたいからと言う理由で そのままフリーランスになって、 結婚して子供がいて妻がフルタイムで働いているから自分が家事全般して、 空いた時間の制約の中でソフトウェア開発をするようになって、 子供も大きくなっってきて余裕が出来てきたからコミュニティ始めて、 っていうことをざっくりと話した。

すると意外な反応があった。

主夫でフリーランスでコミュニティをオーガナイズしてる人なんて他にいないよ。
本書けるよ。ロールモデルとして目指す人いそう。
などなど。

自分のような仕事や生活の仕方をしてる人は珍しいだろう、 ということに自覚はあったけど、 改めて他の人から言われることでそれを再認識した。

そして、そういうこと知りたいと思う人がいるということ。

フリーランスだから出来る話があるらしい

ということで、これまでは技術系の内容をブログに書いていたけど これからはライフスタイル的なものもブログに書いていこうと思う。

ユーチューバーなりましょう、という話もあったけどそれはどうなんでしょうね。