プランクトンサミットに参加してきました

こんにちは、すぎやんです。
今日からインターンなので頑張ります。また終わったら参加記的なのを書こうと思っています。

さて、昨日プランクトンサミットというイベントに参加してきました。
プランクトンサミットは何かと言うと、ぶっちゃけ未だによくわかってないです。笑 
まぁ簡単にいうと、いろんな分野にお熱な人たちが集まってわいわいガヤガヤするイベントだと思ってもらえばいいと思います、多分。

で、開催場所がまたすごかったんですよ。サイボウズ東京本社さん。しかも丸々1フロア貸切ですよ。なんだこの神待遇は。

f:id:yuji9511yuji:20190513075055j:plain
f:id:yuji9511yuji:20190513075133j:plain

今回初参加だったのですが、参加者は50人、100人と次第に増えているようで3回目の今回は200人ほどいたそうです。すごい人の集まり方。ヴァネロピさんおそるべし。

で、僕が何をもくもくしたかというと、大してもくもくしませんでした。笑
一応バチャコン解いたりこないだのE問題のDPの解説を聞いてたりしてたんですが、進捗を生むというよりもどちらかというとここでしか会えないいろんな人と絡みたいという気持ちの方が強かったですね。
なので適当にフラフラ場内を歩きつつ名札をチェックして、よく見るフォロワーさんとか話してみたいと前から思ってた人に声を掛ける、みたいなことをしていました。
競プロ界隈で有名な人が思ったよりも来ていて、いろんな人に挨拶できたのでとても充実していました。

競プロの人たちと絡むので精一杯で余裕がなかったのですが、他の畑の人々とも絡んでみたかったですね。どうしてもTLでも見たことのない初めましての人に声をかけるっていうのは結構ハードルの高い行為ではあるんですが、思わぬ趣味の共有とかそういうのができそうな気がしたのでもっと交流してみたかったです。

それにしても本当に色々な人がいました。メイドさんになっている人。浴衣姿の人。ポーカーしてる人。なんかカードゲームしてた人々。スクイズみていた人々。折り紙配っていた人。お茶を点てていた人。某アイコンを描いていた人。改めてすごい濃い空間だなと思いました。

まとまりのない文章ですがこんなところにしておきます。こういうイベントはとてもいい刺激をもらうことができて活力が湧いてくるので是非とも定期的に開催してほしいですね。
次回はおそらく競プロキャンプの参加記みたいなものを書くかなーと思います。それでは。

VSCodeのワークディレクトリに出現した巨大ファイル .vscode/ipch を取り除く

タイトルの通りです。VSCodeを主に競技プログラミングで使っているのですが、C++のコードを生成する度にワークディレクトリの.vscode/ipch以下に謎のサイズクソデカファイルが生成するようになりました。
ちょっと放っておいただけで数百MB程度まで成長していたので結構なサイズです。
そのまま置いておく分には多少ストレージを圧迫する程度なのですが、レポジトリをgit管理しているひとにとっては少し邪魔だと思います。
なぜならgitはgit LFSなどを用いないとアップロードできるファイルサイズの上限が100MBであり、これらのクソデカファイルをアップロードしようとすると怒られてしまうからです。

そこで今回はいくつか対処法をまとめておきたいと思います。
英語が読める人はこのissueでいろいろ議論されているのでお読みください。
github.com

1. gitignoreする

最も単純な解決策はこれだと思います。これでgitが壊れる問題は解決しますが、もちろんローカルにはファイルは残ったままになります。
ワークディレクトリに.gitignoreを作成して

.vscode/ipch

などと書いておけば大丈夫です。

2. キャッシュの保存先を移動させる

キャッシュは残しておきたいというときはVSCodeの設定でファイルの保存先を変更します。
Settingを開き、"C_cpp: Intelli Sense Cache Path"の部分を書き換えます。

3. キャッシュを保存しないようにする

これが一番解決策としてはスッキリするかなと思います。
先ほどと同様にSettingを開き、"C_cpp: Intelli Sense Cache Size"の数値を0にします。
デフォルトだと5120MBになっていました。そりゃ5GB分のファイルがレポジトリ内に生成されたらアップロードできるわけないですね。

