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

『Java SE 8実践プログラミング』が届きました [本]

Bx0BabDCEAAuQtn.jpg
4月から翻訳を始めた、私にとっては14冊目の翻訳本となる『Javaプログラマーなら習得しておきたい Java SE 8 実践プログラミング』出版社から届きました。5月に『APIデザインの極意 Java/NetBeansアーキテクト探究ノート』を出しましたので、今年で2冊目の翻訳本となります。2冊続けて翻訳し、両方で約1年半(約800時間)を費やしました。

今回の本には、「日本語版によせて」はありませんが、日本語版向けの段落が「まえがき」に1段落だけ追加されています。今回は、余白を多めに取って組版していますので、書き込みなども行いやすいと思います。

通勤電車の書斎化」で述べているように、翻訳作業の半分ぐらいは電車の中です。残りは、スターバックスなどか自宅です。組版の最後の調整や、レビューアからの指摘事項の反映・確認などは、大きなディスプレイで作業するのが効率的だったりするので、自宅では27インチのThunderbolt Displayに接続して作業します。

翻訳のきっかけと翻訳作業」で述べているように翻訳を行うことの個人的な恩恵の1つは、(メールのやり取りを通して)著者と知り合えることです。そして、その著者の次の著書のレビューをする機会を得られたりすることです。今回も、翻訳の予定はないですが、Horstmann氏の次の著書のレビューを行っています(「技術書のレビュー」)。
コメント(0) 

再び聴けるようになったKOIT(2) [インターネット放送]



iPadの「96.5 KOIT」アプリで聴けるかを試してみました。きちんと聴けるようです。

米国シリコンバレーにあるPalo Alto, CAに住んでいた頃(1991年5月から1993年4月までの2年間)、カーラジオでよく聞いていたFM放送局がKOITでした。当時は、車には、カーラジオかカセットテープのプレイヤーだけしかない頃でした。KOITを聞いていると、シリコンバレーの青空や、当時はそれほど混んでいなかったフリーウェイ260を思い出します。
コメント(0) 

再び聴けるようになったKOIT [インターネット放送]

再び日本で聴けなくなったKOIT(2)」では、聴けなくなったKOITが聴けるようになる場合があるというのことを書きました。その記事では、KOITのホームページへ行って、「Listen Live」ボタンを押しても、通常のPCのブラウザーからはだめで、iPadのブラウザーでは、PCとは別のURLヘ接続されて、聴けるということを書いています。

その後、そのiPadのブラウザーから接続されるURLも変更になったのですが、てっきりiPadなどのiOSからだけの接続先が変更になったという先入観を持っていました。つまり、普通のPCのブラウザーでKOITのトップページから「Listen Live」ボタンを押してもそのURLヘの接続は行われないと思い込んで、実際には試していませんでした。

今朝、試しにMac上のChromeブラウザーでKOITのホームページへ行って、「Listen Live」ボタンを押したら、iPadのブラウザーから接続されるURLと同じページに行って、普通に聴くことができました。iPadのKOITアプリから聴けるかは、まだ、試していません。

KOITのホームページは、こちらです。
コメント(0) 

学生気分の人(2) [プログラマー現役続行]

以前、荒井玲子さんの著書から引用した内容で「学生気分の人」という記事を書いています(まずは、読み返してみてください)。

その中で特に次の部分について、私なりの経験からの補足をします。
 一方、企業にとっては、社員は利益を生み出す人材です。したがって、社員に対する教育投資です。投資に対する利益が得られなければ、投資機会も存在しません。よって、自分がどこまでスキルアップするのか、というのは、自分で設定する必要があります。そのスキルがその企業にとって有益である場合、企業は少しは支援をしてくれる場合もあります。
「社員に対する教育は投資」であり、「利益が得られなければ、投資機会も存在しません」と述べられています。会社によっては、様々な教育制度を提供していたり、有償の教育を受けるための予算を準備していることもあります。つまり、それらも投資なのです。

