AtCoder での実力アップを目指そう！ ～競プロ典型 90 問～ - Qiita
競プロにおける「上達の壁」 そこで私は、主に以下の 3 点が競技プログラミングにおける上達の壁になっているのではないかと考えています。 基礎的なコーディングの知識。for 文・条件分岐・配列などを使った基本的なプログラムが書けるかどうか。（レーティング 1～99 程度） 競プロで戦うために必要な、最低限のアルゴリズムや数学の知識。例えば二分探索・動的計画法・グラフ理論・逆元といったものが挙げられる。（レーティング 100～1199 程度） アルゴリズムや数学的知識 [2. で扱ったもの] をどうやって実際の問題に応用するか、考察面・実装面両方含めた典型テクニック。（レーティング 200～1999 程度） 今はどの壁が問題か？ 現在、1. と 2. についてはかなり教材が整備されており、例えば 1. のプログラミングの基本を学ぶにあたっては、 C++入門 AtCoder Programmin
Value Objectについて整理しよう - Software Transactional Memo
Value Objectとは何であるか? マーチン・ファウラーのPatterns of Enterprise Application Architecture(PofEAA)やエヴァンス・エリックのDomain Driven Design: Tackling Complexity in the Heart of Software(DDD)が原典であるが、PofEAAではこう切り出している。 When programming, I often find it's useful to represent things as a compound. プログラミング時は物をcompound(合成物)として表現すると便利なことがしばしばある。 例えば2次元空間上での座標のように複数のメンバ(属性)を持つ物は便利である、と。しかしそれらを比較する方法は一意ではない、そこで Objects that a
GoF デザインパターン チートシート - Qiita
ここまで読んでくださった皆さんに、ちょっとしたクリスマスプレゼント。マンガでわかる GoF デザインパターン 23 種チートシートです。これでもうデザインパターンは完全にマスターしましたよ。やったね! (注: ここからはあとがきポエムです) ところでみなさん、せっかくデザインパターンを学んだので、これを使ってプログラムを書こう、チートシートがあるからなんでも書けそうだぞ、なんて思っていませんか。ダメですよ。そんなことしたら 2000 年前後に起きた失敗を繰り返してしまいます。 実は GoF のデザインパターンは、ビジネス的には成功したけど、教育には失敗しました。最初に出版された本に「オブジェクト指向における再利用のための」という肩書が付いていましたが、これが本当に良くなかった。 あの頃 (ポール・グレアムが LISP と Ruby を褒めるまで) は、「オブジェクト指向様こそが良い設計のす
システムの複雑さはどこから来るのか – Out of the tar pitを読む - Uzabase for Engineers
Uzabase Saas Product Divisionフェローの矢野です。 この記事は、Rich Hickey（プログラミング言語Clojure作者）のプレゼンテーションSimple Made Easyへと繋がっていく、Ben MoseleyとPeter Marksによる「Out of the tar pit」というシステム設計について論じた論文の内容について説明したもので、ユーザベースのSaas Productでのテック発表の一つとしてプレゼンしたものを、ブログとして再度まとめたものです。プレゼン自体は25分くらいでしたので、おそらくこの記事の方がプレゼンよりも詳しいと思います。 ソフトウェア危機 ソフトウェアは本質的に複雑 ソフトウェアの複雑さはどこから来るのか？ 複雑さは、別の複雑さを産む 複雑さを分類する 本当に必要な複雑さと、そうでないものがある どうやって複雑さを扱うのか
運用に耐えられるコードを書くために - Magnolia Tech
オブジェクト指向とか、DDDとか言う前に、「落ちる時は速やかに落ちる」「原因がきちんと解析できる情報を出す」「リトライポイントが用意されている」「最終的な結果の正当性、整合性を確認する方法が用意されている」っていうコードをですね.... https://t.co/I5bIfhZYN8— magnoliak🍧 (@magnolia_k_) 2021年5月3日 異常系への対処がちゃんとできているコードが書けるようになってこそ一人前、みたいな、そんな価値観— magnoliak🍧 (@magnolia_k_) 2021年5月3日 いや、その手前の「つべこべ言わず、エラーが起きる可能性があるところは全てエラーコードをチェックする」なんだよ https://t.co/zmJBWR0ybX— magnoliak🍧 (@magnolia_k_) 2021年5月3日
アルゴリズム・AtCoder のための数学【後編：数学的考察編】 - Qiita
0. はじめに こんにちは、大学 1 年生になったばかりの E869120 です。本記事は、 アルゴリズム・AtCoder のための数学【前編：数学的知識編①】 アルゴリズム・AtCoder のための数学【中編：数学的知識編②】 からの続きです！！！ ※前編・中編を読んでいなくても理解できる、独立したトピックになっているので、ご安心ください。 後編から読む方へ 21 世紀も中盤に入り、情報化社会が急激に進行していく中、プログラミング的思考やアルゴリズムの知識、そしてアルゴリズムを用いた問題解決力が日々重要になっています。 しかし、アルゴリズム構築能力・競プロの実力は、単純にプログラミングの知識を学ぶだけでは身につきません。近年、数学的なスキルが重要になりつつあります。実際、私はこれまでの経験で「数学の壁で躓いた競プロ参加者」をたくさん見てきました。そこで本記事では、 AtCoder のコン
「DDD をやっている」とは
脳内整理のため、つまり僕のためのポエム 自分の中で理解が一区切りついた感じがしたので、コミットしておく 「DDD をやっている」に対して感じていた違和感 DDD を始め ( させられ ) て以降感じていた違和感がある 僕にはこんなフレーズが頻繁に聞こえていた 若干文面は違うだろうが、弊社に限らないニュアンスだとは思う これらに対するモヤっとを解消したいのでいろいろ考え直してみた 曰く「DDD だと仕様とモデルが一致する」 第一印象 いや、テキストと絵は一致しないっしょ？ そもそも一致ってなにさ？ 仕様書を Java で書くってこと？ それとも実装を日本語でするってこと？ 曰く「DDD だと業務の文章でコーディングする」 第一印象 業務の〜もなにも文章は全部日本語じゃん？ そもそも、じゃあ DDD でなければ何の文章で実装していると仰るの？ 曰く「DDD だと変更に強い」 第一印象 DDD
現代のオブジェクト指向の class の割れ窓化と宣言的プログラミング
オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだの Hatena の件。基本的には同意。ただちょっと切り口が違うので自分の意見を言っておく。ただ、このテーマで何度か書こうとして失敗していて、今回も成功しているとはいえない。 宣言的プログラミングの時代 現代の主流は「宣言的プログラミング」であると思っている。これはリソースの宣言と、その状態遷移の手続きや振る舞いの付与が中心にある。 宣言型プログラミング - Wikipedia その代表的な例がフロントエンドの React と、バックエンドの k8s で、どちらも時系列に基づいた状態の宣言と、フレームワーク側による状態遷移処理、 Reconcillation(調停) が基礎にある。 フロントエンドとバックエンドという両極端な世界で、この変化が起きたのがこの時代を反映したものであると思う。 例えば、jQuer
もうじき40代なかばを迎えるプログラマーの遺言（少し追記）(もうちょっと追記）(さらにもうちょっと追記)
世の中にはプログラマー35歳定年説というものがあった。昔からそんなのはないという人と、あるという人がいた。40代も半ばになったときに「あぁ、これが35再定年説の根拠か」というものがなんかちらほら見えるようになってきたので書いてみようと思った。 世の中にはものすごいプログラマーというのはやっぱりいる。なんなら死ぬまでプログラミング書いていられるという人たちもいる（ブラック的な意味ではなく）。そんな彼らからしたらプログラマー35再定年説とか意味がわからない都市伝説にしか映らないだろう。 だが、普通に職業プログラマとして生きている俺のような人からすると、この35歳定年説はかなりの真実味を帯びている。 だが、そんな俺でも40代半ばまで延命できたのはやはり技術革新のおかげかもしれないが、結局平均寿命が伸びただけとも言えるだろう。 まず、技術に対する姿勢が変わる。正直言うとプログラミングとかもうしたく
GitHub - ryanmcdermott/clean-code-javascript: :bathtub: Clean Code concepts adapted for JavaScript
Software engineering principles, from Robert C. Martin's book Clean Code, adapted for JavaScript. This is not a style guide. It's a guide to producing readable, reusable, and refactorable software in JavaScript. Not every principle herein has to be strictly followed, and even fewer will be universally agreed upon. These are guidelines and nothing more, but they are ones codified over many years of
ぼくはこうしてプログラミングを覚えた
オリジナルはココです。フェイスブックのエンジニアで史上ベスト３に入るといわれるEvan Priestley氏への質問「どうやってプログラミングを覚えましたか」に対する本人からの答えです。 手短かに言えば 何年もの歳月の賜物というか。ぼくはただひたすらプログラミングが大好きで、（フェイスブックで働いていた）過去４年間、ほとんど他のことをしていない。その前も２.５年ほどプログラマーとして働いていたし、そのさらに前も６年くらい趣味でプログラミングをしていた。ぼくは高校も大学も中退しているので、それで空いた時間もプログラミングに費やした。つい最近フェイスブックを辞めたけど、未だに起きている時間のほとんどはプログラミングだ。 もっと詳しく言えば 月並みだが、ぼくはちっちゃい頃からコンピューターが好きで、我が家にあったヤツで（最初はMac Plusで途中からIIsiになった）で散々遊んだ。８歳か９歳の
Martin Fowler's Bliki (ja)
ここは、Martin Fowler's Blikiの日本語翻訳サイトです。Martin Fowler氏本人の許可を得て公開しています。データはGitHubで管理していますので、どなたでも翻訳に参加することが可能です。 ※現在、移行中につき、Markdown形式になっていないものが多々あります……。PRいただけると大変ありがたいです。 API design / agile / agile adoption / agile history / application architecture / application integration / bad things / build scripting / certification / clean code / collaboration / computer history / conferences / continuous deliv
プログラミングできる人とできない人との間の深い溝 - masatoi’s blog
どうしてプログラマに・・・プログラムが書けないのか?を読んでいて出てきたので出展の一つを訳してみた。Separating Programming Sheep from Non-Programming Goatsの和訳。 プログラミングというものには向き不向きが強く出るということはわりと知られていると思うが、このエントリではプログラミングができるかできないかは比較的簡単なテストによって、プログラミングの訓練を始める前の段階で分かると主張している。どうしてプログラマに・・・プログラムが書けないのか?では、そもそもこの事前テストをパスしていないような人達までプログラマとして応募してくると言っており、その判定法として有名なFizzBuzz問題を挙げている。 追記（2019/2/28) 注意： なおこの論文はしばらく前に著者の一人によって撤回されたようです Camels and humps: a r
オブジェクト指向が0.05%も理解できない記事
尽く書を信ずれば即ち書無きに如かず 《孟子『尽心下』より》 イントロダクション 「最も理想的なオブジェクト指向を実現しているプログラミング言語は何か？」と問われたとき、君は何と答えるだろうか？ C++、Java、C#。君がそうだと思っているのは表面だけで、たぶん何もわかっていないのだろう。無知であることを知っているのであれば、無知のまま過ごした方が幸せなときもある。 Simula、Smalltalk、Ruby。君は本質をいくらか知っているようだから、引き返すなら今のうちだろう。深淵を覗けば、君もまた怪物にならざるを得ない。 JavaScript、Python、Go。君が真剣にそう答えるなら、私とは異なる真理に辿り着けたのだろう。君と私のどちらかが正しいのではない、どちらも常に正しく、どちらも常に間違っている。 Erlang、Elixir。君は既に答えを知っているようだから、この記事は全く以
プログラミングフォント Myrica
プログラミング用フォント Myrica Myrica （ミリカ）は、フリーなプログラミング用 TrueType フォントです。 視認性、判別性 が高くなるように、複数のフォントファイルを元に合成/修正しました。 フォントの特徴 多くの特徴をプログラミング用フォント Ricty から継承しています。 ASCII文字は「Inconsolata」が適用されます。 それ以外の文字には「源真ゴシック」または「Mgen+」が適用されます。 半角文字と全角文字の横幅の比が 1:2 に調整されています。 視認性の高い日本語文字 (半濁音など) が使用できます。 Rictyにない特徴 以下の文字にはヒンティング情報がありますので、Windowsでもクッキリしています。 ASCII文字はヒンティング付きの Inconsolata から、ヒンティング情報を継承しています。 平仮名と片仮名にもヒンティング情報を付
デザインの「悪い方がよい」原則 The Rise of "Worse is Better"
デザインの「悪い方がよい」原則 The Rise of "Worse is Better" rpg@lucid.com 日本語訳: daiti-m@is.aist-nara.ac.jp 私や Common Lisp と CLOS のデザイナーのほとんどは、MIT/Stanford 方式の設計に親しんでいる。 この方式の核心は、「正しい」やり方をせよ、という ことにつきる。デザイナーにとっては、以下の点をすべて正しく満たすことが 重要である。 簡潔性 デザインは実装と使用法の両面において単純でなければならない。 このとき、使用法が単純な方が、実装が単純なことより重要である。 正当性 デザインはすべての点において正しいものでなければならない。 誤りは許されない。 一貫性 デザインは一貫性を欠いたものであってはならない。一貫性を保つ ためには完全性は少しだけ犠牲にしてもよい。一貫性は 正当性と同
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
system-design-primer/README-ja.md at master · donnemartin/system-design-primer
あの日見た M V Whateverの Modelを僕たちは まだ知らない
SimpleとEasyは違う / Simple is not Easy
https://github.com/trekhleb/javascript-algorithms/blob/master/README.ja-JP.md