f:id:yuji9511yuji:20190505182532p:plain
Setting内のパラメータ

僕は3番目の方法を使いました。このキャッシュがないことでパフォーマンスにどれくらいの差が出るかは不明ですが、とりあえず巨大ファイルはなくなってくれたのでよしとしましょう。

今回はVSCodeのextensionの一つであるC++ Intellisenseでの問題でしたが、他のextensionでも似たような問題が出るかもしれません。そのようなときは該当extensionのSetting内にあるパラメータを疑ってみる癖をつけるといいと思います。

応用情報技術者試験を受けてみました

昨日、応用情報技術者試験を受けてきました。

結果の発表は2ヶ月先なので合否は不明ですがとりあえずどんな感じだったか等を残しておこうと思います。

受けようと思ったきっかけ

今年の1月くらいに少し手が空いている状態になっていて、どうせなら資格の勉強でもしてみるかーと思い立ちました。
その少し前にTOEICも受けていた(ほぼ勉強しなかったので微妙な結果でしたが...)ので、その流れで勉強を始めようと思っていました。
どうせなら自分の興味に沿った内容がいいなと思っていたところ、どうやら応用情報というIT系の人たちがよく受けがちな試験があるらしいのでこれにしようと思って応募しました。

勉強をはじめた

応募を終えすぐに合格教本というやつを一冊手に入れたのですが、勉強をはじめたのは受験日まで1ヶ月に迫った3月の中頃だと思います。
とりあえず最初は参考書を一読しようと思ったのですが、一読するような量ではなかったのでだいたいどんなジャンルがあるか把握する&辞書がわりとして使うことにしました。

f:id:yuji9511yuji:20190422132237j:plain:w200
王道らしいのでこの本を使いました
勉強を本格的に始める前にこの試験はどうやって勉強すればラクできるかというのを知ることは大事です。「応用情報 攻略」みたいなワードでググってみると、どうやら午前試験の選択問題は過去問を過学習すれば余裕で、午後はまぁどうにかなることがわかりました。
なので、過去問の過学習が得意な僕は過去問道場にこもってひたすら過去問を解くことにしました。

f:id:yuji9511yuji:20190422102707p:plain

これは応用情報の過去問道場でみられるランク?みたいなやつですが、このふきだしが書いてある四段ってとこまでやりました。
この分布をみた感じだと割と頑張った方なんですかね?
とにかく「未出題の問題を解く」みたいなタイプを選択して解いていたのですが、それでもかなり同じ問題が出ていたのでやはり過去問は正義だなと思いました。
結局2240問中1700問程度は答えたっぽいです。別に何時間もぶっ続けてやってたわけではなく暇を見つけてはやっていた感じなのでそこまで面倒ではなかったです。
既出の問題に関しては計算などせずとも条件反射的に答えられるようになっていると本番でも時間の節約になっていいと思います笑

こんな感じで午前試験はもう大丈夫だろうってなった時(3日前)くらいにふと午後試験の存在を思い出しました(!)
さすがに何か対策をしないとと思って過去問をチラチラみたのですが、そこまで規則性がないんですよね。
過去問をやったところで出題される内容は毎回考えなきゃいけない感じのものでした。
なのでやったことは「どのテーマの大問でどんな雰囲気の問題が出てるか」を把握しただけです。
みた感じ「アルゴリズム」「データベース」「組み込みシステム」あたりがやりやすそうだったのでその辺を重点的に解こうかなと考えていました。

当日のはなし

当日です。午前は過去問だいぶ網羅したし大丈夫だろうって感じの一方、午後は完全に問題との相性次第なので少し緊張してました。
案の定午前は見たことある問題たちがたくさんあったので気楽にできました。大半は聞いたことのないワードの意味を気合いでイマジネーションするのに時間を使ってました。

