はてなキーワード: 競技プログラミングとは
コンピューターサイエンスや競技プログラミングに懐疑的な人たちは決まってソートのアルゴリズムがどうとか言う傾向にあるけど、たしかに増田の言う通り、ソートなんて自力実装するような時代ではないからその辺は無視してもらって構わないとは思う。
でもソートについて「ソートだけをして終わり」なんて実装をすることはなくて他の処理と組み合わせて存在しているものじゃない?
たとえば「配列をソートしてからサーチする」「ソートしていない配列に対して都度サーチする」「配列をハッシュマップに変換してからサーチする」要求に対してどれが効率的かみたいな判断は要る場面はあるでしょう。
「今書いているコードが呼び出す機能の一つ一つがどういうふうに書かれているかがわかったとして、一体何が嬉しいんだ?」
たとえば配列に対する.find() 的な関数があると思うが、これは「配列を先頭から順にチェックして、指定のものを見つける」ような実装であることが多い。内部的には配列長に比例する時間がかかるループが書かれている、O(N)の関数。
これを自分が実装するコードのループ内で使うと、自分が書いたコード自体は一重のループにしか見えないが、実は二重ループになっているということがあり得る。
その処理がやけに遅いと思ったとき、「find()は標準の関数だから無罪!中身を見る必要なし!」って感じでスルーしてたらコードの全体像は永遠に見えないことになる。
とはいえ、勉強したくないものを無理に勉強する必要もないとは思うよ。
サンプルで実装してあげたものの一部改変などをしてもらうぶんには知識もスキルもいらないだろうし。
https://gigazine.net/news/20210302-hacker-reduces-gta-online-load-times/
JSONをパースする処理や、配列から重複を探す処理など、増田が言う通りラップされたものを使うだけでできることではあるけど、求められる出力を満たせる部品をただ並べただけではこういうダサいことが起こりうる事は知っていてほしい。
「時間あったらなにがしたいですか?」
何かアイデアくれ。
子供いるので泊りがけの一人旅とかは無理。仕事はIT系、仕事は嫌いだが何か作るのは好き。読書は嫌い。多少金がかかってもいい。
今考えてるのは
学歴がよくなくて、就職が困難だったので中小 SIer で働いていた。 (プライム案件を取ってこれる分マシらしい)
レキサルティ、レクサプロ、デパスのお世話になって続けてたけど、結局は薬でどうにかできず、辞めてしまった。
参考程度だけど、未経験の人が 300万 をもらうために、どのようなスキルが必要かを、まとめておく。
ちなみにどれくらいプログラムが書けなかったかというと、競技プログラミングで努力しても AtCoder の黄色になれず青色のままってくらい。
AtCoder でいう、初心者から抜け出せないという、要するにセンスがないということなのだけど、そういう人も居そうなので、参考までに。
未経験のプログラマに対して、これだけ要求されるのだから、未経験の人は覚悟するようにという指針を提供したいので書いた。
基本的に、損害を与えた場合には、それを作業者が補填するという誓約書を結ぶ。
要するに、捨て駒として扱って、失敗したら賠償しろ、という事になる。
このことを認識して、失敗しないように振舞ないと、連帯保証人含めて迷惑をかける事になる。
要するに、低賃金で未経験プログラマを案件にノーリスクで送りこんで、稼ぐための手段です。
基本的に PL (夢想家) → PM (御用聞き) → プログラマ という環境なので、プログラマが自分でディレクションして意思決定する必要がある。
例えば、下請けの場合は、PM の御用聞きの結果の WBS に合わせないと、顧客から DM で 瑕疵担保責任がどうとか言われる。
社内開発の場合は、PL の方から直接、長時間の叱責を受けなくてはならない。
そういう不幸を防ぐためにも、自分でディレクションして、PM の決めた実態を反映していない WBS に合わせて作業するスキルが要求される。
基本的に手戻りは個人の過失になってしまうため、手戻りしないように考え抜いて意思決定をする、というのが重要になる。
これこそ、ガクチカと呼ばれる、頑張れますというスキルなので、学生時代に頑張っておけばよかったなぁ。
こう見せたい、こう表現したい、という事を伝えるには、必然的にデザインの知識が必要になる。
創造的思考とデザインは切っても切り離せない概念で、デザインとは創造なのだから、当たり前である。
ソフトウェアアーキテクチャも、ソフトウェア設計も、コーディングもデザインと言えるかもしれない。
顧客と 1:1 で話す事が DM でもボイチャでも突発的に発生するので、いつ、いかなる時でも論理武装していなければならない。
まぁ、顧客であったり PL であったりはキレるのが仕事なので、それに対して理路整然と説明する必要がある。
なんとなく、では納得しないし、すぐ損害賠償請求とかそういう話にいくので、答えられないと持ち帰りますとお茶を濁して、エマージェンシーになる。
後述する設計能力においても、課題を把握するための言語技術(言語化能力)は重要なファクターだと思う。
C/C++ のシステムプログラムはフレームワークが基本的に無いので、自分で概念を整理して、どのような変更、拡張があるかを考えて設計する必要がある。
この能力が弱いと、手戻りが発生しやすくなり、瑕疵担保責任を問われることになる。
読んだ本の中だと、ボブおじさんの本が、やっぱりしっくりくるなという個人的な感想がある。
UDP で送ってくるデータを受けて 24/365 で停止しない WebAPI への繋ぎ込みという簡単な作業があって、振られた。
リークしてはいけないという事で malloc は禁止で、グローバル変数を利用するという変なルールがあった。
Rust で書けばいいんじゃないかなと思ったけど、Rust 書くのもシンドイし、C/C++ で、しんどくて読みづらいコードを書いた。
あとで保守する人が大変そうだけど、そういうルールを決めたのは PL だしね。
なんか、特殊な PCI Express のカードからベンダーが用意している SDK でデータ引っこ抜いて Web API へつなぎ込む部分をやった。
一応、SDK の使い方をパラ見して 1 日で作ったので、別に負担じゃなかったけど、素人にやらせるんなとは思った。
当たり前だが、DB 作って RestAPI を生やすのは現代のプログラマにとって自然にできなければならない。
なので、新規開発のサブモジュールのバックエンドを任せられた。
だが、ORM の癖を把握したり、発行されるクエリを確認したりするのは、疲れる。 SQL を直書きするのはシンドイ。
結局 SQL を直書きすることにしたけど、あまりいい決断ではなかったと思っている。
それ以外は フレームワーク に乗ってしまっていいので、書き捨てる分には楽だった。
最近だと、TypeScript で Prisma 使うのが、型安全でよさそうだなと思っている。
デプロイを EC2 直でやったり ECS にしたりとしていたので、ベアメタルの知識が必要になった。
要するに systemd のいじり方とか、死活監視の仕方とか。
個人的には、クラウド嫌いなので、ベアメタルの方が安心できる。
Bind で権威DNS を管理して、postfix で絶対止めてはいけないメールサーバを管理するとかもあったけど、出来て当然ではある事だし。
未経験プログラマでも、月単価 100 万以上で顧客に請求してるんだから、会社はそりゃ儲けるだろうと思った。
会社が一人前の経験N年のプログラマといったら、その通りに振舞う必要がある。顧客に責任はないのだから。
当たり前だが、Webディレクション、Webデザイン、Webプログラミング, Webマークアップ は、全て作業者であるプログラマの仕事になる。
個人的には、これが分かれている理由が良く分からないけど、分けたい人がいるんだろう。
デザインで、CSSフレームワークを使うと、その色が出るという事で、全部 CSS は手書きしていた。
tailwind が出た現在では使っていればよかったなと思う。
結局、全く分からない中、手探りでデザインし、コードを書いて、顧客に 1 日 5 ~ 10 回リリースするという行為をした。
顧客は大手企業だったので、自社のエンジニアならもっと出来る、と叱責されまくったけど、だったら自社でやればいいじゃんと思った。
一応、今でもサービスは生きていて、ユニークユーザ数は上がっているらしい。
そして、焼き付け刃だったので、 WAI-ARIA を知らず、アクセシビリティへの配慮が足りない事が問題になってしまった。
これはなんとか保守対応にねじ込めたのでトラブルにならなかったけど、瑕疵担保責任と綱渡りだなと思った。
当たり前だが、リリースサイクルを短くしないと顧客はキレてしまうので、CI/CD を整えないといけない。
今は Github Actions とかあるけど、昔は無くて Bitrise が高いからみたいな理由で Azure Pipelines で CI/CD フローを構築した。
もう Multi Stage Pipeline になってるだろうけど、Release Pipeline が GUI からしか設定できないのが辛みだった。
当然だが、デプロイするためには IaC を整える必要がある。
これを知らずに、コンソールでポチポチしていたので、 IaC 出来てない事がバレた時に色々怒られてしまった。
本来はテストも自動テストを整えて、質保証をしてバグを減らさなければならない。
だが、テストを書くという手間を払えなかったので、人力テストしかできなかった。
一応、リグレッションテストを人力でやりまくったので、バグ発見曲線が結合テストでの IF 不一致しかない、という結果にはなったけど
自動化できれば費用が必要じゃなかったから、怠慢だと、責められてしまった。
未経験でも誓約書を盾に、振られた事全部を出来なくてはならない慣習があるので、プログラマはそんなに良い職業じゃないよ。
甘い考えで、プログラマになろうと思っているのなら、考え直した方がいいです。
元増田です。
なるほど。スクリーニングを突破した後に競技プログラミングが活きてくるのか。仕事に役立つとか考えず、完全に趣味でやってたけど、役に立つならよかった。
競技プログラミングやっているなら尚更都合がいい。書き忘れたけど、欧米企業はほぼ100%技術試験は出る。口頭での技術試験に加えてコーディングテスト。
コーディングテストは応募後、スクリーニングが突破できたら、期限内に成果物を提出するように、問題がメールで渡されることが多い。
問題はいろいろあって、こういうのを作ってってパターンと、競技プログラミング系が多い。前者のほうが多いけど。自分も海外企業応募するかーってなったら、その準備として競技プログラミングはやる。日々やれればいいんだけど、座学によるinputも大事というかそっちにも時間取られるんだよね。
休みの日にあなたは何をしているだろうか。 Youtube を見ている?アニメを見てる?競プロをしている?
お金をもらうわけでもなく自発的に行うそれらの活動は趣味と呼んでも差し支えないだろう。 人生を豊かにするためには趣味の充実が不可欠だ。 私は趣味は以下のような4つ種類に類型化できると考える。
体験型は体験することに価値を見出す。 登山や釣り、旅行、スポーツなどこれに該当する。
求道型は能力の向上に意味を見出す。 数学や競技プログラミングなどの学問的なものや将棋、筋トレなどが該当する。
また、消費以外の全てのタイプの趣味は求道型の要素を含んでいる。 スポーツや釣り、絵を描く、どれも能力の向上も重要な目的だろう。
しかし、それらは求道型とは異なる。 なぜなら多くの場合能力の向上自体が目的ではないからだ。 (もちろん人によって例外はある)
創作型は自分で何かを創作することに価値を見出す。 絵を描く、音楽を作る、小説を書く、編み物をする、歌を歌うなどがこれに該当する。
消費型は消費したコンテンツ自体に価値を見出す。 見た映画が面白ければ嬉しいし、つまらなければがっかりする。
私はこの4つのうち全てをバランスよく行うのが最適だと考える。 少なくとも現状は消費型に偏りすぎている人が多いと感じる。 私の場合で言えば YouTube を見すぎている。
消費ばかりをしていては人生は豊かにならないのではないかと最近私は考えている。 問題はそこじゃないとつっこみが入りそうだが。
(追記)
・機械工学は大学で学んだ。機械系4力学のさわりだけなら大体やったがもう忘れている。
・切削加工はけがき、フライス盤、ボール盤、くらいならできるが複雑な形状は作れる気がしない。そういえば旋盤は使わなかった。耐久性を考えなければ3Dプリンタでなんでも作れるらしいが、3Dプリンタは触ったことがない。
・CADは大学の演習でSolidWorksを触った程度。もうすっかり忘れている。手書きの製図とかは調べて思い出せば簡単な形状ならできるかもしれない。
・シミュレータはANSYSをマニュアル通り触った程度。動力学解析とか連成解析とか仕組みは全くわかっていない。
・電気工学はだいぶ勉強不足。簡単な回路図はチップの製品情報を睨めっこしながらINとOUTと接地をどうすればいいかくらいはわかったが、複雑なものになるとダメ。ArduinoとRasberryPiは買ってみたが埃かぶっている。論理回路の読み方はすっかり忘れているが調べれば思い出せると思う。
・化学系は全くの無知。大学受験で知識は止まっている。物性物理的なところも無知。
・数値計算はPythonやMatlabでちょっとできる程度。ライブラリを使った行列計算や簡単なニュートン法くらいなら書けるが、精度や速さが必要だったり複雑になるとダメ。解析は微分積分や常微分方程式を調べて思い出せばできる程度。測度論とか特殊な積分とかいわゆる大学数学的な道具が必要になる解析はできない。
・競技プログラミングはちょっとかじったがやめてしまった。むずかしすぎた。
・機械学習や統計はなんとなく知識はついているが、手を動かして何か作ったことはない。この前統計検定1級落ちた。
・バックエンドはSQLをそれなりに書いてとりあえず動くものなら書ける程度。可用性とかパフォーマンスとか考えられるレベルではない。JavaはJavaEEを横展開的に書いた程度。理解できている自信はない。保守性高めたりデザインパターン的に綺麗な書き方とかできない。C++は一瞬だけ触ったことがあるが、環境構築ハマった&謎のSegmentation Faultで苦手意識を残したまま。Go?Rust?なにそれおいしそうだね。
・クラウドはAWSをマニュアル通りに使っている程度。1から設計なんてできない。なのでAWSのソリューションアーキテクトを勉強中。AzureやFirebaseは触ったこともない。
・ネットワーク系とかセキュリティ系は全く勉強不足。応用情報をギリギリ合格できる程度の知識しかない。わかるようにはなりたい。
・フロントエンドはFlutterを勉強中。Flutterむずかしい、どんな言語でもそうだけどチュートリアルから業務レベルまでの乖離がありすぎてよくわからない。javascriptはjQuery一強時代にちょっと書いた程度。VueとかReactとかなにもわからない。TypeScript?なにそれおいしそうだね。
・ハード系だったりファームウェア系だったりコンパイラ系は何もわからない。わかるようにはなりたい。
全部中途半端だな、、、
人にオススメされたセレステ、とりあえずエピローグまで終わった。
エンドロールを見ているときの満足感がすごかった。やっぱこういうティーンエイジャーが悩みを超えていく物語は洋ゲーによくみる(※自分がプレイした中では)ストーリーでかなり好きだ。セレステの主人公マデリンはうつやパニック障害といった心因性の症状に苦しんでいて、自分を映し出す鏡であるセレステ山でこの悩みに立ち向かっていくことになる。
ゲームシステム自体はジャンプとステップを利用してステージをクリアしていくアクションゲーム。かなり死ぬけどすぐ手前から復活できて全くイライラは感じなかった。アクション自体は終盤まで対して変化しないけど、チャプターごとに独特のギミックが存在するので最後まで飽きもこなかったなあ。ステージの攻略には2段階あると思っていて、1段階目が解法をつくること。ここでジャンプして壁掴んでからステップを斜め上に入力・・・みたいな方針が立てば、後はそれを達成できるまで何度もプレイする。この考え方はAtCoder(競技プログラミング)みたいだな、とか感じたり。適切に解法を立てて攻略できたときに正解(AC)として認められる感じが。区切りの間隔が短いから途中まではできるのにどうしても最後のここで失敗する・・・みたいなことも無く、サクサクと集中してプレイできた。
ステージは一本道ではなく、高難度の寄り道があってクリアすると♡をもらえる。ただこの♡、集めてもあんまり意味がないみたいだからステージをしらみつぶしに探すのが嫌で積極的には集めなかった。そしたらチャプター8(エピローグの後の章)!!!!♡が無いとプレイできないっぽくね???特別集める必要はないんとちゃうんかい!!!!!!それだけ思いました。
ストーリーはざっくり言うとセレステ山の山頂を目指していくというもの。山登りは頂上っていうゴールが明確にあるからゲームのストーリーの柱として相性がいいなと思った。というのもストーリーだけで見ると「A Short Hike 」によく似ていたから。どちらも山頂に行くことで悩みを克服するんだけど、その悩みというのがA Short Hikeなら母親の手術、Celesteならパニック障害。どちらもなんかリアルで嫌な不安感でそれが山頂での景色を見たときの達成感を演出するためにものすごく効いてると思った。
エンドロールは山頂に到達した後のその後がずっと後ろに流れていて雰囲気がとてもよかった。ちょっと置いて行かれそうになった”もう一人の自分”が慌ててマデリンに走って追いつくところとかは、近付く別れを惜しんでるのかなとか考えてしまって悲しかった。エンドロールにこういったその後を描くのは「洞窟物語」と似ているな。自分が攻略したステージを背景に各NPCが思い思いに過ごしている様子はNPCとしてではなくその世界の住人として生きているようでなんか嬉しい。
チャプター8以降はやるか分からないけど、アクションとストーリーどちらもかなり好きなゲームだった。
Epic Games Storeの無料配布でプレイ