読者です 読者をやめる 読者になる 読者になる

Deemo 2.0の聖地を巡礼した話

Deemoという音ゲーがある。台湾のゲーム開発会社Rayarkの、代表作と言ってもいいと思う。主としてピアノ曲で構成された楽曲に合わせて「ピアノを弾く」類の、ルールの簡単なゲームで、音楽の美しさと、背景にある不思議な世界観のストーリーとグラフィックスが人気だと言えるだろう。楽曲は概ね台湾と日本のインディー系ミュージシャンから提供してもらっているようだ。

play.google.com

今日はそのネタバレ話を書こうと思う。ネタバレを見たくない人はここでこのページを閉じたほうがいい。読みたい人は「続きを読む」から先に行ってほしい。

続きを読む

Xamarin.Forms本 邦訳読書会について

以前JXUGのイベントのどれか(多すぎて忘れちゃった)でちょろっと告知したことがあったと思いますが、Charles PetzoldがXamarinにjoinして執筆している Creating Mobile Apps with Xamarin.Forms(以下「Forms本」) の日本語訳作業が進行しています。現在、藤原さん(@yfakariya)とわたしがほぼ半々ずつ監訳するという感じで進行しています(ここまでの実績に基づく予想値)。

ただ、原著が1200ページくらいある大作なので、ごくわずかな監訳リソースで見ていると、それなりに不安感があります。そこで、Forms本の進行中の訳本の原稿をもとに読書会を開いて、希望する人に読んでもらい、何かしらのコメントやフィードバックをもらえたらもらおう、というのを思いついたので、発行する日経BPさん、それと監訳チームのひとりである田淵さん(@ytabuchi)にご協力いただいて実現することになりました。

そういうわけで、これからしばらく、多分半年弱くらいの間、20章以上を十数回にわたって読み解く読書会をやろうと思っています。かなりの回数になるので、たぶん週1回くらいやることになると思います。紙に印刷した訳本の一部をお渡しして、それを読んでいただくことになる予定です。

そこで、まず参加者を募集したいのですが、いかんせん勉強会の内容の性質から、人数は多くても10人弱、そしてメンバーはなるべく固定しない(主にわたし、たまに田淵さんがホストするところだけ固定)、参加者はわたしが諸々考えて調整させていただく、という運用を想定しています。(実際に参加者が多く集まらなければ、実質的に固定メンバーになる可能性もあります。) ベテランの視点も重要ですし、初心者の観点でもコメントをもらえればいいと思っているので、Xamarin.Formsに技術的な関心がある方、という以上の条件は今のところ考えていません。

開催日時は、第1回のぶんから未定なのですが、今のところ「水曜・木曜の19:00くらいから」を想定しています*1。一応、毎回connpassあたりにイベントを立てようと思っています。

会場については、少し奇策を考えています。オフィスの会議室などをお貸ししていただけるところを転々としたいと思いつき、実際にいくつかの場所はお借り出来そうなので、試しにそれで回してみようと思っています。わたしが東京にいるので、だいたい東京開催になると思います(ごめんなさい)。書いていて思ったけど地方巡業するのもいいな…(!) あと、この勉強会を開催するために会場をお貸しいただける会社さんなどありましたら、ぜひご相談させてください。

というわけで、近々イベントを乱立(毎週分)させようと思っています。twitterで @atsushieno から告知しますので、そこでチェックしてくださいませ。

1/12追記: イベント登録を始めました。各回ここから辿れると思うので、チェックしてみて下さい。

xamarinformsbookreading.connpass.com

*1:ノー残業デーが多そうな水曜を主に想定しつつ、曜日を固定すると参加できない層のために木曜も考える、という感じです

楽器を作ろうハッカソン

年末からこんなに連続投稿していて、どうしちゃったんだろうわたしもうすぐ氏ぬのかなみたいな感じになってきましたが、皆さんいかがお過ごしでしょうか。

そんなわけで(?)、今日はイベントの直前告知(!)です。RasPiなどを使って楽器などをハードウェアハックしてみたい人のための集まりです。

insthackersnewbies.connpass.com

適当に思いついて開催するので、参加者が具体的に何をするかは参加者次第です。RasPiでもいいし、そいつにAndroid Thingsを載せてただのAndroid開発にしてもいいし、Arduinoでもいいし、素材は問いません。ハードウェア系のハックということになっていますが、実際に行う作業は純粋にソフトウェアだけかもしれません(わたしが今のところそうなりそう)。