午後はたっぷり時間を使って解けるとこを確実に得点しよう、みたいな感じでゆっくり解いてました。もともとデータベースが得点しやすいだろうと思って解いていたのですが、予想以上にごちゃついていて自身がなかったので急遽後半の国語っぽいやつに切り替えました(サービスなんちゃらってやつ)。雰囲気で書いたので合っているかはよくわかりません。

おわりに

こんな感じでどこか片手間でやってしまいましたが、これで応用情報チャレンジは終了しました。
結果は2ヶ月後くらいに発表されるようです。受かっているといいですね。
また何か別の資格の勉強でも始めようかなーと思ってます。有名どころからいくと簿記とかやってみるのも面白いかもしれないですね。

競プロを始めて1年が経って思うところをまとめた

こんにちは、すぎやんです。
去年の4/14にAtCoderのコンテストに初めて参加してから1年が経ちました。ちょうどいい節目のような気がしたのでこれまでの競プロ生活を少し振り返ってみようと思います。

なぜ競プロをはじめたか

去年の4月に競プロのコンテストに参加したと先ほど言いましたが、厳密にいうと競プロに出会ったのはこのタイミングではありません。多分同様の経験をした人も一定数いるのではないかと思うのですが、初めに競プロを布教されたタイミングではそこまでやりこむことはしませんでした。
f:id:yuji9511yuji:20190415184839p:plain
これは僕の精進グラフです。これを見れば一目瞭然なんですが、AtCoderの問題を初めて解いたタイミングとコンテストに参加してレートがつき始めたタイミングには1年くらいの差があります。別に実力不足を気にして隠れて精進していたわけではなく、ここまでは競プロに対する熱が特にありませんでした。
最初に競プロに出会ったのは学部2年の時に僕が属していたeeic (工学部電子情報工学科)でふと開催された「競プロをやってみよう」という企画でした。
企画してくれたのは学科の同期ですでに競プロをある程度やっていた人たちで、ABCの適当な回からA~Dの4問を持ってきて情報教育棟あたりでみんなでやってみましょうみたいなものです。
当時学科ではC言語を習い始めたばかりで僕自身も学科に入って初めてプログラミングというものに出会ったので、まだ右も左もわからない状態でした。それでもC問題くらいまでは考えれば解けるんだなぁみたいに思った記憶があります(当時は考察よりも実装が全くできなかった気がします)。
そんな感じで競プロと出会ったわけですが、この時はそこまで魅力を感じるようなことはありませんでした。なぜでしょうかね。
今となってはこんなに楽しいのになぜすぐ始めなかったんだという感じですが、おそらく学科の課題などで余裕がなかったのではないでしょうか。
あと、プログラムを書くことに慣れていないので自明な問題の解答を書き起こせないもどかしさみたいのもあったのかもしれません。

こんな感じで1年間は温めておいた競プロですが、ちょうど去年の4月ごろに突然ブームが訪れます。
このブームの着火剤はなんだったのでしょうか。最近しばらく思い出そうとしているのですが思い出せません。
きっと誰かが競プロの話をしていたとか何かあったんだと思うのですが特に記憶に残っていないんですよね。でも今ほど周りの人がみんなやっていて触発されたという状況ではないと思うので謎は深まるばかりです。
まぁもともと受験っぽい数学とかを考察して解き進めるみたいな作業は好きだったのでもともと相性はいいんだと思ってます。
こうしてコンテストに参加し始めました。

開始当初の目標とか

誰しも初めはこの辺を目指したいみたいな目標を持つと思います。僕もそうしたものは最初からあって、簡潔にいうと「やっていれば青色にはなるだろう」という所感でした(まだなってませんがw)。水色までは慣れさえすればすぐに到達し、そこからアルゴリズムや競プロ特有のテクニックを少し習得すれば青にはなるんじゃないかなーと思っていました。黄色に関してはセンスによっては到達できないかもくらいに考えていました。頭の構造的に橙以上は到達できないだろうという感じです。
この感覚は現在もそんなに変わってないです。黄色が開始当初よりは雲の上ではなくなったかなーという感じです。今年の中頃には青になっていると信じたいのでそこからどの辺まで上がるかというところです。

緑になった時

