So-net無料ブログ作成
検索選択

PDF版『Java 2 Standard Edition 5.0 Tiger』を更新しました [プログラマー現役続行]

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

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


出版してからすでに8年が経過していますが、「PDF版」を公開しています。書籍は初刷りで終わってしまいましたので、誤りの修正はすべてこのPDFに反映して公開しています。

今回は、Java研修で指摘された説明の誤りを1点だけ修正しています。

言語仕様の制約を理解するためには、コンパイラがどのようなことを行っているのかとか、1.4まではどうであったかを理解する必要がある場合があります。そのために、Java研修では、『プログラミング言語Java第4版』に加えて、本書を予習範囲のテキストに加えています。

ソフトウェアエンジニアとしての評価 [プログラマー現役続行]

拙著『プログラマー”まだまだ”現役続行』 では、ソフトウェア・スキル・インデックスとして以下の7段階を紹介しています。

初心者(1) ソフトウェア開発を行うには、プログラミングの基礎知識や、コンピュータに関する基礎知識が不足している
見習い(2) 指導を受けながら実践ができる
初級職人(3) 見習いレベルの実践はできるが、時々指導が必要である
中級職人(4) 必要な技術を仕事の上で自然に自動的に使っている
上級職人(5) 新たな技術も含めて自分で常に学習を行い、自然と実践できている
名人(6) 技術を完全に消化し、いつルールを破るべきか知っている。また、技術記事などを執筆している。さらに、中級職人以下の職人を上級職人にすべく、組織に対して教育・指導を行っている
匠(7) 専門書を著作し、講演し、技術を拡張する方法を業界に問う。一方で、より良い方法で職人を育成するための方法も探求している。

社内の評価というのは相対評価であり、ソフトウェアエンジニアとしてのキャリアパスを続けるためのモチベーションを維持するためには、外向きの活動が必要だということで、「名人」「匠」を定義しています。

このソフトウェア・スキル・インデックス吉澤正孝さんと検討してまとめたのは、かなり前のことです。2007年に出版した『プログラマー現役続行』には掲載していますので、2005年か2006年に検討したのだと思います。

残念ながら、ここで定義されている「名人」「匠」のような活動をすることで社外からは評価されるようになっても、日本の多くの企業(特に大企業)では、社内からは評価されないかもしれません。その理由の一つは、名人や匠で定義している活動は、社内の評価基準に存在しなかったりするからです。もう一つの理由は、評価する側がそのような活動に関心を持たないからです。つまり、社外向けの著作物の内容を評価する側が読んだりしたことがないからではないでしょうか。実は、仮に評価基準が存在したとしても、後者の理由により評価されないかもしれません。

たとえば、ベストラー作家として何冊も著書がある人でも、その人を本当に評価するのは読者です。名前は知っていても、一冊も著書を読んだことがなければ、一個人として高い評価をすることはありません。これと同じで、企業内での評価は、評価する側がどれだけ関心を持ってその人の活動の内容やその人そのものを知っているかによって決まるのかもしれません。

結局のところ、社内の評価を気にしないで、外向きの活動と若手育成を行っていくことが「名人」「匠」の定義となります。

書籍『The REST API Design Handbook』 [本]


最近読み始めた書籍です。電子版しかない専門書であり、$4.25(Amazon.co.jpでは396円)しかしませんが、きちんと要点がまとまっていて分かり易く書かれています。私自身は、今までREST関連の技術書は読んだことがないのですが、最初に読む本としては適しているかと思います。

書籍『The Cucumber Book』と『Cucumber Recipes』 [本]

The Cucumber Book: Behaviour-Driven Development for Testers and Developers (Pragmatic Programmers)

The Cucumber Book: Behaviour-Driven Development for Testers and Developers (Pragmatic Programmers)



Cucumber Recipes: Automate Anything With BDD Tools and Techniques (Pragmatic Programmers)

Cucumber Recipes: Automate Anything With BDD Tools and Techniques (Pragmatic Programmers)

  • 作者: Ian Dees
  • 出版社/メーカー: Pragmatic Bookshelf
  • 発売日: 2013/02/19
  • メディア: ペーパーバック

先月からアプリケーションの自動テストということで、Cucumberの学習用に読み始めたのが『The Cucumber Book』です。こちらの書籍は、インストールから始まって、ステップ・バイ・ステップに学習する方法で、実際に手を動かしながら学習するには適しています。私の学習は、第14章「Bootstrapping Rails」のところで上手くいかず躓いています。

『Cucumber Recipes』は、色々な環境でCucumberを使用したテストを行う方法が環境ごとにまとめてあります。私自身は、ここで述べられているSwingアプリケーションの自動テストの説明を参考に、JRuby、Festを組み合わせて簡単なSwingアプリケーションの自動テストを行う小さな学習用プロジェクトの環境構築を行いました。

