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

Java研修OB・OGグループ(Facebook) [プログラミング言語Java教育]

Java研修の修了生をメンバーとしたグループをFacebookに作成しています。Facebookのアカウントも持っているJava研修の修了生は知らせてください。

英語学習 [英語]

最近、社内で昇格条件としてTOEIC点数が話題となったので、何か書こうかと思ったのですが・・・

私の英語勉強法に関して過去に書いた記事リンクです。
英語の勉強法は、「どうやって英語を学んだですのか?」と聞くと、人ごとに違った答えが返ってくると思います。私の若い頃と違って今では様々な学習方法が可能になっている時代ですが、何かの参考になればと思います。

書籍『Objective-C明解プログラミング』予約受付開始したようです [プログラマー現役続行]

ObjectiveーC明解プログラミング―基礎から応用までステップ・バイ・ステップ方式でわか

ObjectiveーC明解プログラミング―基礎から応用までステップ・バイ・ステップ方式でわか

  • 作者: スティーブン G.コーチャン
  • 出版社/メーカー: ピアソン桐原
  • 発売日: 2013/05
  • メディア: 単行本

Amazon.co.jpで予約できるようになりました。私の手元には、先週の金曜日に出版社から届きました。
942798_605251369494144_1256024576_n.jpg

目次は、以下の通りです。
訳者まえがき
第1章 はじめに

I. プログラミング言語Objective-C
第2章 Objective-C プログラミング
第3章 クラス、メソッド、オブジェクト
第4章 データ型と式
第5章 ループ
第6章 判定
第7章 さらにクラスについて
第8章 継承
第9章 ポリモフィズム、動的型付け、動的バインディング
第10章 さらに変数とデータ型について
第11章 カテゴリとプロトコル
第12章 プリプロセッサ
第13章 基本的なC 言語機能

II. Foundation フレームワーク
第14章 Foundation フレームワークへの序論
第15章 ナンバー、文字列、コレクション
第16章 ファイルを扱う
第17章 メモリ管理と自動参照カウント
第18章 オブジェクトをコピー
第19章 アーカイブ

III. Cocoa、Cocoa Touch とiOS SDK
第20章 Cocoa とCocoa Touch への序論
第21章 iOS アプリケーションの作成
付録B アドレスブックのソースコード例
付録A 用語集
最初のプログラミング言語としてObjective-Cを学ぶ人を対象としており、Objective-Cのプログラミング言語としての詳細が説明されています。もちろん、普段Objective-Cでプログラミングしている人にとっても、あらためて言語をきちんと学習し直すのにも適していると思います。
私は、最初にC 言語を教えないしC 言語の知識を持っていることも前提としないと決めました。代わりに、オブジェクト指向プログラミングの視点から単一の統合化された言語としてObjective-C およびそのベースであるC 言語を教えるという、今までにないアプローチを取ることにしました。本書の目的は、そのタイトルが意味する通りのものです。つまり、Objective-C でプログラミングを教えることです。はっきりと言えば、プログラムを入力してデバッグするために利用可能な開発ツールの使用方法を詳細に教えたり、インタラクティブなグラフィカルアプリケーションの開発方法を詳細に説明したりしないということです。プログラムの書き方をObjective-C で学んだ後に、それらの題材に関しては他の書籍などで詳細に学ぶことができます。実際、Objective-C でのプログラムの書き方の確固たる基本を習得すれば、それらの題材を習得することは非常に容易になります。本書は、今までに多くのプログラミング経験があることを想定していません。実際、あなたが初心者プログラマならば、熱心に真剣に取り組むことで、あなたの最初のプログラミング言語としてObjective-C を学ぶことができるはずです。本書の以前の版に対して私が受け取った読者からのフィードバックによれば、多くの読者はそうすることに成功しています。
『Objective-C明解プログラミング』(p.2)

第17期「プログラミング言語Java」コース終了 [プログラミング言語Java教育]

5月24日(金)に、私にとって第17期となる「プログラミング言語Java」研修が終了しました。今回の修了は、8名でした。今回のコースは18名でスタートしたのですが、最終的には8名だけとなってしまいました。

また、私の後任なる講師を育成するということも当初活動としては行っていましたが、後半は結局私がすべて講師を行うということになり、育成に関しては、失敗したコースでした。と同時に、育成するのは、無理とも思ったコースでした。

午後2時までは、『Effective Java 第2版』の残りの部分のQ&Aを行った後、2時からは成果発表会ということで、一年間の振り返りとデジタル時計課題のデモを行ってもらいました。

NEC_0286.PNG
第17期生と私