6回くらい参加したら緑になったのでここまでは順調という感じでした。1回だけBで手こずりCが解けないという激ヤバ回がありましたがそれ以外は特に問題なく徐々に競プロに慣れていきました。

水色になった時

水色になった時は前にブログにまとめました。
ysugiyama.hatenablog.com

10回程度で水色手前になったのですが、そこから何回か連続で失敗したので思っていたより水色になるのに時間がかかりました。
この頃にABC-C,Dの過去問をやるべきだと思い、上から埋め始めました。水色になるくらいには難しいものを除きだいたいこなしていた気がします。
また、水色になった瞬間に連続で2回冷えて緑に包まれた時は自分のポテンシャルを少し疑いました。そこから連続でうまくいったので挽回することはできました。

水色になってから

水色になってからはコンテストごとではなく企業コンも含め点数順に埋めていきました。
400点の解ける割合が増えてきたので500点や600点の簡単な問題に少しずつ慣れていきました。次第に考察重視の問題が増えてきたので、早く実装することはもちろん、じっくり考える習慣をつけるようにしました。
よく「◯◯になるために習得したテクニック」みたいなのを列挙している記事を見ますが、あのような形式で実力を把握するのはあんまり意味がないかなーと思ってます。「このようなタイプの問題でこれらの解法の選択肢が思い浮かぶ」みたいな部分に実力の指標がありそうです。

オンサイトのコンテストとかイベントとか

オンサイトで対面して議論したり同時に競プロをすることはモチベアップにめちゃくちゃ効果的です。今まで参加したものおよびこれから参加しようと思っているものを簡単にまとめました。

  • CODE THANKS FESTIVAL

去年の11月に開催されたオンサイトコンテストです。当時まだ水色と緑のはざまでしたが、500点の早解きに運よく成功し参加できました。
確かコンテスト直前のratedで緑落ちして当日どっちの色で自己紹介しようか唸っていた覚えがありますw

THANKSより奇跡的な通過だったのですが、就職をする年度ではない一般の枠での滑り込みでした。THANKSの時よりは界隈の知り合いが増えていたので、自分が普段twitterや順位表で見ている人たちが目の前にたくさんいてとても楽しかったです。コンテスト結果も自分のレートにしては悪くない成績だったので大満足でした。

  • ゆるふわコン

2月ごろに開催されたフォルシア株式会社さん主催のコンテストです。誰でも参加できるゆるっとふわっとしたコンテストでした。
知り合いもちょくちょく来てたので僕もゆるっとしたテンションで参加することができました。
フォルシアさん優良企業そうだなって思いました。笑

  • 競プロキャンプ

今年の5月にあるので参加しようと思ってます。とにかく同じ競プロerの方々と少しでも交流を持ちたいと思っているので楽しみにしてます!

  • プラサミ

こちらもこれから参加しようと思っています。やることは具体的に決まっておらず各自やりたいことを持ちいるみたいな話を聞いたので、何をやるか考えておこうと思います!

あと、競プロとは直接関係していないのですが、AtCoder Jobsで応募したフィックスターズ さんのインターンに申し込んでありがたいことに採用していただいたので5月半ばに開始する予定です。
今まで経験してこなかったソフトウェア高速化などをやらせてもらえる予定なので楽しみにしています。

これからどうする

順調にいけば夏までには青になれると思うのですが、現在のパフォのhighestが黄色に届いたことがないため、このままいくと確実に青で停滞します。
つまり今と同じような精進をしていてはダメということになります。
今までの精進は500点程度までの比較的考察時間が少なく実装にかける時間の割合が多い問題の数をこなしてきました。
しかし、今後取り組むことになる600-700点の問題になると考察が重くなるので問題を解くペースも落ちることが想定され、思うように精進が進まなくなる気がします。
どのタイミングでeditorialを見るか、という永遠の課題がありますが、初期はある程度高得点になれるためにも早めに見るべきなのかなーと今は考えています。
この辺の問題が時間をかけてでも解けるようになれば青の上位に推移することができると思うので努力していきたいと思います。
ただ、授業とか色々あって春休みほど精進ができないのがネックなので時間の創出は考えないといけないですね。

