give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

「エラーが出ました。どうすればいいですか?」から卒業するための記事をQiitaに書きました

お知らせ

Qiitaに「プログラミング初心者歓迎!『エラーが出ました。どうすればいいですか?』から卒業するための基本と極意(解説動画付き)」という記事を書きました。

タイトルにあるとおり、今回も解説動画が付いています。
というよりむしろ、解説動画がメインで記事の本文がオマケです。


プログラミング初心者歓迎!「エラーが出ました。どうすればいいですか?」から卒業するための基本と極意

最初は動画の内容を丁寧に文章として書き起こしていこうと思ったのですが、あまりにも時間がかかりそうだったので諦め、本文は要点をまとめるだけにしました。

Railsの赤いエラー画面(下図)に遭遇しても右往左往しないように、エラー画面の見方やスタックトレースの読み方、デバッグするときの心構えなど、プログラミング初心者が独学ではなかなか身につけられない「エラー解決のノウハウ」を解説しています。

f:id:JunichiIto:20160626052853p:plain

動画と合わせて読むと学習効果百倍です。
ぜひ動画と合わせて読んでやってください。

この記事を書こうと思ったきっかけ

この記事を書こうと思った直接のきっかけは、Qiita記事にも書いてあるとおり、スタック・オーバーフローで次のような質問を見かけたからです。

Railsで知恵袋のようなBA機能を実装しようと奮闘していますが、アソシエーションに対しての理解ができておらずに、はまっています。


(中略)