しかし、エンジニアの中には、そのような教育は毎年受けられるとか、教育の予算をもっと増やすべきだと意見を述べるのですが、実際の開発業務では成果が上がっていない人がいます。つまり、学生気分で教育を受けているし、受けるのが当然の権利だと勘違いしているわけです。

私自身は、昔から、有益だと思えるカンファレンスなどは、業務扱いで行くように指示したりします(無料のカンファレンスならなおさらです)。業務扱いというのは、休みを取る必要もないし、交通費も支給するということです。しかし、1日分の給与と交通費という投資なのです。海外のカンファレンスならもっと多くの投資となります。

ある時、ある(無料)カンファレンスに参加したいので業務扱いで参加してもよいかと聞かれたことがあります。その時の私の回答は、「行きたいなら有給休暇を取って行ってください」でした。そしたら、「業務扱いで行ける基準は何ですか」と聞かれたので、「業務扱いで参加させるという投資に、その人が値するかという私の判断です。業務扱いの参加は、会社にとってあくまでも投資です」と答えました。

自分のスキル向上を会社に頼るべきではありません。荒井さんの言葉を借りれば「自分がどこまでスキルアップするのか、というのは、自分で設定する必要があります」。そして、スキルアップのための支援を会社がしてくれることを期待しないことです。
コメント(0) 

書籍『A Practical Approach to Large-Scale Agile Development』(2) [プログラマー現役続行]


先日紹介したこの本には、技術的負債とういうことはあまり話としてはできてきませんが、日々の開発活動を通して、技術的負債を少なくすることができる開発プロセスの確立とも言えます。

技術的負債に関しては、過去に以下の記事を書いていいます。

技術的負債を残し続けるというのは、長期的に見れば、その開発組織のソフトウェア開発力を徐々に下げて行くことになっていきます。

「技術的負債(3)」では、次のように書いています。
見方を変えると、技術的負債は、将来性のある若手をきちんとしたソフトウェアエンジニアとして成長させる場を奪ってしまうことになります。良いコードを書くという機会もなく、リファクタリングを経験する場もなく、過去に誰かが作った負債と格闘させるだけとなります。そのような状況では、ソフトウェア開発にもともと興味がない人は、負債を膨らませていくだけでしょう。一方、意欲のある若手は、成長できないため会社を辞めていくことになります。その結果、技術的負債に無頓着な人々が開発組織の大半を占めるようになり、会社は負債をますます増大させることになります。
「技術的負債(4)」では、さらに次のように書いています。
さらに、一からシステムを作成した経験がないエンジニアが組織内に増えてしまうことにもなります。製品を出し続けることで技術力があると思っているのは単なる錯覚に過ぎず、画期的な競合製品が出てきた時に、技術の空洞化が起きていて、自社製品開発では追いつけない可能性が高くなります。
1,000万行を超えるソフトウェアを、継続的インテグレーションや継続的デリバリーを達成したアジャイル開発へと移行させるということは、普通の企業ではまねできないことだと思います。
コメント(0) 

継続した学習(3) [プログラマー現役続行]

ソフトウェア開発は物づくりです。その物づくりをうまくなるためには、様々な知識を吸収して、それを日々実践して習得する必要があります。本を読んだだけでは、プログラミングできるようにはなりません。ましてや、読みやすく理解しやすいプログラムを作成するというのは、単に動作するだけのプログラムを作成するよりは、高いスキルレベルが要求されます。

たとえば、読みやすいコードを書くために、推奨される書籍としては、以下のような本があります。
当然のことながら、これらの本を読んだだけでは、読みやすく理解できるようなコードが書けるわけではありません。単に知識を詰め込んだだけです。それを実際の日々のプログラミングで試してみて、自分のコードが読みやすくなったかと判断しながら実践していく必要があります。そして、自分視点ではなく、他人視点(つまり、他の人が読んで理解しやすいか)と自分で判断できるようになるまで実践していく必要があるのです。

