概要 †
- プロコンで必要となる知識のまとめ。
- 難問を解いて自分のものにする、短時間で学習するサイクルが回せ。
- 役に立つとは別の軸でプログラミングの面白さを主張することで裾野を広げる活動
下位ページ †
目次 †
記録 †
失う信用 †
- 人が作った問題を解くという枠組みから出られていない
- いつも自分が作った問題を解いているわけではないでしょう？サーベイの高速化になる。
- じゃあどういう枠組みかというと、「世界中から10秒以内で解ける全ての問題を集める」世界なので
- 別に人が作った問題を解くのも面白いじゃん…
- 意味のないことをしている
- 競技プログラマのコード速度を見たことがありますか？めちゃ早いよ。
- 無意味だからやらない、と人事の人が言っていると、優秀層エンジニアが逃げる。
- 強いエンジニアは往々にして「技術が面白いから技術をする」ので、そういう優秀層エンジニアが逃げる。
- お金が儲からない
- コード速度が上がることはお金が儲からないと思っているの？
- お金が儲からないからやらない、となると優秀層エンジニアが逃げる。
- 社会貢献できていない
- プログラミングの能力を高めるのが社会貢献に繋がらないなら、仕事ばっかりやって成長しないゴミエンジニアを応援してそう
- 承認欲求に取り憑かれている
- それは真逆で、やると自信がどんどんなくなってくるので、承認欲求は満たされない。
- 実績を求めるという話もある。競技や資格以外に求められる人はやらなくてもいい
- レートを見ればどれくらいのコーディング能力があるか一目瞭然なので、就活にも役に立つみたいになっていく。
アルゴリズムの勉強必要性 †
- 特にこのページはアルゴリズムのまとめ。
- アルゴリズムが判ってない、計算量が判ってないから、「○○は遅いからダメ」みたいなのをあらゆる状況で言っちゃう人は割と多い。必要なところだけ早くすればいい。
- 以下の問題を何とかしたいから勉強しているのだけど、キリがないという気分
- 正しいと信じてるプログラムが間違ってるケースを減らしたい
- 脳内でこうやればできる、というところと実装の溝を減らしたい。実装を単純作業にしたい
- トップレベルの人でも普通知らない、非自明かつ一般的なアルゴリズムを使えるようになりない
- 典型なのに知らずに解けないケースを減らしたい
- 上位者の提出の早いコードを読んで学ぶ必要性
- コンテスト中だけでもいいから、「ちゃんと最後まで問題に向き合う」というのは大切
- 「サンプルが通った時の提出前の回答の信頼度」みたいなのもまるで計れないと、テストの数をどれくらいにすべきかの直感がなくなる
- 実装に時間がかかった問題は、ちゃんと上位陣のコード読んでリファクタリングしないと、実装力の伸びは鈍化する。ちゃんとシンプルな実装を学ぶのとても大切。
マネタイズ †
- Atcoder 定期コンテスト1回で100万-200万（AGCだと1コンテストで15万円くらいを業務委託で払っている？）, マラソンも1問30万くらい？オンライン一発だと150~200万、予選＋決勝方式だと300~400万くらい
- Codefestivalは異常なので一回問題だけで1000万以上
- Topcoder
練習方法 †
- 解いた問題数を増やすのは良い事なんだけど、解いた問題数を増やすためだけに、簡単な問題を解きまくるのってすげえ時間の無駄
- Codeforces
- 黄色の人とかがCFのBCD埋めるのは典型力と非典型力と実装力が程よくついていいと思うけどE埋めは本当に虚無なのでやめた方がいいと思う
- Eには典型重実装がたくさんあって不毛
- AOJ-ICPC
- 多くの人にはオススメできない気がしてきました。
- 自分はすごい実力ついたと思っていたけれど、赤になってから実装力不足が目立ち始めたから始めただけ
- 赤になるまでは質の高い問題をひたすら解くべき
コンテストの目的 †
- コンテストの役目は、優秀な人材を育てることではなくて、優秀な人材と、そうでない人材とを容易に見分けることが可能な場を提供すること
- 実は緑くらいあれば、ウェブ開発とかは普通にできる。
外部の人への説明 †
- 「単体テストは用意されているけど、単体テスト専用対策による不正がされないように、不正解ケースを教えてくれないシステム」
参考 †
ライブラリ †
|
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
