So-net無料ブログ作成
検索選択
前の10件 | -

言語研修と練習問題 [プログラマー現役続行]

長年『プログラミング言語Java第4版』をテキストの一部としてJava研修を実施しています。また、『Javaプログラマーなら習得しておきたい Java SE 8 実践プログラミング』を用いたJava8研修も三回実施しました。

どちらの書籍にも練習問題がそれぞれ100問以上あります。研修の受講生は、それらの練習問題全部に取り組みプログラミングしてくることが求められています。来年2月から開講予定のGo言語研修ではテキストとして『The Go Programming Language』を使用します(実際には翻訳原稿)。そして、この本にも練習問題が100問以上あり、すべてプログラミングしてもらうことになります。

技術書を一人で黙々と学習する場合と、研修で学習する場合の大きな違いの一つは、全部の練習問題のプログラミングに取り組み続けられるということです。私もそうですが、一人で技術書を学習している時は、技術書に練習問題があっても、それをプログラミングして解くことは少ないです。

一人で学習する場合とは異なり、研修受講生は全員が同じ練習問題に取り組んでいるという状況が、結果として個々の受講生がプライベートの時間(休日など)に取り組み続けられるモチベーションになっているのだと思います。研修日には、全員の解答のコードを確認することはできませんが、他の受講生の解答を見ることで得ることも多いと思います。


スポンサーリンク





副業 [プログラマー現役続行]

私自身は、1984年4月に就職してからずっと会社勤めをしています。会社は4回変わりましたし、これからも変わらないとは言い切れません。一方で、会社以外から給与以外の収入(雑所得)を得るようになったのは2000年からです。

主な収入は、「原稿料」、「印税」、それと「組版料」です。雑誌の原稿を書いていたのは2006年までなので、それ以降は「印税」と「組版料」のみです。一部の本を除いて、基本的に自分が翻訳した本を自分で組版して納品してきました。残念ながらこれらの収入で暮らせるほどには、日本では技術書は売れません。

安達 裕哉さんが”「副業すると、本業の成績も上がる」と語る経営者の話”と題したブログ記事で、副業をしている人の特徴として以下の三つが書かれています。
  • 人脈が多い
  • 収入の口が他にもあるので、評価に拘泥(こうでい)しなくなる
  • 経営者視点が持てる
人脈ですが、確かに多少は広くなっているかもしれません。出版社と著者達との人脈は普通のソフトウェアエンジニアよりもあります。原著の草稿のレビューをするというのも、そのような人脈のおかげだったりします。今回の『The Go Programming Language』の英語草稿のレビューも、担当している米国の出版社の(知り合いである)編集者へ直接自分でお願いして、著者のAlan DonovanとBrian Kernighanに紹介してもらいました。

ソフトウェアエンジニアとしては、翻訳を通して多くの知識を学ぶと同時に、著者達と多くのメール(質問や間違いの指摘)のやり取りをすることで、実際に会ったことはない人が多いですが人脈は広がっていると思います。

二つの目の「会社での評価にこだわらなくなる」というのは、ある程度そうかもしれません。そのため、ソフトウェア開発に関しては社内で褒めるところが見あたらないことが多く、問題点を指摘することが多いため評価が下がったりするのですが、あまり気にしていません。あるいは自分が重要だと思う活動が評価されなくてもそほど気にしないようになってきています。

三つ目の「経営者視点が持てる」ですが、何かを作って売るという副業ではないので、それほど持てるようになっているとは思えません。ただ、翻訳は膨大な時間を費やす必要があるので、それが結果的にどのくらいの時給になるのかは最近は気にして、すべての作業時間を記録しています。ちなみに昨年出版した『APIデザインの極意』は「今日までの収入」を「翻訳に費やした時間」で割ると時給1,722円です。

副業により給与以外の収入はありますが、それに加えて上記の最初の二つの項目は大きなメリットだと思っています。


スポンサーリンク





専門書には間違いもある [プログラマー現役続行]

一冊の専門書を仕上げるというのは大変な作業であり、出版時に誤りが残っているのは普通です。たとえば、『The Go Programming Language』のErrata(正誤表)を見てみるとすでに20項目弱の訂正が掲載されています。

技術書の誤りに関しては、拙著『プログラマー”まだまだ”現役続行』に「専門書には間違いもある」として書いているものを引用しておきます。

