JavaGold SE11の感想

JavaGold SE11を無事に取得できた。
試験勉強を通じて、有意義な経験を得られたと思う。
ラフなメモ書き。
間違っていたら後で直す。

【参考】
Java歴13年がJava Gold(SE 11)を受けてみた - yucatio@システムエンジニア

JavaGoldSE8に受かったので(前編) - Qiita

JavaGoldSE8に受かったので(中編) - Qiita

JavaGoldSE8に受かったので(後編) - Qiita

JavaSilverの感想～Javaはオブジェクト指向と関数型言語の2つの性格を持つ: プログラマの思索

Javaはなぜ関数型言語になろうとしているのか: プログラマの思索

【1】受験のきっかけ
コロナ禍がずっと続いて、リモートワークになりプライベートでも対面の付き合いがほとんどなくなって、余った時間を有効活用したい。
過去にJavaで開発していた頃はせいぜいJava5くらいで、それ以降のバージョンは完全に理解できていなかったので、ラムダ式等をきちんと習得したい。
15年以上前にSunのJava試験を受けて落ちたのでリベンジしたい。

【2】勉強方法
「オラクル認定資格教科書 Javaプログラマ Gold SE11（試験番号1Z0-816）」(通称、紫本)と『徹底攻略Java SE 11 Gold問題集[1Z0-816]対応』(通称、黒本)を最終的に5回転以上回した。
黒本だけでは理解できず、紫本を5回転以上回して慣れる必要があった。
なお『徹底攻略Java SE 11 Gold問題集[1Z0-816]対応』の「総仕上げ問題」は実際の試験問題に似ているのでやるべき。

【3】JavaSilverは「Javaはオブジェクト指向である」ことを設計でもコーディングでも理解できれば合格できる。
しかし、JavaGoldは「Javaは関数型言語である」こと、特にラムダ式を使って設計でもコーディングでも理解する必要があった。
頻出論点は、ストリームAPIと関数型インターフェイス、モジュールシステムだったと思う。
僕には正直難しかった。
理由は、オブジェクト指向プログラミングはUMLによるモデリングを通じて経験していたが、関数型言語プログラミングのお作法もその概念も理解していなかったから。
「OptionalはMaybeモナド、ストリームAPIはMapReduceでありリストモナド、入出力APIはIOモナド」ということを最終的に理解する必要があるのではと思った。

【4】 第1章　クラスとインタフェース

なぜ内部クラス(inner class)が必要なのか？
2つのクラスソースファルを1つにまとめる必要がある時に使う。

内部クラス→static内部クラス→ローカルクラス→匿名クラス→ラムダ式　の順に昇華されていく。
よって、ラムダ式の発端は内部クラスにある。

インナークラスのインスタンス化には、エンクロージングクラスのインスタンス化が必要である。
つまり、無意味なインスタンス化のロジックが発生する。
そこで、インナークラスをstaticインナークラスにすれば解決できる。
staticインナークラスならば、エンクロージングクラスのインスタンス化無しで、インナークラスのインスタンス化ができる。
staticインナークラスにすれば、staticなインナークラスのフィールドやメソッドをエンクロージングクラスでそのまま参照できる。

staticなインナークラスでは、フィールドやメソッドの参照はコンパイルエラーになる。
一方、staticでないインナークラスでは、フィールドやメソッドを参照できる。

Effective Javaでは、「内部クラスにはstaticを付けるべき」というプラクティスがある。

内部クラスにstaticを付けると、内部クラスから外部クラス(エンクロージングクラスとも言う)のフィールド変数にアクセスできなくなる。
つまり、スコープが小さくなる。

ローカルクラスから参照するローカル変数は、実質finalが必須。
実質finalでなければコンパイルエラーになる。
ローカルクラスから参照するローカル変数を、ローカルクラスの後で変更するとコンパイルエラーになる。
この仕様は関数型言語のイミュータブルな性質に似ているので、そのような仕様にJavaが合わせたのではないか。

一方、RubyやPythonのクロージャでは、ローカル変数を変更しても問題なく動く。
Rubyのブロックはメソッドによる手続きブロックとは異なって、ブロックの外側で定義されたローカル変数をブロック内で参照・変更できるという性質を有する。ただブロック内で定義された変数はその外側で参照できない。

無名クラスは、メソッド内に無名のインナークラスを定義するので、ラムダ式。と実質同じ。
Effective Javaでは、「無名クラスよりもラムダを選ぶ」プラクティスがある。
無名クラスは冗長な記述であり、ラムダ式の方が簡潔に書けるからだ。

匿名クラスにコンストラクタは定義できない。
しかしインスタンス初期化子を使えば、似たような処理を行うことが出来る。

インターフェイスのdefault/privateメソッドは、Scalaのtrait, Rubyのmoduleと同じ。
ただし、インターフェイスを継承した2階層下のクラスや2階層下のインターフェイスでは使えない。
インターフェイスのstaticメソッドは、継承直下の子クラスのみ利用できる。
privateメソッドはdefaultメソッドから呼び出されることを前提としている。
インターフェイスは型の提供が目的であり、メソッドの実装は基本は実装クラスが提供する。
インターフェイスのstaticメソッドとラムダ式のおかげで、Factroyクラスが不要になった。

なぜJavaのインターフェイスがのstatic/default/privateメソッドを必要とするのか、理由が分からなかった。
たぶん、Scalaのtrait, Rubyのmoduleを真似て、共通ロジックをわざわざインスタンス化して利用する面倒な手続きを減らしたい意図があるのだろう。

Enumはシングルトンクラス。
Effective Javaでは、Enumに独自に新規メソッドを実装するプラクティスがある。

Javaのenum型はシングルトンクラスみたいだ: プログラマの思索

Effective Java 第３版 第６章enumとアノテーション - Qiitaでは、int型をEnu型で書くべき、というプラクティスは理解できる。
しかし、「拡張可能なenumをインタフェースで模倣する」プラクティスのように、通貨クラスに「＋」「-」のようなメソッドを独自で実装するという発想はなかった。
こういう考え方がドメイン駆動設計の値オブジェクトの実装に役立つのだろう。

