ストレスの少ない就活をした
就活の話を少しだけ．あまりTwitterとかでしてなかったので，というか就活中にあまり適当なこと言わない方がいいかなーと思っていたのでしていませんでした．
深夜テンションなのでそのうち消える可能性もあります．
就活していた期間はM1の11-3月くらいです．ちょうどコロナが流行り出した時に終わったという感じですね．ちょうど全ての面接がリモートとかに切り替わり始めた頃だったので，早めにやっていてよかったなーというのが正直な感想でした．
就活の方針ですがインターンとかの流れでいった方がどう考えても進めやすそうだと思ったのでその方針でいきました．そうすると夏とか秋にあるインターンをやっておく必要があったので，ある程度時間があった8-9月に何週間かぶち抜いてインターンをしていました．
インターンをやるやらないの違いですが，受かりやすいとかそういうのはまぁいいんですけど，やはり社内の雰囲気が予めわかっているというのがとても大きいですね．人事のその場でのアピールでは正直そこまで伝わってこないのでちゃんと内部から見ないと怖いですよね．
結局インターンを行った2社，インターンをやろうとしたけど日程が合わなかったり祈られたりしたところ3社，その他1社の計6社を受けました．かなり省エネな就活にできたのではないかと思います．受けすぎてもアップアップになることは目に見えていたので，受かってもいく覚悟のあるところだけにしました．もちろん全て落ちてしまうようなら足していこうと考えていたのですが，3つくらい通ればよくてその中から選べばいいかなーという算段でした．結局6つ中4つ内定もらい，そこからとりあえず2つに絞り，じっくり考えて1つにしました．
業種がエンジニアで特殊というのもあるかもしれませんが，世に言う就活らしい行動をほとんど何もしなかった気がします．スーツは着ませんでした．グルディスというやつも一回もやりませんでした．ESをまとも書いた記憶がありません．説明会などもありませんでした．一回合同説明会というものに行ってみたくて凸する計画してたんですけどコロナで潰れてしまいました．
あと，一切面接中に話を持ったりはりきったりしなかったですね．自分の興味のある話題だけ話して面接官の食いつきの良さそうなだけ熱く語る作業を繰り返していました．御社が第一志望ですってどの企業にも言わなかったですね，第一志望決まってたらその会社しか受けてないだろって思いますけどね．
就活関連のイベントにはもう少し顔を出したかった感ありますね．興味のあるところは少しご飯食べれたりしましたが期間が結構短かった&行く気のないところに行くのは良心が自制したので．何だか大学1年生で新歓されている頃を思い出しました．
結局最後は2社に絞って迷うという理想的な形に落とし込みました．ここだけ真剣に比較して考えましたね．双方に面談とかいろいろセッティングしてもらって最終的に面白そうだなって思う方に決めました．
今考えるとあんな企業やこんな企業も魅力的で受けてみればよかったかなーというのはたくさんあるのですが，どうせまたどこも魅力的に見えて迷うだけなので今の立ち回りでよかったのではないかなーとおもっています．
きっと数年働けばまた企業の見方変わると思うので転職とかなった時に改めてどんな企業あるのかなーって見方すると今とは違った観点でみれて面白いかもしれないですね．
AtCoder黄色になりました
AtCoder黄色になりました！！ pic.twitter.com/DoeiZ4Fm3P
— すぎやん🍋 (@yuji9511_compro) January 19, 2020
毎度おなじみ、変色エントリーです。
こないだのABC152でとうとう黄色コーダーになることができたのでまた少し感想など残しておこうと思います。
精進の方法について
青になってからはかなりコンテストが多かったので、自分で猛烈に精進せずともかなり解く問題の量は多かったように思えます。
AtCoderとこどふぉとゆきこにしっかりと出ていればそれだけでかなりの問題数をこなせるので、無理をして過去問を大量にやる必要もありませんでした（もちろん時間的余裕があるならやるに越したことはありませんが）。
AtCoderに関しては600以降の重めの問題を多く残しているため、気が向いた時に頭の中に数問入れておいて暇な時に考察する、みたいなことをしばらくやっていました。
他の作業ができない虚無みたいなイベントとかの時に時間を有効活用できるのでおすすめです。
身に付けた技術について
昔考えていたよりは大して新しい知識はついていない気がします。文字列系のアルゴリズム、いろいろできるセグ木、包除とかいくつか増えた部分もありますがそこがレートの伸びに直結した気はあまりしないです。ただ、明らかに既に身に付けているアルゴリズムをどんなパターンの時に適用すべきか、みたいな選球眼の部分は問題数をこなしてく過程で良くなってきているのは感じました。
モチベーションの源は何か
黄色あたりまでくる人は何かしらモチベーションの源となる何かがあって競プロを続けていると思います。競うことが好きな人もいれば難しい問題を解くことが好きな人、綺麗なコードや短いコードを書くのが好きな人もいます。
僕のモチベーションは「この人には勝ちたいなという格上の相手を見定めて、レート差を一瞬で縮めて追い抜くこと」です。僕は問題を解くことはもちろん好きですが、競争やレーティングのシステムがより大好きな人間なので、レートが1でも上がって順位が1つでも上がることに快感を覚えます。レーティングに色をつけるというシステムはとても良いと思っていて、数値よりレベルがわかりやすくなるとともに色の境目を超えた時の達成感が何もないときに比べて桁違いです。色を跨いだだけで一気に力が湧いてきたような錯覚を見せてくれます。また、常に自分よりちょっとレベルの上だけが見えていて、そこにたどり着くと前まで見えていなかったまたその先の敵が見えてくる、みたいなゲームのような展開もすごい好きです。今は黄色になったので橙という世界の住人がわずかに見えてきた気がします。
レートを上げるために必要なこと
青あたりでレートを上げるために何が大事なんだろうなーと最近考えることが多かったです。もちろん毎回のコンテストで難しい問題を華麗にACすればものすごいペースでレートは上がるのでそれが理想なのですがなかなかうまくいかないのが現状です。
自分は正直言ってレートという数値をかなり気にしている部類だと思います。レートに拘らずに難しい問題を解くことが楽しいという人も一定数いますが、僕はコンテストに出て1でもレートが上がって上位に行くことにやりがいを感じている人間です。もちろん難しい問題に時間をかけて粘って解けた時の快感みたいのも好きです。
レートを上げていくために一番大切なのは「レートを下げないこと」だと思っています。当たり前のように聞こえてしまいますが、めちゃくちゃ難しいことです。
自分と同じくらいのレート帯にいる人で結構な回数橙パフォを出して大成功しているけどレートはそこまで高くないみたいな人もいますが、そういう人はそれだけ激冷えをしているということです。
これは青色になってから黄色を達成するまでのパフォーマンス遷移です。大成功した回こそそこまで多くないものの、下振れを引く回数がかなり抑えられていると思います。黄色に入った人でここまで橙パフォを出せないのもなかなか問題だろうという気もしていますが...。 黄色からレートを上げていくにはこの状態では限界があるものの、黄色を達成するという状況においてはこういったパフォーマンスを出すことで比較的スムーズにレートを上げていくことができました。ただ、特に1900を超えてきたあたりからはある程度うまく行ってもレートは微増なので失敗をしないままある程度の成功をし続ける必要があって大変でした。
レートを下げないために実行していることはいくつかあると思いますが、まず大事なのは必ずA問題から解き始めることだと思っています。ある程度できるようになってくるとこの問題が解けたら提出、みたいなムーブをしている人が増えていく印象ですが、途中から提出する人のパフォーマンスが安定しているのをあまり見たことがない気がします。予想外のコーナーを踏んで慌てて前の問題を通すも順位はかなり下がるような状況の人をよく見かけます。
もう少しレートが上がってくるとこのムーブは意味を成してくるかもしれません(問題の得意不得意が結果に如実に影響しそうな橙あたり〜)。ただ青くらいの段階でこれをやるメリットをあまり感じません。この問題が解けたら出す、みたいなことをする人が結構いますが、苦手な問題が入っていたらどうせその回をしのいだところでその先大して上がらないので大人しく前からやればいいと思います。前から解けば自分より2つ以上下のパフォーマンスをとるなんてことはそうそう起こらないはずなので、安定感は増すと思います。ただ大成功の確率は多少下がると思うので同時出しのギャンブル性がクセになっている人は楽しい方を選ぶべきです。
また、黄色になるまでは「みんなが解ける問題を落とす」が致命的になります。僕は考察の難易度が高くなる800~はほとんど通した経験はないですが、逆に比較的通す人が多い~600の問題を落とす率はかなり抑えていると思います。
比較的簡単な問題で詰まったときにいったん他の問題に逃げるべきか、みたいな葛藤に苦しむことがあるかもしれませんが、自分の場合はほとんどの場合その場に止まった方がいい結果が出ています。飛ばすということは少なくとも今解いている問題以上の配点の問題に取り組むということなので、余程得意分野に当たったなどの場合を除いてすんなり解ける確率はそれほど高くないと思っています。しかも、問題を飛ばした場合常に前の問題に意識が何割か持っていかれた状態になってしまう(ここを完全に切り替えられる人は尊敬します)ので、パフォーマンスを最大限発揮できない状態になってしまいます。上手な人はあとの問題に賭けて成功するようなこともしていますが、僕が今までそのような状況になったときには大抵同じ問題にとどまった方が良い結果をえている気がします。もちろん本戦枠・賞金がかかっている場合などはこの限りではなく起死回生の一手を狙うしかないと思います。
その他にも自分に関する特徴として、「比較的ペナを出しづらい」傾向にあると思っています。
実装と考察どちらが得意かどうか二分するのが競プロ界隈の特徴でもありますが、僕は完全に実装側に寄っているタイプだと思っています。比較的考察はスムーズにいく問題に関して、バグを埋め込まない実装しやすいコードを高速で書くことには長けていると思っています。
バグを埋め込まないための実装をするためにはいろいろな工夫も行っていて、同じ処理を行う変数は毎回確実に同じものが使える状況にする、スペースの区切りやif文をワンライナーにする時の条件などは全て統一しておく、実装が複雑だった問題はコンテストが終わった後にリファクタリングしてみて本番中にどこまでだったら綺麗な状態で実装できそうか考えてみる、などです。また、ライブラリの使い方周りでバグを踏んだ場合はそのライブラリが自分に合っていないということなので何かしらの改善を行います。ライブラリは使い始めこそ人のコピーを使うものの(これ重要です。いきなりスクラッチで書くと確実にバグを埋め込むのでお勧めしません)、場数を踏むごとに自分の使いやすい形にどんどん変形していきます。
マクロは必要最低限に留めています。マクロを多用するとバグが発生したときに少なからずそちら側まで疑う必要性が出てくるのが苦痛でしかないからです。自分にとって確実に必要なのはfor文のrepマクロ(確実に時短になる、添字ミスが減る)、可変長のprintマクロ(Pythonライクにデバッグできる、printデバッグの人間なので重宝しています)、using ll = long long;(こと競プロに限ればint64で全て統一した方がミスは確実に減ると思います、ここで意固地になって定期的にオーバーフローを踏む必要性が皆無)くらいだと思っています。バグを埋め込まなくするのは不可能なので、バグがあるとわかったときに疑うべきポイントを予め可能な限り潰しておくことが大事になってくると思っています。
これからの立ち回り方
こんな感じで黄色まではかなり守備力の高そうな立ち回りをしていましたが、ここからはそうも言ってられなくなります。
現時点の自分の実力だと橙パフォに届くボーダーの問題のAC率がかなり低いためレートが上がらなくなります。
このままコンテストにで続けた場合、おそらく黄色と青の狭間を永遠にさまようことになると思います。ここを打破するためにはやはりその得点帯の問題をみるしかなくなってくると思います。長いこと特定のレベル帯に絞った精進というものをしてきませんでしたが、そろそろ再開する頃合いだと思います。
今AtCoderの埋めはこんな感じです。黄色にしてはやる気のない精進してますね。700~800あたりの問題は結構在庫が豊富にあるので、まずはこの辺の問題を重点的に取り組むことで力をつけて行こうと思っています。
あと、少し前に手をつけ始めたのですがJOIの過去問埋めもなかなか面白いです。AtCoderとはまた違ったタイプの問題と触れ合うことができるのでこちらも8-9あたりを定期的にやっていきたいと思います。
さいごに
現時点では令和ABCに助けられて黄色にタッチしただけなのでまだ黄色の実力はほとんどありませんがまずは青落ち圏内を脱するように頑張りたいと思います。 次の変色である橙があまりにも遠いですね。これが最後の変色エントリーにならないことを願っています。
HTTF2020本選に参加しました
今回は12/7にフューチャー株式会社さん主催で開催されたHTTF 2020の本選の参加記を書いていきます。
HTTF2020とは
HACKING TO THE FUTURE 2020という名前のコンテストで、マラソン形式のコンテストです。何週間か前に予選が行われ、そこでいい順位をとった50人がフューチャー株式会社さんで開催された本選に参加しました。
新卒枠、地方枠、Youth枠などいろいろな条件があったのでいろいろな畑の人が幅広く本選に参加していました。
予選
8時間のハーフマラソンみたいな感じでしたが、マラソンというよりアルゴリズムによった問題で、マラソン経験があまりない自分でもそこそこのスコアを出すことができました。
順位はそこまで良くはありませんでしたが、新卒枠という最強のカードが使えたのでなんとか本選に参加することができました。
本選が始まるまで
ビジュアライザ、ダメです…。
— ツカモ (@tsukammo) 2019年12月6日
なんかいきなり不穏なツイートを見ました。この辺りからすでに異変は始まっていたのかもしれないですね。
問題を見るとわかるのですが、確かにテーマ的にビジュアライザが使いづらいタイプの問題でした。
ちなみに今回もらえた布類はウィンドブレーカーでした。あまりもっていないタイプのやつだったので使い勝手が良さそうです。
本選1開始 (10:30 - 14:30)
なんで本選に1がついていて、なんで4時間で終わっているのかは読み進めていけばわかります。
atcoder.jp
簡単に問題の概要を説明すると、1000個程度の頂点が存在してそれぞれの点の間に辺を張れるかが指定されています、この中の頂点を使って指定された木構造をいくつ含むことができますか、といった感じです。予選と同様あまりマラソンっぽくない雰囲気がしますね。
問題文が割と長く、出力がvalidな条件も比較的厳し目なので開始直後はしばらく正の得点が出ていませんでした。
ただ、問題の条件を読んでいたところ、案外制約が緩く、比較的点数が出しやすいのではないかなとなんとなく見当をつけていました。
異変が起こったのは開始90分を回ろうとした時でした。
みんなが騒ぎ出しました。「満点が出たぞ。」と。
アルゴのコンテストならいいのですが、これはマラソンです。満点などそうそう出るはずがありません。しかもコンテストはまだ6時間半も余っています。
同点の場合は早い順に順位が決まるはずなので、残り時間であがいたところで抜かすことはできません。
やはり異常事態だったらしく、まもなくしてchokudaiさんが会場に現れ、状況の説明とともに本選2の開催が発表されました。
元々8時間だった本選を4時間で終え、そのまま本選2を開催するということです。
問題の大枠を変える時間はないので制約を厳しくして点数を抑えるといった変更を加えるそうです。
当然この状況はメンタルに大きく響きました。少しでもスコアをあげようと努力していたところに満点が出たと言われたらそりゃ動揺しますよね。
ただ、現在のコンテストも賞金などは変わらず与えられると言っていたので、気持ちを切り替えて頑張ろうと思いました。
それから30分ほどして、ある一つの点から貪欲に頂点を増やしていくという至極単純な実装をしていたところやけに上手くいっていることに気付き、ビジュアライザに投入してみるとスコアには100000（1ケースの満点）の文字が。
これはもしかして満点が取れるやつなのではと思った瞬間鼓動が爆速になりました。とりあえず心を落ち着かせて提出して様子を見守っていました、すると...
満点！！まさかこんなにすぐに出るとは思っていなかったのでとても驚きました。でもみんな結構解き終わってるんだろうなーと順位表を見にいくと...
えっ4位!!??
まさかオンサイト初入賞and初賞金がこんなタイミングで来るとは思っていませんでした。とりあえず2時間ほど時間が余ってしまったのでほわ〜んとした気持ちで配られたお弁当を食べていました。
実績解除: マラソンコンテストで満点 pic.twitter.com/M2uMYCIKLE
— すぎやん (@yuji9511_compro) 2019年12月7日
解法について話せない状態で昼ごはんを食べながら他の参加者と懇親していたのでなんだか本質を話せない歯痒い感じのコミュニケーションをしていました。
本選2開始 (14:30 - 18:30)
本選1から間髪入れず本選2が始まりました。先ほどより構築すべき木の頂点数が増え、頂点同士が繋げづらい制約になっています。
先ほどと同様のコードを投げたところ、満点の3割程度のスコアしか出なかったためいろいろ修正を加えました。
具体的には頂点を強い頂点から順にとっていく、木の頂点数が少ない順に使う、開始頂点をいくつか試して最もスコアが出るものを採用する。ランダムに根を選び直して時間の許す限り木が挿入できないか試す、あたりでしょうか。
そこまでクリティカルにスコアが上がったものは少なかったですが、じわじわとスコアを上げていき300万点(全体の6割)ほどになったところでスコアが上がらなくなりました。中盤は賞金圏内でしたが後半どんどん抜かれていき最終的には全体17位で終了しました。やはりスコアを改善していく部分でマラソン的立ち回りに慣れていないのでその部分で負けてしまった気がしますね。
制約が厳しくなった本選2ですが、今回も満点が2人出ました。ただ今回の満点は難易度が相当高いので素直に尊敬します。
懇親会
8時間のコンテストも終了して懇親会が始まりました。いつもと違いマラソンの本選であること、Youthなどの枠があることもあり普段とは違ったメンバーが集まっていたのでいろいろな方と話すことができました。
ご飯はすごいたくさんの種類が用意されていて、しれっと美味しいシャンパンが置いてあったりと内容もなかなかに豪華で満足度が高かったです。
懇親会中に結果発表が行われました。本選2がメインとなったコンテストだったので本選1の方は比較的さらっと流されてしまいましたが、それでも初めて入賞という経験をしたのでとてもうれしかったですね。金額が書かれたプレート的なやつを持つという実績を解除できました。ちなみに1位だった方はどちらのコンテストでも満点をとってどちらも優勝していました、さすがです。
懇親会の後にはあらかじめ飲みに行こうと言っていたメンバー+αで二次会に出かけました。あとで考えたらみんなレート青以上とかだったのでレートの高い飲み会だなーと思いました。今年の競プロ界隈での流行語の話とか面白かったです。1位は満場一致だったのでみんなで2位や3位の予想が行われていました。結構遅くまで飲んでましたが無事終電で帰宅できました。
まとめ
本選1での入賞なのでなんとなく自慢しづらい感じになりましたがとりあえず入賞は入賞なのでよかったです！
最近オンサイトの予選で冷えがちなのでこれからもオンサイトにたくさん出れるように精進していきたいと思います。
とりあえず目先の目標はAtCoder黄色ですね。あと+34で黄色なので頑張ります！
GigaCode2019に参加してきました
有志で行われた競プロのイベントに参加したので簡単に書き残しておこうと思います。
11/24日にYahooさんのオープンスペースにてGigaCode2019というイベントが開催されました。
普段オンサイトなどになかなか参加できない競プロ初心者にとっての交流や競プロの普及を目的としたイベントだったのですが、このイベントを開催していたのは高校生でした。最近の高校生はすごいですね。イベントの企画から実現までの様子はここのQiitaに事細かに綴られていました。
qiita.com
元々抽選には落ちてしまっていたのですがキャンセル者が出たため繰り上がりで参加できることになりました。参加者の年齢層は幅広く、中学生から1970年代生まれという方まで参加していました。普段のオンサイトとはまた違った雰囲気のメンバーが集まっていた気がします。
コンテストは主にLT、コンテスト、パズルの3つの部分からなっていました。LTでは参加者の3割程度のメンバーがいろいろなジャンルについて語っていたのでとても楽しかったです。コンテストは3時間ぶっ続けの思っていたよりガッツリしたもので、いつも通りのコンテストの緊張感をもって問題を解いていました。パズルはコーディング禁止という条件で、ひらめきが鍵となるような設定になっていてとても面白かったです。
コンテストでは全体48人中9位にランクインすることができ、銀メダルをもらうことができました。目標としていた一桁順位をギリギリ確保できたのでよかったです。JOI形式だったので、部分点を取りに行く立ち回りが慣れていなくて難しく感じましたが幅広いレベルに対応した問題を置くことができるメリットも感じました。
僕はオンサイトなどで普段TLで見ている方と交流するのが好きなのでこういったイベントがもっと増えていくといいなと思いました。
運営に携わっていた方々、お疲れさまでした！とても楽しかったです！
サイボウズ株式会社でインターンに参加してきました
きっかけ
サマーインターンを何にしようか考え始めた5月くらいにインターンの募集を見つけて応募しました。
選んだ理由としては「自分がチャレンジしてみたかったインフラ関連のコースがあったこと」「待遇が他と比べてよかったこと」あたりです。5月終わりくらいのかなり早いタイミングで合格をいただいたので参加することになりました。
参加したコース
今回は「クラウド基盤コース」という部門に参加することになりました。募集要項をみても特にこれを必ずやりますというものは決まっておらず、自分が興味のある内容のテーマを自由に選ぶことができるようでした。
事前にどのようなことをやるかはあまり知らされていなかったため、行ってから流れに身を任せようみたいな調子でインターンが始まりました。
インターンの内容
1日目: オリエンテーション＆テーマ決め
順調に1日目が開始...と思いきやこの日は台風が前夜に直撃してJR始め多くの路線が運転を見合わせていたあの日でした。
インターン初日だったため在宅作業にすることもできなかったため、集合時間を12時にずれることになりました。全く電車が動かずたどり着けない人もちらほらいて大変そうでしたが簡単なオリエンテーションとランチの後業務が始まりました。
僕たちはサイボウズ内のSite Reliability Engineer (SRE)チームで業務を行うことになりました。同じチームのインターン生が僕以外にもう一人いたのでインターン2人とメンター3人ほどを中心に作業を進めていきます。
1日目に議論を進めていく中で早速気づいたのですが、僕は思っていたよりインフラの知識が備わっていませんでした。 知らない言葉が大量に流れてくるので喋りつつググりつつとにかく疑問点を投げまくることをしていました。インプットはもともと大好きですが流石に分量がすごかったですね。
そんな感じでディスカッションを行い、テーマとして「既存のサービスをコンテナ化してkubernetes上で動作させる」というものに決まりました。
2~4日目: 開発
実際の業務を手伝っている形なので、この日程で何をするというのは特に決まっておらず、進捗に合わせてメンターさんと話し合いながら作業内容を決めていくスタイルでした。とりあえず僕は周りの話や作業風景をみながらわからない知識をひたすらインプットしながら実装が見えたら手伝う、といったスタンスで作業していました。ディスプレイを使ってあれこれ議論しながら開発を進めていけたのでチーム開発のとても良い経験ができたと思います。
具体的な作業内容ですが、3日目にダミーのnginxコンテナとの疎通が確認できたので、それ以降はその部分を今回扱うアプリケーションに置き換える実装を行なっていました。アプリケーションが動作するのに必要なツール類は作成済みのdockerイメージがあったのでそこまで難しくなかったのですが、Pythonの謎のimportエラーなどに悩まされて思ったより時間がかかってしまいました。
結局、置き換えたアプリケーションで疎通が完了したのは成果発表を行う日の朝でした。
ちなみに僕が今回の作業の全体像を一通り理解したのは4日目でした。5日間のインターンなのでこれから面白くなりそうというところで終わってしまいました。
5日目: 成果発表
5日目は僕は開発をせずにスライド作りを行なっていました。その間にも相方が発表用のデモの準備やコンテナのさらなる改良をしてくれていたので大変助かりました。
作業内容は一通り理解できる状態にはなっていたのですが、果たしてこれを成果発表で他のチームの人に理解させるにはどうしようという部分でかなり悩みました。そのまま説明すると皆がポカーンとしてしまう構図が容易に想像できたのでできるだけ概要だけをわかりやすくなぞりつつ嘘は言わないようにいい感じにスライドを作成しました。
成果発表は特に問題なく行うことができました。詳細はわからなくても、なんとなくどんな領域のことをやっていたかが伝わっていたらいいなと思っています。
所感・感想など
バリバリの実務経験ができた
クラウド基盤コースはあらかじめ作業内容が決まっているわけではなく、インターン開始後に何をするべきかの話し合いから始まりました。
他のコースだと業務内容が完全に固定されていることもあるそうですが、僕らのコースはそれが一切なかったので個人的にはとてもいい経験ができたと思っています。ただ、答えをメンターさんですら知らないような部分もあったのでレベルとしては比較的高めだったと思います。
社風がしっかりと定まっていて過ごしやすい環境だと感じた
社員にとって働きやすい環境が整っていると感じました。年功序列や過剰な上下関係が存在せず、比較的フラットな立場で意思の反映ができる環境に魅力を感じました。お土産としてもらった社長の青野さんの書籍も一通り読んでみたのですが、良い組織を作るための考え方がとてもわかりやすくまとまっていていい勉強になりました。
技術力の高い社員さん・インターン生が集まっていた
それぞれ得意分野を持ったメンバーが集まっているなと感じました。社員の方は業務以外にも講師として大学などで講義を行なっている人や趣味の開発に本腰を入れている人など色々なメンバーがいました。インターン生もポテンシャルの高そうな人たちばかりでこの企業の人気の高さを感じました。
ランチが美味しかった
社内の弁当×2と外食×3をご馳走になりました。個人的には最終日に食べた海鮮丼が一番好きでした。ただ、日本橋は意外と良心的な価格のランチを食べれる店が多くないようです。
おわりに
5日間ですがとても密度の濃い経験ができました。協力していただいた社員や他のインターン生にはとてもお世話になりました！ 色々な新しい技術領域を知ることができたのでこれを機にさらに知識を深めていければなと思っています。
TTPCオンサイトに参加してきました
これは何
8/31に行われた東京工業大学プログラミングコンテスト、通称TTPCに参加してきました。その時の様子をざっと振り返ってみようと思います。
結果はチームeeic_ttpcで参加して7完56位でした。
会場に着くまで
かなりギリギリに大崎についたので会場のあるビルで丸亀製麺を急いで食べました。周りの人がみんな「あの小宮」の話をしていました。今度時間があれば行ってみようと思います。
チーム決めとか
会場はフューチャー株式会社の部屋をお借りして行われました。ご協力ありがとうございます！
チームはあらかじめ決めておいたぴーよくんとモジャンボくんの3人で組みました。学科の2個下の後輩なのですが、僕はずっとB4だと思われていたことを知りました。僕はM1です。
チームで競プロするのは初めてだったので段取りとかよくわからなかったのですが、5時間もあるしのんびりやればいいねってことで皆の意見が一致していました。
コンテストの内容
問題は全部で15問あり、前6問は比較的簡単だよみたいな話をしていたので素直に前から埋めていくことにしました。
僕は開始後すぐにAを通し、Dをちょっと考えつつBCを見守ってました。
他の人がCのバグ取りに苦戦していたのでCを書き直してAC、そのあとに考察が終わっていたDを通しました。
そのあとはずっとFを考えていたのですが、見事に沼にはまってしまい断念。終盤はFを考えつつOのパズルを必死に構築していたら時間になりました。
結局、A-Eの他にぴーよくんが中盤にGを通し、モジャンボくんがお絵描きしたOを一瞬で実装に落とし込んでくれたので計7完でした。
コンテスト後の懇親会
今回はTTPC側が全員にアイコン付きの名札を作ってくれたので特定がとても捗りました。
やはりTLで合う人は実体を見ても全くピンと来ないのでこういう配慮はありがたいですね。
知ってる方達も割といましたが、せっかくだからということで今まで話したことないような人を探して話しかける、みたいなことをしてました。
普段TLで見かけるつよい方達と結構しゃべれたので良かったです。
みんなマスコットを携えてきていたので僕もそろそろ何か生み出さないとなぁと思いました。
感想とか
チーム戦なので個人とはまた違った楽しさがあってとても良かったです。多分ICPCみたいな雰囲気だともう少し殺伐としてしまうのかもしれませんが、ゆったりとしたオンサイトコンテストだったので何も気にせずに楽しむことができました。僕らのチームは青3人だったのですがオンサイトの中だと平均より少し下くらいの平均レートで、参加者のレベルの高さに驚かされました。
あと、東工大陣の作問力の高さにも驚かされました。赤や冠保持者まで参加してくる5時間のコンテストを作るってめちゃくちゃ難しいことだと思います。本番も問題に特にトラブルもなく進んでいたので、きっと相当な準備を行なっているのだろうなーと感心していました。
コンテストを開催してくださった東工大競プロerの方々、ありがとうございました！
株式会社アカツキでサマーインターンに参加してきました
自己紹介
現在東京大学大学院に通っているM1です。情報系の研究室に属しています。
学部2年ごろからプログラミングをはじめ、アルバイトなどを通してWebや自然言語処理など色々な分野を経験してきました。
最近はサーバサイドに興味を持ち、Goを少し前から勉強しています。
また、1年半ほど前から競プロにハマり、最近は暇さえあれば問題を解いています。このブログにも競プロの記事がいくつかあるのでもし興味があれば読んでみてください。
きっかけ
アカツキさんを知ったきっかけは巷で有名の魔法のスプレッドシートでした。
このスプレッドシートにはサマーインターンを開催している企業の募集要項がずらっと並んでいました。
僕はサーバサイドの開発をこの夏にやってみたいと考えたので、自分のやりたい内容にあった企業を探していたところ、アカツキさんから合格の連絡をいただいたので参加することになりました。
開発を行なったプロジェクトの概要
とあるスマホアプリのゲーム内通貨の管理を行うバックエンドのサービスの開発を行いました。ゲーム内通貨とは課金して手に入れることのできるアイテムのことで、よく石などと呼ばれるものです。
この課金アイテムの購入や消費などの取引を正常に行い、チートなどによる悪質な攻撃を未然に防ぐのがこのサービスの目的です。
概要は下図のようになっています。主にGAEやTask Queue、BigQueryなどから構成されています。
作業内容
実際に取り組んだIssueをいくつか紹介します。
APIのパスパラメータのvalidation
まず最初のissueとして取り組んだのは、APIのエンドポイントに含まれるフィールド名が適切であるかのvalidationを行うというものでした。入力されたURIをパースしてフィールド名が想定されているものかどうかのチェックを行いました。
とりあえずコードがどのように書かれているかを把握するということで、APIが叩かれてから結果が出力されるまでどのような処理を経ているのかに注目しながら実装を行いました。
そこまでソースコードの規模が大きいわけではありませんでしたが、 実際の開発におけるGoのコードを読むのが初めてということもありソースコードの理解にだいぶ苦戦しました。
また、変更された箇所に関してテストコードの作成も行いました。Goの標準ライブラリであるtestingを用いることで変更後のコードが正常に実行されているかを自動的に確認することが可能となります。僕は今までSeleniumなどの外部ライブラリを用いたテストしか行なったことがなかったため良い勉強になりました。
TQ handlerのエンドポイントを処理ごとに分ける
データベースであるBigQueryへデータを登録する際、まずデフォルトサービスはTask Queue(TQ)と呼ばれるqueueにリクエストを送信します。
TQはFIFOの順でTQ handlerにPOSTを行い、BigQueryへの登録を実行させます。
登録に関する情報は内部パラメータとして渡すため、今までは全ての処理(charge, consumeなど)で同一のエンドポイントを使用していました。
しかし、Stackdriver Loggingなどでログを確認するとなるといちいち内部パラメータを覗く必要があり、可視化の観点では優れていませんでした。
そこで、処理ごとにエンドポイントの名称を変える変更を行い、ログの可読性を高めることを行いました。
しかし、単純に新しいエンドポイントに置き換えてしまうことには問題があります。
このサービスのデプロイはTQ handler -> デフォルトサービス の順で行なっているため、前のエンドポイントを削除してしまったTQ handlerをデプロイしてしまうと現在稼働しているデフォルトサービスのPOSTリクエストを受け取ることができなくなってしまいます。
したがって、まずは新旧両方のPOSTに対応したTQをデプロイし、デフォルトサービスが置き換わったのちに古いものを削除するという二段階の処理が必要になります。図で表すと下のようになります。
GitHubのブランチ運用の方式を変更する
まず、このプロジェクトで行なっていたブランチ運用を簡単に説明します。開発はdevelopブランチからトピックブランチを切ることで行い、developの変更をmasterブランチにmergeします。CircleCIの設定により、トピックブランチやdevelopではコミット毎にlinterやユニットテスト、統合テストなどが自動的に実行されるようになっています。また、masterではdev環境へのデプロイが実行されるようになっており、masterのコミットに対してreleaseタグを付与することで本番環境にデプロイが実行されます。
この運用の問題点として、「master環境へのコミットの時、デプロイ前にテストが走らない」という問題がありました。万が一テストで問題があってもdev環境へのデプロイが実行されてしまうおそれがあります。
これを解決するため、ブランチ運用をdevelop, master, releaseの3段階に変更する作業を行いました。フローの概要は下図のようになります。
実装としては主にCircleCIの設定ファイルであるconfig.ymlをいじる形になります。masterブランチへのプッシュ時に、全てのテストの終了を受けて実行がスタートするジョブ"create_release_branch"を作成します。このジョブではmasterブランチのHEADをチェックアウトし、releaseブランチへのpushを行います。この際、CircleCIにブランチの作成及びpushを行わせるため権限が必要になります。今回はGitHubでデプロイキーを作成し、その秘密鍵をCircleCIのconfigへ登録することで解決しました。
Task Queueに取引情報をPushする時にはPayloadのサイズが大きくなる問題を解決する
BigQueryに登録すべき情報をTask Queueから送信する際、payloadのサイズが大きいことにより処理が失敗することがあるという問題がありました。この原因として、DBへの登録に必要のない情報も含めて送信してしまっていることが挙げられます。そこでDB登録に最低限必要な情報のみを先に作成し、そのデータをpayloadに載せるという変更を行いました。
このIssueではpayloadの送信側と受信側どちらの処理も書き換えなければならず、影響範囲がかなり大きく難易度の高い作業でした。
また、TQを先にデプロイするという先ほどの理由により過去のバージョンのPOSTを受け付ける処理も残したまま変更を加えなければいけないという考慮も必要でした。
Goの型チェックや隅々まで張り巡らされたCIのおかげでなんとか形にはなりましたが、既存の処理を変更しないようにコードを変更していくのはなかなか難しかったです。
こういった変更点がある時にテストを細かい部分まで充実させておくことは重要であると認識することができました。
今回学んだこと・感想など
GoやCircleCIなど、今まであまり触れてこなかった技術を経験することができた
アカツキのインターンを選んだ目的として、「サーバサイドの開発経験がほしい、できたらGoに入門してみたい」ということがありました。Goは実務で触ったことがなかったのでインターンの中で習得していきたいという熱意を語ったら採用していただいたのでありがたかったです。Goは型の管理やコーディングの規約が非常にしっかりと固まっているので、ある程度大きな規模のコードを見ても統一感を持って眺めることが可能となっていました。今後も使い続けていきたい言語です。
また、CircleCIの知見を得たことも大きかったです。テストやデプロイなどを自動化させることで人為的ミスやそこにかける工数を削減することができ、機能追加などに集中することができました。
少し前にはGitHubも公式でCI/CDをサポートするとの発表があったのでそちらも楽しみですね。
社内の環境がとても快適だった
3週間という期間ではありますが平日週5で来ることになるので、開発環境がどのようなものか気になっていましたが、とても快適に作業を行うことができました。
ひとチームあたりの人数がそれほど多くないため、意見の疎通もしやすくスピード感のある開発をすることができました。
また社内のイベントやインターン同士の交流なども積極的に開催していただき、たくさんの人とお話ししてたくさん美味しいご飯をいただくことができました。
これからインターンに参加しようと思っている人へ
アカツキの就業型インターンは募集人数こそそこまで多くないですが、その分一人ひとり手厚くサポートなどをしてくれるところがオススメできるポイントです。
手厚いといっても過剰にゲストとしてのもてなしをされるわけではなく、しっかりと実サービス開発のメンバーとして参加することができるので普段どのような段取りで開発が進んでいるのかを間近で体験することができました。
また、ゲーム会社ということで社員さんもゲームに対する愛が強い人が多いため、ゲーム製作に対するモチベーションが高い人にとってはとても良い環境だと思います。
就業型だけではなくUnityでゲームを作るハッカソンのようなコースもあるので、そちらも併せてチェックしてみるといいと思います。
おわりに
3週間という短い期間でしたがとても密度の濃い経験をすることができました。ありがとうございました！
