So-net無料ブログ作成
  • ブログをはじめる
  • ログイン
前の10件 | -

『Effective Java 第3版』研修 [プログラミング言語Java教育]

Effective Java 第3版

Effective Java 第3版

  • 作者: Joshua Bloch
  • 出版社/メーカー: 丸善出版
  • 発売日: 2018/10/30
  • メディア: 単行本(ソフトカバー)

第1章「はじめに」には次のように書かれています。
この本は初心者向けではありません。つまり、みなさんがJava をすでに使いこなしていることを想定しています。もし、そうでなければ、Peter Sestoft の『Java Precisely』[Sestoft16] などの多くの優れた入門書籍を検討してください。『Effective Java』はJava 言語の実用的知識を持つ人なら誰でも理解できるように意図していますが、上級プログラマに対しても考えるべき材料を提供しているはずです。
また、私自身も「『Effective Java 第2版』は、やはり初心者向けではない」と題する記事を書いています。

従来、富士ゼロックスグループおよびリコーグループで行っていたJava研修では、『プログラミング言語Java第4版』を学んだ後に『Effective Java 第2版』を学んでもらっていました。『Effective Java 第3版』に関しては、第25期Java研修の修了生を対象として翻訳原稿を使って「補講」を行いました。

『Effective Java 第3版』をきちんと理解しようと思うと多くの基礎知識を必要とします。少なくとも以下の3冊は読んでおく必要があります。

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

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

  • 作者: ケン アーノルド
  • 出版社/メーカー: 東京電機大学出版局
  • 発売日: 2014/05/10
  • メディア: 単行本
Java 5までの言語仕様、メモリモデル、シリアライズなどの基礎的な事柄が書かれています。

Java 2 Standard Edition 5.0 Tiger―拡張された言語仕様について

Java 2 Standard Edition 5.0 Tiger―拡張された言語仕様について

  • 作者: 柴田 芳樹
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2005/04
  • メディア: 単行本
Java 5で導入された言語拡張がどのように実現されているかも含めて解説されています(PDF版を公開しています)。

Javaプログラマーなら習得しておきたい Java SE 8 実践プログラミング

Javaプログラマーなら習得しておきたい Java SE 8 実践プログラミング

  • 出版社/メーカー: インプレス
  • 発売日: 2014/09/22
  • メディア: Kindle版
Java 8で導入された機能(ラムダ式やストリーム)およびJava 7で導入された機能が解説されています。

第25期Java研修生はこれらの3冊の学習まで終えていたので、補講として『Effective Java 第3版』を学習してもらいました。しかし、従来のJava研修では期間が長すぎる(一年半)ので、『Effective Java 第3版』だけを学習する研修を企業向けに半年間(月に1日で6か月)コースとして開催します。Javaに関する受講生の知識に応じて技術的な補足・解説を行いながら読んでいきます。

『Effective Java 第3版』研修の第1期は、12月から開講です。開催時期を調整中ですが、第2期も予定しています。


スポンサーリンク





コメント(0) 

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

最近は、企業が副業を解禁するしないという話題が目立つようになりました。今働いているメルペイ社では副業は禁止されていません。私自身は、技術雑誌の記事の執筆、技術書籍の翻訳、技術書の執筆などを2000年から副業としてやってきました。現在は、技術書籍の翻訳と企業向けの技術教育が中心です。

最初に副業を始めたのは富士ゼロックス情報システム社に勤務している頃で、就業規定に明確に兼業禁止規定がありました。しかし、技術系の活動に関しては、毎回社内で申請処理をする必要がありましたが、認められていました。

2008年9月にリコーへ転職したのですが、就業規則を何度読み返しても「兼業禁止規定」は書かれていませんでした。それでも、技術書の翻訳で社内申請をしようとしたのですが、当時の室長に「入社前からやっている活動であり、そのことは承知して採用しているし、申請するとそれを審査するために無駄に社内の工数が取られるので申請しなくてよい」と言われました。それ以来、リコー内では何も申請することなく、技術書の翻訳本を出したり、自分の本を出したりしていました。

リコーに勤務していた間には、頻度は年に1回程度でしたが新卒新人向けの技術教育を2社ほど他社向けにやっていました。1社は土曜日で、もう1社は有給休暇を取得してやっていました。これらは、最初だけ社内の申請を行いました。