【5】 第2章　関数型インタフェースとラムダ式

Javaのラムダ式は、関数型インフェーエイスの宣言とインスタンスの生成を同時に行う文法とみなす。
つまり、ラムダ式＝関数型インターフェイス(抽象メソッド1個だけ)＋インスタンス生成。

ラムダ式を使えば、Factroyクラスは不要になる。
つまり、DIを実現するために、Factoryパターンを使い、その実装にラムダ式を使う。
ラムダ式を使えば、Strategyパターンを短く書ける。
ラムダ式をメソッドチェーンで書けば、Builderパターンを短く書ける。

Javaのラムダ式のローカル変数は、スコープ外では実質finalとして扱われる。
ローカル変数の値を更新するとコンパイルエラーになる。
この性質は関数型言語の特徴に似ていると思う。

@FunctionalInterfaceを付けたインターフェイスは、自動的に関数型インターフェースとして使用できるが、抽象メソッドは1個だけ限る。
他言語では関数1個で定義できるが、Javaは必ず関数をclassで囲む必要があるので、関数型IFで定義する必要がある。

Javaの関数型インターフェースの抽象メソッドで注意すべき点は、java.lang.Objectのメソッドはカウントされない。
たとえば、public abstract String toString()があれば、抽象メソッドにカウントしない。

ラムダ式を使うと何が嬉しいのか？
1.抽象メソッドを実装したクラスを最小のコード量で実装できる
2.抽象メソッドの実装と、メソッドを使うところを一つにできる

関数型インターフェイスには1つしか抽象メソッドがないので、戻り値・引数の型と順番を、関数型インターフェイスの型からJavaコンパイラが推測できる。この仕組みが型推論なわけだ。
だから、Haskellのような関数型言語はコンパイラを作りやすいという理由は、型推論が強力な特徴があるからだろう。

通常パターン；
* Function, XXXFunction ：apply()
* => 戻り値：R
* Supplier：get()
* => 戻り値：T
* Consumer, XXXConsumer ：accept()
* => 戻り値：void
* Predicate, XXXPredicate ：test()
* => 戻り値：boolean

特殊パターン：
* ToXXXFuntion:applyAsXXX()
* ToIntFunctionならapplyAsInt()のような感じ。
* XXXSupplierの形だけ注意！ => getAsXXX()
* IntSupplier：getAsInt()
* DoubleSupplier：getAsDouble()
* LongSupplier：：getAsLong()

UnaryOperator、BinaryOperator＝引数と戻り値の型が同じ。
引数と戻り値の型が同じなので、Gnericsは1つで良い。

【6】 第3章　並列処理

並行処理(concurrent)：処理を切り替えて同時に動いているように見せる。Threadクラスと同じ。
並列処理(parallel)：複数のコアで同時に処理を行う。ストリームAPIでparallelメソッドを使う。

Executor によって処理されるタスクの状態遷移図
created（タスク生成）　
→ submitted（キューにタスクを登録）　
→ started(タスクのrun実行)
→ completed（タスクの終了）

Thread.run()がキューに登録されて、Thread.start()で、run()が実行される。
キューに登録されたRunnable.run()が実行される。

なぜ、並列処理はラムダ式や匿名クラスを使うのか？
スレッドのタスクは、関数型インターフェイスRunnnableのラムダ式で実装されるから。

Future＝スレッドを生成したメソッドが、新しく作ったスレッドの結果を保持する。
submitの戻り値＝Future => Future.get()で取得できる。
list.add(services.submit( XX -> XX))を実行できる。
一方、executeの戻り値＝無し。

Runnable.run()はvoidなので、何も返さないから、Future.get()はNULLを返す。
Callable.run()は戻り値があるので、Future.get()は結果を返す。

Future fut = ex.submit( () -> {処理}, 0);　は、第2引数0を返す。

Callableで定義したタスクで例外が発生した時、ExecutionExceptionでキャッチする。

CyclicBarrier＝スレッドを待機させる。
java.util.concurrent.CyclicBarrierクラスを利用すると、複数のスレッドが特定のポイントまで到達するのを待機させることができる。
CyclicBarrier＝複数のスレッドが特定のポイントまで到達するのを待機できるようにする同期化支援機能を持つスレッドクラス。
スレッドN本目を通過すると、await()の待機は解除される。

* バリアー：複数スレッドの待ち合わせポイント
* バリアーアクション：待ち合わせ後に実行される処理

マルチスレッドで扱うクラスのフィールドにvolatile修飾子を付けると、キャッシュされなくなる。
これにより並列処理時にどちらかがキャッシュを読み込むことによる不整合をなくせる。

【7】 第4章　ストリームAPI

ストリームAPIとは何なのか？
一言で言えば、JavaのMapReduce用APIと思えばいい。
大量データをリストで引数として設置して、Mapで処理させて並列処理できるようにばらして、並列処理の結果をreduceで1つにまとめて戻り値に返す。

実際の問題では引っ掛けパターンが多い。

ラムダ式のローカル変数は実質finalなのに、2回代入している
ただし、ローカル変数が配列ならポインタ参照なので、2回代入はOK。
たとえば、ArrayListやint[]の場合。

ラムダ式を{}で書いたのに「;」なし。

ラムダ式の中で、varの引数はコンパイルOK。
つまり、ラムダ式内の処理の引数は型推論される。
ただし、varはメソッド引数やメンバ変数に使うとコンパイルエラーになる。

Stream<型>のようなGnericsで引っ掛けるパターンが多い。

* map(T -> R)とflatMap(T -> Stream)
* mapToInt()とmapToObject()
* mapToInt(ToIntFunction)とmap(T, R)
* pararell(Stream --> Stream)とpararellStream(Collection --> Stream)
* reduce(BinaryOperator --> Optional)とreduce(DoubleBinaryOperator -->DoubleStream)

終端操作を2回実行すると実行時に例外が発生する。
例：anyMatch, count, reduce, forEach, collect

中間操作だけで終わると、値は返却されない
例：peek

