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

『Effective Java 第2版』正誤表を更新しました [正誤表]

Effective Java 第2版 (The Java Series)

Effective Java 第2版 (The Java Series)


原著の間違いを反映して、正誤表を更新しました。正誤表は、私のホームページにあります。

http://www001.upp.so-net.ne.jp/yshibata/

函館でのハンズオン・セミナー(7月30日) [プログラマー現役続行]

2009年初めから行っている無料の講演・セミナーですが、今週末の7月30日(土)に再び函館で行います。2年前の夏に、はこだてIKA(http://hakoika.jp/)様主催で、「ソフトウェアエンジニアの心得」の講演を行いましたので、今年は「テストファーストで学ぶプログラミングの基本」と題したハンズオン・セミナー形式です。

基本的には、簡単なテストファースト開発を小さなプログラミング課題を通して行ってもらうものです。最初に、「テスト駆動開発」や「防御的プログラミング」に関する説明を行い、その後、Eclipse/JUnitを用いて簡単な課題プログラミングを行ってもらいます。課題は4つ用意していますが、時間の関係で2つか3つだけになるかと思います。

普段は、練習のために私が行っている課題ですが、社内では、「プログラミング言語Java」教育で一度だけ私自身が、今度のハンズオン・セミナーの最初の課題を受講生の前で行って見せたことがあるだけです。社内では、来月行う「テスト駆動開発」コースで同じデモを行って見せる予定です。

※ 昨年は、帰省のスケジュールが上手く調整できずに、単なる帰省になってしまいました。今年は7月中旬に当初予定していたのですが、予定外の輪番制夏休みが導入されたために急遽再調整して7月30日(土)となりました。9月下旬には「オープンセミナー@高松」で話をする予定です。

書籍『Android SDK 開発クックブック』のサンプルコード [本]

Android SDK 開発クックブック

Android SDK 開発クックブック

  • 作者: ジェームズ・スティール
  • 出版社/メーカー: ピアソン桐原
  • 発売日: 2011/07/26
  • メディア: 単行本(ソフトカバー)

英語版の原著に対応したサンプルコードは、この翻訳本の中にも訳注で追記していますが、以下のURLにあります。

http://www.informit.com/store/product.aspx?isbn=0321741234

しかし、英語の原著にあるコードとこのURLからダウンロード可能なサンプルコードとは食い違っている箇所も多いです。また書籍の中のスタイルも不統一な部分が多いため、できるだけ日本語版では統一するようにしてあります。

英語版のサンプルコードに対応した、日本語版の書籍中のコードを用意しました。

http://www012.upp.so-net.ne.jp/eshibata/android/ADCCode.zip

ホームページの更新とデジタル時計 [Google Web Toolkit]

ホームページに新たに『Android SDK 開発クックブック』を追加しました。また、「活動一覧」のタブには、今年の活動を追記してあります。今回の追加で、翻訳本がちょうど10冊目です。自著も5冊となっていますので、合計で15冊となります。

http://www001.upp.so-net.ne.jp/yshibata/

最初の雑誌の記事を書いたのが2000年3月発売の「Java PRESS, Vol.11」ですので、ほぼ11年が過ぎたことになります。40歳から始めた執筆活動ですが、1996年の夏にJavaの独学を始めてから、Java言語が成熟していく過程だったこともあって、運良く活動ができたのだと思います。

ホームページは、Google Web Toolkitを使用して作成しています。Google Web Toolkitは、オープンソースなので最新のソースコードを開発用trunkから持ってきてビルドして使用しています。最近は、あまり触れていなかったために、以前に作成したbuild.xmlファイルは、内容が古く正しくコンパイルされませんでした。それで、再度webAppCreatorコマンドで別の場所にプロジェクトを作成して、そこからbuild.xmlをコピーして、正しくコンパイルされるようにしました。

ホームページの右隅には、デジタル時計が表示されています。表示されている時刻をクリックするとプロパティが表示されます。そして、「Advanced Settings」の「Clock Mode」の「detached」にチェックを入れると、右隅から消えて、マウスでドラッグして移動可能な表示に切り替わります。マウスでドラッグするとブラウザー内で好きな位置に移動可能です。再度、「detached」のチェックを外すと、ホームページの右隅に戻ります。

どのようにして実装しているのか興味がある人のために、このデジタル時計部分だけのウィジェットのソースコードをホームページからダウンロードできるようにしました。

http://www001.upp.so-net.ne.jp/yshibata/digitalclock.zip

jp.ne.sonet.ca2.yshibata.client.digitalclock.DigitalClockがウィジェットになっているデジタル時計です。

書籍『Android SDK 開発クックブック』が届きました [本]

2011-07-23 05.53.34.jpg

昨日、出版社から届きました。書店にそろそろ並び始めるのではないかと思います。Amazon.co.jpでも、購入可能になっています。

Android SDK 開発クックブック

Android SDK 開発クックブック


書籍『残業3時間を朝30分で片づける仕事術』 [本]

残業3時間を朝30分で片づける仕事術

残業3時間を朝30分で片づける仕事術


長津田駅の書店で見かけて購入しました。早起きにシフトするのと仕事のやり方を工夫するということでがテーマの書籍です。

著者の永井さんは、10時に寝て5時に起きるというパターンのようです。私は、9時に寝て4時に起きるパターンです。私自身は、過去10年間は会社に行く前に翻訳をしたり、雑誌の記事や自分の本の執筆と行ってきましたが、時々言われるのが「ストイックによくやれますね」という言葉です。でも、実際には、この本に書かれているように、生活の時間帯を早朝にシフトしているだけです。

「ストイック」ということに関して、面白い表現をしているなと思ったのは、次の部分です。
 早朝出勤すると、それほど混んでいない電車にゆったりと座れます。とても楽ですし、本を読んだり、パソコンを広げたりして、自由に時間を使えます。
 私からすると、普通の通勤時間帯に、ギュウギュウ詰めの超満員電車で、一時間も我慢して出勤するほうが、ずっとストイックのように思えます。まるで修行のようです。わずか、2、3時間、早い時間にシフトするだけで、この体力を消耗する状況を避けることができるのです。
『残業3時間を朝30分で片づける仕事術』(p.050)
私も転職してから、こどもの国線の「こどもの国」駅から大井町線の「荏原町」駅まで通勤していたのですが、当初は座れない時間帯に乗っていました。ある日、台風が来るということで、遅れると困るので普段より早く家を出て、始発の次の電車に乗ってみました。そうすると、途中の「溝の口」駅での乗り換えも含めて、ずっと座って行けることを発見したのです。それからは、毎日、家を早く出て、荏原町には7時台前半に到着し、マクドナルドで翻訳作業を行った後に出社していました。

WiMAXに加入しました(2) [WiFi]

WiMAXに加入しました」で書きましたが、WiMAXの利用を開始して2週間が過ぎました。やはり、今まで公衆無線LANサービスのエリア外ではノートPCも利用できずに不便だったのですが、便利になりました。単にメールやTwitterをチェックするだけであれば、Kindleでも十分できたのですが、返信や書き込みは不便でした。

Aterm WM3500Rは、カバンの中に入れて使用していると結構熱を帯びますので、喫茶店などで作業する場合には、カバンから出すようにしています。普段は、GDDフォンを持ち歩いているので、Kindleは読み物専用で、メールやTwitterチェックはGDDフォンで行っています。ただ、そうするとGDDフォンのバッテリーが夕方には切れてしまうことが多くなってしまいました。

書籍『Being Geek』(3) [プログラマー現役続行]

Being Geek ―ギークであり続けるためのキャリア戦略

Being Geek ―ギークであり続けるためのキャリア戦略


副題にあるようにキャリア戦略なので転職の話が色々と書かれているのですが、その中で「転職先の価値を見極める」(p.27)には転職先には「新しさとは別の、独自の価値があるかどうかが大切である」と述べられた後に、次のように述べられています。
 会社に独自の価値があるか、また、その価値とは何かがわかれば、次に問うべきことは、「そこで本当に自分のやりたいことができるか」である。むしろこの方が重要な問いだろう。それが自分の将来を左右する。また、この問いに答えるには、自分が本当にやりたいことは何かを考えなくてはならない。
 本当にやりたいことは何か、一言で明確に答えられなくてもいいだろう。私にもまだ明確な答えはない。だが、答えるのが非常に難しい問いだからといって、答えなくてもいいという意味にはならない。たとえおぼろげな目標だとしても、転職先の会社が、その目標に向かう上でプラスになるかどうかを考えることはできる。その会社に移ることで、目標に一歩でも近づけそうだ、と自分が感じるかどうか、それが最も大事である。
 つまり、転職先を選ぶというのは、ただ会社を選ぶというよりも、自分の進むべき道を選んでいるということなのだ。その道が本当に自分の進みたい道なのか、それをじっくり考えて決断すべきだ。
私自身が4回転職し、この部分は非常に耳が痛い話です。自分が何をやりたいかとうことは、若い頃には明確であった訳ではなく、色々な職場を経験して、徐々に明確になってきている気がしています。

しかし、4回目の転職がその目標に一歩でも近づいたと感じるかと問われるとしたら、大幅に後退したと言わざるをえません(感覚的には10年は戻った感じです)。では、何も得られていないかというと、そうでもなく、後退した結果、転職する前の位置までの道のりがどのようなものであったかが良く理解できるようになりました(「教育、場、権限」)。

後退した結果、同じ道のりを歩んで後退前の地点まで戻ることはあり得ないと思っています。それは過去の道のりであり、今歩んでいる道のりとは異なるからです。今の道のりで後退前の地点を遙かに超えたと言えるような地点まで歩めるのか、あるいは、もっと手前で別の道を歩むかは今は分かりません。

書籍『Being Geek』(2) [プログラマー現役続行]

Being Geek ―ギークであり続けるためのキャリア戦略

Being Geek ―ギークであり続けるためのキャリア戦略


この本の「退屈な時間の重要性」(p.124)には毎週行うチーム全体でのミーティングについて次のように述べられています。
 コミュニケーションに終わりはない。いつまでも続けなくてはならない。チームのメンバーをお互いにいくらよく知っていても、実際に話してみた時、会話がどういう方向に進むかを正確に予測することはできない。常時、同じパターンでミーティングを実施するメリットをまとめると、だいたい次のようになるだろう。
  • チームのメンバー一人一人のスケジュールが把握できる。特定の人に直接、話を聞きたくなった時なども、いつなら都合が良いかがだいたいわかる。
  • チーム全員が、開発中のシステムについての多くの情報を得ることができる。
  • 自分たちの仕事が今、うまくいっているかどうか、1週間ごとに確認できる。
 こうしたメリットは、ミーティングを機械のように正確に開催することによって得られる。何があっても執拗に、同じパターンでミーティングをするのだ。何年か後、チームのメンバーが転職してよそへ行ってしまっても、月曜の朝10時15分になるとつい時計を見て「ああ、対話ミーティングの時間だな」と思ってしまう、そのくらい強く習慣づけたい。だが、それはメンバーを縛りつけるためではない。メンバー間の信頼関係を築き上げるために必要なことなのだ。それは自分の経験から確信を持って言える。
私の経験からも、毎週一回、決まった時間にメンバー全員が集まって行う週報会は、メンバー間の信頼関係を築き上げるには重要だと言えます。個々のメンバーから先週の活動内容や問題を1、2分で報告してもらい、それに対して必要なら質問したりするという簡単な週報会であっても、上で述べられているようなメリットが得られます。

組織によっては、「機械的マネージャ」が多く、その結果、全員で集まるのは時間の無駄と考える傾向が非常に強い場合もあります。そのような組織では、コミュニケーションが悪い組織になっているように私には思える場合もあります。「機械的マネージャ」と「有機的マネージャ」に関しては、「スタッフミーティング」(p.71)に述べられているのですが、極端な分類として次のようにミーティングに関する対応が述べられています。
有機的なマネージャと機械的なマネージャとでスタッフミーティングがどう違うかを具体的に見てみよう。まず、ミーティングに関して着目するポイントは、両者で次のように違っている。
  • 何か他に問題はあるか:機械的マネージャ
  • 未対策の問題はあるか:機械的マネージャ
  • 皆が活発に意見を言えるような雰囲気になっているか:有機的マネージャ
  • マネージャの発言を待たすに、皆が進んで意見を言っているか:有機的マネージャ
  • 議論が時間内に終わったか:機械的マネージャ
  • ミーティングのために確保した時間は長すぎなかったか:機械的マネージャ
  • 今日話し合ったことを他人にうまく説明できるか:有機的マネージャ
  • 十分な議論ができたか:有機的マネージャ
  • 楽しいミーティングになっているか:有機的マネージャ
 正確には、完全に有機的なマネージャや、完全に機械的なマネージャというのはあまりいない。
私はどちらかというと有機的だと思います。だから、全員が集まって話をするよりは、週報を書けば良いというだけの組織では、非常に居心地が悪かったりします。

書籍『Being Geek』 [献本]

Being Geek ―ギークであり続けるためのキャリア戦略

Being Geek ―ギークであり続けるためのキャリア戦略


出版社から献本していただきました。対象とする読者は、ソフトウェア開発の経験を数年経てこれからリーダになる人からでしょうか。全体として、転職も含めたキャリアの話とマネージャとしてのマネジメント関連の話です。

キャリアに関して、「成長」ということで次のように述べられています。
成長はかなり正確な指標になり得るのだ。私の経験からもそう言える。成長していれば、その背景にはおそらく何らかの戦略が存在していると考えられるからだ。たとえば、人が成長しようとすれば、そのために新たなことを学ぶ必要がある。しかも、ただ漫然と学ぶのではなく戦略的な学びが必要なのだ。そうして成長することができれば、より大きな結果が出せるようになり、会社に利益をもたらすこともできるだろう。昇進もし、より大きな責任を担うようにもなるだろう。この場合も、「成長しないのは、死んでいると同じ」と言い切ってしまってもさほど間違ってはいないと思う。少なくとも、そう言ってしまった方が分かりやすいだろう。
そして、「成長しないのは、死んでいると同じ」という言葉はマネージャにも当てはまるとも述べています。そして、キャリアに関しては、当たり前ですが、次のように述べています。
おそらく健全なのは、「私の仕事に対して責任を負うのはマネージャだが、私のキャリアに対して責任を負うのは私自身である」と考えることだろう。
転職に際しての電話インタビューから始まる採用面接の話も書かれているのですが、日本ではあまり当てはまらない内容かと思います。そもそも電話で30分ほどインタビューして、最初に適性を見るということは、日本ではほとんど行われません。そして、その後に、一緒に仕事をすることになるかもしれない人達からインタビューを受けるということはないです。ただ、一度でもそのような採用プロセスを経験したことがあれば、そういうことだったのかと考えながら読める内容です。

エンジニアがマネージャになった時に注意を払うべきことも多く述べられているのですが、その中で「スケーリング」として次のように述べられています。
 マネージャにとって大切なことはいくつもあるが、その1つは「スケーリング」である。マネージャになったら、元々自分の持っているスキルをスケーリングしなくてはならない。エンジニアだった時にバグ修正に超人的な能力を発揮していたのだとしたら、マネージャとしては、チームが全体としてその超人的な能力を発揮できるようにしなくてはならないのだ。
 自分の学んできたことを、部下にわかるように翻訳して教えていく必要がある。そして、学ばせるには、信頼して任せるということが必要だ。以前なら、自分でしていたこと任せてしまうのである。
 信頼することで、良いフィードバックループが生まれ、徐々に生産性は上がり、満足のいく仕事ができるようになっていく。部下を信頼することでスケーリングができ、自分と同じクオリティの仕事を、自分一人の時よりはるかに多くこなせるようになる。多くの仕事をこなすほど、多くの経験ができ、多くを学ぶことになる。そうしてたくさんのことを学び、理解すれば、それだけ、教える材料も増え、ざらにスケーリングを進められるだろう。
このスケーリングを実施している、あるいは、意識している元エンジニアであるマネージャは少ないのではないでしょうか。

本書は、ソフトウェアエンジニアとしてキャリアを考える上で参考になる事柄が多く述べられています。ただし、技術的なことはあまり書かれていません。どちらかと言うとマネジメント関連が多いかと思います。