おわりに

最後まで読んでくださってありがとうございました。最近文字に起こすことをしていなかったのでその練習も含めて書いてみました。
TLにいる同朋の方々にはいつもいい刺激を受けているのでこれからも共に精進していきましょう!

Macbook Proのキーボードのチャタリングが直らなくてキレたのでソフトウェア的に直した話

タイトルの通りです。
つい3ヶ月ほど前に購入したMacbook Pro 2018ですが、キーボードの特定のキーが一定確率で2回押されてしまうという不具合を踏みました。
調べてみると何件か同様の症状を訴えている記事を見かけたので、よくあるハードウェアの不具合なんだなと思い無償の修理に出しました。
修理までの対応は電話を通じてとても丁寧にやっていただき、商品も配送修理に出してからわずか2日で帰ってきたのでその対応の速さにはとても感謝しています。
修理から戻ってきた時のMacはキーボードの交換をはじめ他の場所もピカピカになっていて、問題のチャタリングも無くなっていました。
やっとあの症状から解放されたとこの時は安心していました。

しかし...
修理から戻ってきて1ヶ月ほどたち、作業をしているとまた例の症状が現れたではありませんか。
もちろんまた修理に出せば無償でやってくれてすぐ返ってくるでしょう。でもなんかまた手続きをするのが面倒臭かったので、ソフトウェア的な解決手段が何かないかなと考えてみました。

調べてみると、まずKarabinerというMacにインストールできるキーボード操作ツールが引っかかってきました。これの設定ファイルにある「連続して反応する時間の最小値」みたいのを設定すればチャタリングは回避できるようでした。早速インストールしてその設定を探してみたのですがそんなものはどこにもない。
他の更新時期の新しいサイトをみたらわかったのですが、その機能は少し前のアップデートで削除されたようでした。やれやれ。

そのあとに見つけたサイトがチャタリングを抑制するプログラムを裏で走らせておくというものです。参考にしたのは以下のサイトです。

macOSのチャタリングをソフトウェアで対応する:株式会社サブスレッド

基本的にこのサイトに書かれている通り、レポジトリをgit cloneしてmakeしたファイルを実行すれば指定した間隔以下の入力を無視することができます。
半信半疑でやってみましたが、思ったよりうまくいったので驚きました。
僕はしきい値の変更を行いました。デフォルトの値(100ms)だとたまにチャタリングがすり抜けてしまうことがあったため、値を120msに変更しました。
やり方ですが、レポジトリ内のdebounce.mを開き、15行目にあった以下の部分を書き換え、再びmakeを行います。

...
#import <Foundation/Foundation.h>
#import <AppKit/NSEvent.h>

#define DEBOUNCE_DELAY 100 // ここの数値を変える
#define SYNTHETIC_KB_ID 666
..

こうしてチャタリングが解消することを確認し、これをdaemonを用いて起動時に毎回自動で立ち上がるように設定したのですが、先ほどのページ通りに行なってもうまく動きませんでした。
おそらく実行権限などの問題と思われますが、とりあえず実行ファイルのパスを/usr/local/binではなく自分でcloneしたディレクトリに設定することで無事動くようになりました。例えば、.plistファイルの中身を下のような感じに書き換えます。

    <array>
        <string>/Users/username/debounce-mac/debounce</string>
    </array>

これでとりあえずチャタリングは回避できました。あまりに高速に同じキーを押さない限り、正しいものが入力されないということはないと思います。
このまましばらく使ってみて、やっぱり使いづらさが出てくるようならもう一度無償修理にでも出そうと思います。

この記事が同一の症状が出てる人の参考になればなーと思ってます。 バタフライキーボード、色々問題点が多いらしいのでこういう不具合が減ってくれるといいのですが...

AtCoder Grand Contest 029

久しぶりのAGCでDまで時間をかけて考察したので残しておこうと思う。
本番は比較的速い時間にBを通すことができたので青パフォを得ることができた。
欲を言えばDは通せたなーと思ったが、まぁいいでしょう。

A - Irreversible operation