終端操作countだけ実行しても出力されない。System.out.println(count)が別途必要。

List.stream().pararell() <=> List.pararellStream()は同じ。

boxed()は、XXStream -> Streamへ変換する。
逆の操作は、Stream --> mapToInt(IntToIntFunction)--> IntStream。

reduce().orElse()でint型、double型を返す。

Javaのsumはreduceで置き換えられる: プログラマの思索

Javaのreduceの使い方は2種類ある: プログラマの思索

モナドとは「メソッド内の副作用の存在を戻り値の型で表現する」ためのデザインパターン。
「関数に副作用がある」ことを「戻り値の型」で表現している。
Genericsを使って、戻り値の型を増やしている。

なぜ関数型IFではGenericsが頻繁に使われるのか？
理由は、関数の副作用を戻り値の型で表現するために、Genericsを使って戻り値の方の個数を増やしているからと考える。

OptionalはMaybeモナド。
Optionalの語源：値がないかもしれない => オプションの値を作りましょう。

StreamはListモナド。
MapReduceの戻り値はOptionalを返す。
それにより、Nullの戻り値はなく、ヌルポを防げる。

IOはIOモナド。
入出力処理における副作用は、戻り値の型をGenericsで表現する。

StreamAPIはメソッドチェーンで書かれるので、処理の途中でどのように戻り値の型が変換されて遷移するのかわかりにくい。
そこで、StreamAPIはバラして考えるとよい。
Eclipseの「ローカル変数の抽出」を使って、メソッドチェーンをばらすといい。

【8】 第5章　入出力

java.ioパッケージは古い機能。
たとえば、Fileクラスは、ディレクトリやファイルへのパスを扱うだけで、ファイル自身を表すのではない。

java.nioパッケージは新しい機能なので、痒い所に手が届くようになっている。
nio.Filesクラスは新しい入出力API => 同じパスに同じファイルがあれば作成時に例外を発生させて検知してくれる。
NoSuchFileException - ファイルが存在しない場合
DirectoryNotEmptyException - ファイルがディレクトリで、ディレクトリが空でないために削除できなかった場合

FileクラスとFilesクラスの違いは覚える。
Fileクラス提供のisXXXメソッドは、引数を取りません。
* 例：File.isDirectory() : boolean
* 例：File.isFile() : boolean

Fileクラス提供のメソッドは、renameTo(dest)以外はほとんど引数を取りません。
* 例：dirFile.mkdir()
* 例：dirFile.mkdirs()
* 例：file.renameTo?(File dest)
* 例：dirFile.listFiles()
* 例：file.getAbsolutePath()
* 例：file.toPath()
* => new File("ファイル名").toPath()の形式でPathオブジェクトを生成する

Filesクラス提供のメソッドは、全て引数を取ります
これ覚えとくだけで事前にコンパイルエラーかわかるようになった。
* 例：Files.isDirectory(Path dirPath)
* 例：Files.deleteIfExists(Path path) =>ファイルやディレクトリが存在している場合だけ削除する
* 例：Files.list(Path dirpath): Stream =>ディレクトリ内の全てのパスを表示
* 例：Files.find(開始パス、深さ、BiPredicateオブジェクト、オプション): Stream
* 例：Files.isSameFile(path1 : Path, path2 : Path) : boolean : path1とpath2が同じか否か
* Files.move?(Path source, Path target, CopyOption... options)
* Files.copy?(Path source, Path target, CopyOption... options)

Files.walk(), Files.find()は引数を覚えるのが重要。
Filesクラスのwalk()は再帰的にパス情報を取ってくる。
Files.walk(開始パス、深さ、オプション)：サブディレクトリまで展開したパスを再帰的に表示
指定された開始ファイルをルートとするファイル・ツリーを参照することで Pathが遅延移入されるStreamを返します。

Filesクラスのfind()は再帰的にパス情報を処理して、判定条件に合致したファイルだけを探す。
Filesクラスのfind()の引数の順番は覚えたほうが良い。
Files.find(開始パス、深さ、BiPredicateオブジェクト、オプション)：サブディレクトリまで展開したパスを再帰的に処理して必要なフィルのみ表示
指定された開始ファイルをルートとするファイル・ツリー内でファイルを検索することで Pathが遅延設定されるStreamを返します。

XXのようにStreamがついてなければCharacterストリーム。
XXStreamのようにStreamがついていればByteストリーム。

getDefault()は、FileSystemsクラス, Localeクラスにある。
SystemDefault()はZoneIdクラスにある。

Serializableのtransient修飾子は、シリアライズ対象から外す。
デシリアライズ後はnullになる。
static変数は、シリアライズ対象外になる。
∵static変数はグローバル変数なので値は保持される。

【9】 第6章　JDBCによるデータベース連携

Statement　◇--PreparedStatement, CallableStatement

Statement 単純な実行計画を行いたい時(select * from ... を 1 回だけ など)
PreparedStatement 複数回に渡る実行計画を行いたい時, ? のパラメーター解析を使いたい時
CallableStatement ストアドプロシージャを実行

Statementは静的なSQLを扱い、PreparedStatementはプレースホルダを使った動的SQLを扱えます。
基本は、Statementクラスを用いずにjava.sql.PreparedStatementクラスを使用する。
∵SQLインジェクション対策になる。
∵名前の通り、SQLがDBにキャッシュされるため、繰り返し同じSQL文を発行する場合に処理速度が速くなる。
PreparedStatementはDBMSが理解できるようにSQL文をあらかじめコンパイルするから。

まあ、今ならベタなPreparedStatementで実装することはなく、フレームワークで書くのが普通だろう。

【10】 第7章　汎用とコレクション

Genericsの使い道は2種類しか思いつかない。
ListやMapの型安全。
関数型IFの引数、戻り値の型定義。

Cell と Cellは全く別のクラスになる。
Genericsを使う時に、初心者が間違えやすいらしく、僕も最初はハマった。