成果発表は特に予定していません。5時間弱で成果が出るのを目標とするのもどうかと思いますし。成果・やりたいことを問わず、しゃべりたい人は適宜雑談してください(「みんなに聞いてもらう」時間は設けない予定です)。

なおtwitter上で会場未定で応募をかけたところ、株式会社ISAOさんのオフィスを会場として提供していただけることになりました(ありがとうございます)。電源とwifiは使えるようです。ハンダ付けなども注意して作業してもらえるならOKだそうです。(自分で持ってくる必要があります。はんだごての備品はありません。)

秋葉原付近なので、いざとなれば部品の買い出しに行くことも出来ます(たぶん往復+買い物で1時間くらい見たほうが良いでしょう)。

わたしも含め初心者が多いと思うので、まだよく分からない…という方でもお気軽にどうぞ。

技術書典2でXamarin本を出そう

昨年2016年の6月に行われた技術書オンリーの即売会イベント技術書典が、今年2017年の4月にまた開催されます。

techbookfest.org

前回の技術書典の成果については、こちらに詳しくまとめられています。これを見るに、次の技術書典2では、Mono/Xamarinだけでも十分に格好のつく同人誌販売が行えるのではないかと思います。そこで、折角なので興味のある皆さんは、わたしと一緒に原稿を書いて1冊にまとめた同人誌を出してみませんか?

わたしもTechBoosterでの同人誌発行作業を見ていてある程度は分かるのですが、まだまだ手探り状態なので、細かいことはおいおい決めていくつもりです。とりあえず、今書ける詳細を列挙していきます。

  • 原稿はgithubのprivateリポジトリ上でまとめていきます。執筆に参加するにはgithubアカウントが必要です(無償アカウントでも大丈夫のはずです)。
  • 原稿はRe:VIEW形式でまとめます。 https://github.com/TechBooster/C89-FirstStepReVIEW-v2 が参考になるでしょう(これとだいたい同じ形式の書籍が出来上がるイメージです)。md2reviewを使うと、markdownからの変換も出来るでしょう(ただし完成原稿を上げるにはRe:VIEW形式で修正を加えていく必要があります)。atomとVSCodeにはRe:VIEWサポートのプラグインが存在します。
  • 原稿のページ数については、制限はしませんが、だいたい10-15ページ、15000字くらいあればサマになると思います。30ページ以上の大作も受け付けます。
    • もし人数が多く、あるいはページ数が多くなりすぎた場合(だいたい140ページくらい以上になった場合)は、分冊することになるでしょう。あまり多いとわたしが編集作業できなくなるので、絞り込むことになるかもしれません。
  • 内容の難易度は問わないこととしますが、基本的にatsushienoがお品書きを決めるということには同意していただきます。
  • 方向性としては、基本的に、ゆるゆると、MonoまたはXamarinに関係するものとします。
  • 原稿を執筆した後で、参加者同士のクロスレビューを行います。原稿を読み合って、修正案を出していく作業です。
    • レビューが終わったら、atsushienoが最終的な文言レベルの編集作業を行います。

というわけで、もし参加してもいいよという方がいらっしゃったら、ぜひtwitterの@atsushienoにmentionするか、このエントリへのコメントなどでお伝えください。ちなみに、twitterで募集してみたところ、3名くらいの方が手を上げてくださったので(ありがとうございます)、それらの皆さんにはgithubアカウントから参加リクエストを送ろうと思います。

なお、1/7締切の技術書典の参加申し込みそれ自体にはもう申し込んでありますが、サークルカットや内容など未確定の部分もあるので、早めに参加表明していただけるとわたしが助かります。あと参加の確約があるわけではないので、もし落選したらゴメンナサイ(今回は会場にゆとりがあるので、前回のような厳しい倍率での争いにはならないと思いますが)。

…というわけで、皆さんのご参加をお待ちしています。

2016 + 2017 EP (技術編)

2016年振り返り

2016年もいよいよ最後の1日となりました。今年は実にさまざまな物事に振り回された1年でしたが、何とかわたし1人の実力で乗り切ることが出来ました。自分自身に感謝を述べるとともに、来年も気を引き締め、誰に何を恥じることもないよう誠心誠意筋を通して適度にがんばっていこうと思います。