専門書には間違いもある

 専門書を読む際に注意しなければならないのは、たとえ専門家が書いていたとしても、誤植などの誤りがあるということです。そう思って読む必要があります。一冊の本を仕上げるという作業は、膨大な時間を要する作業であり、どうしても完全に仕上げることは不可能である場合が多いからです。つまり、説明が間違っている場合もあるということです。
 さらに、たとえばサンプルコードなども、必ずしも適切でない場合もあると思って読むことです。よく、そのような間違った記述や不適切なコードが書かれている本を根拠に、論理的に矛盾していても「本に書いてある」と主張するエンジニアがいたりします。みなさんは、くれぐれもこのようなエンジニアにならないように心がけてください。
 そして、間違いかなと思ったら、正誤表(英語ではErrata)が公開されていないかを探して、公開されていればすでに掲載されているかを確認します。公開されている正誤表に掲載されていなかったり、正誤表が見つからなかったりした場合には、著者や翻訳者へメールなどで連絡してください。本の間違いであれば、著者や翻訳者によっては、正誤表の謝辞の欄に名前を掲載してくれたりします。
 私の場合、最近では、誤りだと思われる箇所については躊躇なく著者へメールで問い合わせるようになりましたが、記憶にある最初のメールはスレッドプログラミングに関する記述の間違いの指摘でした。
 1993年に、あるプロジェクトでマルチスレッドプログラミングをするようになったのですが、当時はマルチスレッドプログラミングに関する書籍はほとんどない状態でした。しかし、プロジェクトが終わりかけた1995年頃、いくつかの書籍が出版されて、その中の一冊を読んでいました。自分の知識を復習する意味で読んでいたのですが、今まで行ってきたマルチスレッドプログラミングの前提を覆すような記 述があり、その記述は間違いではないかと指摘するメールを送ったのです。著者からは、記述が誤りであるという返信が返ってきたのですが、その誤りを指摘したのは私が最初だったようです。そのときの返信を印刷したものを、今でもその書籍に挿んであります。
 たとえつたない英語であっても、間違いを連絡してもらえれば、著者にとっては助かりますし、正誤表の謝辞欄に掲載されている自分の名前を見るのは嬉しいものです。
 誤りの指摘をするには、単なる誤字脱字ならば簡単なことですが、技術的内容であれば、自分でもサンプルプログラムを書いて確認したり、ソースコードを調べたりする必要があります。そのような調査を行うことも、技術者としてのレベル向上に役立ちます。そして、いくつもの指摘を実際にすることで、技術者としての信頼を著者から得ることもできたりします。
 そのためには、業務で使用している技術に関しては、きちんと学習することです。おそらく、業務ではその技術のすべてを使用していないかもしれませんが、使用していない部分に関しても学習することが重要です。
 時には、誤りだと思った事柄が実は正しくて、自分自身が誤解して技術を理解している場合もあります。その場合であっても、著者へメールで誤りではないかと知らせることで、実は、あなたの勘違いですよと説明してもらえたりします。その場合でも、自分の不正確な理解を正す良い機会となりますので、積極的に著者へ問い合わせることをお勧めします。
プログラマー”まだまだ”現役続行』(p.108)

プログラマー”まだまだ”現役続行 (技評SE選書)

プログラマー”まだまだ”現役続行 (技評SE選書)

  • 作者: 柴田 芳樹
  • 出版社/メーカー: 技術評論社
  • 発売日: 2010/09/04
  • メディア: 単行本(ソフトカバー)



スポンサーリンク





Go言語研修 [プログラミング言語Go研修]


社内の教育コースですが、2016年2月よりプログラミング言語Go研修を始めます。Java研修と同様に、テキストの予習と練習問題を全部解くプログラミングを、私的な時間に行ってもらいます。業務扱いは、月に1日だけの研修の日だけです。研修の日は、事前予習で疑問に思った点をまとめた質問表に対する回答・議論、そして、練習問題の解答の確認です。

テキストは、やはりバイブル本である上記の本です。日本語版はまだ出版されていませんが、出版されるまでは翻訳原稿で予習をしてもらいます。2000年に始めたJava研修も実は翻訳原稿を使っています(研修実績はこちら)。

書籍『The Go Programming Language』(10) [golang]