2017年8月末で8年間勤めたリコーを早期退職しました。年齢的にも58歳に近くなっていたので、週4日勤務という条件でソラミツで働き始めました。それは、金曜日は個人で技術教育やコンサルティングなどの副業をする日に当てたかったためです。企業向け技術教育となるとどうしても平日ということになります。

今の若い人達は、ソフトウェア開発で副業をしている人も多いようです。私が20代から30代の頃は、そのような副業は不可能な時代でした。ソフトウェアを開発するには、会社に行かないとできなかった時代ですので、平日の夜とか休日にプログラミングの副業は無理でした。

今日のベンチャー企業やスタートアップ企業では、ソースコードコントロールやCIツールなどの多くがクラウドベースになっているため、自宅でもソフトウェアを開発できる時代になっています。

私の30代に同じ環境があってもソフトウェア開発での副業は無理だったかもしれません。当時は、朝7時に出社して12時間近く会社でソフトウェア開発をして、そして飲み会という日々だったからです。そして、休日出勤しない限り、土日にプログラミングすることはなかったので、休みには体を休めることができました。副業でお金をもらってソフトウェア開発をするには、若くても体調管理をしっかりとする必要があるかと思います。


スポンサーリンク





コメント(0) 

デバッグを支える知識(3) [プログラマー現役続行]

以前、「デバッグを支える知識」として次の記事を書いています。
また、デバッグの科学的手法を「デバッグの科学的手法」で述べていますが、再度『ビューティフルコード』の第28章から引用すると以下の通りです。
1. プログラムの失敗を観察する
2. 観察と矛盾しない失敗の原因についての仮説を立てる
3. 仮説を使って予想する
4. 予想を実験でテストして、さらに観察する
 a. 実験と観察が予想を満たすなら、仮説をさらに精緻なものにする
 b. 満たさないなら、別の仮説を立てる
5. 仮説がこれ以上精緻にできなくなるまで、手順3と4を繰り返す。
この「仮説」を立てるために必要なのが「知識」です。バグに直面したときには、仮説を立てるために必要な知識が不足していても、今日ではある程度ネットで調べて補えます。しかし、本質的な知識の欠如は、デバッグを阻みます。

メルペイ社で働き始めて、私にとってはGCP(Google Cloud Platorm)やKubernetesは初めての経験です。そもそもAWSもほとんどやったことがないです。結果として数時間ではなく、数日の単位で行き詰まったデバッグが今までに3件ありました。3件とも解決はしましたが、最近経験した3件目は、ほぼ完全に行き詰まった状態で、それまでの状況を再度整理して社内のSlackで流したら、「○○をやってみたら」という返事があり、それで解決しました。
※ 1996年9月に日本オラクルに入ってからデータベースを勉強した経験に似ています。

解決してしまえば、現象を説明できる原因、それにもらった助言の意味を理解できたのですが、私自身は、現象から原因への仮説を立てるのがほぼ行き詰まっている状態でした。このような経験により仮説を立てるための知識が少し増えたことになりますが、やはり、1時間で解決したかった種類の不具合でした。

コメント(0) 

オフィスと技術書 [オフィス]

今日、技術書は電子版と紙版のどちらかを購入できるものが多くなっています。電子版の場合、オフィスに書籍のための空間は必要ありません。一方、紙の本では物理的に置く場所が必要となります。私自身は色々な職場でソフトウェア開発をしてきたのですが、オフィスと技術書というテーマで過去を(忘れにうちに)振り返ってみたいと思います。

1984年に富士ゼロックスに入社して、Fuji Xerox 6060 Workstationの開発グループに配属されてワークステーションの開発に従事しました。机は普通の事務机でした。ワークステーションを開発しているといっても、机の上には何も無かったと思います。ソフトウェア開発用にVAX (780?)を使っていたのですが、端末は自分の机の上には無かったと思います。そのため技術書を持ってきても、すべて「机の上か袖机の中」のどちらかに入れていたと思います。この状態は、1988年11月に米国El Segundo, CAへ駐在で赴任するまで続いていました。