今年はややランダムにアウトプットを出してきた1年だったと思うので、いろいろ引っ張り出しつつ主だったものを振り返ってみます。

.NET Platform Standard日本語訳

.NET Coreは標準的なAPIを提供するんじゃなかったの? PCLプロファイルが増えすぎてワケわからなくなってんだけどどうするの? みたいなところを解決するための方法として導入された仕様でしたね。今年はこの話がいろんなところで地味に出てきたので、.NET技術者クラスタでは関心の高いネタのひとつだったと思います。

Android Studio 2.0のInstant Runの仕組みを解読する

DroidKaigi2016でしゃべったネタ。信じがたいことに、コレがまだ2016年の話でした。DroidKaigi、初参加でしゃべる側でしたが、他のセッションも面白く、たいへん充実した2日間でした。Instant Runでしゃべることになったのは、もちろんXamarin.Androidのfast deploymentを見てきたからイケると思って応募したためなのですが、Android開発者クラスタには新しいトピックだったこともあって、また次世代の話としてinstant programmingのストーリーまで用意していったこともあって、今年一番完成度の高いセッションが出来たのではないかと思います。そしてセッションよりまとめ解説のほうが本気度が高いです。わたしの技術情報まとめとしてはここ数年で一番の出来だと思います(ワインっぽくなってきた)。この頃から、技術セッションを事前の長文まとめをもとに用意する、という流れを作るようになりました。

長かったこれまでと、分からないけど楽しみなこれから

ご存知MicrosoftによるXamarin買収の発表を受けて書いたポエムです。qiitaに書けばよかったかしら。消されないはずだし。この頃から「所在不明で海外の会社で仕事する謎の生き方」からの引退を意識して、同じことをしたい人たちに道筋を残しておかなくては、みたいなことを考えるようになりました(概ね日本の会社ではたらくより自己実現しやすいと思うので)。日本ではXamarin最後の日と合わせてポエム2本書いたし、台湾でもXamarinコミュニティ第1回meetupでその話をしてきました。

Xamarin.Android SDK解説 @ 技術書典(1)

6月には技術書典が開催されました。Xamarin関係の原稿を書けという指令があったところだったので、4月のBuildで告知されEvolveで公開されたオープンソースXamarin platformのうちXamarin.Android SDKについて、そこそこ詳しく踏み込んだ話を書きました。30ページくらいでだいぶパワーを使ったのですが、正直なところ、踏み込み度合いで考えると、まだまだ雑な部分が多い感じです。ともあれ、これをもとに、7月にはYAP(achimon)Cで、8月には台湾のCommunity Open Campで、いずれもXamarin.Android SDKについてしゃべりました。来年4月には技術書典2もありますし、Xamarin本もまとめたいと思っています(Androidの話は書かないかもしれません)。技術書典自体にもスタッフとして参加していたのですが、来場者も1500人ほどで、イベントとして大成功でした。

language server protocolについて(前編)