Cellにすれば、パラメータに全てのクラスを扱える。
しかし、Cellではパラメータにクラスの制約がないのは不便。
そこで、Cell,Cellを使って、パラメータに使えるクラスの範囲に制約をかける。

一般的に PECS という呪文が存在し、上限付き境界ワイルドカード型をProducerと呼び、下限付き境界ワイルドカード型をConsumerと呼ぶことがあるらしい。
Producer - 値の生成専門
Consumer - 値の受取専門

PECS(Producer extends and Consumer super)とは、Javaのジェネリックスプログラミングにおいて、ジェネリッククラスのメソッドに柔軟性を持たせるための原則である。基本は以下の通り。
メソッドが値を取得するコレクション(Producer)は型にextendsをつける
メソッドで値を設定するコレクション(Consumer)は型にsuperをつける

Javaジェネリクス：PECSって何？ - Qiita

java - What is PECS (Producer Extends Consumer Super)? - Stack Overflow

JavaジェネリックスのPECS原則、extendsとsuperの勘所 -- ぺけみさお

Genericsの型推論は、ダイヤモンド演算子<>を記述すると、下記が推論される。
* 変数への代入　=>例： var a = new ArrayList<>();
* メソッドの戻り値 =>例： return new ArrayList<>();
* メソッド呼び出しの引数 =>例： execute(new ArrayList<>());

ComparableとComparatorの違いも注意。

ComparableとComparatorの違いは何か: プログラマの思索

【11】 第8章　アノテーション
【12】 第9章　例外とアサーション
【13】 第10章　ローカライズ
は省略。

【14】 第11章　モジュール・システム

JavaのモジュールシステムでSPIとDIを実現するやり方: プログラマの思索

Javaのモジュールシステムの考え方をまとめてみた: プログラマの思索

Javaのモジュールシステムは複雑性をより増している: プログラマの思索

【15】 第12章　Java SEアプリケーションにおけるセキュアコーディング
は省略。

「Redmineハンドブック」は良い本です

9月に出版された「逆引きでわかる！ Redmineハンドブック バージョン5.0対応」を@agilekawabataさんから献本して頂きました。ありがとうございます。
読みどころを書きます。

【1】「Redmineハンドブック」の一番良い点は、こういうことがしたいんだけどRedmineの機能は何だっけ？と疑問に思った時に、逆引きで探せること。

たとえば、期日が切れたチケットを表示したり、放置されたチケットを表示したり、チケット同士を関連付けたり、チケットに先行後続の関係を付けるとか、探す時に便利。
Redmineのようなチケット管理ツールに慣れていれば、すぐに分かるけれど、初心者や慣れていない人にとっては、知らないことがすごくストレスになる。
たぶん、目次や索引から探すようになるだろう。

【2】「Redmineハンドブック」では細かいノウハウが紹介されている点も良いと思う。
たとえば、親子チケットの設定では、大日程だけで概算見積して親チケットの開始日・期日を設定した後、小日程計画で小チケットに細かくブレイクダウンして期間を設定すると、親チケットの開始日・期日が消えてしまう。
なぜなら、Redmineの初期設定では、親チケットの情報は子チケットをロールアップされる仕様だから。
よって、管理画面で、親チケットの開始日・期日を独立させるような設定をする必要がある。

また、大人数のユーザや多数のユーザグループを作った場合、細かくロール設定するのが面倒だ。
そんな場合、JAXAのロール設定の事例の話が「Redmineハンドブックで紹介されている。

CODA チケット管理システム | JSS@JAXA
「CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム: Redmineの事例と利用のヒント」

JAXAのRedmine運用事例の分析～「ロール設定のORルール」と「カスタムフィールド設定のANDルール」: プログラマの思索

JAXAのスーパーコンピュータ活用課でRedmineを使ったチケット管理システムの経験論文: プログラマの思索

【3】「Redmineハンドブック」では、WF型開発やアジャイル開発の運用方法が紹介されている点も良い。
慣れていない人にとっては、やはり実際にどのように運用できるのか、イメージが湧きやすいと思う。

WF型開発では、WBSをチケットに落とし込んで、ガントチャートで管理するのが一般的だ。
ガントチャート画面にイナズマ線が表示される機能も紹介されている。

一方、アジャイル開発では、スプリントはバージョン、タスクはチケットに対応付けて、チケット一覧でスプリントごとにグルーピングしてタスク管理するのが一般的だ。
チケット一覧ではやりにくい場合は、かんばんプラグインを入れて、タスクボードをかんばんで見立てるとよりアジャイルな雰囲気が出てくるだろう。
たとえば、アジャイルウェア社のLycheeかんばんもあるし、フリーでいくつかのプラグインがある。

チケットパネル （Redmineプラグイン） - ファーエンドテクノロジー株式会社

[Redmine] チケットをかんばん表示にするプラグイン | 適当に書き連ねるネタ帳のようなもの

GitHub - happy-se-life/kanban: Kanban plugin for redmine

【4】「Redmineハンドブック」で面白いと思った点は、最終章にGTDのタスク管理が紹介されている点だ。
やっぱりチケット管理はGTDのようなライフハック的なタスク管理のほうが向いていると思う。
Redmineにガントチャートはあるが、タスクをチケットでサクサク登録して更新してCloseしていく方が開発のリズムが生まれる。
すると、粒度の小さいチケットをたくさん作り、バックログとして一列に並べて、上から順にチケットをこなしていったり、溜まったチケットは定期的に棚卸しして作業しやすくする、といった運用方法になってくる。
つまり、自然にGTDのようなタスク管理に近づくわけだ。

さらに「Redmineハンドブック」では、仕事に追われない仕事術 マニャーナの法則 完全版 | マーク・フォースター, 青木 高夫 |本 | 通販 | Amazonをもとにいくつかの役立つ概念を紹介している。

タスクチケットは期日や重要度、優先度、ステータスによって種類がいくつかある。
それらをリストに分類し、リストに名前付けして管理するわけだ。
たとえば、オープンリストとクローズリスト、マスターリストとフィルターリスト、いつややることリスト、ペンディングリストなど。
初歩的なやり方ではあるが、割と使える方法だと思う。