つまり、「継続した学習」に加えて「日々の実践」による自分自身のスキルアップを行いながら修得していく必要があります。しかし、そもそも書籍を読まない、読んでもきちんとした実践を行う努力をしていない人のレベルは、その設計やソースコードに現れてしまいます。あるいは、色々指摘しても、「自分にとっては分かりにくくない」という言い訳をすることになります。

場合によっては、普段の開発業務でまったく実践できていないのに、本を読んでいるのだから評価されるべきだと、業務の目標設定に書いてくる人もいます。目標とする達成レベルは本を読むことではありません。学習を通して学んだことを実践して修得して、自分自身のスキルが向上して、それが日々の成果に現れていることに、達成レベルを置くべきです。そのための継続した学習なのです。
コメント(0) 

継続した学習(2) [プログラマー現役続行]

継続した学習を行うために、あらかじめ平日に1時間とか学習する時間を決めて、地道に学習を続けて行く必要があると思います。平日は全く学習しないで、週末に行うというのは、長続きしないのではないかと思います。

年間を通してみれば、全く学習をしない週があったりするかと思います。しかし、学習は、短距離走ではなくマラソンであり、地道に継続していく必要があります。週1回で1時間程度の技術書の勉強会であっても、続けていくことで、最後には読み終えます。それは、週1回といっても、継続して開催し続けるからです。

個人の学習という点では、基本は平日に毎日続ける方が、1日、2日、何らかの理由(飲み会とか)でできない日があっても、次の日にはまた行うことになります。しかし、週末だけというのは、長続きしないかと思います。その理由としては、私なら次のようなことが挙げられます。
  • 長時間集中が続かない
  • 週末なので予定や用事が多い
それよりも、平日に1時間とか決めてコンスタントに続けている方が、長期的に見れば、継続した学習の習慣化にもなりますし、多くのことを学ぶことになるかと思います。みなさんは、いかがでしょうか?
コメント(0) 

訳者まえがき 『APIデザインの極意』 [訳者まえがき]

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

APIデザインの極意 Java/NetBeansアーキテクト探究ノート


私自身がJava 言語を学び始めたのは、1996 年の夏でした。その後、Java 関連の技術雑誌の記事を執筆したり、2001 年に『プログラミング言語Java 第3 版』を翻訳したりしました。しかし、それまでは、API 設計に関しては、初心者の域を出た程度でした。API 設計に対する私自身のレベルを大きく押し上げてくれたのが、2001 年に翻訳したJoshua Bloch 氏の『Effective Java プログラミング言語ガイド』でした。そして、Jaroslav Tulach 氏のこの『API デザインの極意』(Practical API Design)は、さらにAPI 設計に対する私のレベルを大きく押し上げてくれました。Tulach 氏の言葉を借りれば、私の水平線を大きく押し広げてくれました。

API 設計は、大学で体系的に教えられることはないですし、企業でも教えられることはないと思います。その結果、日本企業においては、いわゆるSDK と呼ばれるソフトウェアを外部へ提供していても、必ずしも優れたAPI になっていないことがあります。私自身も、数多くの悪い設計のAPI を見てきました。しかし、なぜ、そのようなソフトウェアが量産されるのでしょうか。それは、何が良いAPI で何が悪いAPI であるかを分からないレベルのソフトウェアエンジニアが開発しているからかもしれません。あるいは、きちんとしたレビューを受けていないのかもしれません。あるいは、レビューできちんと指摘できるレベルのソフトウェアエンジニアがいないのかもしれません。

きちんとしたAPI 設計を学ぶには、ある程度独学で書籍を通して学習して、実践して習得していくしかありません。その意味では、Joshua Bloch 氏の『Effective Java』は必読書と言えますし、デザインパターンなども学ぶ必要があります。しかし、残念ながら、API を発展させていく観点でAPI 設計について書かれている書籍は、まれです。