残念ながらJenkins(CentOS上)でGUIテストを動作させることまでは述べられていませんので、この小さなGUIテスト環境をJenkins上で動作させるのにはちょっとした工夫が必要でした。

Behaviour-Driven Developmentということで、Cucumberを学ぶには良い書籍だと思います。ただし、どちらも日本語には翻訳されていません。

ラムダ式(2) [Java 8]

ラムダ式に実際に渡されているオブジェクトが何であるかを調べるためのテストコードです。
import java.util.Arrays;
import java.util.function.Consumer;

public class Lambda02 {
    public static void main(String[] args) {
        showInfoOfLambda(msg -> System.out.println(msg));
    }

    private static void showInfoOfLambda(Consumer<String> consumer) {
        consumer.accept("Hello World");

        Class<?> consumerClass = consumer.getClass();
        System.out.printf("class name : %s%n", consumerClass.getName());
        showImplementedInterfaces(consumerClass);
        showSuperclass(consumerClass);
    }

    private static void showImplementedInterfaces(Class<?> consumerClass) {
        Class<?>[] interfaces = consumerClass.getInterfaces();

        if (interfaces.length == 0) {
            System.out.println("no interface is implemented");
            return;
        }

        System.out.print("implements : ");
        Arrays.asList(interfaces).forEach(
            cl -> System.out.printf("%s ", cl));
        System.out.println();
    }

    private static void showSuperclass(Class<?> consumerClass) {
        System.out.printf("superclass : %s%n",
                         consumerClass.getSuperclass());
    }
}
ラムダ式を受け付けるメソッドとしてshowInfoOfLambdaメソッドを定義して、mainメソッドで引数を表示するだけのラムダ式を渡しています。

showInfoOfLambdaでは、最初に、Consumerインタフェースとして渡された引数に対して、acceptメソッドを呼び出しています。次に渡されたオブジェクトのクラス、実装しているインタフェース、スーパークラスと順に表示しています。

このプログラムをコンパイルして実行すると、次の結果になります。
shibata-yoshiki-no-macbook:java8study yoshiki$ javac Lambda02.java
shibata-yoshiki-no-macbook:java8study yoshiki$ java Lambda02
Hello World
class name : Lambda02$$Lambda$1
implements : interface java.util.function.Consumer 
superclass : class java.lang.invoke.MagicLambdaImpl
shibata-yoshiki-no-macbook:java8study yoshiki$ ls -l *.class
-rw-r--r--  1 yoshiki  staff  2313  3 17 11:07 Lambda02.class
shibata-yoshiki-no-macbook:java8study yoshiki$ 
実際に渡されているオブジェクトのクラスは、Lambda02$$Lambda$1、実装しているインタフェースはjava.util.function.Consumer、スーパークラスは java.lang.invoke.MagicLambdaImplと表示されています。

また、コンパイル結果の.classファイルは、Lambda02.classしかありません。したがって、Lambda02$$Lambda$1は、実行時に動的に生成されていることが推測されます。

ラムダ式(1) [Java 8]

Java 8では、Java言語の仕様が大きく変わります。新たな言語仕様にキャッチアップするために学習を始めたので、メモ程度ですが、分かったことを順不同に今後書いていきたいを思います。したがって、新たな言語仕様のチュートリアルではありませんので注意してください。

ラムダ式は、現在、EarlyAccess版のOpenJDKで使用でき、以下のサイトからダウンロードできます。

http://jdk8.java.net/lambda/

Java 8ではIterableインタフェースにforEach()メソッドが追加されていますので、Iterableインタフェースを実装しているコレクションを使用して、次のようなコードを書くことができます。
import java.util.List;
import java.util.ArrayList;

public class Lambda01 {
    public static void main(String[] args) {
        List<String> messages = new ArrayList<>();

        messages.add("Hello");
        messages.add("World");

        messages.forEach(msg -> System.out.printf("%s ", msg));
        System.out.println();
    }
}
forEach()メソッドには、引数msgを受け取り、それを出力するという簡単なラムダ式が渡されています。コンパイルして実行した結果は、次の通りです。
C:\Users\Yoshiki Shibata\Desktop\java8study>javac Lambda01.java

C:\Users\Yoshiki Shibata\Desktop\java8study>java Lambda01
Hello World
ここで不思議に思うのは、forEach()メソッドの引数の型はIterableインタフェースではどのように定義されているかということです。調べて見ると次のようになっています(コメントは削ってあります)。
package java.lang;

import java.util.Iterator;
import java.util.function.Consumer;

@FunctionalInterface
public interface Iterable {
    Iterator<T> iterator();

    public default void forEach(Consumer<? super T> consumer) {
        for (T t : this) {
            consumer.accept(t);
        }
    }
}
インタフェースのなのにメソッドの実装が書かれていることは今回は無視して、引数の型はConsumerインタフェース型となっています。Java 6までの言語仕様の知識から、「Consumberインタフェースを実装した無名クラスをコンパイラが生成しているのでは」と単純に推測できます。