米国では個室で、SunワークステーションとStarワークステーションを使ってソフトウェア開発をしていていました。オフィスには3段ぐらいの「書棚」があったので、そこに自分の技術書を置いていました。1991年4月にゼロックス社のPalto Alto研究所へ転勤して、そこも個室でした。ここでも本棚があったと思います。結局、4年半の米国では、個室で、書棚があったので自分の技術書を置いていました。

1993年5月に日本に戻ってきたときは、勤務地が溝口にある神奈川サイエンスパーク(KSP)だったのですが、オフィスはパーティションになっていました。パーティションは上の部分が棚になっていたので本棚として使っていました。棚に入りきれない分は、袖机の中に入れていたと思います。

自分の本を会社へ持って行くときは、たいてい1冊ずつなので問題はないのですが、問題は会社を退職したときです。就職してから米国駐在、そして帰国してKSPへというのは富士ゼロックス内の話です、書籍もすべて会社の引っ越し費用で移動させていました。しかし、「退職」となると話が変わります。

KSPに勤務していた頃は、車も持っていなかったので、毎日少しずつ自宅へ持って帰りました。今から考えると段ポールに詰めて郵便局から送ってしまえばよかったと思います。

1996年9月から日本オラクルで働き始めましたが、書籍は、袖机の中に入れていました。在籍期間も短くて、多くの本を会社へ持って行くことはありませんでした。

1997年5月から徳島のジャストシステムで働いたのですが、パーティションになっていて上の方は棚になっていたので本棚として使っていました。半年後に新社屋に移りました。そこもパーティションでしたが、キャスター付きの3段の書棚が与えられていたので、かなりの数の本を会社へ持って行っていました。ジャストシステムを退職するときは、書棚を駐車場まで押して行き、本を車のトランクに移し替えて自宅まで持って帰りました。

1998年5月からは、富士ゼロックス情報システム(FXIS)で働き始め、海老名にあるプライムタワーというビルが勤務地でした。オフィスはパーティンションで、いつものように棚になっているので、かなりの本を会社に持っていきました。棚だけではたりず、袖机、さらに、別途共用のドロワーの一部を割り当ててもらいました。2009年8月末に退職するときには、かなりの数の技術書を会社に持って行っていたのですが、さすがに半分は会社に寄贈して、残り半分を近くの郵便局から段ポールで自宅に送付しました。

2009年9月からリコーの大森事業所で働き始めました。最初に違和感を持ったのは職場にほとんど技術書がないことです。フロアに書棚が1つある程度で、個人の机の上にはほとんどないことです。袖机の中にでも入れているのかと思いましたが、実際はそうでなく、全体として自分の技術書を会社に持ってくるという人が少なかったようです。

リコーに勤務した8年間は、富士ゼロックスグループ勤務の頃と比較すると職場の技術書の数は圧倒的にに少なかったです。海老名のプライムタワーの頃は、自分の会社(FXIS)や親会社(富士ゼロックス)のフロアで働いていたのですが、多くのエンジニアが自費で購入した書籍を会社に持ってきていたので、自分が持っていない本で調べたいときは、フロアを歩き回って、各人のパーティションの棚を探せば見つかったものです
※ 現在の富士ゼロックスや関連会社の職場がどのようになっているかは全く知らないです。

退職時の大変さを何回か経験して、リコーでは自分の技術書を会社には極力持って行かないようにしました。しかし、8年間勤務したあとの退職時には、段ボール箱で1箱分の技術書を着払いで会社から自宅へ送りました。

2017年9月からソラミツ社に勤務し、今年の6月からメルペイ社で働いていますが、今の個人的方針は、会社で参照するために置いておきたい「紙の技術書」は自分で購入しないということです。つまり、会社購入で、退職時にはそのまま置いていける状態にすることです。

富士ゼロックスグループでの勤務が長かった(合計で約23年間)ので、私は必要な技術書は自分の机から手が届くところに置いておきた方です。それは、自分の本や会社で購入した本に関係なくです。したがって、「技術書の購入も全額支援します」とサポートしてくれるにしても、各人が自分の机の上に置くための空間がないオフィスはどんなものかなと思います。普段、業務中に参照する技術書は、各人が手元に置いておけるオフィス空間が必要だと思います。