これで、リコーグループでの修了生は合計57名ですが、17期生には2回目の修了生がいるの、延べ56名です。

書籍『Objective-C明解プログラミング』まもなく発売 [プログラマー現役続行]

POC.png

まだAmazon.co.jpを含めてどこも予約注文できませんが、近日中に発売されます。出版社は、ピアソン桐原です。今回も、翻訳だけでなく、組版もLaTeXを使用して私自身で行っています。

原著はこちらの本です。原著の第5版の翻訳本であり、原著は第4版までは翻訳されていません。

Programming in Objective-C (5th Edition) (Developer's Library)

Programming in Objective-C (5th Edition) (Developer's Library)


悪いAPIは伝染していく(2) [プログラマー現役続行]

以前、「悪いAPIは伝染していく」という短い記事を書きました。

APIが悪いライブラリを使用する別のライブラリを設計する場合には、元のライブラリのAPIの悪さを、新たなライブラリでは修正することが可能です。しかし、よく見かけるのは、使用する元のライブラリのAPIの悪さをそのまま引きずったライブラリが設計されることです。その意味で、低レベルのライブラリのAPIの悪さは、上位レベルへと伝染していきます。悪さが伝染しないように新たにAPIを設計できるエンジニアは少ないようです。

きちんとしたAPIを持つライブラリを使用しているのにもかかわらず、出来の悪いAPIを持つ上位のライブラリが作成されることがあります。私自身がかなりレビューしてAPIを整備させたライブラリを使用して、その上に出来の悪いAPIを持つライブラリが設計されているのを見ると、がっかりしてしまいます。

どんなAPIでも、最初のバージョンは完璧ではないです。しかし、それを理由に、出来の悪いAPIを設計してい良い訳ではありません。

私自身の経験から言えば、2000年にC++言語用のメモリ管理ライブラリとそれを使用した基本的なライブラリ(スレッドやコレクション関連)※1を設計しました。私自身がAPIを設計したライブラリでしたが、実際に私がそれを使用してコードを書くことはありませんでした※2。しかし、2003年からそのライブラリを使用して、自分でもかなりのコードを書くことで、いくつかのAPI設計の誤りに気付いたのです。その誤りのほとんどは、些細なものでした。しかし、1行で書けるべきところを2行書かなければならなかったりして、非常に面倒に感じたのです。結局、その場合には、後方互換性を保ったままAPIを修正することが可能だったので、APIを修正しました。

※1 Fuji Xerox社のカラー複合機ApeosPortで使用されているライブラリです。
※2 私自身は、主に設計コンサルタント的な活動をしていました。

私が大学で情報工学を学んだ頃には、優れたAPIを設計することに関する教育はありませんでしたし、今でもないのではないかと思います。社会人となっても、体系的に教えられたりすることもなく、自己学習しながらでした。ただ、その中でも、様々な書籍を読むことで、著者が体験して習得したこを学んだ部分は大きいです※3

※3 私自身にとって、もっとも衝撃だったのは『Effective Java プログラミング言語ガイド』でした。

最初からきちんとしたAPIを作成できるようにはなりませんが、優れたAPIを作成するために、様々な学習を続けて実践していくことがソフトウェアエンジニアには求められると思います。「サラリーマンエンジニア」であれば、API設計に必要な書籍を読むことなく、悪いAPIを伝染させたり、APIを改悪していくことになります。

技術的負債(5) [技術的負債]

リーンソフトウェア開発と組織改革』の一部を紹介した「技術的負債」でも引用したように、負債が破綻にいたらないように努めながらソフトウェア開発/製品開発を行っていくことが必要です。
技術的負債
成功するソフトウェアは変化している。成功するコードは変更を受け入れやすく書かれている。コードの変更をむずかしくするものはすべて技術的負債である。技術的負債は、ソフトウェアの所有コストを容赦なく引き上げ、いずれその精算を迫られたり、システムが破綻したりする。そんなことはすべてわかっている。けれども現実は・・・・

(途中省略)

技術的負債の本当の姿を知らなければならない。負債が破綻に至らないよう、コスト上の重荷をふだんから取り除いておくべきだ。
技術的負債を軽減しながら、同時にソフトウェア開発/商品開発を進めていくことが重要です。技術的負債を積み上げないように努力をしながらソフトウェア開発を行っている開発組織では、「どのような商品を作るのか」に集中しても、開発そのものが技術的負債を積み上げる可能性は少ないです。しかし、毎年のように技術的負債を積み上げている組織では、技術的負債を返済することを諦めてしまうと、ある時、突然破綻してしまってもおかしくはないかもしれません。

ソフトウェア開発は非常に複雑な活動です。その複雑さにどのようにきちんと取り組んでいくかを考えていかないと、技術的負債は積み上げられて、開発に従事したエンジニアのスキルは向上することはないかもしれません。私個人のソフトウェア開発経験から言うと、技術的負債が積み上げられて、負債を解消することを行っていないソフトウェア開発だけにしか従事したことがないソフトウェアエンジニアで、その経験年数に見合ったレベルのスキルを獲得している人はほとんどいません。単に、XX年の開発経験がありますという程度に過ぎないということです。

技術的負債(4) [技術的負債]

かなり前に「技術的負債」として、3つの記事を書いています。
「技術的負債(3)」では、次のように書いています。
見方を変えると、技術的負債は、将来性のある若手をきちんとしたソフトウェアエンジニアとして成長させる場を奪ってしまうことになります。良いコードを書くという機会もなく、リファクタリングを経験する場もなく、過去に誰かが作った負債と格闘させるだけとなります。そのような状況では、ソフトウェア開発にもともと興味がない人は、負債を膨らませていくだけでしょう。一方、意欲のある若手は、成長できないため会社を辞めていくことになります。その結果、技術的負債に無頓着な人々が開発組織の大半を占めるようになり、会社は負債をますます増大させることになります。
さらに、一からシステムを作成した経験がないエンジニアが組織内に増えてしまうことにもなります。製品を出し続けることで技術力があると思っているのは単なる錯覚に過ぎず、画期的な競合製品が出てきた時に、技術の空洞化が起きていて、自社製品開発では追いつけない可能性が高くなります。

Question: 次の2つの製品は、別物でしょうか?

REST API関連の本 [プログラマー現役続行]

最近、色々と購入したので、REST API関連の書籍を列挙してみました(購入していない本もありますが)。

The REST API Design Handbook

The REST API Design Handbook


APIs: A Strategy Guide

APIs: A Strategy Guide

  • 作者: Daniel Jacobson
  • 出版社/メーカー: Oreilly & Associates Inc
  • 発売日: 2011/12/24
  • メディア: ペーパーバック

Rest in Practice: Hypermedia and Systems Architecture

Rest in Practice: Hypermedia and Systems Architecture

  • 作者: Jim Webber
  • 出版社/メーカー: Oreilly & Associates Inc
  • 発売日: 2010/09/24
  • メディア: ペーパーバック

RESTful Web Services Cookbook

RESTful Web Services Cookbook

  • 作者: Subbu Allamaraju
  • 出版社/メーカー: Oreilly & Associates Inc
  • 発売日: 2010/03/15
  • メディア: ペーパーバック

REST API Design Rulebook

REST API Design Rulebook

  • 作者: Mark Masse
  • 出版社/メーカー: Oreilly & Associates Inc
  • 発売日: 2011/10/31
  • メディア: ペーパーバック

Restful Web Services

Restful Web Services

  • 作者: Leonard Richardson
  • 出版社/メーカー: Oreilly & Associates Inc
  • 発売日: 2007/05
  • メディア: ペーパーバック
この本は、翻訳があります。
RESTful Webサービス

RESTful Webサービス

  • 作者: Leonard Richardson
  • 出版社/メーカー: オライリー・ジャパン
  • 発売日: 2007/12/21
  • メディア: 単行本

これから出る本としては、次の本があるようです。

Restful Web Apis

Restful Web Apis

  • 作者: Leonard Richardson
  • 出版社/メーカー: Oreilly & Associates Inc
  • 発売日: 2013/08/22
  • メディア: ペーパーバック

オライリーが圧倒的に多いようですが、日本語になっているのは1冊だけということは、やはり、英語で読まなければならないということでしょう。

外部に公開するAPIというのは、様々なことを考慮しなければなりません。APIに関して、RESTとは別に次の本をも読んでいる最中です。

Practical API Design: Confessions of a Java Framework Architect (Expert's Voice in Java Technology)

Practical API Design: Confessions of a Java Framework Architect (Expert's Voice in Java Technology)

  • 作者: Jaroslav Tulach
  • 出版社/メーカー: Apress
  • 発売日: 2008/07/30
  • メディア: ハードカバー

API設計の領域は、非常に難易度が高く、重要な領域です。しかし、何も本も読まず、レビューや指導を受けたことがない人達に作成させるためでしょうか、実際のソフトウェア開発では、いい加減なAPIを多く目にします。そして、「どうしてこうなっているの?」と聞くと、「参考にしたコードがそうなっていました」と答えるサラリーマン・エンジニアが多かったりします。