WとBを何回入れ替えることができるかという問題。
できるだけWを左に寄せればいいんだなーというのはすぐ気づき、ゆったりと実装してAC。
みんなの解くスピードが速すぎて順位表みてびびった。A問題のWA恐怖症なので結構念入りに確認してたのもあるかもしれない。

B - Powers of two

和が2のべき乗となるようにペアを組んだ時のペアの最大数を求める問題。
とりあえずN = 200000だからdpとかは無理そうだからソートしようってなってソートする。下から見ていったが貪欲に決めていったら決まらないことに気づく。例えば {1, 3, 15, 17}と{1, 3, 5, 15}の組み合わせだと{1,3}で組んでいい時とダメな時がある。

しばらく考えて上から貪欲に見ていくとうまくいくことに気づく。上の2つの例でもうまくいく。

それでは大きい数から見ていって、ペア候補となる数はどのようなものがあるかを考えてみる。注目する数をKとすると、ペアとなるべき数Xは
 K+X=2^t, X\leq K
この条件を考えると、 2^tの表す値はKより大きな最小の2のべき乗のみを考えればよいことがわかる。
たとえば、K=14であったら、14+X=2^4=16のみを考えればよく、14+X=2^5=32を考える必要はない。なぜなら後者を考えるとXは必ずKより大きな数になってしまうからである。
したがって、大きい順に見ていき、まだ使われていないペア候補が見つかればそれを使ってペア数をインクリメントすればよい。まだ使っていない数を見つけるために二部探索などを使っている人もいたが、mapを用いて使える残りの回数を持っておけばいいと思う。
atcoder.jp

C - Lexicographic constraints

いくつの文字数を使えば辞書順に並ぶような文字列を構成できるかという問題。コンテスト終了後に解いたが、かなり実装に手こずってしまった。

当然使える文字数が多いほど構築できる可能性は高くなるので、最小何文字を使えば可能かという二部探索の問題と捉えることができる。ここは経験があれば割と気づきやすい部分だと思うが、難しいのはこの判定を実装する部分である。  
文字列長を左から順にみていく。もし前の文字列より後の文字列の方が大きければ末尾に'a'をその差分だけ足すのが最小とわかる。この場合は問題ない。
逆に前の文字列長が後の文字列長以上である場合には整数の繰り上がりのように最小の位のアルファベットを移動させていくことになる。この最小の位の位置は小さい方の値によって決定する。したがって文字列が'aaaa'の状態で文字列長が4から2へと遷移すれば上から2文字目のaがインクリメントされ結果として生じる文字列は'ab'となる。
この実装が思ったより難しく、文字列を圧縮したりstack使ったりする方法が色々紹介されていたが僕はmapのみを使うことにした。
具体的には、文字a,b,c...を0,1,2...とし、i桁目の文字をmp[i]というキーバリューの形で保持する。
K種類の文字列を使うとき、値を更新する桁を下から見ていき、値がK-1を超えたら次の桁へ繰り上がるということを繰り返す。
そうして繰り上がりがK文字以内でできなくなればそのKでは不可能と判定できる。
ここの判定はAtCoder公式の解説動画がわかりやすいと思う。

コードはこちら。
atcoder.jp
このコードでひたすらバグに悩んだのは45行目で特定の桁から下の数値をリセットする部分。これをしていなかったので桁の繰り上がりが正しく行われていなかったようだ。数ケースだけ落ちると原因がホントわかりづらい...

D - Grid game

800点問題。なのだがさすがに800点にしては簡単だと思う。800点問題初AC。
先攻はできるだけ下に行き続け、後攻はたどり着くのが可能な範囲で最も近い行き止まりをめがけて進むのが最適だとわかるので、まずはたどり着くことのできるマスの範囲を絞る。
高橋くんが先攻で下に移動した後、後攻の青木くんが右に進むことができるかできないかで経路が変わります。青木くんは必ずしも右に行かなくてもいいのだが、まずは行ける限り右に行くとして経路を決定する。
すると以下のようになる。
f:id:yuji9511yuji:20181218221531p:plain
青木くんが最も右に移動した場合に図のような経路になるので、青線で囲った部分および経路上に関しては青木くんが自分の意志で移動できることになる(高橋くんは進む以外に選択肢がないため)。
したがって、この範囲の中から最も早くぶつかる(=最もX座標が小さい)点に行くのが青木くんにとって最善になる。
XとYが直感と逆なのでそこだけ気をつけよう。
atcoder.jp