一方で、昔と違ってインターネットで検索したり、電子版の書籍を使ったりするのであれば、紙の本を置く空間がオフィスには必要ないのかもしれません。
コメント(0) 

『Effective Java 第3版』の正誤表 [Effective Java 第3版]

Effective Java 第3版

Effective Java 第3版

  • 作者: Joshua Bloch
  • 出版社/メーカー: 丸善出版
  • 発売日: 2018/10/30
  • メディア: 単行本(ソフトカバー)

『Effective Java 第3版』の正誤表を私のホームページに用意しました。


「正誤表」のタグを選んでもらえれば表示されます。

コメント(0) 

メルペイで5か月が過ぎました [プログラマー現役続行]

2018年6月1日にメルペイ社に入社(メルカリから出向の形態)して働き始めて5か月が過ぎました。

【仕事】メルペイが提供するサービスを構成するバックエンドのマイクロサービスの1つの開発を担当しています。開発言語はGo言語です。マイクロサービスが提供するAPIはgRPCベースですので、提供する機能の仕様をprotoファイルに書く作業をしばらく行っていました(「API仕様を書く」)。

最初から最終版のAPI仕様を書くことは不可能ですが、最初の仕様ができあがったので、テスト方法の検討と実装です。私が担当しているマイクロサービスは複数のマイクロサービスに依存しているので、どのようにe2eテストコードを書くかを検討しました。要件としては、以下の項目を最初に考えました。
  • 担当するマイクロサービスを起動して、gRPCを本当に呼び出してテストできること
  • 依存するマイクロサービスのgRPCを本当に呼び出すこと
  • 依存するマイクロサービスの振る舞いを、テストコードに記述できること(RPCが呼び出されたら、返すレスポンスをテストコードで記述できること)
  • テストを実行したら、担当するマイクロサービスのカバレッジが取れること
  • このe2eテストをCIで実行できること
これらの要件を満たす方法を検討・実装した後は、担当するマイクロサービスが提供する機能を実装したり、必要に応じたAPI仕様の修正したりといった開発業務を行っています。また、開発環境にデプロイされた後に、外部から疎通テストを行うテストの開発も行っています。

【学習】長年、デジタル複合機のコントローラソフトウェア開発に従事していて、組み込み系がほとんどだったので、使っているクラウド技術は全く初めてのものばかりです。基盤としてはKubernetesを使っているので、読むべき本をAmazonで自分なりに調べて、『Kubernetes in Action』を選びました。読みながら実際に手を動かして学習してきました(まだ全部は読み終えていません)。本に従って、開発環境を整備したり、Google CloudにKubenetesを設定しながら学習することできます。

Kubernetes in Action

Kubernetes in Action

  • 作者: Marko Luksa
  • 出版社/メーカー: Manning Publications
  • 発売日: 2018/01/20
  • メディア: ペーパーバック

【勤務時間】基本的に7時30分頃に出社して、16時過ぎには退社します。通勤時間は、往復で4時間を超えています。16時過ぎには退社するので、19時過ぎに行われることが多い各種イベント(社内向け、社外向け)に出席することはありません。

【副業】副業をそのものは禁止されていませんが、メルペイ社に入社前から行っていた以下の副業は続けています。
  • 技術書の翻訳
  • 講演や技術教育
技術教育に関しては、今年はリクルートテクノロジーズ社向けの「Go言語研修」が主です。『Effective Java 第3版』の翻訳原稿を用いたJava研修の補講もやりました。今後は、企業向けの「『Effective Java 第3版』研修」も予定しています。

コメント(0) 

ロック(ミューテックス)の再入可能性 [プログラマー現役続行]