ActiveRecord::AssociationTypeMismatch (Comment(#70182053951140) expected, got Fixnum(#15377440)):
app/controllers/best_answers_controller.rb:5:in `best'


ここで、エラーがでるのですが、どうすればいいでしょうか?

よろしくお願いします。
 

Ruby On Railsで質問に対してのBA機能 - スタック・オーバーフロー

質問者の方は自分でエラーの原因と解決策を見つけられず、「ここで、エラーがでるのですが、どうすればいいでしょうか?」で終わってしまっています。

ただ、スタック・オーバーフローの質問を見ていると、この質問に限らず、昔から「エラーが出ました。どうすればいいですか?」系の質問を非常によく見かけるんですよね。
厳しい言い方をするなら「僕のデバッグ手伝ってください」と言っているに等しい質問が結構多いです。
よっぽど難しいエラーなら話は別ですが、そういった質問の場合、エラーメッセージやスタックトレースを読めばすぐに解決しそうなエラーが大半です。

「僕のデバッグ手伝ってください」系の質問を見ると正直な話、僕は回答者として「いや、それぐらいがんばって自分で解決してよ」と思ってしまいます。
なぜなら、そういった質問は以下のような点で、回答しても自分の頑張りがムダになりやすいからです。

  • 質問の内容がそのプログラム固有の問題になりがちなので、他の人が同じ問題に遭遇する可能性が低い(つまり、質問が解決しても質問者以外の人の役に立たない)
  • その質問に回答してエラーを解決したとしても、同じ人から「今度はこんなエラーが出ました。どうしたらいいですか?」という質問が繰り返し挙がってくる(自力で問題を解決するスキルが身に付かない)

なので、自分のデバッグは自分自身で解決してもらうのが一番いいと思っています。
(身近にいる人に質問するのは全然アリですが、ネットで不特定多数の人に回答を求めるのはちょっとね、という感じです。)

とはいえ、独学でプログラミングをやっている人だと、「わっ、エラーが出た!わからん!助けて!!」になってしまう理由もわからなくはありません。
プログラミングを始めたばっかりの状態で、こんな英語と記号の羅列で画面を埋め尽くされたら、そりゃ「なんじゃこりゃあ!!」になってしまいますよね。

f:id:JunichiIto:20160626055649p:plain

しかし、「なんじゃこりゃあ!!」とずっと言い続けているようでは、いつまでたっても一人前のプログラマになれません。
そこで独学&初心者プログラマの方も、なんとかして自力でエラーを解決できるようになってもらおう、と思ってこの記事を書くことにしました。(というか、前々からこういう記事を書こうと思っていました)

ちなみに、Q&A系のサイトで質問をするのであれば、「こういうことを実現したいと思っているんですが、どうすればいいでしょうか?」という質問の方が、他の人に役立ちやすい(=同じ疑問を持っている人が多い)と思います。

まとめ

というわけで今回はQiitaに投稿した「プログラミング初心者歓迎!『エラーが出ました。どうすればいいですか?』から卒業するための基本と極意(解説動画付き)」という記事を紹介しました。

基本的にプログラミング初心者向けの記事ですが、中級者以上の方でも「へ~、知らなかった」と思うようなテクニックや考え方が載っているかもしれません。
みなさん、ぜひ動画と合わせてご覧くださいませ~。


プログラミング初心者歓迎!「エラーが出ました。どうすればいいですか?」から卒業するための基本と極意

Software Design 2016年7月号に正規表現の特集記事を寄稿しました

お知らせ

Software Design 2016年7月号「手を動かして学ぼう正規表現入門」という記事を書きました。

f:id:JunichiIto:20160620071716j:plain

今回は誌面の第2特集をまるまる僕一人で書いています。(全27ページ!)
Software Design誌に寄稿するのはこれで3回目ですが、今回最長記録を更新しました。

f:id:JunichiIto:20160620071738j:plain

どんな内容なの?

今年の初めにQiitaで公開した正規表現記事がベースになっています。
ただし、ネットではなく雑誌なので内容を一部修正したり、新しく加筆したりした部分もあります。
また、プロの編集者の方にきれいに編集してもらったので、非常に読みやすくて理解しやすいレイアウトになっています。
(編集者のYさん、どうもありがとうございました!)

f:id:JunichiIto:20160620071818j:plain

「じっくり読んで理解する」という行為においては、PCやスマホのディスプレイよりも紙の本の方が向いていると思います。
「以前Qiitaで読んだ」という人も一度雑誌を手にとって、ディスプレイと紙の違いを体感してください。

(と、言いつつ、PDF版も発売中です → PDF版購入サイト

おまけ

妻のパン屋もちゃっかり誌面に登場していますw

f:id:JunichiIto:20160620071828j:plain

まとめ:言語やフレームワーク以外のスキルも身につけよう!

というわけで、このエントリではSoftware Design 2016年7月号に寄稿した「手を動かして学ぼう正規表現入門」という記事を紹介しました。
2016年7月号はこの他にも第1特集として、「プログラマが知っておくべきTCP/IP」という記事が載っています。

正規表現もTCP/IPも、「プログラミングスキル=言語やフレームワークのスキル」だと思い込んでいるプログラマは、ついないがしろにしてしまいがちな分野です。
特にプログラミングを初めて間もない人ほど、言語やフレームワークの派手な知識やテクニックにどうしても意識が偏りがちなのではないでしょうか。

しかし、いざというときに正規表現やTCP/IPのような言語やフレームワーク以外の知識を活用できるかどうかで、問題解決の時間に大きな違いが出てきます。
熟練したプログラマであれば、そうした知識も必ず身につけているはずです。

そう考えると、今回のSoftware Design 2016年7月号は技術者としてのスキルを一段レベルアップさせる、とても良い内容になっていると思います。

みなさんもぜひ一度お近くの書店で誌面をチェックしてみてください!

ソフトウェアデザイン 2016年 07 月号 [雑誌]

ソフトウェアデザイン 2016年 07 月号 [雑誌]

あわせて読みたい

Software Design誌にはこれまでに何度かお世話になっています。
以下は過去に掲載された記事の紹介エントリです。

Qiitaに動画付きの解説記事を2本投稿しました

お知らせ

Qiitaに「これであなたのQiita記事もランキング入り!?@jnchitoによる編集リクエスト解説(解説動画付き)」と「Devise confirmable用のテスト(フィーチャスペック)を書く(解説動画付き)」という2本の記事を投稿しました。

解説動画もあります!

どちらも解説動画をYouTubeにアップしています。
記事と一緒に見てもらうと理解度が100倍アップします。(たぶん)


これであなたのQiita記事もランキング入り!?@jnchitoによる編集リクエスト解説



Devise confirmable用のテスト(フィーチャスペック)を書く

「編集リクエスト解説」について

僕が実際に送信した「編集リクエスト」の内容を解説した記事です。
なぜその書き方だとダメなのか、どう直せばわかりやすくなるのか、といったポイントを説明しています。
もっと良い技術記事を書きたい!と考えているエンジニアのみなさんにオススメです。

f:id:JunichiIto:20160616050107p:plain

「Devise confirmable用のテスト」について

他の方が投稿されたQiita記事のサンプルアプリケーションに、僕がRSpecのテストコード(フィーチャスペック)を書きました。
そのテストコードの内容を解説した記事です。

モデルのテストは書けるけど、フィーチャスペックのテストを書くのは苦手、という人は結構多いです。
この記事を読むとフィーチャスペックをどう書いていけばよいのかが、よくわかると思います。

f:id:JunichiIto:20160616050721p:plain

また、動画の中ではRubyMineを使ってテストコードを書いています。
僕が使っているショートカットキーも画面に表示されるので、RubyMineをもっと使いこなしたい人にも参考になるはずです。

f:id:JunichiIto:20160616050908p:plain

まとめ

というわけで、このエントリでは僕が投稿した2本のQiita記事の紹介をしました。

最近、技術系、非技術系を問わず、誰かから質問や相談を受けると「これ読んでみて」と自分のブログやQiita記事のリンクを渡して終わり、という機会が増えています。

ブログやQiitaに記事を書く理由は「誰かの役に立ちたいから」というのが理由の一つです。
しかし、最近では「リンクを教えるだけで説明が終わる」ので自分の役にも立ってるなあ、と思うことが多いです。

文章をアウトプットしてるといろいろ役に立ちますね。
みなさんもどんどんアウトプットしていきましょう!