新人プログラマーが検索すべき文字列、見るべき検索結果、検索すると辛い文字列

明日からの即席研修を経て ~~速攻ドナドナ~~ 開発業務に携わることになる新人プログラマーのみんな！
入門書を読んだだけでは中々身につかないグーグル検索の勘を身につけて定時帰宅しような！

# 検索したい文字列

ここに書いてある文字列を見つけたら、フレーズまるごと検索するだけで幸せになれる (ことがある)。

## Exception

プログラマーがクソみたいなプログラムを書いた時に出てくる定番メッセージ。ほとんどの場合 `NullArgumentException` みたいな文字列として画面の下の方に出てくる。

慣れてくると一瞥して理解できるようになるが、最初は難しいので素直に検索すべし。

## ORA

オッス `ORA-00059` みたいなメッセージ。ギャグではなく本当に `ORA-00059` が出てくる (平成生まれの新人にオッスオラ極右が通じるのかは敢えて考えないことにする)。

`ORA-xxxxx`の正体は「オラクルデータベース」というシステムでエラーが発生した場合の通知メッセージ。これが出るときには「 `ORA-00059` DB_FILES の最大値を超えました。」という親切な日本語も付いてくるが、オラクルの表示するメッセージは控えめに言って難解であるため「DB_FILESってなんだ？ドラゴンボールか？」などと考える間に検索する方が早い。

検索するときは基本的に `ORA-xxxxx` の部分だけで検索すれば良い。

## ceil, floor, round, substring, aggregate, その他なんでも英単語

よほど英語に心得のある人でない限り、「プログラミングの世界でよく見かけるけど、意味がわからない英単語」というものに出くわす。こういう単語については、プログラミングにおける意味より先に「そもそも英単語としてどういう意味か」を検索しておきたい。つまり `ceil java` ではなくて `ceil 意味` で検索する。

例えば `"ceil" = 天井` `"floor" = 床` という定義さえ分かっていれば、`ceil(-2.5)` は天井であるから上側に張り付いて `-2` になり、`floor(-2.5)` は床であるから下側に張り付いて `-3` になるのは全く当然のことであると納得できる。
もしここで短絡的に `"floor" = 切り捨て` などと暗記してしまうと `floor(-2.5)` が何になるのか想像もつかないことになる。


プログラミングの世界は基本的にアメリカ様のテリトリーであるため、頻出英単語を押さえることで全作業が楽になる。

# 検索結果に見つけたらチェックしたい文字列

検索結果にコレを見つけたら問題解決の可能性が高いと思われる文字列。

## Qiita

…と言いたいところだが正直なところ微妙である。最近は日記みたいな記事と金太郎飴みたいな入門記事が増えすぎだし、記事に対する第三者の評価もない。ストック数も内容のクオリティとあんまり関係がない。ただ良質な記事も沢山あるのでチェックはしておきたい。

## Stack Overflow

どん詰まりプログラマーが質問し、一流プログラマーが回答する神々しいサイト。我々ドサンピンも自由に閲覧できる。サイトの性質上「良くあるトラブルが質問され、一流の解決策が書いてある」というケースが極めて多いため、検索経由で使えるようになると尋常でなく役に立つ。

日本語版もあるのだが、英語で蓄積された膨大なログには敵わない。Stack Overflow 見たさに敢えて英語で検索することすらある (例えば「java ウィンドウが出ない」ではなく "java window show" で検索するとか)。

(自分で質問するなら日本語版が便利だと思います。使ったことないけど。)

## はてなブログ

日本のエンジニアは「はてな」が大好きである。検索上位に出てくる「はてな」の長文記事は概して品質が高い。間違っていると反論もつくことが多いので比較的安心して読める。

## slideshare

発表資料を公開するサイトのようなもの。とりあえず開いてみたうえで「閲覧数が多かったら熟読する」「見覚えのある著者なら熟読する」というパターンで使うと効率がよい。ただ本当に放置されているだけの資料もあるので、ちょっと難しいサイトでもある。

## プログラミング言語やシステムの公式サイト

いわゆる「ドキュメント」である。公式資料であるから「ここに書いてあることは仕様であり、ここに書いてないことは存在しない」と胸を張って断言できる。**Javaで可能だからC#でも可能なはずだ**等と繰り返す壊れたラジオの修理において最も有効である。

最近の製品・プロジェクトであれば、たいていの場合は公式ドキュメントが最も品質のよい資料である。そのため熟読したいところだが、文書の性質上なかなか専門的であったり、簡易的なまとめが無かったりして読解に時間がかかってしまうケースがある。

したがって、できれば読みたいので一応チェックするが、あまりにも難しそうなら他をあたる、というのも合理的な選択肢である。

# 検索する前にちょっと待ってほしい文字列

## Error: something is found

ごく普通の英語によるメッセージが出た場合、それは原則として「英語を読めば解決する」ケースと考えるべきであり、検索する前に熟読してほしい (除オラクル)。

「苦労せず検索しても成長しない、辛くても英語を読め」などという精神論ではない。ちゃんとメッセージを読まないことで、問題解決まで余計な時間がかかってしまうためである。

## [追加] 「失敗」「うまくいかない」

望み通りの結果にならないことを「失敗」とか「うまくいかない」と表現することは普通のことであり、日本語として何も間違っていない。だがプログラミングの世界では「どういう意味において思い通りになっていないのか」を表すために「エラー」および「例外」という言葉を使うことが多い。
そのため、ざっくり「うまくいかない」と検索するのではなく、「エラー」なのか「例外」なのか「エラーでも例外でもないけどうまくいかない」のかを把握してから調べる方がよい。

この判断は実に簡単であり、`Exception` と書いてあれば「例外」、 `Error` と書いてあれば「エラー」、その2つは書いていないけれども先輩に怒られたら「失敗」である。


## 解説記事の多い専門用語

主として「関数型言語」とか「関数型言語」とか「関数型言語」のことである。

ざっくりと知識を得たい、とりあえず話を聞いてみたいという場合はまだしも、もしあなたが自分の為に専門的知識を習得したいのであれば、「難解な概念を分かりやすく説明する！」という類の記事で満足してはいけない。
というかむしろ個人的には、その種の記事に甘んじるくらいなら「こんな断定口調はセンター試験なら100％間違いであり読む価値がない」と決めつける方がマシだとすら思う。知識がない状態で「分かりやすく説明」されても内容の正しさを評価できないからである。

もちろんその「説明」が本当に良質な説明である可能性はあるが、だからと言って地雷原を散歩していいことにはならない。正しい専門的知識が欲しければ、最終的にはじっくり時間をかけて評判の高い専門書を読むことである。なんでもネットで手軽に調べれば最高の答えが得られるという訳ではない。

# おわり

職場のインターネット検閲に気をつけて楽しい開発生活を！

「これも検索しとけ！」というネタがある各位は記事なりコメントなりで新人応援オナシャス！