Go言語で提供されているsync.Mutexは、再入可能(re-entrant)ではありません。それについては、『プログラミング言語Go』(p,306)には次のように書かれています。
Go のミューテックスが再入可能ではないことには正当な理由があります。ミューテックスの目的は、共有された変数のある種の不変式がプログラム実行中の重要な時点で維持されているのを保証することです。不変式の一つは、「共有された変数へアクセスするゴルーチンが存在しない」*2ですが、ミューテックスが保護しているデータ構造に特有の追加の不変式が存在するかもしれません。一つのゴルーチンがミューテックスロックを獲得したときには、そのゴルーチンは不変式が維持されていると想定するでしょう。ロックを保持している間に共有された変数が更新され、一時的に不変式が破られるかもしれません。しかし、ロックを解放するときには、秩序が回復されて不変式が再び維持されていることを保証しなければなりません。再入可能なミューテックスは他のゴルーチンが共有された変数へアクセスしていないことを保証するでしょうが、それらの変数の追加の不変式を保護することはできません。
*2 訳注:ゴルーチンがミューテックスロックを獲得する前の時点とそのロックを解放した時点で「共有された変数へアクセスするゴルーチンが存在しない」という意味です。この段落は、ミューテックスロックが獲得されていない場合の不変式について言及しています。
一方、Javaのオブジェクトのロック(モニター)は、再入可能です。つまり、同じスレッドが同じロックを複数回獲得できます。

私自身がマルチスレッドプログラミングを本格的に行ったのは、Solaris 2.3を用いていたFuji Xerox DocuStation IM 200の開発です。当時、Solaris 2.3で提供されていたC言語用のスレッドライブラリ(POSIX Threadが登場する前です)は、再入可能なロックは提供していませんでした。そのためデッドロックが発生すると、場合によってはC++のメンバー関数の分割を行ったものです。privateのロックを獲得しないメンバー関数と、ロックを獲得してprivateのメンバー関数を呼ぶpublicの公開用のメンバー関数へと分割します。この分割については、上記の『プログラミング言語Go』にも書かれています。

IM 200が商品化された後の1996年にJavaを学び始めた時に、ロックが再入可能だというのは非常に魅力的に思えました。Javaの影響を受けて、2000年に設計したC++用のスレッドライブラリ(「clibと呼ばれるライブラリー開発の思い出」)では、再入可能なロックを提供するCSynchronizerというクラスを用意しました。そのライブラリを用いた最初の商品開発では、オブジェクトを介してスレッド間で同期するという設計は行われていませんでしたので、再入可能であることはそれほど利点がありませんでした。

2003年から2009年に従事したコントローラソフトウェア開発では、clibを用いてマルチスレッドプログラミングをかなり行ったのですが、再入可能であるために起きる問題に悩まされて、マルチスレッドプログラミングの難しさを痛感したものです。幸い、その開発は完全なテスト駆動開発でしたので、「マルチスレッドプログラミングにおける重要な4要件」を満たしており、様々な問題を解決する経験を積むことができました。このソフトウェア開発で経験した問題は、『Effective Java 第3版』でJoshua Blochが述べていることそのものでした。
再入可能ロックは、マルチスレッドのオブジェクト指向プログラムの作成を単純化しますが、活性エラーを安全性エラーに変える可能性があります。

『Effective Java 第3版』(p.319)

活性エラーはデッドロックとして表面化しますが、安全性エラーはコードが動作しているように見えるが正しく動作していないという問題を引き起こします。特に競合状態(race condition)により引き起こされる問題は、現象の再現性も低く、調査が非常に難しいことが多いです。

2013年7月から2015年5月まで行ったコントローラソフトウェア開発は、私にとっては4回目のコントローラソフトウェア開発でしたが、マルチスレッドプログラミングの複雑さをGo言語のゴルーチンとチャネルで軽減できないかの検証も狙っていました。しかし、やはりデジタル複合機のコントローラソフトウェアは複雑であり、デッドロックはよく発生しましたし、競合状態も発生しました。幸い、Go言語には競合検出機能が提供されているので、その点は助かりました。

現在、従事しているソフトウェア開発では、再入可能性が問題となるような複雑なソフトウェア開発は行っていません。その点では、4回のデジタル複合機のコントローラソフトウェア開発は、私に貴重な経験を与えてくれたと言えます。

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)

  • 作者: Alan A.A. Donovan
  • 出版社/メーカー: 丸善出版
  • 発売日: 2016/06/20
  • メディア: 単行本(ソフトカバー)

Effective Java 第3版

Effective Java 第3版

  • 作者: Joshua Bloch
  • 出版社/メーカー: 丸善出版
  • 発売日: 2018/10/30
  • メディア: 単行本(ソフトカバー)


コメント(0) 

