言語研修と練習問題 [プログラマー現役続行]
長年『プログラミング言語Java第4版』をテキストの一部としてJava研修を実施しています。また、『Javaプログラマーなら習得しておきたい Java SE 8 実践プログラミング』を用いたJava8研修も三回実施しました。
どちらの書籍にも練習問題がそれぞれ100問以上あります。研修の受講生は、それらの練習問題全部に取り組みプログラミングしてくることが求められています。来年2月から開講予定のGo言語研修ではテキストとして『The Go Programming Language』を使用します(実際には翻訳原稿)。そして、この本にも練習問題が100問以上あり、すべてプログラミングしてもらうことになります。
技術書を一人で黙々と学習する場合と、研修で学習する場合の大きな違いの一つは、全部の練習問題のプログラミングに取り組み続けられるということです。私もそうですが、一人で技術書を学習している時は、技術書に練習問題があっても、それをプログラミングして解くことは少ないです。
一人で学習する場合とは異なり、研修受講生は全員が同じ練習問題に取り組んでいるという状況が、結果として個々の受講生がプライベートの時間(休日など)に取り組み続けられるモチベーションになっているのだと思います。研修日には、全員の解答のコードを確認することはできませんが、他の受講生の解答を見ることで得ることも多いと思います。
どちらの書籍にも練習問題がそれぞれ100問以上あります。研修の受講生は、それらの練習問題全部に取り組みプログラミングしてくることが求められています。来年2月から開講予定のGo言語研修ではテキストとして『The Go Programming Language』を使用します(実際には翻訳原稿)。そして、この本にも練習問題が100問以上あり、すべてプログラミングしてもらうことになります。
技術書を一人で黙々と学習する場合と、研修で学習する場合の大きな違いの一つは、全部の練習問題のプログラミングに取り組み続けられるということです。私もそうですが、一人で技術書を学習している時は、技術書に練習問題があっても、それをプログラミングして解くことは少ないです。
一人で学習する場合とは異なり、研修受講生は全員が同じ練習問題に取り組んでいるという状況が、結果として個々の受講生がプライベートの時間(休日など)に取り組み続けられるモチベーションになっているのだと思います。研修日には、全員の解答のコードを確認することはできませんが、他の受講生の解答を見ることで得ることも多いと思います。
副業 [プログラマー現役続行]
私自身は、1984年4月に就職してからずっと会社勤めをしています。会社は4回変わりましたし、これからも変わらないとは言い切れません。一方で、会社以外から給与以外の収入(雑所得)を得るようになったのは2000年からです。
主な収入は、「原稿料」、「印税」、それと「組版料」です。雑誌の原稿を書いていたのは2006年までなので、それ以降は「印税」と「組版料」のみです。一部の本を除いて、基本的に自分が翻訳した本を自分で組版して納品してきました。残念ながらこれらの収入で暮らせるほどには、日本では技術書は売れません。
安達 裕哉さんが”「副業すると、本業の成績も上がる」と語る経営者の話”と題したブログ記事で、副業をしている人の特徴として以下の三つが書かれています。
ソフトウェアエンジニアとしては、翻訳を通して多くの知識を学ぶと同時に、著者達と多くのメール(質問や間違いの指摘)のやり取りをすることで、実際に会ったことはない人が多いですが人脈は広がっていると思います。
二つの目の「会社での評価にこだわらなくなる」というのは、ある程度そうかもしれません。そのため、ソフトウェア開発に関しては社内で褒めるところが見あたらないことが多く、私が問題点を指摘することが多いため、「柴田さんは褒めない」と評価が下がったりするのですが気にしていません。あるいは自分が重要だと思う活動が評価されなくてもそほど気にしないようになってきています。
三つ目の「経営者視点が持てる」ですが、何かを作って売るという副業ではないので、それほど持てるようになっているとは思えません。ただ、翻訳は膨大な時間を費やす必要があるので、それが結果的にどのくらいの時給になるのかは最近は気にして、すべての作業時間を記録しています。ちなみに昨年出版した『APIデザインの極意』は「今日までの収入」を「翻訳に費やした時間」で割ると時給1,722円です。
副業により給与以外の収入はありますが、それに加えて上記の最初の二つの項目は大きなメリットだと思っています。
主な収入は、「原稿料」、「印税」、それと「組版料」です。雑誌の原稿を書いていたのは2006年までなので、それ以降は「印税」と「組版料」のみです。一部の本を除いて、基本的に自分が翻訳した本を自分で組版して納品してきました。残念ながらこれらの収入で暮らせるほどには、日本では技術書は売れません。
安達 裕哉さんが”「副業すると、本業の成績も上がる」と語る経営者の話”と題したブログ記事で、副業をしている人の特徴として以下の三つが書かれています。
- 人脈が多い
- 収入の口が他にもあるので、評価に拘泥(こうでい)しなくなる
- 経営者視点が持てる
ソフトウェアエンジニアとしては、翻訳を通して多くの知識を学ぶと同時に、著者達と多くのメール(質問や間違いの指摘)のやり取りをすることで、実際に会ったことはない人が多いですが人脈は広がっていると思います。
二つの目の「会社での評価にこだわらなくなる」というのは、ある程度そうかもしれません。そのため、ソフトウェア開発に関しては社内で褒めるところが見あたらないことが多く、私が問題点を指摘することが多いため、「柴田さんは褒めない」と評価が下がったりするのですが気にしていません。あるいは自分が重要だと思う活動が評価されなくてもそほど気にしないようになってきています。
三つ目の「経営者視点が持てる」ですが、何かを作って売るという副業ではないので、それほど持てるようになっているとは思えません。ただ、翻訳は膨大な時間を費やす必要があるので、それが結果的にどのくらいの時給になるのかは最近は気にして、すべての作業時間を記録しています。ちなみに昨年出版した『APIデザインの極意』は「今日までの収入」を「翻訳に費やした時間」で割ると時給1,722円です。
副業により給与以外の収入はありますが、それに加えて上記の最初の二つの項目は大きなメリットだと思っています。
専門書には間違いもある [プログラマー現役続行]
一冊の専門書を仕上げるというのは大変な作業であり、出版時に誤りが残っているのは普通です。たとえば、『The Go Programming Language』のErrata(正誤表)を見てみるとすでに20項目弱の訂正が掲載されています。
技術書の誤りに関しては、拙著『プログラマー”まだまだ”現役続行』に「専門書には間違いもある」として書いているものを引用しておきます。
技術書の誤りに関しては、拙著『プログラマー”まだまだ”現役続行』に「専門書には間違いもある」として書いているものを引用しておきます。
専門書には間違いもある
専門書を読む際に注意しなければならないのは、たとえ専門家が書いていたとしても、誤植などの誤りがあるということです。そう思って読む必要があります。一冊の本を仕上げるという作業は、膨大な時間を要する作業であり、どうしても完全に仕上げることは不可能である場合が多いからです。つまり、説明が間違っている場合もあるということです。
さらに、たとえばサンプルコードなども、必ずしも適切でない場合もあると思って読むことです。よく、そのような間違った記述や不適切なコードが書かれている本を根拠に、論理的に矛盾していても「本に書いてある」と主張するエンジニアがいたりします。みなさんは、くれぐれもこのようなエンジニアにならないように心がけてください。
そして、間違いかなと思ったら、正誤表(英語ではErrata)が公開されていないかを探して、公開されていればすでに掲載されているかを確認します。公開されている正誤表に掲載されていなかったり、正誤表が見つからなかったりした場合には、著者や翻訳者へメールなどで連絡してください。本の間違いであれば、著者や翻訳者によっては、正誤表の謝辞の欄に名前を掲載してくれたりします。
私の場合、最近では、誤りだと思われる箇所については躊躇なく著者へメールで問い合わせるようになりましたが、記憶にある最初のメールはスレッドプログラミングに関する記述の間違いの指摘でした。
1993年に、あるプロジェクトでマルチスレッドプログラミングをするようになったのですが、当時はマルチスレッドプログラミングに関する書籍はほとんどない状態でした。しかし、プロジェクトが終わりかけた1995年頃、いくつかの書籍が出版されて、その中の一冊を読んでいました。自分の知識を復習する意味で読んでいたのですが、今まで行ってきたマルチスレッドプログラミングの前提を覆すような記述があり、その記述は間違いではないかと指摘するメールを送ったのです。著者からは、記述が誤りであるという返信が返ってきたのですが、その誤りを指摘したのは私が最初だったようです。そのときの返信を印刷したものを、今でもその書籍に挿んであります。
たとえつたない英語であっても、間違いを連絡してもらえれば、著者にとっては助かりますし、正誤表の謝辞欄に掲載されている自分の名前を見るのは嬉しいものです。
誤りの指摘をするには、単なる誤字脱字ならば簡単なことですが、技術的内容であれば、自分でもサンプルプログラムを書いて確認したり、ソースコードを調べたりする必要があります。そのような調査を行うことも、技術者としてのレベル向上に役立ちます。そして、いくつもの指摘を実際にすることで、技術者としての信頼を著者から得ることもできたりします。
そのためには、業務で使用している技術に関しては、きちんと学習することです。おそらく、業務ではその技術のすべてを使用していないかもしれませんが、使用していない部分に関しても学習することが重要です。
時には、誤りだと思った事柄が実は正しくて、自分自身が誤解して技術を理解している場合もあります。その場合であっても、著者へメールで誤りではないかと知らせることで、実は、あなたの勘違いですよと説明してもらえたりします。その場合でも、自分の不正確な理解を正す良い機会となりますので、積極的に著者へ問い合わせることをお勧めします。
『プログラマー”まだまだ”現役続行』(p.108)
Go言語研修 [プログラミング言語Go研修]
The Go Programming Language (Addison-Wesley Professional Computing Series)
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2015/11/16
- メディア: Kindle版
社内の教育コースですが、2016年2月よりプログラミング言語Go研修を始めます。Java研修と同様に、テキストの予習と練習問題を全部解くプログラミングを、私的な時間に行ってもらいます。業務扱いは、月に1日だけの研修の日だけです。研修の日は、事前予習で疑問に思った点をまとめた質問表に対する回答・議論、そして、練習問題の解答の確認です。
テキストは、やはりバイブル本である上記の本です。日本語版はまだ出版されていませんが、出版されるまでは翻訳原稿で予習をしてもらいます。2000年に始めたJava研修も実は翻訳原稿を使っています(研修実績はこちら)。
書籍『The Go Programming Language』(10) [golang]
The Go Programming Language (Addison-Wesley Professional Computing Series)
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2015/11/16
- メディア: Kindle版
紙の本での別のIndex(索引)の話題です。整数のオーバーフロー(integer overflow)として索引に次のように書かれています。
p.113に関しては、そのページを見ても「integer overflow」という言葉は見当たりません。これは間違いかと思ったのですが、そうではありませんでした。integer literal 55 overflow 53, 113 overflow, integer 53, 113
この索引は、練習問題 4.12に付けられているものです。そこでは、
https://xkcd.com/571
へ言及しており、そこを開いてみると・・・・確かに「integer overflow」していました。