競プロにおける俺的C++コーディングルール・気をつけることリスト
これは何
僕がC++を用いて競プロをする上で守っているルールや大事だと思っていることについて軽くまとめてみた記事です。
C++で競プロをする
C++で競プロをして1年以上経ちました。
実は最初の何回かはPythonで提出していたのですが、C++に乗り換えるなら早めの方がいいかなと思ってかなり早いタイミングでC++に移行しました。
もともと授業でCを書いていたので導入は比較的すんなりとすることができました。
この記事では普段競プロをC++で実装していく上で僕が大事だなと思っていることをまとめていこうと思います。僕のレートはAtCoder青の真ん中程度なのであまり高度な話はできませんが、バグを埋め込みにくいスムーズな実装をするために心がけていることを語っていこうと思います。決してこれが正しいというものではなく反対意見はいくらでも出てくる話だと思うのであくまで一意見として読んでいただけると嬉しいです。
俺的コーディングルール一覧
bits/stdc++.hを使う
C++の標準ライブラリを一挙にincludeしているやつですね。全て明示的にincludeしないと嫌だという話もよく聞きますが、僕はそれよりもコードのシンプルさを求めているのでこれは使います。大手のコンテストサイトではほぼ全て使えると思うので安心です。ローカルでこれをつけて実行ができない場合は以下のリンクからstdc++.hを取ってきて自分のPCの /usr/local/include/bits/ 以下に置くことで動くと思います(Mac OSの場合)。
Competitive-programming/stdc++.h at master · ysugiyama12/Competitive-programming · GitHub
using namespace std;
有名なn575ですね。開発するならよろしくないですが競プロするならこれつけといていいでしょう。ただし登録語は把握しておきましょう。
typedef long long ll
オーバーフローでいつまでも消耗するのは辞めましょう。どこが間違っていますかって初心者が出してくるコードのある程度の割合はオーバーフローしてます。intで足りるところをlong longにしたところでメモリが溢れることはほとんどないので競プロでは全てlong longで行きましょう。
さすがに #define int long longはちょっと極端なのでは？と僕は思ってます笑
typedef pair lp
あんまり単純な省略はしないんですが、かなり使う上に長いのでこれは導入しています。
#define rep(i,m,n) for(ll i = (m); i < (n); i++)
よく見るfor文の省略ですね。これをやるのは書くのがめんどくさいというのもありますが、変数ミスをしないというのが最大の目的です。iとかjとか3回も書いてたら混同する確率がだいぶ上がってしまうのでミスを減らすという意味でもマクロは大切です。
僕は逆順のrrepも登録しています。イコールがつく・つかないとかで全部マクロ作るのはやりすぎでしょう。
あと、#defineするときは変数をカッコでくくっておくことをお勧めします。#defineはそのまま該当部分を置換するので意図していない区切られ方になることがあります。
#define print(x) cout << (x) << endl;
cout毎回書くのはめんどくさいのでこれは大事です。llと並んでもっともよく使うマクロですね。
#define printa(x,n) for(ll i = 0; i < n; i++){ cout << (x[i]) << " \n"[i==n-1];};
いまだにprintデバッグで凌いできている人間なので配列をパッと見たい時に使っています。そろそろデバッガを導入した方が良いなーと思いつつ愛用させてもらってます。
cin.tie(0); ios::sync_with_stdio(false);
詳しくは理解していません。どうやら入出力が速くなるらしいです。touristが書いていたので僕もおまじないとして書いています。
if(not ok){ print("No");}
否定を表す時に"!"をよく使いますが、見落としやすいので僕は"not"を使うようにしています。シンタックスハイライトもされるので可読性がグッとあがります。
否定のフラグを作らない
「~してない = true」みたいにフラグとして変数を作ると頭がこんがらがって死ぬので必ず肯定の意味を持ったフラグを立てるようにしています。
gotoを使わない
完璧に使いこなせれば良いのですが僕は怖いので使ったことがありません。
rep(i,0,N) cout << ans[i] << " \n"[i==N-1];
最後の部分です。普段はスペースでi=N-1の時だけ改行してくれるので末尾に空白を入れたくない配列の出力とかに使えます。なんかゴルフみがありますね。
変数をmainで宣言するかグローバルに書くか
これは決めていません。あまり外には書きたくないので基本mainに書いて他の関数でも使いたい時とか関数内だとメモリが溢れる時とかにその都度外出ししてます。
S.size() - 1
size_t型に対して引き算をすることに敏感になってください。unsigned型なのでやばい挙動をします。なんかループを抜けてくれないとかいう時の原因になることがあります。long longなどにキャストをする癖をつけましょう。
ライブラリは使うやつだけ貼る
常にすごい量貼ってる人たまにいますよね。やりづらくないのでしょうか。
スペースとかしっかり入れる
この辺は好みが分かれると思います。速く書く目的で詰めて書く人もいますが、僕はとにかく可読性重視なのでスペースとかかなりちゃんと入れてます。人にバグ見つけてもらう時とかもあるので綺麗に越したことはないでしょう。
コードの先頭に署名
touristがやっていたので最近入れてみました。人によっては可愛いAA書いてたりしますよね。
わかりやすい変数名とは
変数名はどれくらいわかりやすい方がいいんでしょうかね。僕は割と2文字程度で作ってしまいますが、数字変えるだけとかだと書き間違いの元になるんですよね。かといって長い変数名もなんかだるいし...
変数名は大文字か小文字か
これも好みの問題ですが、僕は与えられた変数は大文字にしておこうかななどとざっくり決めています。これらの変数は基本的に書き換えないようにします。
bit演算で優先順序を間違える
XORをカッコでくくらなかったからどうのってやつですね。僕はVSCodeのlinterが緑波線を出してくれるのでやったことはないです。
(1 << 60)
これもよくあるオーバーフローです。ビットシフトの時は1LLにしておきましょう。これもVSCodeだと緑波線出してくれます。
二次元配列の定義
vectorでやる人と生配列でやる人がいますね。僕は生配列でやっています。これは書きやすい方でいいかと。
dp.at(i)
範囲外参照が防げるというやつですね。これから入った人は慣れていてやりやすいかもしれないですが僕は最初からdp[i]とやってしまっていたのでつかいませんでした。
setとかmultisetのerase
eraseしたイテレータをそのまま使うと壊れるらしいので別の変数にコピーして再代入してやりましょう。
過去の提出コード
過去作ったコードはとりあえず作業ディレクトリに取っておくとキーワード検索とかで昔にやった類題とかが爆速で見つかるのでオススメです。
さいごに
また思いつき次第追加していきます。オレオレのルールでも解くスピードが上がってミスが減ればそれが正しいので自分なりのコーディングルールを少しずつ固めていくことをオススメします！
iPhoneのSafariブラウザにAtCoderのお気に入り一覧を移動する
きっかけ
AtCoderのお気に入り一覧は順位表を確認するときによく見ることが多いと思うんですが、例えば自分が用事があって参加できていないときにも周りの人たちの結果って気になりますよね。そういったときにスマホの順位表を覗くのですが、お気に入りの欄がまっさらで後悔したなんてこと、ありませんか？（僕はあります
なので、今ブラウザに登録されているお気に入りデータをスマホのブラウザにも反映させることができたら幸せになるんじゃないかなーと思ったのがきっかけです。
やること
お気に入り一覧はローカルストレージというブラウザ内部のDBに保存されています。なので別ブラウザから開くとお気に入りの内容は共有されていません。このローカルストレージからお気に入り一覧を取り出してスマホのブラウザのローカルストレージに貼り付けるのが今回やることです。それだけです。
やり方
1. 元のお気に入りデータをPCのブラウザから取っておきます。
SafariのWebインスペクタを開き、「ストレージ」タブ > ローカルストレージ > atcoder.jpをクリックします。キーに"fav"と書かれている行のデータを見ると、今まで登録したお気に入りした人たちの名前がjson形式で格納されていることがわかります。この値の部分を全てコピーしてテキストとしてどこかに貼り付けておきます。
Safariの開発タブがない場合はSafariのメニュー > 環境設定 > 詳細からメニューへの追加が可能です。
Chromeの場合もデベロッパツールを使えば似たような方法で取得ができます。
2. iPhoneの設定 > Safari > 詳細をタップし、Webインスペクタと書かれている項目をオンにします。
3. お気に入り情報を使っているAtCoderの該当ページ(順位表のページとか)を開いた状態で、ケーブルを用いてPCとiPhoneを接続します。
4. PCのSafariの開発タブから自分のiPhone端末の名前を選択し、該当ページのurlを選択します。urlをクリックすると先ほどのブラウザのWebインスペクタと似たような画面が開きます。これがiPhoneのSafariのインスペクタです。
(自分がやってるときにこのインスペクタになにも表示されない状態に何回かなりました。ブラウザの再起動とか色々やったら出るようになりました)
5. 先ほど取っておいたPCブラウザのお気に入りデータのテキストをローカルストレージのfavの行にペーストします。
おわりに
いかがでしたか？ これで外出時でも誰か冷えてるヤツいないかなーって確認することができます！
AtCoder青色になりました
6/22に開催されたABC131で、ついにAtCoderで一つの目標としていた青色(R1600)を達成することができました！
AtCoder青というのは僕が競プロをはじめたときにとりあえずの目標として設定した場所だったのでとても満足しています。
青コーダーになりました！！！！！ pic.twitter.com/QegtkAOknl
— すぎやん (@yuji9511_compro) 2019年6月22日
水色になった時期との違いとかに注目しつつ今まで何をやってきたかとかをまとめてみようと思います。
水色まで
水色までの話は半年ほど前に自分が水色になった時に記事を書いたのでもしよければ呼んでください。
ysugiyama.hatenablog.com
競プロ始めて1年のとき
どのくらいで青に入るのか全く検討がつかなかったため、いい節目だろうと思って記事を書きました。今回書くべきものも割とここですでに触れてしまっているかもしれません。
ysugiyama.hatenablog.com
青になるために何をしたか
青になるためにどんなことをしてきたかなーと考えたのですが、思ったより高得点帯の問題に挑むことはしませんでした。
AtCoderですでに埋めているのが500点程度までだったので、やろうと思えば600-700点の問題をたくさん解くことはできました。ただ、それよりは自分のできていないところとして400-500点の問題を解くのが遅いことが課題だと思ったのでそこを改善することにしました。
じゃあどうやって改善したかという話なんですが、これはコンテストに出続けることが解決してくれるだろうという安直な考えでやっていました。
実際、水色の後半では他のことが忙しくてコンテスト以外の精進をほとんどできていないような状況だったのですが、早解きが安定して0WAでACできるような確率が上がってきたためそれが青中盤のパフォーマンスを出すことに繋がったのではないかなと思ってます。
人によってはABC-Fの600点をじっくり解くことでパフォを得ることができる人もいると思いますが、僕はまだ考察力が不足している部分があるので500を早く解くことを命にコンテストに挑んでいました。
実装力と数学力
よく競プロerが「実装力と数学力どっちが強いか」みたいな話をしていますよね。僕は最近「実装力」の方があるのではないかと感じています。数学的な考察が得意ではないからという消極的な選択の部分もあるのですが、実装は比較的得意で苦にならないタイプだと思っています。
たぶんこの理由としては長らくアルバイトとかで競プロ以外の開発経験があるという部分だと思っていて、どう書いたら自分が混乱しにくいかとかの感覚が意識せずともあるのではないかなーと思っています。自分が書いたコードはマクロもそこまで多く使っておらず比較的読みやすいんじゃないかなと勝手に思っているのですが、もしジャッジしてくれる人がいたら僕のコードを読んでフィードバックいただけると嬉しいです。
実装の基本方針はtouristに従うといいかなと思っています。最低限書くのがラクになるマクロのみ使っているというイメージなのでC++erでAGCで人のコードを参考にするときはtouristがおすすめです。
一応僕のC++コードのベースを貼っておきます。これくらいが実装を速くする最低限のマクロかなーと今の所思っています。VSCodeのeasy-snippetという拡張機能でコマンド一つで貼り付けるようにしています。この拡張機能を使うことで一行ずつクォーテーションで囲って登録するみたいな虚無がなくなるのでおすすめです。
#include <bits/stdc++.h> using namespace std; typedef long long ll; typedef pair<ll, ll> lpair; const ll MOD = 1e9 + 7; const ll INF = 1e18; #define rep(i,m,n) for(ll i = (m); i < (n); i++) #define rrep(i,m,n) for(ll i = (m); i >= (n); i--) #define print(x) cout << (x) << endl; #define printa(x,n) for(ll i = 0; i < n; i++){ cout << (x[i]) << " ";} cout<<endl; int main(){ cin.tie(0); ios::sync_with_stdio(false); }
数学力は...どうやってつければいいんですかね。数学が得意な人は800点程度の考察重くて実装一瞬問題をさらっと通したりしていてとても羨ましいのですが、その辺はこれから精進をしていくしかなさそうですね。
どの程度アピールしていいのか
現在M1なのでサマーインターンの選考など受けている段階なのですが、せっかく青になったのでアピールポイントとして積極的に出していきたいですよね。
ただ、あまり競プロばかり前に押し出すのも微妙だし、人によっては競プロのレート感覚を適切に捉えてくれない人もいそうなので難しそうだなーと思いました。
競プロやってれば実装のスピードとかバグを埋め込みにくい実装などが上手になっていく気がするので、その辺に競プロの知見が生きるよ！みたいな話し方をすると万人に受けるかもしれませんね。chokudaiさんも青については「8割以上のIT企業において、アルゴリズム力はカンストです。一部企業においては、少し持て余してしまうかもしれません。」とか言っているのである程度自信を持っていいのかもしれませんね。
chokudai.hatenablog.com
これからどうやってレートを上げていくか
今のところ全く見えていません。なんせ黄パフォをとったことが今まで1回しかなく、青パフォも最近になって1800↑が何回か取れるようになってきた程度です。このままの生活をしていくと一生青と水色を行ったり来たりするムーブをしてしまいそうです。
そろそろ本格的な精進を再開しないといけないと感じています。水色上位で完全に停滞したら精進を再開しようかなと思っていたのですが、思ったよりもうまくいくことが増えて精進せず青まで来てしまいました。さすがにここからは600-700点に挑む必要が出てくるため精進を進める必要がありそうです。
今の精進具合がこんな感じです。700を手をつけずに置いておいたので、これからここを中心に手をつけていけばさすがに実力は上がっていくのではないかと思っています。ただ、現時点だと700点問題をみても解説ACの割合がかなり多くなってしまいそうなのでどれくらいまで考えるか、みたいな部分の折り合いをこれから考えたいと思っています。
おわりに
どちらかというと今考えていることみたいな内容を中心に書いたので「このアルゴリズムをやった」みたいなことにはあまり触れませんでした。もし聞かれたら答えたいと思うので興味あれば聞いてください。水色のうちは青にすごい偉大さを感じていたのですが、いざなってみると周りに青上位や黄色がたくさんいるのをみて自分まだまだ弱いなと思ったので精進はもちろんこれからも続いていきます。黄色になるには明らかに今までとレベルの異なる精進をしないといけなさそうなのでこれから頑張っていこうと思います。とりあえずしばらくは青色になった自分の名前を見てニヤニヤしていようと思います。それでは。
フィックスターズの短期インターンに参加してきました
こんにちは、すぎやんです。
5月の平日2週間で株式会社フィックスターズのインターンに参加してきました！
実際の業務の一部を手伝わせていただいたので詳しい内容は書くことができないのですが、作業をしてみた感想などをまとめていきたいと思います。
きっかけ
フィックスターズを知ったきっかけはAtCoder Jobsでした。様々ある企業からここを選んだ理由としては色々あるのですが
- 短期でのインターンでもOKだったこと（研究室とか色々忙しかったので長期は避けたかった）
- 水色コーダーでも申し込める条件だった
- ある程度時給がよかった（これ大事）
などが大きいですね。まだサマーインターンの時期としては早かったのですが、この時期にやっておくのも面白いかなと思ってエントリーしました。
ちなみにこの時期のインターンは穴場らしく、サマーインターンの時期と比べて応募者が少ないので合格率が高いらしいです。予定がつく人にはおすすめです。
面接とか
書類審査に通ったあと、本社がある大崎で面接を行いました。通常の面接を行なった後、コーディングテストなるものを行いました。具体的な内容などは書くことができませんが、競プロをしてる皆さんなら解けますよね、みたいな問題が出ました。たぶんAtCoder Jobsで水色以上という敷居を乗り越えている人たちなら大丈夫な問題だと思います。
ライブコーディングは初めてだったので少し緊張しました。普段書いているテキトーなコードがリアルタイムでみられてると思うと恥ずかしいものがありました。
インターンでやった内容
無事合格をいただき、2週間のインターンが開始しました。平日週5日とはいっても、どうしても外せない授業などの時間は空けるなどの柔軟な時間調整をしてもらったのでありがたかったです。
2週間という短期間なので導入部分はざっくりと済ませ、いきなり実際の業務の内容に触れる形となりました。
今回のテーマは「DSPをターゲットとしたSIMD高速化」でした。DSPとはDigital Signal Processorであり、低電力、低コストながらも高速な演算の実行が可能なマイクロプロセッサです。SIMDとはSingle Instruction Multiple Dataのことで、1つの命令で複数のデータに関して演算を行う手法のことです。一度に演算を実行したい要素数(16や32になることが多い)をメモリの連続した領域に割り当て、適切な命令を実行することで演算が行われます。この演算は実行するDSPの種類によって変わってくるため、どのような結果を返すどういった命令が存在するかをレファレンス等で都度参照する必要があります。 
上の図は8つの演算を並列実行する操作のイメージです。このような要素のひとまとまりをベクトルと呼びます。ベクトルは全体のサイズが決まっていて、要素1つのサイズによって要素数が決定します。例えば、512bitsのベクトルにおいて1要素がint16_tであれば32要素、uint_8型であれば64要素となります。
このSIMDを用いることで定数倍の高速化を実現することが可能となります。競プロでいうとbitset高速化がこの感覚に近いでしょうか。アルゴリズム的な高速化はもう行えない場合などにこの並列化を実装してよりパフォーマンスを高めることが多いそうです。
このSIMD化を用いてとある関数の高速化を行いました。SIMD化する前と後でクロック数にして20分の1程度の差が出たことから、SIMD化によってこの関数の処理がかなり高速化されたことがわかります。
感想とか
まず、SIMDなど比較的低いレイヤーにおける開発の経験がなかったため、はじめに状況を理解するのにとても苦しみました。インターン前にSIMDとは何か、みたいなQiitaのまとめ記事を軽く読んだ程度の知識しかなかったのでほぼはじめて学ぶような状況でした。
また、今回用いる命令セットがAVX-512のような有名なものではなく、検索しても解説記事がほとんど出てこないようなマイナーなものだったため、わからない事柄の調査にとても苦戦しました。公式レファレンスをゴリゴリ読み解く力みたいなのはつきましたね。
またオフィスの雰囲気はエンジニアが多い環境だなと実感しました。たとえお昼休憩でもみんな自分の好きな技術の話で議論を交わしていて、たくさんの強いエンジニアが一堂に会するとこういう環境になるんだなーと思いました。社内の勉強会も見学させてもらったのですが、とてもレベルの高い話し合いが行われていていい刺激になりました。
今回の作業を通して低レイヤーの開発に興味が湧きました。コンパイラの最適化やアセンブラのことなど、今までやったことのない分野に触れてみるいいきっかけになった気がします。友人に組み込みOS自作入門なるものを薦められたので時間があるときに購入して挑戦してみたいなーなどと思っています。
おわりに
別にAtCoderのまわしものではないですがAtCoder Jobsでのマッチングは素晴らしいと思います。実際、同時にインターン開始した3人全員がJobsからの応募でした。競プロで培った力を何か実務に生かしてみたいと考えている人は興味のある企業を見つけて応募してみるといいと思います。
jobs.atcoder.jp
また、夏のエンジニア向けインターンは以下の有名なスプレッドシートにもまとまっています。有名企業のインターンはだいたい網羅されている気がするので併せて参照してみるといいと思います。
docs.google.com
それでは。
プランクトンサミットに参加してきました
こんにちは、すぎやんです。
今日からインターンなので頑張ります。また終わったら参加記的なのを書こうと思っています。
さて、昨日プランクトンサミットというイベントに参加してきました。
プランクトンサミットは何かと言うと、ぶっちゃけ未だによくわかってないです。笑
まぁ簡単にいうと、いろんな分野にお熱な人たちが集まってわいわいガヤガヤするイベントだと思ってもらえばいいと思います、多分。
で、開催場所がまたすごかったんですよ。サイボウズ東京本社さん。しかも丸々1フロア貸切ですよ。なんだこの神待遇は。
今回初参加だったのですが、参加者は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分のファイルがレポジトリ内に生成されたらアップロードできるわけないですね。
僕は3番目の方法を使いました。このキャッシュがないことでパフォーマンスにどれくらいの差が出るかは不明ですが、とりあえず巨大ファイルはなくなってくれたのでよしとしましょう。
今回はVSCodeのextensionの一つであるC++ Intellisenseでの問題でしたが、他のextensionでも似たような問題が出るかもしれません。そのようなときは該当extensionのSetting内にあるパラメータを疑ってみる癖をつけるといいと思います。
応用情報技術者試験を受けてみました
昨日、応用情報技術者試験を受けてきました。
結果の発表は2ヶ月先なので合否は不明ですがとりあえずどんな感じだったか等を残しておこうと思います。
受けようと思ったきっかけ
今年の1月くらいに少し手が空いている状態になっていて、どうせなら資格の勉強でもしてみるかーと思い立ちました。
その少し前にTOEICも受けていた（ほぼ勉強しなかったので微妙な結果でしたが...）ので、その流れで勉強を始めようと思っていました。
どうせなら自分の興味に沿った内容がいいなと思っていたところ、どうやら応用情報というIT系の人たちがよく受けがちな試験があるらしいのでこれにしようと思って応募しました。
勉強をはじめた
応募を終えすぐに合格教本というやつを一冊手に入れたのですが、勉強をはじめたのは受験日まで1ヶ月に迫った3月の中頃だと思います。
とりあえず最初は参考書を一読しようと思ったのですが、一読するような量ではなかったのでだいたいどんなジャンルがあるか把握する＆辞書がわりとして使うことにしました。 
なので、過去問の過学習が得意な僕は過去問道場にこもってひたすら過去問を解くことにしました。
これは応用情報の過去問道場でみられるランク？みたいなやつですが、このふきだしが書いてある四段ってとこまでやりました。
この分布をみた感じだと割と頑張った方なんですかね？
とにかく「未出題の問題を解く」みたいなタイプを選択して解いていたのですが、それでもかなり同じ問題が出ていたのでやはり過去問は正義だなと思いました。
結局2240問中1700問程度は答えたっぽいです。別に何時間もぶっ続けてやってたわけではなく暇を見つけてはやっていた感じなのでそこまで面倒ではなかったです。
既出の問題に関しては計算などせずとも条件反射的に答えられるようになっていると本番でも時間の節約になっていいと思います笑
こんな感じで午前試験はもう大丈夫だろうってなった時（3日前）くらいにふと午後試験の存在を思い出しました（！）
さすがに何か対策をしないとと思って過去問をチラチラみたのですが、そこまで規則性がないんですよね。
過去問をやったところで出題される内容は毎回考えなきゃいけない感じのものでした。
なのでやったことは「どのテーマの大問でどんな雰囲気の問題が出てるか」を把握しただけです。
みた感じ「アルゴリズム」「データベース」「組み込みシステム」あたりがやりやすそうだったのでその辺を重点的に解こうかなと考えていました。
当日のはなし
当日です。午前は過去問だいぶ網羅したし大丈夫だろうって感じの一方、午後は完全に問題との相性次第なので少し緊張してました。
案の定午前は見たことある問題たちがたくさんあったので気楽にできました。大半は聞いたことのないワードの意味を気合いでイマジネーションするのに時間を使ってました。
午後はたっぷり時間を使って解けるとこを確実に得点しよう、みたいな感じでゆっくり解いてました。もともとデータベースが得点しやすいだろうと思って解いていたのですが、予想以上にごちゃついていて自身がなかったので急遽後半の国語っぽいやつに切り替えました（サービスなんちゃらってやつ）。雰囲気で書いたので合っているかはよくわかりません。
おわりに
こんな感じでどこか片手間でやってしまいましたが、これで応用情報チャレンジは終了しました。
結果は2ヶ月後くらいに発表されるようです。受かっているといいですね。
また何か別の資格の勉強でも始めようかなーと思ってます。有名どころからいくと簿記とかやってみるのも面白いかもしれないですね。
※6/26追記
先日結果発表があり、午前80点午後65点で無事合格していました！
午前中は過去問を過学習した成果がしっかり出ましたが、対策をしなかった午後は案の定ギリギリの結果となりました。
まぁ受かってしまえば勝ちなので良しとしましょう！
もし今後時間があればスペシャリスト試験とかも手をつけてみようかなーと思います。