Code Thanks Festival 2018に参加してきました

最近あまり競プロできていなかったので久しぶりの更新です.

さて,人生初のオンサイトコンテストであるCode Thanks Festivalに参加してきました!
f:id:yuji9511yuji:20181126231633j:plain
おそらくレベル的にはThanksもまだ厳しいくらいだったのですが,たまたま予選Bで相性のいい問題が早解きできたので運よく参加させていただくことができました.
参加者のレート一覧みたら下に10人もいなかったですね,最頻値が青なので順位表みただけでも少しひよってました.

会場はとても広く綺麗な場所で,お菓子とか飲み物も充実していたのでとても好印象でした.

あと,chokudaiさんが会場内をぶらぶらしていたので声をかけたら噂のAtCoderステッカーをくれました.ステッカーが徐々に増えてくると強者になった気がしますね(気のせい).会場で生ファボ爆を披露してるのも面白かったです.f:id:yuji9511yuji:20181126232503j:plain

昼にでた弁当にリクルートさんの財力を感じました.叙々苑と何かと何かの三種類があったのですがぼうっとしていたら叙々苑が一瞬で無くなっていました.みなさんこういう時は素早い.代わりに食べた牛すき弁当もめちゃくちゃ美味しかったです.多分どれも2000円近くしそう...


12時からコンテストが開始しました.
制限時間が3時間というのをみて,おそらく今の実力だと300くらいまで早解きしてあとはずっと唸ってたら終わりそうだなーと思ってたらその通りになりました.
BのWA量産の焦りは若干ありましたが,A~Dは特に問題なかったです.順位表見てほぼ全員がDまですぐ解いているあたりやっぱり選ばれた人たちしかいないんだなーと思いました.

ほとんどの時間はEを考えていましたね.制約的にN^3程度のDPだろうというところまではたどり着くものの,そこからindexをどう設定してどう遷移していくみたいな部分の考察がまだできませんでした.解説見ても簡単じゃんとはならなかったのでまだ精進が足りないですね.

パーカーは上位50人で,Eまでをある程度早く解いた人がボーダーだったのでちょっと厳しかったですね.まぁ青コーダー中位に勝てるわけもなく.

コンテストが終わったあとは懇親会でした.みんなのビンゴカード見てるとそれぞれ独自のこだわり(特に好きな言語,好きなアルゴリズムあたり)を持っていて面白かったです.

服装に個性を見出してる人も結構いましたね.kyopuro_friendsさんはどこからどう見てもサーバルちゃんでしたし,C++完全に理解している人とかいろんな人がいました.何か自分を特徴付けるもの身につけていって特定してもらうみたいなことするのも賢いですね.

もう少し界隈で知り合いが多いとオフ会みたいな感じで盛り上がったのかもしれないですけど,まだ始めたばっかりでオンサイトの経験もなかったのでこれからその辺のコネクションは作っていきたいですね.

懇親会でもchokudaiさんのAtCoder株式会社に関するいろんな裏話を聞けたので面白かったです.クソマイナー言語に対応するのにリソース割く必要性とか攻撃に対する対応のめんどくささとか,あと今後のARCの開催候補日(まだ非公表)とか教えてくれました.

いろんな人と話して美味しいものも食べ,とても満足のいく初オンサイトでした.あとは自分の競プロの腕を磨くだけですね.来年は少なくとも青色になった状態で迎えたいと思います.
最後に今回の戦利品です.交通費も支給されているしこれだけいただけるなんてオンサイト素晴らしいですね!
f:id:yuji9511yuji:20181126234101j:plain

多分1月にあるDDCCにも出場できそうなので次のオンサイトも楽しみにしています!