2016年はVisual Studio Codeが大躍進した1年でした。単なるエディタの実装というより、オープンなIDE技術の標準仕様を策定して「みんな」を幸せにしようという本家MSの開発者の姿勢は素晴らしいですね。language serverはそのオープン仕様の主要な例ですが、IDEのコードエディタの仕組みって、なかなか理解してもらえない難しいトピックなんですよね。なので、この文章はわたしらしくもなく「わかりやすさ」を第一にまとめたものです。台湾のイベントの後でVSCodeの話をしていたスピーカーに見せたら、これは他で読めない内容だから是非とも英語でまとめてくれ、と言われて、これは成功した!と思ったものでした。いや英語化できていませんががが。あと前編と言いつつ後編が書きかけのままなのですが…そのうち…(汗

.NET Fringe Japan 2016が見せた「オープンな.NET」という世界

今年わたしが主催側で開催したイベントは多分これしかないのですが、オープンソースを主軸にさまざまな.NET開発のセッションを集めることができて、大成功だったと思います。わたしは9月頃はけっこう他でテンパっていてセッション準備がおろそかになってしまった側面があるのですが、あのセッションの後、Xamarinのソースをカジュアルに見てくれる人が多くなったし、今年はちらちらとPRを出してくれる人も出てきたし、ある程度は種を蒔けたのではないかと思います。monoやXamarinに恒常的にcontributeしてくれるような後継者は出てきませんでしたが、来年もこりずに新しく挑戦してくれる人たちを待ちたいと思います。

vscode-language-review

VSCodeの技術解説を書いておきながら、アドインのひとつも書いたことがないというのは、ちょっと忸怩たるものがあり、冬コミ向けの原稿執筆で使われることもあろうと思って、ちまちまとVSCodeアドイン開発…というかTypeScript開発全般…を勉強しながらアドインを作りました。動くようになってくると面白かったです。今はRe:VIEW原稿を書くのに使っています。10月までは技術セッションでしゃべりすぎたので、今年書いたコードは少なく(まあもともと多くありませんが)、完成したのはこれくらいでしょうか。VSCodeアドインはもうひとつ作りたいネタがあるのですが、当面は重厚な監訳タスクが邪魔をしていて、それに着手できるまではしばらくかかりそうです。

AndroidでJavaCPPを使用する in なないろAndroid @ C91

(公表順ではありませんが、書いた順としてはこれなので…)唐突にJava?と思われそうですが、5年前にまとめたBridJ以来のC++相互運用フレームワークの調べ物のJava編の流れだと理解してもらえればいいです。100% Javaの話を書いていますが、当然ながら.NET方面の実装についても関心があるわけです。ただ、現状のCppSharpが最適解だとは思えないので、まずJava方面を見て歴史に学ぶべきだと思っています。同じネタでDroidKaigi 2017トークに応募したのですが、さすがに周縁トピック過ぎて不採用でした…。次はJNAかな?

Visual Studio for Macの.NET Coreサポートの実装について

Connect();に向けたXamarinの大きなアップデートで発表されたVS for Mac、その中で特に面白かったdebug protocolの取り込みの話を中心に書きました(.NET Coreプロジェクトのサポートについて調べていたらそこに行き着いた)。これも動機付けとしてはlanguage server protocolのネタと重複する部分が多いです。最後のまとめといい、こんなに「MSの手先」みたいな雰囲気の記事を書くつもりはなかったのですが(今年日本MSの中の人が書いた技術記事の中でも、トップクラスの前向きかつマトモなMS推し記事だと思いませんか?)、まあたまにはいいでしょう。

Xamarin.Formsに新しいプラットフォームを追加する: 前哨戦)

Xamarin Advent Calendarでは、余人の追随を許さないネタを書くつもりでした。さんざん手垢の付いたXamarin.Formsを選びつつ、わたしはただの消費者にすぎないおまいらとは違う!みたいな気持ちで(!?)、新しいプラットフォームのサポートなら誰もやるまいと思ってソースをいじり始めたのでしたが、いかんせん12月は海外渡航業務が重なって週末が完全につぶれるという憂き目にあい、すっかり不完全燃焼で終わってしまいました(もちろん未完成でも現状有姿で当日に出すつもりでしたが)。しかもTizenで先鞭をつけられちゃうしィ。Xwtでまともに動くようになるまでは、まだまだかかりそうです。

…とまあ2016年はこんな感じです。

2017年の予定

いつもなら年末年始はのんびり過ごしつつコードを書いたり長大な記事を書いたりしているところなのですが、今年はいつもより少々慌ただしい感じになりそうです。とりあえず明日を目標に、以下の3つについて書く予定です。また来年もよろしくお願いします。

  • Raspberry Pi etc.で楽器を作ろうハッカソン
  • 技術書典2でXamarin本を出そう
  • Xamarin.Forms訳本勉強会について

2016年の終わりに感謝する作品集

毎年クリスマスまたは歳末に書いている恒例のエントリです*1。例によって今年初めて出会った作品がメインであり、今年リリースされた作品には限りません。

2015 2014 2013 2012

まずは音楽から。

Electrocutica "Piano Lesson"

electrocutica.com

アルバム"SWANSONG"は、最初、曲目を見て、何だよまた旧作だらけじゃねーか!と思って半ば冷めた目で見ながら聞いていたのですが、vocaloidではなく人が歌っているバージョンの完成度の高さに気付いてから、すっかり聴きこむようになってしまった1枚です。