しかし、コンパイル結果としては、Lambda01.classファイルしか存在しません。それで、javapで調べると次のような結果となります。
C:\Users\Yoshiki Shibata\Desktop\java8study>javap -p Lambda01
Compiled from "Lambda01.java"
public class Lambda01 {
  public Lambda01();
  public static void main(java.lang.String[]);
  private static void lambda$0(java.lang.String);
}
forEach()メソッドに渡したラムダ式の実体は、どうもこの lambda$0(java.lang.String)のようです。でも、acceptという名前でないし、一体どうやってConsumerインタフェースとして渡されているのかが不思議になります。(続く)

英語とTOEIC(2) [英語]

英語能力を測定する指標としてTOEICが日本では広く使用されており、私自身も1984年に社会人になった時に初めて受験して600点でした。その後も時々受験してきました。

最近の若い人たちの勉強方法を見ていると、TOEICの目標点数を決めて、それを達成するためにTOEIC対策本を購入し、その対策本を勉強しているという人が多いようです。確かに、TOEICの試験形式と内容を考慮している対策本は短期的には効果的かもしれません。しかし、そのようなTOEIC対策勉強では、目標点数を達成したら、英語の学習はその後どうなるのでしょうか?

私自身は、大学時代、全く聞き取れないアルク社の雑誌「English Journal」のカセットテープを聞き、テレビドラマの音声だけを録音して聞くということ続けていました。現在でも、朝起きると、iPadを使用してPodcastで「Anderson Cooper 360」「CNN Student News」「BBC RADIO」などをながらで見ています。ほかにも、TEDを見たり、映画をみたりとしています。

英語力を向上させるための努力としては、ヒアリングに関してはニュース、映画、ドラマなどを聴き、リーディングに関してはたくさんのペーパーバックを読むなどを継続して行い、結果としてTOEICの点数が上がっていくというのが良いと思っています。映画やドラマを楽しみ、ペーパーバックで小説を楽しむのであれば、それは、習慣化していきます。そうすれば、TOEICでの目標点数を達成したからやめてしまうような活動ではなくなります。

TOEICの目標点数を達成したらやめてしまうよな勉強法ではなく、英語で様々なことを楽しむための努力を続けることをお勧めします。

書籍『アジャイル開発とスクラム』 [本]

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント


3部から構成され、全部で10章から構成されます。

第1部「アジャイル開発とは何か、スクラムとは何か」は、平鍋氏が執筆されており、アジャイル開発およびスクラムが分かりやすく解説されています。普段、アジャイル開発の手法を取り入れて開発をしているのであれば、日々の開発活動と対比しながら読むことができると思います。完全なウォータフォール開発しか経験したことがない人にとっては、なかなかピンとこないかもしれませんが、アジャイル開発とウォータフォール開発の違いを理解することができると思います。

「スクラム」という言葉は、本書の共著者である野中 郁次郎氏が竹内弘高氏と共著した"The New New Product Development Game"(Harvard Business Review, 1986)で用いられた言葉であることも紹介されています。アジャイル開発のスクラムの生みの親であるジェフ・サザーランド氏は、本書に掲載されているインタビューで、ソフトウェア開発のためのより良い組織構造を調査するプロジェクトにおけるこの論文との出会いを次のように答えています。
チームワークと生産性に関する数百の論文を読み終えたところで、私たちが探していた新しいソフトウェアの作り方に、最も影響を与えることになる論文に出会った。それが、竹内氏と野中氏の「The New New Product Development Game」だった。私たちがこの論文に出会ったとき、ここに書いてあることこそが探していたチーム構成とマネジメントの考え方である、と全員が納得したのを覚えている。
『アジャイル開発とスクラム』(p.222)
1996年に書かれた論文の主旨としては、次のように述べられています。
新製品開発という速さと柔軟性が求められる場面では、成果物を紙に書き、それを壁越しの別のチームに渡すようなリレーをしていてはだめである。様々な専門性を持った人が一つのチームを組み、ラグビーのように開発の最初から最後まで一緒に働くことが求められる。人とチームを重視し、彼らに自立的に動ける環境を与えることでブレークスルーが起こりやすくなると同時に製品化までの時間が短くなるというのがこの論文の主旨だ。
『アジャイル開発とスクラム』(p.199)
元の論文とアジャイル開発を比較して何が本質なのかが、第3部「アジャイル開発とスクラムを考える」として野中氏と平鍋氏により解説されています。

第2部「アジャイル開発とスクラムを実践する」では、リクルート、楽天、富士通でのアジャイル開発の導入事例が紹介されています。

本書は、副題に「顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント」となっているように、現場のエンジニアだけなくマネジメント層にも向けた内容となっています。より優れたソフトウェア開発組織を作りだし、迅速な製品開発を行うために、アジャイル開発がソフトウェア開発における大きな流れであることを理解するのに役立つ一冊と言えます。