第14期「プログラミング言語Java」コース終了 [プログラミング言語Java教育]
私にとっては第14期になるリコーITソリューションズ社向けのプログラミング言語Javaコースが終了しました。最終の成果発表会には、1名が出張先の福岡からテレビ会議で参加となりましたが、6名の受講生に一年間の振り返りと発表と最終課題のデジタル時計のデモを行ってもらいました。
2011年度入社の若手社員7名や受講生が所属する部署の上司など多くの人々が参加され、受講生の発表内容やデジタル時計に対する質問やコメントが活発に交わされました。過去14回で、受講生以外でもっとも多くの人が参加して成果を聞いてもらった成果発表会でした。
第14期生
成果発表会出席者と第14期生
現在、第15期も社内で開催していますが、リコーITソリューションズ社向けとしての第16期は2012年4月から開講する予定です。
2011年度入社の若手社員7名や受講生が所属する部署の上司など多くの人々が参加され、受講生の発表内容やデジタル時計に対する質問やコメントが活発に交わされました。過去14回で、受講生以外でもっとも多くの人が参加して成果を聞いてもらった成果発表会でした。
第14期生
成果発表会出席者と第14期生
現在、第15期も社内で開催していますが、リコーITソリューションズ社向けとしての第16期は2012年4月から開講する予定です。
書籍『ｉＯＳプログラミング 第2版』 [本]
- 作者: アーロン･ヒレガス
- 出版社/メーカー: ピアソン桐原
- 発売日: 2011/12/21
- メディア: 単行本（ソフトカバー）
初版は翻訳されていませんが、第2版が翻訳されて出版されます。初版は、『iPhone Programming: The Big Nerd Ranch Guide (Big Nerd Ranch Guides)』ですが、第2版ではタイトルを変更して『iOS Programming: The Big Nerd Ranch Guide (Big Nerd Ranch Guides)』となっています。
訳者は3名であり、Amazon.co.jpには次のように紹介されています。
訳者について実際に、日々の開発業務でiOSを使用して開発をされている人達です。
木南 英夫 東海大学大学院で電気工学科修士課程を修了。現在富士ゼロックス株式会社にて同社提供のクラウドサービスSkyDeskのiOSアプリケーション開発に従事する。 著書として『Google Android アプリケーション開発入門 画面作成からデバイス制御まで－－基本機能の全容』( 日経BP 社) など。
上堀 幸代 筑波大学大学院理工学研究科修士課程終了。現在富士ゼロックス株式会社にて現在同社提供のクラウドサービスSkyDeskのiOSアプリケーション開発に従事する。
内橋 真吾 東京大学大学院工学系研究科情報工学専攻（修士）修了。富士ゼロックス株式会社入社以来、同社研究所およびＦＸ Palo Alto Laboratory,Incにて、主にマルチメディア技術の研究に従事。
第2版は、初版と比較すると内容が非常に分かりやすくなっており、iOSでプログラミングする人にはお勧めの書籍だと思います。各章の概要は、木南英夫さんのブログを参照してください。
書籍『Go言語プログラミング入門 on Google App Engine』 [本]
Go言語プログラミング入門on Google App Engine
- 作者: 横山 隆司
- 出版社/メーカー: 秀和システム
- 発売日: 2011/12
- メディア: 単行本
今年9月23日（金）のオープンセミナー@香川の懇親会で、著者の横山さんからGo言語でのGoogle App Engineの本を執筆中と聞いた本です。目次は、以下の通りです。
Chapter 1 はじめに目次を見て分かるようにGo言語そのものの解説はChapter 3だけであり、Google App Engineに関するページの方が多いです。
Chapter 2 開発環境の構築
Chapter 3 Go言語の基礎
Chapter 4 Google App Engine API
Chapter 5 Google App Engine for Goを使ったWebアプリケーション作成
補章 今度のSDKの変更と、APIの追加に備えて
Go言語がどのようなものであるかの基本を知るには、Chapter 3を読むことで学ぶことができますが、本格的にGo言語でプログラミングする場合には、「The Go Programming Language Specification」、「Effective Go」、「A Tutorial for the Go Programming Language」なども一読されると良いでしょう。
本書の正誤表に関しては、著者の横山さんのブログをチェックされると良いかと思います。
Go言語は、来年初めにGo version 1がリリースされて、正式に言語の互換性を保証するようになります。それに合わせて執筆が進められている英語の書籍もあります。しかし、日本語でGo言語とGoogle App Engineの両方を学べる本は、今はこの本しかありません。
ソースコードに技術者のレベルが現れる [プログラマー現役続行]
新規に書かれたソースコードを見ると、それを書いた技術者のレベルがある程度分かります。特に、レベルが低いエンジニアが書いたコードほど、よく分かります。レベルが低いというのは、全くの初心者という意味ではありません。社会人となってソフトウェア開発に従事して数年を経過して、本人はプログラミングできると思って書いているレベルであっても、書かれたコードを見ると、レベルが低いということです。
レベルが低い大きな理由の1つは、自分が書いたコードをスキルが高い人にレビューしてもらうという習慣を本人が持たないし、組織も持たないからです。もう1つの大きな理由は、使用しているシステムや開発言語に関した、きちんとした学習をしていないということも挙げられます。※
※ たとえば、Java言語で開発していても『Effective Java』を読んだことさえないとか。
「初心者だからと言って汚いコードを書くことが許される訳ではない」ということで、レビューによって初心者が書いたコードの品質を上げる努力を組織として継続している場合には、本人の勉強不足はレビューによる指摘によって補われ、コードには現れないかもしれません。しかし、レビューをきちんとしない組織では、本人のレベルと学習不足ははっきりとコードに現れます。
つまり、ソフトウェア開発組織の成果物であるソースコードを見ていけば、その組織を構成するエンジニアのレベルがある程度分かってしまうということです。しかし、幸か不幸か、通常の企業活動におけるソフトウェア開発ではソースコードが外部へ公開されることはありませんので、外部からその開発組織に属するエンジニアのレベルを知ることはできません。
しかし、その開発組織のトップやリーダはソースコードを見ることができる訳ですから、ソースコードを見て自分の組織に属しているメンバーのレベルを知ることはできます。あるいは、業務委託先から納品されたソースコードを見れば、その業務委託先のレベルは分かったりします。ただし、見て判断できるレベルの人が見ればですが。
ソフトウェアエンジニア個人としては、自分が書くソースコードは、自分のスキルレベルを写し出すものだと認識することが重要です。
レベルが低い大きな理由の1つは、自分が書いたコードをスキルが高い人にレビューしてもらうという習慣を本人が持たないし、組織も持たないからです。もう1つの大きな理由は、使用しているシステムや開発言語に関した、きちんとした学習をしていないということも挙げられます。※
※ たとえば、Java言語で開発していても『Effective Java』を読んだことさえないとか。
「初心者だからと言って汚いコードを書くことが許される訳ではない」ということで、レビューによって初心者が書いたコードの品質を上げる努力を組織として継続している場合には、本人の勉強不足はレビューによる指摘によって補われ、コードには現れないかもしれません。しかし、レビューをきちんとしない組織では、本人のレベルと学習不足ははっきりとコードに現れます。
つまり、ソフトウェア開発組織の成果物であるソースコードを見ていけば、その組織を構成するエンジニアのレベルがある程度分かってしまうということです。しかし、幸か不幸か、通常の企業活動におけるソフトウェア開発ではソースコードが外部へ公開されることはありませんので、外部からその開発組織に属するエンジニアのレベルを知ることはできません。
しかし、その開発組織のトップやリーダはソースコードを見ることができる訳ですから、ソースコードを見て自分の組織に属しているメンバーのレベルを知ることはできます。あるいは、業務委託先から納品されたソースコードを見れば、その業務委託先のレベルは分かったりします。ただし、見て判断できるレベルの人が見ればですが。
ソフトウェアエンジニア個人としては、自分が書くソースコードは、自分のスキルレベルを写し出すものだと認識することが重要です。
プロセス中心ではなく、スキル中心（3） [プログラマー現役続行]
「プロセス中心ではなく、スキル中心」というテーマで、過去に記事を書いています。
個々のソフトウェアエンジニアのスキルを向上させるには、そのエンジニアのレベルを最初に知る必要があります。そのエンジニアのレベルを知るには、直接会話するだけでなく、普段の開発成果物をレビューしてどのような考えに基づいて作成しているかも把握していく必要があります。そして、開発に必要な知識が不足している場合には、教育を行うとか勉強会を開催したりすることも必要だったりします。
私自身、ソフトウェア開発に加えて、30代の終わりから技術書の社内勉強会、技術教育、設計やコードレビューと様々な活動を行ってきました。ソフトウェア開発は、人が行う非常に複雑な活動です。ある側面にだけ注目しても、上手くいかないことが多く、特に、人のスキルを無視したり、避けたりするソフトウェア開発は、多くの障害を作り出して、デスマーチを繰り返すことになります。
そのことに気付くことなく、プロセス中心に陥った組織は、いつまでもそのわだちからは抜け出せないかもしれません。
個々のソフトウェアエンジニアのスキルを向上させるには、そのエンジニアのレベルを最初に知る必要があります。そのエンジニアのレベルを知るには、直接会話するだけでなく、普段の開発成果物をレビューしてどのような考えに基づいて作成しているかも把握していく必要があります。そして、開発に必要な知識が不足している場合には、教育を行うとか勉強会を開催したりすることも必要だったりします。
私自身、ソフトウェア開発に加えて、30代の終わりから技術書の社内勉強会、技術教育、設計やコードレビューと様々な活動を行ってきました。ソフトウェア開発は、人が行う非常に複雑な活動です。ある側面にだけ注目しても、上手くいかないことが多く、特に、人のスキルを無視したり、避けたりするソフトウェア開発は、多くの障害を作り出して、デスマーチを繰り返すことになります。
そのことに気付くことなく、プロセス中心に陥った組織は、いつまでもそのわだちからは抜け出せないかもしれません。
You can’t tell you’re in a rut while you’re in it — you need to see it from an outside vantage point.Josh Carter — New Programmer's Survival Manual
【社内連絡】『コンピュータの構成と設計 第4版（上）』読書会参加者募集 [読書会]
ブログに書いていますが、社内向けの内容です。
『言語設計者たちが考えること』読書会が終わりましたので、次の勉強会を開催します。今回は、コンピュータの基礎を学ぶことを目的としたいと思います。
希望者は社内の私のメールアドレスに、『勉強会参加希望』と題したメールをください。
開催日： 毎週、木曜日の1回 朝7時40分から8時45分
開始日： 2012年1月19日（木）
場所： 私が勤務している事業所（海老名）の会議室（大森事業所とはテレコン）
書籍： 『コンピュータの構成と設計 第4版（上）』（各人購入してください）
申込み〆切： 2012年1月12日（木）
進め方： 基本的に最初から読んでいきます。事前の予習は不要です。
業務時間外の勉強会ですので、参加資格は社員に限定していません。誰でも参加可能です。
『言語設計者たちが考えること』読書会が終わりましたので、次の勉強会を開催します。今回は、コンピュータの基礎を学ぶことを目的としたいと思います。
希望者は社内の私のメールアドレスに、『勉強会参加希望』と題したメールをください。
開催日： 毎週、木曜日の1回 朝7時40分から8時45分
開始日： 2012年1月19日（木）
場所： 私が勤務している事業所（海老名）の会議室（大森事業所とはテレコン）
書籍： 『コンピュータの構成と設計 第4版（上）』（各人購入してください）
申込み〆切： 2012年1月12日（木）
進め方： 基本的に最初から読んでいきます。事前の予習は不要です。
業務ではありませんので、非業務扱いです
業務時間外の勉強会ですので、参加資格は社員に限定していません。誰でも参加可能です。
- 作者: デイビッド・A・パターソン
- 出版社/メーカー: 日経BP社
- 発売日: 2011/11/17
- メディア: 単行本
ソフトウェア開発組織が持つべきカルチャー 012 [ソフトウェア開発組織が持つべきカルチャー]
ソースコードを調べる
ソフトウェア開発において、自分が書いていないコードであっても、不具合の原因を調べるために、ソースコードを調べると習慣というのは、ソフトウェアエンジニアにとっては重要です。
しかし、実際の開発では、自分が担当しているモジュールでなければ、それ以上調査しようとしない人がいます。その場合には、リーダや上司が、他人のソースコードを調べてでも原因を調査するように指示しているかどうかで、その開発組織のメンバーのスキルに大きな差として現れたりします。
企業におけるソフトウェア開発では、自分が属するチームや設計部門のソースコードしか見られないようなアクセス管理をしている場合があります。そのようなソースコード管理をしている組織では、そもそも他の部門やグループのソースコードを見ることができなかったり、手間暇かけてアクセス権を設定してもらったりする必要があります。その結果、同一商品の中にインストールされるソフトウェアであっても、基本的に他の人のソースコードを調べないという習慣を持ったソフトウェアエンジニアばかりになったりします。そうなると、オープンソースのソフトウェアを使用して何か問題があっても、ソースコードを調べることさえしない人さえいてもおかしくありません。
繰り返しになりますが、何か問題があった場合に、自分が書いていないコードであっても原因を調べ調査するという習慣を持つことは、ソフトウェアエンジニアとして非常に重要なことです。
Use the Source, Luke
ソフトウェア開発において、自分が書いていないコードであっても、不具合の原因を調べるために、ソースコードを調べると習慣というのは、ソフトウェアエンジニアにとっては重要です。
しかし、実際の開発では、自分が担当しているモジュールでなければ、それ以上調査しようとしない人がいます。その場合には、リーダや上司が、他人のソースコードを調べてでも原因を調査するように指示しているかどうかで、その開発組織のメンバーのスキルに大きな差として現れたりします。
企業におけるソフトウェア開発では、自分が属するチームや設計部門のソースコードしか見られないようなアクセス管理をしている場合があります。そのようなソースコード管理をしている組織では、そもそも他の部門やグループのソースコードを見ることができなかったり、手間暇かけてアクセス権を設定してもらったりする必要があります。その結果、同一商品の中にインストールされるソフトウェアであっても、基本的に他の人のソースコードを調べないという習慣を持ったソフトウェアエンジニアばかりになったりします。そうなると、オープンソースのソフトウェアを使用して何か問題があっても、ソースコードを調べることさえしない人さえいてもおかしくありません。
繰り返しになりますが、何か問題があった場合に、自分が書いていないコードであっても原因を調べ調査するという習慣を持つことは、ソフトウェアエンジニアとして非常に重要なことです。
Use the Source, Luke
ソフトウェア開発組織が持つべきカルチャー 011 [ソフトウェア開発組織が持つべきカルチャー]
テストを自動化する
継続的インテグレーションを行い、テストを自動化して実行することは、1990年代までは普及していません。そのため、技術的負債を多く抱えて機能追加が行われているようなソフトウェアでは、今でも手作業でテストが行わているものが多数存在すると思います。
レガシーコードのテストの自動化には困難を伴いますが、それ以前に問題なのは、テストを自動化することの本当の意味を理解していない開発組織です。たとえば、テストの自動化に本格的に取り組んだことがない開発組織であれば、新たな開発であってもテストの自動化を最初から導入しなかったりします。あるいは、テスト駆動開発と言いながらも、実行は開発者が手作業で行うことで、継続的に実行されなくなり、結果としてテストコードが保守されなくなったりするかもしれません。
また、テストの自動化というのは設計に大きな影響を与えますし、そもそもテストコードがきちんと書かれて保守されていることも重要です。しかし、テストは後で良いという開発スタイルでは、テストするのが困難な設計が行われたり、テストコードがいい加減だったりして、実際には何も成果が上がっていないし、現場のエンジニアの意識の改善やスキル向上がなかったりするかもしれません。
継続的インテグレーションを行い、テストを自動化して実行することは、1990年代までは普及していません。そのため、技術的負債を多く抱えて機能追加が行われているようなソフトウェアでは、今でも手作業でテストが行わているものが多数存在すると思います。
レガシーコードのテストの自動化には困難を伴いますが、それ以前に問題なのは、テストを自動化することの本当の意味を理解していない開発組織です。たとえば、テストの自動化に本格的に取り組んだことがない開発組織であれば、新たな開発であってもテストの自動化を最初から導入しなかったりします。あるいは、テスト駆動開発と言いながらも、実行は開発者が手作業で行うことで、継続的に実行されなくなり、結果としてテストコードが保守されなくなったりするかもしれません。
また、テストの自動化というのは設計に大きな影響を与えますし、そもそもテストコードがきちんと書かれて保守されていることも重要です。しかし、テストは後で良いという開発スタイルでは、テストするのが困難な設計が行われたり、テストコードがいい加減だったりして、実際には何も成果が上がっていないし、現場のエンジニアの意識の改善やスキル向上がなかったりするかもしれません。
ソフトウェア開発組織が持つべきカルチャー 010 [ソフトウェア開発組織が持つべきカルチャー]
ビッグバン・インテグレーションを避ける
組織におけるソフトウェア開発では、一人で行うことは少なく、プロトタイピングであっても、数名あるいは10名弱で行われることもあります。昔のソフトウェア開発であれば、各人の担当を決めて、各人が実装が終わった後に全部を結合するというビッグバン・インテグレーションが行われて、様々な問題に直面していました。たとえば、各人は開発がスケジュール通りだと常々報告していても、結合で多くの問題を抱えて、結果的にプロジェクトが遅れていくということもあります。
今日、複数名で行うプロトタイピングであっても、ソースコード管理、自動ビルド、自動テストなどを小さいながらも整備してから開発を行うべきです。そして、開発が進むに従って、必要に応じて環境を改善していくことが必要です。しかし、残念ながらチームリーダがそのような認識を持つこと無く、開発を進めている組織もあるのではないでしょうか。
組織におけるソフトウェア開発では、一人で行うことは少なく、プロトタイピングであっても、数名あるいは10名弱で行われることもあります。昔のソフトウェア開発であれば、各人の担当を決めて、各人が実装が終わった後に全部を結合するというビッグバン・インテグレーションが行われて、様々な問題に直面していました。たとえば、各人は開発がスケジュール通りだと常々報告していても、結合で多くの問題を抱えて、結果的にプロジェクトが遅れていくということもあります。
今日、複数名で行うプロトタイピングであっても、ソースコード管理、自動ビルド、自動テストなどを小さいながらも整備してから開発を行うべきです。そして、開発が進むに従って、必要に応じて環境を改善していくことが必要です。しかし、残念ながらチームリーダがそのような認識を持つこと無く、開発を進めている組織もあるのではないでしょうか。
著書（PDF）
翻訳本（Kindle版）
翻訳本（PDF）