紙の本での別のIndex(索引)の話題です。整数のオーバーフロー(integer overflow)として索引に次のように書かれています。
integer
    literal 55
    overflow 53, 113

overflow, integer 53, 113
p.113に関しては、そのページを見ても「integer overflow」という言葉は見当たりません。これは間違いかと思ったのですが、そうではありませんでした。

この索引は、練習問題 4.12に付けられているものです。そこでは、https://xkcd.com/571へ言及しており、そこを開いてみると・・・・確かに「integer overflow」していました。

『Javaパフォーマンス』読書会 終了 [読書会]

Javaパフォーマンス

Javaパフォーマンス


2015年4月27日(火)から始めた社内の『Javaパフォーマンス』読書会ですが、開催しない週があり進捗が悪かったのですが、今日終わりました。5名で始めた読書会でしたが、途中1名が転職したので4名で終了しました。

2月に大森事業所から海老名へ転勤後の勉強会でしたが、なんとか終わらせることができました。12月7日からは新横浜事業所勤務になります。

技術的負債(6) [技術的負債]


この本の「Chapter 13: A Tale of Two Systems」からの抜粋(p.122)です。

Technical Debt

Technical debt is a term coined by Ward Cunningham that’s widely used in the software industry today. The metaphor leans on the financial world: making a decision to help ship software quickly is like taking on a loan. It can enable you to do something now that you would not otherwise be able to do.

But you can’t ignore that loan—you always have to pay it back. The longer it takes to pay back, the more it costs you. If you fail to make timely repayments, you’ll be stuck paying off interest on the loan, and your purchase power diminishes.

In the software world, that means return to your code to update it, or else your progress will slow as the code bogs down in accrued debt. This is important: in the long run, lower code quality means longer development times, but a responsible short-term loan can speed things up.

Technical debt might be deferred refactoring, design adjustments that reflect what you’ve discovered, waiting to update libraries or toolchains until after the next major release, or rationalising the logging/debugging scaffolding.

This is a colourful metaphor that can be misused: technical debt does not just mean doing something badly. Sometimes writing bad code is justified as being “pragmatic”; there is a difference between a pragmatic choice and a sloppy one.

Consciously managing technical debt is a powerful weapon in your development arsenal. Don’t let debt build up, and keep it visible. Like a real loan, pay back debt as early as possible to avoid suffering excessive interest and charges.
技術的負債に全く関心を払っていないソフトウェア組織が最後はどうなってしまうのかというのも関心事ですが、最近の個人的関心事は、そのような組織で働くことで個々のソフトウェアエンジニアの成長に対して何が起きるのかということです。

書籍『The Go Programming Language』(9) [golang]


すでに紙の本とKindle版が発売されているので、購入された人も多いと思います。紙の本の索引(Index)のRob Pikeのところに次のようにあります。
Pike, Rob xi, xiii, 67, 107
ところが、この最後のp.107にはRob Pikeの名前は登場しません。索引を作り間違えたのかと思いましたが、そうではないそうです。

p.107には次のようなコード例が掲載されいます。
array              ["gold", "silver", "bronze"]
object             {"year": 1980,
                    "event": "archery",
                    "medals": ["gold", "silver", "bronze"]}
実は、これはRob Pikeに関連する例なので、索引が追加されています。関連しているのは1980、archery、silverの三つです。私は知らなかったのですが、これはRob Pikeに関するよく知られたジョークのようです。

Rob Pikeは経歴にジョークで、1980年のオリンピックのアーチェリ競技で銀メダルを取ったと書いていたようです。1980年のモスクワオリンピックを、米国およびカナダ(それに日本)はボイコットしたので彼がオリンピックで銀メダルを取ることはできるはずもないということです。詳しくは、http://c2.com/cgi/wiki?RobPike を参照してください。

第3期「Java 8研修」コース終了 [プログラミング言語Java教育]


この本をテキストとして学ぶコースですが、先週に続いて第3期が11月20日(金)に終了しました。修了生は8名でした。これで、延べ26名が修了したことになります。

書籍『The Go Programming Language』(8) [golang]

ちょっとした手違いがあってGoogle社のNew Yorkオフィスのメール室に放置されていた本が届きました。

IMG_0450.JPG


中を開くとメッセージと著者の二人からのサインが書いてありました。

IMG_0451.JPG


前の10件 | -