『Effective Java 第3版』と『Java Puzzlers』ー パズル91 ー [Effective Java 第3版]

『Effective Java 第3版』の「項目88 防御的にreadObjectメソッドを書く」で言及されているのがパズル91です。
パズル91 連続殺人犯(Serial Killer)

このプログラムは、オブジェクトを生成して、それがクラスの不変式に従っているかを検査しています。それから、プログラムはオブジェクトをシリアライズして、ディシリアライズし、そして、そのディシリアライズしたコピーもその不変式に従っているかを検査しています。 従っていますか? 従っていないとしたら、なぜですか?
import java.util.*;
import java.io.*;

public class SerialKiller {
    public static void main(String[] args) {
        Sub sub = new Sub(666); 
        sub.checkInvariant();

        Sub copy = (Sub) deepCopy(sub);
        copy.checkInvariant();
    }

    // シリアライズで引数をコピー(パズル80参照)
    static public Object deepCopy(Object obj) {
        try {
            ByteArrayOutputStream bos = 
                new ByteArrayOutputStream();
            new ObjectOutputStream(bos).writeObject(obj);
            ByteArrayInputStream bin =
                new ByteArrayInputStream(bos.toByteArray());
            return new ObjectInputStream(bin).readObject(); 
        } catch(Exception e) {
            throw new IllegalArgumentException(e); 
        }
    }
}

class Super implements Serializable {
    final Set set = new HashSet();
} 

final class Sub extends Super {
    private int id;
    public Sub(int id) {
        this.id = id;
        set.add(this); // 不変式の確立
    }

    public void checkInvariant() {
        if (!set.contains(this))
            throw new AssertionError("invariant violated");
    }

    public int hashCode() {
        return id;
    }

    public boolean equals(Object o) {
        return (o instanceof Sub) && (id == ((Sub)o).id);
    }
}

Effective Java 第3版

Effective Java 第3版

  • 作者: Joshua Bloch
  • 出版社/メーカー: 丸善出版
  • 発売日: 2018/10/30
  • メディア: 単行本(ソフトカバー)

Java Puzzlers 罠、落とし穴、コーナーケース

Java Puzzlers 罠、落とし穴、コーナーケース

  • 作者: ジョシュア・ブロック
  • 出版社/メーカー: ピアソン・エデュケーション
  • 発売日: 2005/11/14
  • メディア: 大型本


コメント(0) 

『Effective Java 第3版』と『Java Puzzlers』ー パズル51 ー [Effective Java 第3版]

『Effective Java 第3版』の「項目83 遅延初期化を注意して使う」で言及されているのがパズル51です。
パズル51 何が言いたいの?(What's the Point?)

このプログラムは、2つの不変な値クラス(value class)、すなわち、そのイン>スタンスが値を表すクラスを持っています。1つのクラスは、整数座標を持つ面上の点を表しています。そして、2番目のクラスは、このパズルにちょっと色を添えています。mainプログラムは、2番目のクラスのインスタンスを生成して表示しています。このプログラムは、何を表示しますか?
class Point {
    protected final int x, y;
    private final String name; // 生成時にキャッシュされる
    Point(int x, int y) {
        this.x = x;
        this.y = y;
        name = makeName();
    }

    protected String makeName() {
        return "[" + x + "," + y + "]";
    }

    public final String toString() {
        return name;
    }
}

public class ColorPoint extends Point {
    private final String color;
    ColorPoint(int x, int y, String color) {
        super(x, y);
        this.color = color;
    }

    protected String makeName() {
       return super.makeName() + ":" + color;
    }

    public static void main(String[] args) {
        System.out.println(new ColorPoint(4, 2, "purple"));
    }
}

Effective Java 第3版

Effective Java 第3版

  • 作者: Joshua Bloch
  • 出版社/メーカー: 丸善出版
  • 発売日: 2018/10/30
  • メディア: 単行本(ソフトカバー)

Java Puzzlers 罠、落とし穴、コーナーケース

Java Puzzlers 罠、落とし穴、コーナーケース

  • 作者: ジョシュア・ブロック
  • 出版社/メーカー: ピアソン・エデュケーション
  • 発売日: 2005/11/14
  • メディア: 大型本


コメント(0) 
前の10件 | -