第11期、第12期「プログラミング言語Java」コース終了 [プログラミング言語Java教育]
2010年1月と2月から開始した社内向けの「プログラミング言語Java」コースが終了しました。私にとっては通算で第11期と第12期となります(社内的には第1期と第2期です)。合計で30名で開始しましたが、修了したのは18名です。
修了した18名は、『プログラミング言語Java第4版』から始めて『Effective Java第2版』までをすべて読み通し、練習問題のプログラミング、GUI課題のプログラミング、それに、「リフレクション」の章のInterpretプログラムの作成と多くのプログラミング課題をこなしてきました。まさに、自分の時間を使用して、「練習、練習、練習」をされてきた一年だったと思います。
一年間を通して皆さん苦労された点は、
コース内のAWT(Abstract Window Toolkit)を用いた最初のGUI課題は、Javaで書いても20行程度で完成するのですが、それさえにも苦労されていた受講生が最後の成果発表会では、本当に素晴らしい作品を披露してくれます。最近の傾向で多いのは、やはり、外部のウェブサービスとの連携したアプリケーションとAndroidアプリケーションです。Androidアプリケーションは、6名の受講生が披露してくれました。ほとんどの人が、Androidアプリケーションは学習を始めてからできあがるまでに一週間以内ということでした。
本人達の努力あってのことですが、若手エンジニアの育成という観点では、彼ら彼女らの背中を押してあげることができたと思います。10年後、15年後、「あの時、Java教育を受けて良かった」と言ってくれるように今後成長してくれるのを楽しみにしています。
第11期生
第12期生
修了した18名は、『プログラミング言語Java第4版』から始めて『Effective Java第2版』までをすべて読み通し、練習問題のプログラミング、GUI課題のプログラミング、それに、「リフレクション」の章のInterpretプログラムの作成と多くのプログラミング課題をこなしてきました。まさに、自分の時間を使用して、「練習、練習、練習」をされてきた一年だったと思います。
一年間を通して皆さん苦労された点は、
- モチベーションの維持
- 予習時間の確保
- 独学では読み通すことができなかったであろう『プログラミング言語Java第4版』と『Effective Java第2版』の合計約900頁を読み終えたこと。
- Java言語をきちんと徹底的に学習したことで、今後の新たなプログラミング言語を学ぶ際の基礎ができた。
- 継続して学習する習慣が身に付いた
コース内のAWT(Abstract Window Toolkit)を用いた最初のGUI課題は、Javaで書いても20行程度で完成するのですが、それさえにも苦労されていた受講生が最後の成果発表会では、本当に素晴らしい作品を披露してくれます。最近の傾向で多いのは、やはり、外部のウェブサービスとの連携したアプリケーションとAndroidアプリケーションです。Androidアプリケーションは、6名の受講生が披露してくれました。ほとんどの人が、Androidアプリケーションは学習を始めてからできあがるまでに一週間以内ということでした。
本人達の努力あってのことですが、若手エンジニアの育成という観点では、彼ら彼女らの背中を押してあげることができたと思います。10年後、15年後、「あの時、Java教育を受けて良かった」と言ってくれるように今後成長してくれるのを楽しみにしています。
第11期生
第12期生
RICOH & Java™ Developer Challenge 2010 [Java]
開発環境(3) [プログラマー現役続行]
継続的インテグレーション(Continuous Integration)を行うために、CIツールを使用して、ビルドからテストコードの実行まで行っている開発組織は増えてきていると思います。その場合、CIツールを動作させているサーバではビルドごとにテストコードの実行は1回行ってパスするかどうかを調べることになります。テスト対象のソフトウェアがマルチスレッドで動作するのでなければ、これで良いかもしれません。
テスト対象のソフトウェアがマルチスレッドで動作するのではあれば、1回の実行では不十分です。何千回と繰り返したり、システムに様々な負荷をかけて実行したりということが必要になってきます。そうなると、サーバだけでなく、各開発者の環境でも動作させて、夜間にテストを実行し続けることが必要になってきます。
しかし、ここで注意しなければならないのは、CIサーバーがマルチコアで動作しているのに、開発者にはシングルコアの年代物のPCを与えていてはいけないということです。そのような貧弱な開発環境では、開発者は以下の問題に遭遇します。
残念ながら開発者のPCが貧弱な場合には、開発者の能力がいくら高くても、マルチスレッドに関係する問題の洗い出しや調査に非常に長い時間を要してしまいます(「開発環境(2)」)。ましてや、マルチスレッドに関する正しい識を持っていないレベルの開発者は、貧弱な環境であれば、問題を正しく認識して解決することができなかったりします。
テスト対象のソフトウェアがマルチスレッドで動作するのではあれば、1回の実行では不十分です。何千回と繰り返したり、システムに様々な負荷をかけて実行したりということが必要になってきます。そうなると、サーバだけでなく、各開発者の環境でも動作させて、夜間にテストを実行し続けることが必要になってきます。
しかし、ここで注意しなければならないのは、CIサーバーがマルチコアで動作しているのに、開発者にはシングルコアの年代物のPCを与えていてはいけないということです。そのような貧弱な開発環境では、開発者は以下の問題に遭遇します。
- 自分のPCではテストが動作するのだけど、CIサーバではテストが失敗することがある。
残念ながら開発者のPCが貧弱な場合には、開発者の能力がいくら高くても、マルチスレッドに関係する問題の洗い出しや調査に非常に長い時間を要してしまいます(「開発環境(2)」)。ましてや、マルチスレッドに関する正しい識を持っていないレベルの開発者は、貧弱な環境であれば、問題を正しく認識して解決することができなかったりします。
書籍『デザインのためのデザイン』(2) [プログラマー現役続行]
以前、英語版を購入したのですが、積ん読状態になっていたのと、翻訳版が出たので日本語版で読んでいます。
物を作るほとんどの人間は、実装してみて初めて、アイデアが不完全で矛盾していることに気付く。したがって、書いたり、実験したり、練習したりすることは理論家にとって不可欠な訓練なのである。オブジェクト指向の世界においては、分析→設計→実装と順に行われたりしますが、それらを分業してしまうとウォータフォール開発になってしまいます。物作りという観点からは、すべての行程を経験する必要があります。したがって、いわゆるアーキテクトと呼ばれる人達は、分析・設計・実装・デバッグのすべてを経験している必要があります。それらの経験を踏まえて、システム全体のデザインを考えられるのがアーキテクトだと私は考えています。『デザインのためのデザイン』(5頁)
私自身の開発経験からのバイアスがかかっていると思いますが、実際に設計・コーディングしてデバッグまでをきちんとできない人が、上流だけを行い、分業してウォータフォール開発を行うことでプロジェクトが成功する確率はかなり低くなると思います。ここでの成功とは、プロジェクトが中止にならなくても、技術的負債を残さないことも含めています。
ウォータフォールモデルは間違っており有害である。私たちはこのモデルから脱却しなければならない。実際のプログラミングやデバッグを伴うソフトウェア開発経験を若い頃に行い、それらの経験に基づいて、さらに上流からのシステムの設計を行う必要があります。そして、上流工程行っているからといって、プログラミングやデバッグに関心がないということはありえなく、むしろ、実際の開発での問題を未然に防止するための施策を実施したり、必要とあれば開発者を手伝ってコードレビューやデバッグまでできたりする必要があります。『デザインのためのデザイン』(34頁)