この本には、オープンソースプロジェクトであるNetBeans のアーキテクトとしてTulach 氏が経験してきたことがまとめられています。Tulach 氏が行った様々な誤りが説明されており、それらの経験からAPI の発展を考慮した設計とはどのような設計かが説明されています。また、どのようにして、NetBeans の非推奨のAPI を終焉させてきたかも述べられています。そして、最後に、この本に述べられている方法論をアジャイルAPI 設計Agile API Design)と呼ぶことにすると述べられています。

この本は、プログラミングの初心者向けではありませんし、Java に関する知識が必要であり、『プログラミング言語Java 第4 版』の内容の知識が必要です。多くのJava プログラマが不慣れと思われる箇所に関しては、『プログラミング言語Java 第4 版』の該当箇所を訳注として示しています。

この日本語版が、API 設計に対する読者のみなさんの水平線を押し広げることの助けになれば幸いです。

コメント(0) 

『APIデザインの極意』の内容紹介記事 [APIデザインの極意]


ThinkItで書籍の内容の一部がそのまま紹介されています。第1回は、「現代的なソフトウェア構築の技芸 -合理主義、経験主義、無知-」と題して紹介されています。
コメント(0) 

書籍『A Practical Approach to Large-Scale Agile Development』 [プログラマー現役続行]


大規模な組み込みシステムに対するアジャイル開発の適用例を述べた本です。副題に、「How HP Transformed LaserJet FutureSmart Firmware」となっているようにHPでのプリンターやMFP(Multi-Function Products)(いわゆる、コピー、プリント、ファックなどが一台に搭載されたデジタル複合機)の開発において、いかにしてアジャイル開発を適用したかを述べた本です。どのくらい大規模かというと、コード量にして1,000万行以上開発者数400名以上という大規模なものです。

アジャイル開発に移行する前のHPでは、どのような問題を抱えていたかというと、次のような問題を抱えていたと述べられています。
  • 開発リソースの10%は、「Build Boss」と呼ばれるチームごとの専任のフルタイムのコードのインテグレーション担当者であった。それに加えて、全体をビルドするチームも存在していた。
  • 全体をビルドするチームも1日に1回か2回しかビルドを行えなかった。
  • 非常に時間を要するビルドプロセスだったので、開発者が1つの変更を入れても、システム全体で正しく動作するのを確認できるようになるまで1週間を要していた。
  • 開発リソースの20%が、すぐに不要になったり、提供されない、将来の機能提供に関する詳細な計画に費やされていた
  • 開発リソースの25%は、既存のコードと機能を新製品へ移植することに費やされていた。
  • 開発リソースの15%は、手動によるテストに費やされていた。そのため、製品計画に製品を頻繁に追加できなかった。
  • 開発リソースの25%は、顧客要求に対応するとか、製品間の一貫性を維持するための現行製品のサポートに費やされていた。
そして、残りの5%のリソースしか、新たな価値創造のための活動に費やせなかったという状況だったようです。

結果が、どうなったかは、次のスライドの11ページ目にまとめられています。
http://www.agileleadershipnetwork.org/wp-content/uploads/2012/12/Young-LargeScaleAgielDevelopment-2012-01-20.pdf

また、著者の一人によるプレゼンテーションの動画もあります。
"A Practical Approach to Large Scale Agile Development" - Gary Gruver at Spark 2013

実際の製品開発をどのように行っているかを企業が公表することはないため、多くの企業は、製品のベンチマークは行っても、開発プロセスのベンチマークを行うことはないです。結果として、開発プロセスが、井の中の蛙となってしまうことがあります。この本は、組み込みシステムであっても、自分達の開発プロセスをベンチマークする上で、優れた材料を提供していると思います。

2年前に記事「継続インテグレーションは強みではなくなった」を書いています。その記事を書いた頃には、HPは、はるかに先を行っていたということになります。
コメント(0) 
前の10件 | -