お勧めの記事がありましたらコメントなどで教えて頂けると幸いです。 Guidelines プログラマが知るべき97のこと 技術的負債 不慣れなコードベースで短期間に生産性を高めるための7つの方法 何も知らない人を育てるために(新人教育情報キュレーション) 保守開発に開発者として入って困ることのまとめ(実体験) 技術系の名言まとめ++ 真似をする前にバッドプラクティスかどうかを調べてみよう 読まれない名著「人月の神話」を本気で読み込んでみた（まとめ） 技術的負債とどうやって戦うか 楽しいコーディングのための CUPID - SOLID 原則に対するアンチテーゼ エンジニア基礎(新人研修資料) Coding Style モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう 関数名や変数名に使えそうな動詞・名詞・形容詞のメモ Naming -名前付け- DRY原則をもう一度 -コンカレント

はじめに 「プロジェクト管理ファイルについて」三部作の最後は、.ideaディレクトリについてです。無駄に長いので、もうオススメ設定を公開しておきます。 リスト1　オススメのHOME>/.idea/.gitignoreの例 *.xml !/codeStyleSettings.xml !/copyright/*.xml !/fileColors.xml !/encodings.xml !/gradle.xml !/runConfigurations/*.xml !/inspectionProfiles/*.xml /inspectionProfiles/profiles_settings.xml !/scopes/*.xml /scopes/scope_settings.xml !/templateLanguages.xml !/vcs.xml なぜ、こうしたかは本編のお楽しみです。 プロジェ

プログラミングの勉強にあたってよく言われるのは、「流行に左右されるような技術の尻を追いかけるよりも、土台となる技術を身につけることが大切」ということです。 例えば、ウェブブラウザで動くJavaScriptを書くときは、流行しているライブラリの書き方を暗記するよりも、 ブラウザがどのようにCSSやHTMLを解釈してスクリーンに文字や絵を描き出していく（レンダリングしていく）のかを理解することが大切です。 さもないと、ライブラリの流行が変わるだけで勉強したスキルが失われてしまいかねません。 データベースでも同じことがいえます。SQLの文法を学ぶことよりも、データベースがどのようにスケジューリングを行い、 どのようにデータを探索していくのかを学ぶほうが、パフォーマンス・チューニングのコツなどもひらめきやすくなるでしょう 1 。 「土台となる技術を身につける」を、もう少しちゃんと言い換えれば、「今

irxground 君が再考: GoF デザインパターンといふ記事を書いてゐるので自分もちょっとコメントしてみます。 基本的に irxground 君と同意見のところは省略します。 あと、GoF の本自体は私は読んでゐません。 (GoF のパターン以外のパターンに関する意見の方が長くなってますね……。) GoF のデザインパターン 生成に関するパターン Builder そもそも builder パターンは Java の String と StringBuilder の様に可変オブジェクトと不変オブジェクトを別のクラスに設計しなければならない言語でしか基本的に役に立たないパターンであり、C++ の様にキャストだけで可変オブジェクトを不変オブジェクトに変換できる言語ではこのパターンは無用なはずである。 Java が出る前の本でこれがパターンとして挙げられてゐたといふのが俺には不思議に感じられる

週末の午前中、カフェでアイスコーヒーを飲みながらふとポエムでも書いてみようかと思い立ってしまったので、ちょっと前からよく考えていることを書く。本当に思いつきで書くので乱文になる可能性が高いけどご容赦いただきたい。そもそもブログを書くこと自体が相当久しぶりだ。 僕ももう 30 をすぎて、プログラマの世界ではさすがにもう若手とは呼べなくなり、教育っていうのはおこがましいけど、まあ自分より若い人たちの指導みたいなことをやらないといけない立場になってきたからこそ、「いいプログラマとはどういう人なんだろう。この人たちはどういうことを学べたら幸せだろう。」ということをよく考えるようになった。そういう話をする。 プログラマは手段のスペシャリストである 世の中には目的・手段論みたいな論調が存在する。 「それは手段だよね。目的をはき違えたらダメだよ。」という話はいたるところでよく耳にするんだけど、僕はこれを

みなさんは何のためにプログラミングをしていますか？ 仕事のため、何かをつくるため。 それも良いけれど、「強くなる」ためにプログラミングしてみませんか。 様々なジャンルのプログラミングコンテストとまだ見ぬライバルたちがあなたを待っています。 今回はアルゴリズム/AI/機械学習/セキュリティ等の様々なジャンルのコンテストとその始め方について紹介したいと思います。 ※これはPyConJPでの発表を文字におこしたものです。が、Pythonの話は殆どないです。 プログラミングコンテストとは？ すべてのコンテストに共通する、「コンテストに参加する利点」 1. 自分と同じ問題を解いた、他の人の解法を知ることができる 2. 同じコンテストに出ていた、たくさんのライバルと知り合える アルゴリズムのコンテスト 問題1 問題2 TopCoder Single Round Match CodeForces AtC

今まで読んできた技術書の中で良かったものを挙げていく。 そろそろ本棚が溢れるので捨てる前に書き留めておく。 私は独学でプログラミングを始めたので情報系専攻の人には何をそんなという本も混っているだろうが価値は人それぞれ違う。 一応私自身について語っておくと学生時代はプログラミングに興味を持ちつつも数学科に進んだ。 しかしそこでもプログラミングへの興味は薄れず、色々本を読んだり同学年の情報科学科の真似をしたりしていた。 今思えば日本の精鋭たる東大情報科学科の人達に勝てる筈もなかったのだが学生時代に我武者羅になれたのは悪い経験ではなかった。 私が興味があったのは主にプログラミング言語そのもの、特にLispとその周辺。 何故本か 挙げていく前に1つだけ。Webに大量に情報がある今、何故本かについて説明したい。簡潔に言うと 文章が推敲されていて読み易い 1つの情報ソースに多彩な内容が載っている 巨大

以前に8ccというCコンパイラをゼロからひとりで開発していたときのログです。40日でセルフコンパイルできるところまで到達しています。日付はすべて2012年です。コードとヒストリはすべてGitHubで見れます。 3月4日 というわけでコンパイラを作っているわけだけど、1000行くらい書いたらそれなりに動き始めてきた。こんなのも動くし： int a = 1; a + 2; // => 3 こういうのも通る。 int a = 61; int *b = &a; *b; // => 61 文字列は文字の配列として扱っていて、配列をポインタに成り下げる振る舞いも実装しているので、こういうのも通る。関数呼び出しもある。 char *c= "ab" + 1; printf("%c", *c); // => b 前回もこのあたりはがんばって実装したからここまで作るのはわりと単純作業かも。二回目だから配列とか

まえがき 今回書く内容は、ある程度経験あるエンジニアでも、陥りがちなものに絞って書いてみたつもりですので、[重複コードは書かない]などの超あたりまえの事は書いていません。 2017/03/16 最近よく見られてそうなので１つ追記[そもそも継承するな!!!] そもそも継承するな!!! 継承するのは、どうしようもない場合のみにしてください。 その前に、strategyパターンや、compositeパターンなどの他のやり方を考慮してもなお、継承するのが妥当である場合のみにしてください。 基本的に継承しないほうが、スケーラブルだし、テストコードも容易にかけます。 継承はis-a関係 「あー、継承ね。はいはい」で飛ばしてんじゃねーよ。 いやマジで!!! ほぼ全てのエンジニアは[is-a]が何か知っています。 というのも全てのオブジェクト思考の書籍には出てくる概念だからです。 しかし、私の経験上この概

あなたの好きな言語は何ですか。そして、あなたの好きなアルゴリズムは何ですか。 好きな言語があると、その言語でどんな問題でも解決しようとなりがちになります。その言語を極めるのは素晴らしいことですが、その言語や似たような言語でしかコードが書けなくなったり、他の言語に対して見向きもしなくなってしまう可能性があります。 勇気を出して新しい言語にチャレンジしてみませんか？色々な言語に挑戦してみませんか？ 何から始めればいいか分からない。次にどの言語を学べばいいか分からない。いま特に何も困っていない。何でも得意な言語で書けてしまう。そういう人が多いのではないでしょうか。 新しい言語にチャレンジするきっかけを作る一つの方法は、ある特定のアルゴリズムを一つ決めて、あらゆる言語で実装してみることです。解く問題が大きすぎると力尽きてしまうので、せいぜい20〜30行程度で書ける簡単なものが良いでしょう。大事なこ

note.mu なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、 まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける（当たりのつけかたにもいろいろあるのだが後述） 土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりする この方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う（エディタの undo でせっかく書いたコードを失わないため） 道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッ

English

私はプログラミングは結構自信があるんですが、他の人の作業をつぶさに観察したことがあるわけでもないので、自分で当たり前だと思っているコーディングの方法が他の人にとってはそうではないこともあると思ってます。上手い人がどういうふうにしてプログラムを書いているのか知りたいんですよね。 逆に私はどういうふうに書いているかちょっとまとめてみました。自分はこうしている、というのがあったらぜひ教えてください。 まず私の場合、ゼロからコードを書くよりも現在のプロジェクトのためのコードを書くことのほうが多いので、コードを書くというのは既存のコードに変更を加えることがほとんどです。既存のコードに手を加えるときは、新機能追加か、リファクタリング（動作は変えずにコードをきれいにすること）のどちらかになるわけですが、まず前者をどうしているかどうかをできるだけ説明してみます。 まず必要なのは考えることです。よく知ってい

イントロ 例外処理を書くことはよくやっているのだけれど、その時の主軸となる考え方について、今までなんとなくで行っていた部分が多かった。 毎回考えるポイントは例えば以下のような疑問。 どこのレイヤーで、どこまで例外処理を行えばよいのだろうか？ どの例外をキャッチし、どの例外を伝搬させればよいだろうか？ 前提条件をチェックし、失敗した場合、例外を出したほうがよいか、nil, false を返すほうがよいか？ 例外をどういう単位でラップさせるのが良いだろうか？ 例外をチェインし過ぎると却って煩雑になる気がする。どうすれば良いのだろうか。 しかし、この辺りの話って、API の設計だったり、仕様の影響もあるので、都度対応が異なってしまうもの。 したがって抽象化して理解することが難しく感じた。 とてもよく使ってるし、とても大事な事なことなのに。 そんな今更な事で悩んでいた時に、Effective Ja

4月から予約開始してようやく先日届いたpythonの機械学習本 Python機械学習プログラミング 達人データサイエンティストによる理論と実践 (impress top gear) 作者: Sebastian Raschka,株式会社クイープ,福島真太朗 出版社/メーカー: インプレス 発売日: 2016/06/30 メディア: 単行本（ソフトカバー） この商品を含むブログを見る 宣伝文句としては、 原著『Python Machine Learning』は米国Amazon.comでベストセラー! 3つのカテゴリーで首位(2016/5/24時点) Data Modeling & Design/Data Processing/Neural Networks とのことだったので非常に楽しみにしていたのですが、土日にパラパラと読んだところ期待通りの良い勉強本だと感じました。本国amazonのベスト

はじめに 家帰ったら『主要じゃない200くらいのプログラミング言語の雑な紹介』書いてやるから待ってろ — NANAKASE Kotoko (@make_now_just) 2016年7月1日 このツイートがことの発端でした。元ネタは、 主要なプログラミング言語 5種類を徹底解説! - Programming share 主要なプログラミング言語8種をざっくり解説 - shi3zの長文日記 あたりです。上の方の記事の冒頭に、 現在プログラミング言語は、200種類以上存在していると言われています。(実際に利用されているプログラミング言語の数はその10分の1くらいです。) とあったので200言語解説してみようというわけです。 200言語の解説を書くということは仮に1言語1分で書いたとしても200分、つまり3時間と20分の時間がかかるわけで、まぁそれは無駄に時間のかかる作業になります。そうなると必

◆他の職業との比較が重要 以前、システム設計は専門職であるからには求められる適性があると指摘したが、そこらへんをもう少し具体的にしておきたい。 およそどんな職業向けであっても適性の議論になると、実務者にさえ「そんなスーパーマンってこの業界にいたっけなあ」と皮肉りたくなるような安直な理想像が描かれやすい。とくに論者が職業人として自信に満ち溢れている場合に、そのような議論になるのかもしれない。反対に、自分の職業生活にやけっぱちになっている論者だと「打たれづよさ」だの「何よりも体力」みたいな、わかりやすいが乱暴な議論になりそうだ。 重要なのは「他の職業と比べた場合に、とくにどんな素質が求められるか」、さらにその職業において「劣悪であることが致命的でない素質は何か」を示すことである。たとえば、しばしば耳にする「システム開発者にとってはコミュニケーション能力が重要である」という主張は却下される。なぜ