SSブログ

翻訳のきっかけと翻訳作業 [APIデザインの極意]

書籍の翻訳をする場合、そのきっかけは、大きく分けて2通りあります。1つは、出版社からの依頼により翻訳する場合であり、もう1つは、私から出版社へ翻訳したい旨を伝えて翻訳させてもらう場合です。

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

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

  • 作者: Jaroslav Tulach
  • 出版社/メーカー: インプレスジャパン
  • 発売日: 2014/05/23
  • メディア: 単行本(ソフトカバー)

『APIデザインの極意』は前者であり、2013年3月28日に出版社から翻訳の打診がありました。ちょうど『Objective-C明解プログラミング』の翻訳作業も終えて一段落していた頃でした。

最初は原著のページ数から、単純に半年程度と見積もりました。しかし、実際に翻訳を始めてみると、とにかく量が多かったです。結果として、約13か月を要しました。そして、なんとか出版となり、書店に並び始めて、ほっとしています。

私の場合、翻訳は本業ではなく、完全に私的な時間に行う副業です。様々な方法で時間を捻出しながらの作業となります。今回は、ちょうど転勤して通勤時間が長くなってしまったこともあり、通勤電車内でもノートパソコンを広げて、かなり作業をしました。当初、自宅以外では、昔から使っているVAIO Xで行っていたのですが、性能的にかなり厳しくなってきたので、途中でMacBook Airを購入して切り替えました。

翻訳作業は、基本的にLaTeXを使用して行います。出版社によっては、LaTeXでの納品を受け付けないところもありますが、今回は翻訳を開始する際に出版社に確認して、LaTeXでの納品でした。LaTeXでの納品の場合には、索引作りも行って、組み版のほとんどが終わった状態で、出版社へ納品することになります。

翻訳を通して、私自身が本に書かれている内容を学ぶことが多いです。今回も、多くのことを学びました。そして、会社で行っているプロジェクトへ、プログラミング言語は違いますが応用した部分もあります(会社ではJavaではなくGoです)。

翻訳することのもう1つの個人的な恩恵は、著者と知り合えることです。実際に会ったことがない著者でも、内容の問い合わせに関して多数のメールをやり取りすることになります。メールのやり取りを通して、会ったことはないですが、身近に感じることができます。残念ながら、実際に著者に会う機会はなかなかないですが。

今は、私にとって14冊目の翻訳本の翻訳作業を行っています。私の方から出版社に翻訳を打診して、翻訳権を確保してもらい、翻訳させてもらっている本です。
コメント(0) 

募集:第4回Jolt Awards読書会 [Jolt Awards読書会]

第4回Jolt Awards読書会の参加者を募集します。参加申し込みは、こちらです。

Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン (THE LEAN SERIES)

Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン (THE LEAN SERIES)

  • 作者: ジェフ・ゴーセルフ
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2014/01/22
  • メディア: 単行本(ソフトカバー)

第4回は、新たに『Lean UX』を読み始めます。

コメント(0) 

なぜ新たなデザイン本が必要なのか [APIデザインの極意]

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

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

  • 作者: Jaroslav Tulach
  • 出版社/メーカー: インプレスジャパン
  • 発売日: 2014/05/23
  • メディア: 単行本(ソフトカバー)

まもなく書店に並びます。序章「なぜ新たなデザイン本が必要なのか」の冒頭からの抜粋です。
 みなさんは、「プログラミングの世界にはもう十分な数のデザイン本があるのでは」と思うかもしれません。実際、数多くの本があるので、なぜ私がもう1 冊書かなければならないのか(そして、なぜみなさんが読まなければならないのか)と疑問に思うことは当然です。特に、オブジェクト指向システムでのデザインパターンに関しては、いわゆる4 人組(Gang of Four)と呼ばれる人達が執筆した有名なDesign Patterns: Elements of Reusable Object-Oriented Softwareという、オブジェクト指向言語を使用するすべての開発者の必読書があります。加えて、デザインパターンを説明した多くの専門書があり、特定の種類のアプリケーションを作成する場合にはそれらの書籍が役立ちます。さらに、非公式ながらJava プログラマのバイブルであるEffective Javaがあります。これらの事実に照らし合わせても、本当にデザイン本がもう一冊必要なのでしょうか。

 私は、必要であると確信しています。1997 年以来、NetBeans API(アプリケーション・プログラミング・インタフェース)を設計してきました。フレームワークや共有ライブラリを設計する人が経験するであろうすべての段階を経験してきました。初めの頃は、他の言語でうまくいったコーディングスタイルを適用しながらJava言語に徐々に慣れていきました。後に、Java に精通するようになり、その時点で、Java で書かれた私のコードに様々なよく知られたパターンを適用することは簡単に思えました。しかし、しばらくして、物事は見かけほどいつも簡単ではないことに気付いたのです。NetBeans などのオブジェクト指向のアプリケーションフレームワークには、伝統的なパターンは適切ではないことと、完全に異なるスキルを必要とすることに気付いたのです。

 最も古いNetBeans API は、1997 年に設計されました。そのいくつかは、10 年以上経った今でも使用されていますし、きちんと動作しています。しかし、正直なところ、それらは昔と全く同じAPI ではありません。長年にわたって、新たな要求に対応し、ライブラリの機能を拡張し、初心者として犯した誤りを修正する必要がありました。それでも、コードをコンパイルしたAPI のクライアントは、今日の最新のライブラリでもそのコンパイルされたコードを実行することができます。これは、私達ができる限り後方互換性を維持するように努めてきたことで可能になっています。結果として、10 年前のライブラリに対して書かれたプログラムは、現在のライブラリのバージョンでも動作するでしょう。後方互換性を維持してライブラリを発展させるという私達の決定によってもたらされた、投資を無駄にしない方法は、よく知られたデザイン本には書かれておらず、私が今までに読んだデザイン本には少なくとも書かれていませんでした。すべてのNetBeans API が何の問題もなく発展したということではありませんが、NetBeans チームは互換性を維持する高いスキルを今では習得したと確信しており、そのスキルは他のプログラマでも広く必要とすることを信じています。そのため、この本の大部分が、後方互換性を維持することと、後方互換性を維持しながら保守するのに適したコードを生み出す特別なAPI デザインパターンに費やされています。

