はじめに - アルゴリズムとデータ構造大全
はじめに このドキュメントは，主に競技プログラミングで出題される問題を解く際に利用できるアルゴリズムやデータ構造をまとめたものです．特定の問題にはあまりフォーカスしないため，問題を解く際の考察の仕方等の内容はありません．詳しく，正確に，分かりやすく書いていこうと思っています． このドキュメントは執筆途中です． 想定する読者 C++を用いたプログラミングに慣れている方を読者として想定しており，C++言語の仕様や，文法にはあまり触れません．また，計算量という用語についても説明しません．ただし，償却計算量など，計算量の見積もりが複雑なものについては必要に応じて説明します． コードについて このドキュメントで登場するコードは，可読性向上のため，以下のようなコードがファイルの先頭に記述してあることを前提としています．また，適切な問題を用いてコードの検証がなされている場合は，コード周辺にのように，検証
Low-Level Academy
In this course, you will learn how to work with the UDP and TCP internet protocols in real-world scenarios. You will apply your skills to build small, fun networking applications in Rust — right in your browser! No previous knowledge of network programming is required, but we assume that you are familiar with Rust syntax. If you’re not, that's fine too! You can read The Rust Book and learn by prac
【AtCoder】普通の人である私が緑になるまでにしたこと - Qiita
こんにちは、Kotaです。 ご閲覧いただきありがとうございます！ 昨日開催されましたAtCoder Beginner Contest 176でレーティングが緑になりました！ ついに！入緑しました！！！ ここまで長かったのでめちゃくちゃ嬉しい😄 kota0501さんのAtCoder Beginner Contest 176での成績：1754位 パフォーマンス：1241相当 レーティング：754→815 (+61) :) Highestを更新し、6 級になりました！#AtCoder #ABC176 https://t.co/ONTPDcUzzV pic.twitter.com/jQKX7gwBsa — Kota (@kota0501_orca) August 22, 2020 要約 競プロ開始してから7ヶ月弱で緑になったよ！ この界隈は人外な人が多いよ！(人外についての説明は記事内で！) だ
プログラミング上達したい人に繰り返し読んで欲しい4冊改訂版｜erukiti
プログラミング上達したいんだったら、四の五の言わずに、 ・クリーンアーキテクチャ ・レガシーコード改善ガイド ・アジャイル・サムライ ・リファクタリング 系のどれか を、全部最低5回読み返して欲しい。それでプログラマとしては圧倒的に成長できるんだから、マジで読んで — Next.js + Hasura 最速プロトタイピング本 @技術書典9 出す予定 (@erukiti) July 27, 2020 先日、こういうツイートをしたらバズってしまいまして。これらの本を理解できるまで読みこめばプログラマとして成長できますよーというもので、 ・ クリーンアーキテクチャ ・ レガシーコード改善ガイド ・ アジャイルサムライ ・ リファクタリング 系のどれか（例えばリファクタリング第二版） の4冊を挙げました。いろいろな人の感想を読んで、補足が必要そうだなと思ったので記事として書きなおしています。 この
テストの説明に安易に「正しく」とか書かない - Object.create(null)
みなさんテストは書いていますよね. 書いていなければふりだしに戻る. 例えば関数 add に対して, 以下のようなテストコードがあるとします. describe("add", () => { it("正しく計算できる", () => { expect(add(1, 2)).toBe(3); }); }); よさそうですね? もしよくないと思うのであればここから下は読まなくても大丈夫なくらい理解している方だと思います. 続いて関数名を変えただけのこちらをどうぞ. describe("sub", () => { it("正しく計算できる", () => { expect(sub(1, 2)).toBe(3); }); }); なんだか明らかに間違っている気がします. もしこのテストが通過してしまったとき我々はどうすればよいのでしょうか. 考えられるパターンは 2 つあります. 実装もテストも正
コードを書く際の指針として見返すサイトまとめ - Qiita
お勧めの記事がありましたらコメントなどで教えて頂けると幸いです。 Guidelines プログラマが知るべき97のこと 技術的負債 不慣れなコードベースで短期間に生産性を高めるための7つの方法 何も知らない人を育てるために(新人教育情報キュレーション) 保守開発に開発者として入って困ることのまとめ(実体験) 技術系の名言まとめ++ 真似をする前にバッドプラクティスかどうかを調べてみよう 読まれない名著「人月の神話」を本気で読み込んでみた（まとめ） 技術的負債とどうやって戦うか 楽しいコーディングのための CUPID - SOLID 原則に対するアンチテーゼ エンジニア基礎(新人研修資料) Coding Style モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう 関数名や変数名に使えそうな動詞・名詞・形容詞のメモ Naming -名前付け- DRY原則をもう一度 -コンカレント
良いエラーメッセージの書き方 - Qiita
エラーには大抵「エラーメッセージ」が付いています。 自分は過去に、エラーメッセージの内容を雑にしてしまい後悔することがよくありました。 その経験から、良いエラーメッセージの書き方を考えました。 エラーメッセージを2つに分類する まず、エラーメッセージといっても次の2つのパターンで大きく異なってきます。 (1) ユーザーが見るエラーメッセージ (2) 開発者が見るエラーメッセージ (1) ユーザーが見るエラーメッセージ 内部実装のことは書かないようにする
意外と忘れがちな優秀なプログラマーになるための10のコツ - jfluteの日記
月並みなものは、ここでは話題にしません。よく「忘れがち」なものにフォーカスします。 コツ1. 土日という概念を捨てる 土日は、土日ではなく、たまたま仕事に拘束されない平日です。自分を高めるトレーニングに時間を使えます。 とはいえ、普段の生活もありますから、土日を全部使うのはさすがに厳しいかもですね。なので「半分だけ」とかが現実的でしょう。 半分なので24時間。土曜12時間、日曜12時間。もしくは、土曜16時間、日曜8時間。これなら日曜日はけっこう生活に時間を費やせます。 常にパソコンの前じゃなくても良いでしょう。出かけながらプログラミングしたっていいです。トレーニングになっていればいいので、書くプログラミングだけとは限りません(コツ6を参照)。 ... 「そっか、あのプライベートの用事を削れば、あの機能その日にうちに実装できるかも、よし！」 常に "削れるプライベートを探す" 習慣を。 コ
大阪市プログラミング教育協力事業者募集の件
本当は質疑の内容とか、市政報告会のこととか、色々書かなきゃいけないことがたまっているのですが。 でも、今日だけはこれを書かせてください。 この案件、メチャクチャ炎上しました。 検索してもらえばたくさんの記事がヒットします。 とりあえず、昔から2ちゃんねるにお世話になっている僕は、ひろゆき氏の記事でもリンクしておきますかね。 ▶ひろゆき「炎上させても“誰得？”なのに」――大阪市の“無償で協力募集に非難の声”を不思議に思う この問題についての経緯などを知りたい方は、下記リンク先を見れば大体わかると思います。 ▶「大阪市：平成29年度小学校段階からのプログラミング教育の推進に当たり協力事業者を募集」についてICT戦略室と教育委員会の見解 上記見てもらえればわかるのですが、僕が叩かれまくってます。 まず最初に言いたいのは、 「僕が作った企画じゃないですよ！？」 というところですね。 正直、教育委員
逆FizzBuzz問題 (Inverse FizzBuzz) - 平々毎々（アーカイブ）
just another scala quantを日本語にしました。 ちなみに、私の解はこちらに。 最初の解答 はてブに書いた解答方針、Inverse Fizzbuzz (FizzBuzzの逆関数) - Qiita - 与えられた範囲内のすべての解を数え上げてます。 もっと簡潔な解答 逆FizzBuzz問題 解きなおし - Qiita それでは、問題の日本語訳をどうぞ。 逆Fizzbuzz問題 2012年ではなく、2016年のお話。 世の中は大して変わっていない。 OOPと書き換え可能なオブジェクトによって何度もひどい目にあった後、世界はやっとのことでJohn Hughesの考察が正しかったことに気づき、関数型プログラミングに移行した。GoogleはTypesafe社を買収し、ScalaがAndroid上でネイティブに動作するようになっている。Googleに負けず劣らず、AppleはHas
Webプログラマと数学の接点、その入り口
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
Ruby超入門（前編）
こんにちは。 この連載では、ちょっと変わったRuby入門を書いていきます。 想定読者は、Rubyを学びたいプログラミング初心者です。 Ruby以外の言語でプログラミングしたことがあると理解がはかどると思いますが、 Rubyを知らなくてもわかるように、なるべく丁寧に説明していくつもりです。 Rubyをある程度知っている読者には、最初の数回は退屈かもしれませんが、 回を重ねていくにつれ、より深くRubyを知ることができるはずです。 Rubyとは？ Rubyは「プログラミング言語」です。 プログラミング言語とは、コンピュータにやらせたい仕事を書くための言語です。 つまり、Rubyを覚えて、Rubyでコンピュータへの指示を書けば、 コンピュータはその指示を実行してくれます。 この指示書のことを「プログラム」と言い、特にRubyで書かれたプログラムを「Rubyプログラム」と言います。 ところで、Ru
プログラミングする時にイケてない関数・変数名をつけないために覚えておきたいネーミングルールの良記事＋ツール8選｜TechClips[テッククリップス]
プログラミングをしていて関数や変数名をつけるときに、毎度のことのように考えるのが手間、とはいえ、適当なネーミングでも違和感あるし……。なにより他のエンジニアが見たときに「なんだこりゃ、分かりにくい。」というのは避けたいところ。 そういったプログラミングにおけるネーミング問題を解消できるツールや情報をまとめてみたので、是非、参考にしてみてください！ 1. codic codic ネーミングと言えば、一度は使ってほしいド定番の「codic」。簡単に言うとネーミング辞典サービスで、日本語の動詞で終わるように文章を入力するとプログラミングでよく使われるようなネーミングを提案してくれます。さらに単語のニュアンスも表示してくれるので、和英辞書のような使い勝手というのが分かりやすいでしょう。さらに、ユーザー登録をすれば、辞書として単語を追加していくといった活用も可能。考えずとも最適なネーミングが生成でき
![プログラミングする時にイケてない関数・変数名をつけないために覚えておきたいネーミングルールの良記事＋ツール8選｜TechClips[テッククリップス]](https://cdn-ak-scissors.b.st-hatena.com/image/square/d4a810ad432ced691ee6614ce4293b93b9e7c1ea/height=288;version=1;width=512/https%3A%2F%2Fobject-storage.tyo1.conoha.io%2Fv1%2Fnc_261159609ad84809af5afcb9e5f56abb%2Ftechclips%2Fimages%2F66%2Fimage.jpeg)
Kotlinに対する雑感 | さにあらず
1.0.0 がリリースされました。やりましたね。 僕の観測範囲内に見えることが増えてきたので、興味本位で少しずつ触っています。 まず、ブラウザだけで試せるチュートリアルが大変素晴らしいので、Kotlin が肌に合うかどうか確認するといいですよ。 Kotlin Koansjs で実装されたエディタなのにシンタックスハイライトだけでなく、入力補完がガンガン効くので凄く良い。 僕の理解#大体 3 日くらいかけて言語仕様やマニュアルの類を読みながらチュートリアルをこなした結果、 Kotlin は 安全な次世代の Groovy であるという理解に到達しました。 僕が Groovy に対して持っていた不満は、大体以下の通り。 ランタイムがデカ過ぎるgroovy-all-2.4.6-indy.jar が 6.5Mバイトコードエンハンス等の危険な黒魔術がカジュアルに動く型がありそうで、実は殆どない型があま
プログラミングスタイルガイドのスタイルガイド - Qiita
本文書は、プログラミング言語向けのスタイルガイドに向けたスタイルガイドである。 本文書へのフィードバックはQiita上のコメントにて受け付ける。 構造 対象を明確にする そのスタイルガイドがどのような状況のどのような対象に向けたスタイルガイドであるか規定すること。 状況や対象は広すぎてはならない。 理由: 対象はスタイルガイド記述者には自明かもしれないが、似て非なる言語に誤用されたり、特定分野のアプリケーション向けスタイルガイドが他分野のアプリケーションを理不尽に拘束したりすることがある。これを防ぐべきである。 良い例: 「本文書はRuby on Railsアプリケーション向けのスタイルガイドである」 「本スタイルガイドはX社におけるRubyプロジェクトに適用すべきスタイルを規定する」 悪い例: (何も書かない) 「本文書はX社におけるすべての開発に適用される ... 述語メソッドや述語関
クーポンコードの打ち間違えを防ぐために工夫した話 - クックパッド開発者ブログ
こんにちは。会員事業部ビジネス開発グループの高田です。 クックパッドは今年、株主優待制度として、プレミアムサービス一年間無料クーポンを贈呈しました。本エントリではクーポンコードを打ち間違えて、意図せず他の人のクーポンコードを使用するのを防ぐために工夫した話をご紹介します。 はじめに クーポンコードは入力のしやすさを優先して数字だけの文字列にしました。はじめは rand 関数を使って生成しようとしていたのですが、数字の打ち間違えや順序間違いで、意図せず誤使用してしまうのを防ぐためにチェックサムを加えるのがいい、と同僚から助言をもらいました。 いくつか調べて見たところ、Luhn アルゴリズムが上記を満たしていたので利用することにしました。 Luhn アルゴリズムの利用 Luhn アルゴリズムとは、誤り検出のためのチェックサム符号で、1 桁の間違いや隣接する数字の順序間違いを検出できるという特徴
エンジニアのための英語
本日、以下のような文章を読んだ > I was suffered from ~ ~の部分には遭遇した諸問題について書いてあったので、この文章は「苦しめられた」と言いたいのだと推察できた。ただ、残念な事に、be suffered というのは多分現在ではほとんど使わないし、意味が若干違ってくると思う（詳しくは検索してきて！） sufferと言う言葉は「苦しむ・被る」という意味なので、受け身にすれば「苦し『められる』」という意味になるのではないか、というつもりだったのはないかと推察するが、sufferはすでに受け身の意味なので、I sufferですでに何かに苦しめられているのであり、これをさらに受け身にする必要はない。 > I had to suffer from having to deal with spaghetti code とかなら、「スパゲッティコードに立ち向かわなくてはいけなかった
サイト更新終了のお知らせ - ワザノバ | wazanova
読者のみなさまへ Wazanova News の運営を行ってきた米国法人 Wazanova, Inc. を清算することにともない、当サイトの更新を終了いたします。1 年半にわたりご応援いただき、まことにありがとうございました。 特に、Gittip (Gratipay) を通じて継続的にご寄付いただいた方々に御礼申し上げます。2015年 3月上旬より寄付の受付を終了し、お預かりしたお金は全額 Gittip サイトの運営者に寄付するよう設定してあります。 既存コンテンツは当面の間、従来の URL でも閲覧できます。Jshiike からのご挨拶にもある通り、一部を個人ブログサイトにも移行しており更新も予定されていますので、こちらについてもご愛顧いただければ幸いです。 今後もメンバそれぞれ、IT / ソフトウェアエンジニアの世界に貢献していければと考えております。引き続きどうぞよろしくお願いします
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
読んで良かった基礎知識の入門書 - Qiita
クソコードの測り方