というわけで、手元に1冊あると役立つ本だと思います。

XPエクストリームプログラミングは偉大だ～時代がその設計思想に追いついた

XPエクストリームプログラミング入門をオンラインで聞いた。
改めて、XPエクストリームプログラミングは偉大だ、時代がその設計思想に追いついた、と思った。
ディスカッションの内容から感じたことをラフなメモ。

【参考】
XPエクストリームプログラミング入門 - connpass

ITの地殻変動はどこで起きているのか？～チケット駆動開発はなぜ生まれたのか: プログラマの思索

僕は、「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法 」の第1版の方が好きだ。
理由は、荒削りだが内容はとてもシンプルで、当初考えていた直感的な思いが直接的に表現されているからだ。

- eXtreme Programmingの魅力を探るにある「Embrace Change - 変化ヲ抱擁セヨ」のグラフが一番好きだ。

勉強会の内容は放談会みたいで面白かった。

XPはプラクティスありきではない。
プラクティスは具体的な実践方法。
プラクティスは価値を実現したものの一つ。
しかし、価値は抽象的すぎるので、プラクティスと価値の間に原則を置いて、プラクティスと価値を橋でつなぐ。
そういう絵がXPではよく出るが、その意味がようやく分かった。

XPのプラクティスは、そのテーマ単体だけで一冊の本になる。
たとえば、リファクタリングなら、リファクタリング(第2版)。
テスト駆動開発なら、テスト駆動開発、実践テスト駆動開発。
継続的インテグレーションなら、継続的インテグレーション入門、継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化。
見積もり手法や計画ゲームなら、アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~。
ふりかえりなら、アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き。
シンプルな設計なら、エリック・エヴァンスのドメイン駆動設計。
つまり、それぞれのテーマはとても奥深いのだ。

たぶん、それらのテーマは重要である、とケント・ベックは直感的に感じていたのだろう。
それを言語化して形式知としてプラクティスで取り上げたのはすごいと改めて思う。

福井さんいわく。
最初はスクラムは好きではなかった。
XPは具体的なのに、スクラムではプロセスはしっかりしているが、実際に実践しようとすると中身が分からない。
でも、今はスクラムは好きですよ、と。
スクラムはスクラムマスターの存在が凄く大きい、と。

アジャイル開発は自動車の運転のようなもの。
到着先は分かっていて、その道順が分かっていても、不確定要素があり、ハンドル操作で変化を受け入れながら進める。
つまり、運転は変化が全くない動作ではないし、変化を受け入れる動作範囲に落ち着くようにする。

時代がアジャイルにやっと追いついた。
アジャイラーは当初は周囲と戦っていた。
いかに導入するか、いかに普及させるか、に注力していた。
しかし、今はお客様からも、アジャイル開発を導入したいと言われる。

WF型開発の権化だったPMBOKがアジャイル開発の考え方を取り入れて、PMBOKの最新版でごっそり変わったのも大きいね、と。
実際、PMBOKは従来の分厚い数多くのマネジメント技法の知識体系だったのに、アジャイル開発の考え方を具現化して、価値や原則が主体のマネジメント体系に変わろうとしている。

アジャイル開発を支える技術が揃ってきたのも重要だろう。
特にクラウドが普及したおかげで、すぐにサーバーを立ち上げて、実際に動かしてみて、動かしながら作っていくのができるようになった。
それもコストをあまり掛けずに、個人ですら開発できるようになった。
つまり、継続的インテグレーション、継続的デプロイ、リファクタリング、テスト駆動、短期リリースなどを支える技術が揃ってきたおかげで、アジャイル開発を実践しやすくなった、と。

一方で、SIがアジャイル開発に追いついていないように思える、と。
発注者は自社で内製開発がしたいので、アジャイル開発を自然に受け入れやすい。
しかし、SIは受託なので、既に自分たちの標準プロセスを持っているし、人月単価のビジネスモデルもあるから、いきなりアジャイル開発に変換するのは難しい。

僕がXPやアジャイル開発に惹かれる最大の理由は、IT業界のきつい仕事から脱出できるための救いとして捉えていた面があったからだと思う。
多重請負の人月単価のビジネスモデルの中で、大量のプログラマや技術者をまるで仕掛在庫みたいに扱って、変動するバッファみたいに扱う手法がどうしても慣れなかった。
アジャイル開発は人重視であり、技術者の専門性を活かしながらチームでアウトプットを出していく、という思想に引かれていたのだと思う。
IT技術者として専門性を高めていくと自然にアジャイル開発に収れんされていくはずだ、と思っていた。
今もその思いは変わらない。

「コーディングを支える技術」は良い本だ

「コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)」を読んで、良い本と思った。
ラフなメモ書き。
プログラミング初心者の適当な感想。

【参考】
コーディングを支える技術――成り立ちから学ぶプログラミング作法：書籍案内｜技術評論社

「コーディングを支える技術」著者公式ページ
「コーディングを支える技術」著者公式ページ　補足記事

【1】Javaで開発経験をした後、RubyやPythonを覚えた今、「コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)」を読むと、ああそういうことか、と気づくことがある。

【2】IF文の裏ではGOTO文が動いている、という内容を読んで、VBのことを思い出した。
VBでは、例外処理などのAPIが貧弱なので、割とGOTO文がよく出てくるので、VBは好きでなかった。
たぶん、APIが貧弱な古いプログラミング言語ほど、GOTO文が幅を利かせている。
その分、何でもできるが、とても読みづらく保守しづらい。

「コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)」の一節に、大学でC言語を初めて習った人が、「while文があればfor文はいらないのでは？」と思ったらしいと書かれていた。
僕も似たような感覚を抱いていた時があった。
JavaでもRubyでも、なぜ、while文、do-while文、for文、拡張for文など、似たようなループ処理の文法があるのか？と不思議に思っていた。