コメント(0) 

再出版されました:『プログラミング言語Java第4版』 [本]

プログラミング言語 Java 第4版

プログラミング言語 Java 第4版

  • 作者: ケン・アーノルド
  • 出版社/メーカー: 東京電機大学出版局
  • 発売日: 2014/05/10
  • メディア: 単行本

一度は絶版になりましたが、再出版されました。ページ数は同じなのですが、紙が厚くなったため、本も厚くなりました(そして、重くもなりました)。

1607002_785086924843920_339816122746121471_n.jpg

手前に、再出版された本(左)と古い本(右)を並べていますが、厚みをよく見てもらうと違いが分かるかと思います。出版社によれば、キーボードの横に置きながら読むことを考えて,開きやすい製本仕様となっているということです。

残念ながら、Java 8に対応した第5版は、私が知る限り、今のところ執筆される予定はないようです。
コメント(0) 

書籍『APIデザインの極意』(4) [APIデザインの極意]

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

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

  • 作者: Jaroslav Tulach
  • 出版社/メーカー: インプレスジャパン
  • 発売日: 2014/05/23
  • メディア: 単行本(ソフトカバー)

翻訳では、著者に対して様々な問い合わせをするため、多数のメールのやり取りをします。そして、私が翻訳した多くの書籍と同様に、今回も、「日本語版によせて」を書いてもらいました。書籍によっては、その英語原文を翻訳本に掲載していたりしています。今回の「日本語版によせて」は、「Japanese」と題して、ネット上に公開されていますので、掲載していません。

http://wiki.apidesign.org/wiki/Japanese

コメント(0) 

ソフトウェア開発と人事戦略(2) [ソフトウェア開発と人事戦略]

Java研修を長年続けてきて、近年、非常に進捗が悪くなっています。その理由を考えてみると、基礎的な事柄を知らないままソフトウェア開発に従事している人が増えているためだと思うようになってきました。

ここでの基礎的なこととは、一般的な「データ構造とアルゴリズム」、オペレーティングシステムに関する基礎知識、ハードウェアに関する知識です。それに加えて、デザインパターンに関する知識も欠如しているため、その都度、Javaとは関係ないことを説明しなければならいことが非常に多くなっています。

データ構造とアルゴリズムに関しては、基礎的なことを理解していない人が多く、ハッシュテーブルを説明したりO表記を説明できたりする人は皆無だったりします。オペレーティングシステムに関しても、仮想メモリをサポートするためのページングの仕組みを知らなかったり、Unixでのシステムコールを用いたプログラミング経験が全くなかったりします。デザインパターンにいたっては、全く勉強さえしたことがなかったりする訳です。

このようなレベルの人達が、『プログラミング言語Java第4版』や『Effective Java 第2版』を読んで理解するのは無理な場合が多いです。たとえば、『Effective Java 第2版』の項目6「廃れたオブジェクト参照を取り除く」のp.24の最後に次の一文があります。
極端な場合には、そのようなメモリリークは、ディスクのページングを起こしたり、(以下省略)
ここで、「ディスクのページングとは何か」と質問しても答えられなかったりします。そうなると、説明することになるのですが、このレベルを都度説明していては、全く進まないことになります。

なぜ、基礎的なことを知らないかというと、そもそも、大学での専攻が情報工学ではないということです。全く違う専攻で、就職してからプログラミングをするようになる人が多くなっているからだと思っています。

IT技術者が不足していると言われる今日であれば、大学で情報工学を専攻した方が、就職には全く困らないにも関わらず、情報工学の競争率が高いとは聞きません。大学の専攻とは異なるけど、専攻では職がないためなのか(または別の理由からなのか)、多くの学生がソフトウェア開発に応募してしまうし、企業もそのような学生を採用しないと情報系として採用したい人数を確保できない状況になっているのではないかと思います。

さらにおかしいことは、大学で情報工学を専攻した学生と大学で文系だった学生がソフトウェア開発として採用されたとしても、日本の多くの企業では給与が同じだということです。そして、同じ内容の基礎教育を受講し、情報工学を専攻した人は内容が易しすぎるし、文系だった人には内容が難しすぎるという教育を多くの費用をかけて行っていたりします。

日本の多くの企業(メーカー)でのソフトウェア開発要員の採用およびソフトウェアエンジニアの育成は、大丈夫なのでしょうか?
コメント(0)