その中でもPiano Lessonがすごい。…えろい。今年出会ったあらゆるものの中で圧倒的でしたね。雨音のパーカッションとそれを引き立てる(珍しく?)控え目なリズムセクション、存在感のあるアップライトピアノとメロディラインを弾いているはずなのに他の音の存在感を引き立てるエレクトリックピアノの対照的な繋ぎ合い、vocaloid版には無いミステリアスなモノローグの囁き、どれも繊細に作りこまれているのが分かる。ホワイトノイズ多めのサウンド構成のSWANSONG(8曲目)と比べてハッキリと聞こえるブレシングも、やはり意図的な構成でしょうか。モノローグが鬱展開(?)になるのに合わせて、輝度の高いストレートなエレピから、ロータリーのかかった沈み込むようなエレクトリックオルガンに切り替わる流れも、よく雰囲気を出しているし、そのままの不安定な構成でしばらく続けて不安感を描写するのもうまい。

Electrocuticaはその音作りがプログレッシブで面白いので昔から聴いていますが、これはひたすら美しさを受け止めるという新鮮な気持ちで聴けた作品でした。

Lemm "Atoropa"

www.youtube.com

2014年の終わりに「はやく復活しないかなあ」みたいに書いていたところ、もう復活されたということで嬉しい限りなのですが、戻ってきて出できた作品がいきなりすごい。初音ミクsweetを前面に押し出した基本的なテイストも、前衛的なリズムの楽曲も従来通りで、安心して聴けるのですが、サウンドプロダクションとかかなりレベル上がってる(というのは過去作品と比べて、それぞれの音がずいぶん聞きやすくなったという感想ですが、自分自身がそんな高度な技術をもっているわけではないし、適切な表現なのかは自分でもよく分かりません)。氏の昔の作品で聴かれる「音の洪水」とはずいぶん印象が違うと思います。

www.nicovideo.jp

しかも音楽だけじゃなくてこのPVまで自作とかすごい。去年書いた暗鳴ニュイの人もそうだけど、この界隈はマルチタレント多すぎでは…

それにしても、monochromiaのblindもそうでしたが、意味を理解しないで聴きたいくらいdepressingな歌詞を書くのに(「突き放す手で…触れてくれるの?」とか、ちょっと思いつけない)音のほうはこんなにencouragingなのか。皆に幸あれ。

次はソフトウェア。

Classeur

classeur.io

classeurはブラウザで動作するマークダウンエディタです。編集中にmarkdownの文法を解釈して強調や画像の展開などを行ってくれるので、AtomやVSCodeみたいな「単なるテキストエディタ」で、別タブのプレビュー画面と編集画面の間で視線を行ったり来たりするより、ひとつの編集画面だけでいろいろ完結できるので楽です。qiitaと違って「投稿」を意識することもないし、そのぶん草稿リストの管理もストレートです。

この草稿字体も(投稿先ははてなですが)classeurで書いています。

実装にはStackEditが使われていて、コレ自体はHTML5のoffline storageを活用しています。Google Docsが日本語IMEをinjectしすぎでバグバグで基本的な利用に支障がありすぎたので、しばらく前からStackEditに切り替えていたのですが、StackEditはだいぶnaiveなところがあって、ブラウザ環境が変わるとローカルストレージが切り替わるので結局Google Drive拡張などを使用して共有するしか無いのと、コンテキスト ドキュメントが1つしか開けないために複数ドキュメントを編集できないという致命的な問題があって、なかなか主要なエディタとしては定着できていませんでした。

Classeurはその辺りの問題をきっちり解決してくれていて、主にちゃんとWebサービス化しただけなんですが、UIもきれいに作りなおされていて、素人でもとっつきやすいエディタだと思います。

Visual Studio Code

VSCodeは、わたしがようやく最近のJavaScript/TypeScript事情を真面目に眺めてみようと思うようになった原因です。VSCode自身がnodeベースのOSSアプリで、それ自体が標準的なnpmのパッケージとして作られていて、アドイン拡張の基盤もnodeのやり方で開発できるので、ちゃんと勉強する意味があると感じさせてくれたものです。

また、VSCodeは、単なるbetter (あるいはin-house) text editorを目指して作られたものではなく、標準としていくつかのオープン プロトコルを提案しているところも魅力的です。この辺は既に紹介しているので(language server protocoldebug protocol)、それぞれ参考にしていただければと思います。どれも「VSCodeが初めて」というわけではありませんが、言語開発コミュニティにもエディタ開発コミュニティにも呼びかけて、全体としてバベルの塔状態を解消していこうとする姿勢は、とても新生Microsoft(本家)らしくて良いと思います。