理由は単純で、当初はIF文みたいにwhile文を使っていたが、カウンタ変数のスコープがブロック外にあるので使いにくいから。
だから、while文からfor文の記法により、カウンタ変数のスコープはブロック内に収まった。
さらに、拡張for文により、カウンタ変数そのものも不要になった。
さらに、ListのforEachメソッド、Rubyのブロックのように、for文はクロージャとして吸収される。
つまり、プログラミングの文法もどんどん進化しているわけだ。

【3】変数のスコープの説明では、Perlで静的・動的スコープをプログラムで説明してくれている。
Perlを初めて書いていた時、なぜlocalやmyを変数に付ける必要があるのか、分からなかった時を思い出した。

Pythonでは、わざわざglobal／nonlocalで変数のスコープを制御できるようにしてくれている。
この文法を見た時、Perlみたいだな、と思ったことを思い出した。

Rubyなら、def～endのブロックとクロージャのブロックで、変数のスコープが異なるように使い分けている。
この文法は最初は理解しづらかったが、このおかげで、Rubyはメタプログラミングでやり放題ができるわけだ。

【4】オブジェクトとクラスでは、JavaとRubyでは考え方が全く違う。
親子で継承関係にあるクラスがあった時、インスタンス変数、インスタンスメソッド、クラス変数、クラスメソッドの挙動がJavaとRubyで異なる。
Javaでは、インスタンス変数、クラス変数、インスタンスメソッド、クラスメソッドは、親子クラスそれぞれで保持する。
ただし、親クラスの変数に、子クラスのオブジェクトを代入した場合、インスタンスメソッドは、子クラスのメソッドを利用する。
つまり、Javaでは、親クラスの変数の振る舞いは、ポリモーフィズムで動的に処理が変わるように見せかけられる。

一方、Rubyでは、親子間でインスタンス変数が共通として扱われる。
親クラスが定義したインスタンス変数と同じ名前のインスタンス変数を子クラスで使うと、親クラスのインスタンス変数は子クラスで上書きされる。
この書き方に慣れると、「クラス（型）は仕様である」を時々忘れてしまう。

資格取得に40代後半からチャレンジ　JavaとRubyを比較（注意しておくことその１）

資格取得に40代後半からチャレンジ　JavaとRubyを比較（注意しておくことその２）

資格取得に40代後半からチャレンジ　JavaとRubyを比較（注意しておくことその３）

資格取得に40代後半からチャレンジ　JavaとRubyを比較（注意しておくことその４）

Javaでは「クラス（型）は仕様である」が、Rubyではメッセージを渡したオブジェクトに全てを委ねる。
Rubyはまさにダック・タイピングなので、例えばdesktop.printが変数なのか、メソッドなのかも動かしてみないと分からない。

【5】多重継承のデメリットをどう解決するか？も、Java、Ruby、Pythonなどで全く違う。
Javaは多重継承を禁止するが、インターフェイスを導入して解決しようとした。
Javaでは、継承の代わりに委譲を進めるが、さらに委譲の参照をソースにハードコードするのではなく、依存性の注入により、設定ファイルを使って動的に変更できるような手法が多くなった。
JavaのフレームワークではDIが多いから、設定ファイルにXMLを用いることが多く、その分、プログラムを書くよりもXMLを書いている時が多くてあまり楽しくなくなる。

Rubyは、多重継承の問題を「どの順番で継承関係を検索するか」という問題に置き換えた。
Rubyでは継承関係は、Objectを頂点とするツリー構造だから、継承ツリーをメソッド検索することで解決しようとする。
include, prepend, refinementsはそういう使い道だろう。
また、Rubyでは、どうしても多重継承したい時は、モジュールでMix-inを使う。

Pythonでは多重継承できる、と聞いていてまだ理解できていなかったが、「コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)」によれば、C3線形化のアルゴリズムで継承関係の検索を決めることで解決しているわけだ。

［Python入門］多重継承：Python入門（1/2 ページ） - ＠IT

Pythonのメソッド解決順序(MRO) - 情報系大学院生の勉強メモ

【6】それから、並行処理のプログラミングの章も非常に分かりやすい。
Windows3.1やMacOS9は強調マルチタスクで、プリエンプティブマルチタスクではなかった、という一節を読んだ時、昔のPowerbookがMacOS9だった時を思い出した。

並行処理の問題点は、競合状態が起きること。
競合状態は3つある。
1つ目は、2つの処理が変数を共有している。
2つ目は、少なくとも1つの処理がその変数を上書きする。
3つ目は、一方の処理が一段落付く前に、もう一方の処理が割り込む可能性がある。

1つ目の対策は、結局スレッドを使っているので、変数を共有しない方向で解決していない。
アクターモデルのように、メッセージを送ることで解決しようとしている。
Erlangがその例だろう。

2つ目の対策は、メモリを共有しても書き換えないようにする方針もある。
全ての変数はImmutableにすればいい。
Haskellなどの関数型言語がそうだろう。

3つ目の対策は、協調的なスレッドを使う。
たとえば、Rubyのファイバー、Cのコルーチン、Pythonのジェネレータ。

あるいは、ロック、ミューテックス、セマフォ、モニタのような機構を使う。
Javaなら、synchronizedブロックで囲むだけでいい。

【7】自分は「プログラミングのできない山羊」出身なので、プログラミングを経験してやっとこういう本の内容が分かってきたという気がしている。
ソフトウェア開発は、数学や物理、経済学、財務会計、心理学などと違って、やっぱり独特の考え方がいると思う。
自分の中で言語化できていない部分は気づいたらブログで残しておく。

「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク: プログラマの思索

「60%の人間はプログラミングの素質がない」記事のリンク: プログラマの思索

プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ: プログラマの思索

プログラミングは「ブロックを組み合わせる」感覚に似ている: プログラマの思索

「RubyやRailsは終わった」という記事のリンク

「RubyやRailsは終わった」という記事があったが本当なのか？
見つけた記事だけをリンクしておく。
自分が後で読むためのメモ書き。

【参考】
“Rubyは死んだ”のか？　まつもとゆきひろ氏が語る「プログラミング言語サバイバル」とRubyの未来 - Part1 - ログミーTech

Ruby2系はチームの幸福度を最大化できなかった - Qiita