最後に映画(珍しく)。

聲の形

今年はゴジラ、君の名は、この世界の片隅に…と、名作と呼ばれる日本映画がたくさん出てきた1年でしたが、個人的に一番響いたのはコレでした(意外にも同じ意見の人がわたしの周りにはほぼいなそう)。かなり予備知識無しで、CM動画だけを見て「単純な恋愛モノかな…?」程度の認識で見に行ったのですが、そんな要素はだいぶ隠蔽されていて(そうでもないか)、ひたすらchallengedな行き方を余儀なくされた聾唖者と、その周辺の人々のすれ違いを描写した作品でした。

あまりその魅力を語れる言葉が無いのですが、自分の状況にもある程度近いものがあり、1人で無理することなくがんばってやっていこう的な気持ちになったものです。

また来年も

心を突き動かされるような作品に出会えると良いなと思います。あと、他人にそうしてもらうだけでなく、自分でも何か出来るようになりたいですね。

*1:大元はコレだったんだけどもう誰も覚えていない気がしますね。

C91: 「なないろAndroid」にJavaCPPの記事を書いた

C91(冬コミ)が近づいてきましたね。

 

今回のコミケにもTechBoosterが技術誌を発行するということで、わたしも「AndroidでJavaCPPを使用する」という記事で参加しています。

techbooster.github.io

本当はAndroidにおけるJavaC++の相互運用の最新事情をいろいろ調べてDroidKaigiでしゃべるつもりだったのですが、明らかに多くの人の興味を引くネタではなかったのでめでたく不採用となり、それなら今急いで調べなくてもいいかということで、今冬はとりあえずJavaCPPのみを調べてみることにしました。

 

C++相互運用は、わたしの中では「いつまで経っても解決しない.NETの課題」のとしてずっと関心をもっているネタのひとつで、当然ながら.NET以外の世界ではどう回っているのかも気にしています。

 

詳しくは本編を(買って)見ていただければと思うのですが*1、ここでも簡単にJavaCPPを紹介しておこうと思います。ちなみにわたしの寄稿部分は100% JavaC++の話です。.NETは出てきません。あしからず。

 

github.com

JavaCPPは、C++ライブラリのヘッダから自動生成されるC++の中間ソースコードと(それをビルドして得られる)ネイティブglueライブラリを使用するタイプの、JavaC++の自動的な相互運用を実現するプロジェクトです。

 

これ以外の「タイプ」でどのようなプロジェクトがあるかというと、プラットフォームの違いをglueライブラリで吸収するのではなく、プラットフォーム別のABIの違いを吸収するネイティブライブラリを活用して、ユーザーが純粋にJavaライブラリだけをビルドして配布することができる類のものです。一番有名なものはかつてSun Microsystemsで開発されていたJNAでしょう。また、5年前にBridJについて多分世界で2番目くらいに詳しい記事を書いたので*2、それを見てもらえればと思います。

 

d.hatena.ne.jp

JavaCPPはLLVMプロジェクトのclangを使用していて、それ自身の実装は割とlightweightに出来ています。BridJなど自前でC++ヘッダパーサーなどを書くのに比べてメンテナンスコストが低く、実際に現在でも継続している数少ないプロジェクトのひとつです(BridJはほぼ停止しています)。この「現在でも継続している」という特徴は割と無視できないもので、たとえばサンプルプロジェクトにもtensorflowのバインディングなどが存在しています。

 

JavaCPPのような、中間ライブラリ生成方式のフレームワークのデメリットは、結局プラットフォーム別にJNI呼び出し用のネイティブライブラリをバンドルしなければならず汎用性を損なう、という側面にあって、Androidの場合も例にもれず面倒なところです。そんなわけで、その辺をどうするか、みたいな話を主に書いています。

 

当日(12/29)はわたしも(たぶん午後あたりから)参加していると思うので、ぜひTechBoosterのブースに遊びで話しかけてやってください。西れ-63ab にあります。

*1:ちなみにわたしは(というか関係者全員)宣伝しても全く収入になるわけではなくて、せいぜい売上で食べに行く打ち上げの食事がうまいものになる程度です。

*2:記事があるかはさておき作者が一番詳しいはず