「Railsは終わった」と言われる理由 - Qiita

Rubyは死んだというが。流行り廃りに拘らず、便利なものは活用すればいいのに - Qiita

Rubyは果たして死んだのか | 日経クロステック（xTECH）

Rubyは終わった？将来性と今後の展望をまとめてみた│エンジニアハック

将来性のないプログラミング言語5選として「Ruby」が挙がり話題に | スラド IT

個人的にはRubyは好きだ。
「メタプログラミングRuby 第2版」を読んで、色々動かして、やっとダックタイピングの意味が分かった。
やはりRubyはJavaとは違う。
Rubyは究極のオブジェクト指向言語なのかもしれない。

また、Rubyというコミュニティも素晴らしいと思う。

なぜソフトウエア後進国の日本でRubyは成功したのか？～ソフトウェアの成功の秘訣はコミュニティ、そしてコンウェイの法則にある: プログラマの思索

一方、RubyはPerlのシンタックスを受け継ぐ部分があるせいか、初心者には読みにくい記法がある。
慣れないと使いこなせない部分もある。

「Rubyのしくみ」を読んだ後のRubyの感想: プログラマの思索

Ruby技術者認定試験の感想: プログラマの思索

Ruby初心者が間違いそうなこと: プログラマの思索

メタプログラミングRubyの感想: プログラマの思索

Rubyのブロック、Proc、lambdaのメモ: プログラマの思索

RedmineやRubyについては今後も追いかけていく。

実践した後に勉強するのがエンジニアの本来の道

実践した後に勉強するのがエンジニアの本来の道というツイートに共感したのでメモ。

はじめ??ソシャゲフリーランスエンジニアさんはTwitterを使っています 「中島聡さんが プログラミングの勉強は、アプリの開発を通してするもの と仰っていたけど完全同意です 恐らく100冊の技術書を読むより1アプリを作るほうが勉強になる そして1アプリを作った時の答え合わせのために技術書を読む 勉強→実践が普通の思考ですが 実践→勉強がエンジニアの本来の道です」 / Twitter

エンジニアは、仕事でシステムを開発して経験した後、技術書を読んで自分の経験を振り返る方が良い。

なぜなら、IT、プログラミングの技術書は抽象的で具体性がない。
具体性をいくら書いても、所詮プログラムなので、実際に動かさなければ、どこに落とし穴があるか分からない。
本の中身を丸暗記しても、実際にプログラミングがスムーズにできるとは限らないし、思ったようにプログラミングできない場合が多い。

一通りプログラムを書いて、アプリを動かして体験した後で、その体験内容を技術書で採点する感じ。
技術書に書いている内容に、ふむふむその通りと納得する時もあれば、こんな使い方があったのか、もっと速く知っておけばよかった、と思う時もある。
一方、こういう部分が泥臭くて難しくてハマる部分なのに、技術書に書いていなくて、消化不良だな、と思う時もある。

「大人の学びパターン・ランゲージ」の感想～知識と経験を行ったり来たりするタイミングを大切にする: プログラマの思索

OODAループの時代は、大事なのは使命であり、目標は使命達成のための手段に過ぎない

あるブログ記事で、OODAループの時代は、大事なのは使命であり、目標は使命達成のための手段に過ぎない、というメッセージが非常に心に残ったのでメモ。

【参考】
成績未達のものは、きつく叱責すべきか - ウィリアムのいたずらの開発？日記

PDCAサイクルは、1年毎の年間計画でよく使う。
しかし、超短期のサイクルでは使いづらい。
また、コロナ禍のような時代では、当初立てた計画が無意味となってしまった場合、PDCAを最初から作り直さないといけなくなる。

「PDCAサイクル全盛の時代は、目標を数値化してたてて、それを達成したらちょっと伸びた目標を立て続けていく」そんなやり方だった。
しかし、OODAループの時代では、「会社で大事なのは使命であり、目標は使命達成のための手段に過ぎない。」
つまり、「目標が達成しようがしまいが、目標と現実との差を常に感じ、使命達成のために行動する。そのためには目標の変更もあり得る。」

OODAループの考え方は、More Effective Agile ~“ソフトウェアリーダー"になるための28の道標で知っていたけど、腹落ちできていなかったと思う。
飛行操縦士が敵機を撃ち落とすための意思決定構造を形式化しただけ、というイメージで、ソフトウェア開発や経営に活用するイメージがなかった。

OODAループでは、目標よりも、価値や使命が最重要であり、目標や計画は達成するための手段に過ぎない。
目標や計画よりも、価値や使命が最優先であるという行動を誘発させること。

そんなことを考えると、OODAループはスクラムと相性が良いように思える。

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントの感想～日本に足りないのはプロダクトマネジャーだ

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントを読んで、日本に足りないのはプロダクトマネジャーだと改めて思った。
ラフなメモ。

【参考
ソフトウェア・ファーストの感想: プログラマの思索 】
プロダクトマネジメントの感想～プロダクトオーナーはもっとチームの外のユーザに寄り添うべき: プログラマの思索

「クライアント-ベンダーアンチパターン」という根本問題: プログラマの思索

プロダクトマネージャに必要なスキルは何か？～「世界で闘うプロダクトマネジャーになるための本 ～トップIT企業のPMとして就職する方法」の感想: プログラマの思索

(2) 伊藤 大地 / Daichi ITOさんはTwitterを使っています 「NHKのデジタル人材採用の募集要項に並ぶ言葉がもはや「メディア」ではなくて、「テック」企業のそれ。全てはソフトウェアの構築とその応用…というデジタルの性質が募集要項にそのままアウトプットされている。 https://t.co/yIZHbpQG5y https://t.co/Yu4YGX97Wu」 / Twitter

一括請負案件では、どうしてもプロダクトマネージャーという役割は持ちにくい。
プロジェクトマネージャが案件の中心にいて、顧客とプロジェクトマネージャが対峙するというクライアント・ベンダー・アンチパターンにはまりやすい。

では、日本では、どんなソフトウェア開発でプロダクトマネージャーという役割が必要になるのか？
INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントのあとがきでは、日本でプロダクトマネージャーが必要とされる場面は、スマホアプリの開発だという。

なぜなら、スマホアプリの開発では、利用ユーザの観点で、利用ユーザの導線を極力簡素化すべきであり、そのために機能はできるだけ削ぎ落とし、シンプルでワクワクするUIをいかに作り出すか、が大事になるからだ。
実際、一括請負案件でも、スマホアプリの開発が混じってくると、従来のウォーターフォール型開発で要件をガチガチに固めた後に機能やUIを開発したとしても、最後のユーザ受け入れテストで数多くの不満が出て収拾がつかなくなる場合も多い。
スマホアプリを実際に触ってみて、初めて操作感だけでなく、本来のユーザ導線を考えるという手戻りも発生しやすい。
僕もそういう現場を見てきた。

つまり、スマホアプリの開発はとりわけアジャイル開発に適していて、利用ユーザのユーザエクスペリエンスを重視するには、プロダクトマネージャーという役割の人が統括する方がうまくいきやすいと思う。

CISOは経営がわかる情報セキュリティ最高責任者である

CISOハンドブック ――業務執行のための情報セキュリティ実践ガイドを読んで、CISOは経営がわかる情報セキュリティ最高責任者であると知った。
ラフなメモ。

CISOハンドブック ――業務執行のための情報セキュリティ実践ガイドは、セキュリティの本というよりも、IT技術者が経営層になった時、こういうふうに考えたり行動していくべきで、こういう考え方を持つべき、という点が参考になった。
既存の経営陣に情報セキュリティの重要性を認識してもらうよりも、IT技術者自身が経営の知識を持つ方が手っ取り早いし、その方が実際はうまくいくと思う。

リスク管理は、予想される潜在リスクへの対策だけでなく、想定よりも状況がうまく行った時に備える場合もある。
たとえば、ベンチャー企業が社員20名から200名へ急激に成長した時、事業拡大の速度が速い分、いろいろな歪が出てくる。
上手く行っていたチームも、業務量が増えてメンバーが増えると、チームが回らなくなる。
ソフトウェア開発では人員増はうまくいかないという先入観がありすぎて、人員増を極力抑えるのは失敗しやすい。

事業が予測よりもうまくいくと、問題が少しずつ表面化する。
そこで、こんな対策がある。
業務をアウトソースして、固定費（人件費）費を変動費化する。
商流を変えて、固定費（人件費）を販管費にする。
業務をシステム化して効率化することで、固定費（人件費）を抑制する。

組織的には、事業や業務の観点で組織構造を変えて、チームを分けたり増やしたりする。
チームリーダーを社内で育成する。
それでも不足するなら、リーダーを外部から採用する。

つまり、良い状況に変わることも一つのリスクとみなして、リスク対策は考えるべき。

なぜか2000年代にIT系の良い本が多いと感じる今日この頃

最近、Ciscoベースのネットワーク、組み込みソフトウェア開発・設計のためのモデリング、業務システムやERPを設計・分析するためのデータモデリングや業務フローの本を読み漁っている。
他にも、Matlab・Scilibのようなシミュレーション関係の本も探している。

たとえば、下記の本になる。

【1】「インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門 第2版」「インフラ/ネットワークエンジニアのためのネットワーク・デザインパターン 実務で使えるネットワーク構成の最適解27」は、オンプレのネットワーク設計の解説でピカイチだった。
インフラ担当者なら当たり前の知識なのだろうが、アプリ開発の経験しかない僕にとってはとても新鮮だった。
クラウドやInfrastructure as Codeが何を解決しようとしているのか、について、考えさせてくれた。

なお、この本は2010年代の本だが、ほとんどのCiscoルータ・スイッチの解説・コマンドリファレンス本は2000年代が多い。

【2】「組込みソフトウェア開発のための オブジェクト指向モデリング (組込みエンジニア教科書)」も良かった。
話題沸騰のポットを題材に、ハードウェアのポットを要件定義から、オブジェクト指向設計、C++のソースコードまで落としてくれる。
業務システム設計とは違う観点で、状態遷移図やパッケージ間の依存関係が非常に重要になってくる。
2006年頃の出版で絶版。

【3】「7つの要素で整理する業務プロセス (for Mutual Interest SERIES)」は、業務フロー図の演習本だ。ひたすら、7種類の業務フローのサンプルと解説をしてくれている。
内部統制が導入された頃に、ITに関係ない人が業務フローを使うことになった時に使われたのだろう。
2007年頃の出版で絶版。

【4】しかし、それらの本は2000年代に良い本が多く、2010年代はほとんど出版されていない。
オブジェクト指向モデリング、データモデリング、オンプレのネットワーク、シミュレーションなどの基本的な技術の解説本がほとんど出版されていない。
なぜなのだろうか？

おそらく、IT技術のトレンドが激しく変化してしまい、従来の設計や技術は基盤として埋め込まれて、見えなくなってしまうくらい、当たり前になってしまったからではないか。
実際、データモデリングやオブジェクト指向モデリングも、その概念や考え方は、20年前も10年前も変わらない。

しかし、SOEのWebシステムでも、枯れた業務システムであっても、データモデリングは必須だし、オブジェクト指向モデリングも知っていて当然だろうが、そういう技術を知らずにどっぷり最先端の技術にハマってしまう。
今となっては、最先端の技術から古い技術に遡るしか無いのだろうが、基本的な技術無しで取り組んでいる感じで、何か腑に落ちない時が多いと思う。

2000年代に良い本が多いのに、割と絶版になっていたりする。
すると、それらの本に含まれているノウハウや優れた説明は継承されることなく消えてしまう。

たぶん、ベースとなる技術はもはや当たり前であって、ベースの技術や基盤の上で、次々に新しいサービスをどんどん生み出していくのが普通になっている。
だから、逐一古い基礎的な技術を掘り返すのは手間がかかり過ぎるのかもしれない。

この辺りの理由は色々探りたい。
そして、その悪影響についても考えてみたい。