So-net無料ブログ作成
検索選択
前の10件 | -

『Javaパフォーマンス』読書会  [プログラマー現役続行]

Javaパフォーマンス

Javaパフォーマンス


先日募集した『Javaパフォーマンス』の社内読書会を4月27日(月)から始めます。参加者は、私を入れて5名と非常に少ないです。

この人数が少ないかというと、他の書籍の社内読書会でも最後まで続いた人達なので、特に少なくはないです。朝の読書会では、当初は参加者が多いです。しかし、普段から朝早く起きられる人でないと続かないため、結果として、少人数になってしまいます。


スポンサーリンク





レベル2:見習い [プログラマー現役続行]

ソフトウェア・スキル・インデックス」では、7つのレベルを定義しています。その中で、レベル1である初心者は、次のように定義しています。
指導を受けながら実践ができる
拙著『プログラマー”まだまだ”現役続行』では、次のように解説しています。
 ある程度の基礎知識を身につけたら、ソフトウェアの開発では、本人の経験を積ませるために、難易度の低い開発業務を行ってもらうことになります。このレベルでは、UMLを学び、クラス図やシーケンス図を描いたり、実際に多くのコードを書いたりします。
 しかし、クラス図やシーケンス図を描けるということは、うまく設計できるということとは同義ではありません。したがって、成果物を常にチェックして、ソフトウェア開発業務を行わせる必要があります。
 ソフトウェア開発では、デバッグを回避することはできません。したがって、デバッグの方法についても、間違った考え方や憶測でデバッグしているようでは、その後の成長は望めません。
 このレベルでは、バグの原因が何であると推測できるか、その推測からバグの現象を説明できるかとの仮説を立てさせて、その仮説を証明するには、どのような方法で確認すべきかを、常に論理的に思考させる必要があります。そして、その確認方法(デバッグ文の挿入など)で仮説が否定された場合には、再度別の仮説を立てて検証させていきます。
 本人がどのようにバグを調査したかを確認するのは、重要です。誤った考え方でたまたまバグを発見した、あるいはバグが再現しなくなったというようなことを繰り返すと、成長が望めません。したがって、「バグを修正しました」と報告されたときは、論理的に説明できているかを常に本人に問うことが必要です。

 デバッグには、論理的に推論する力だけでなく、その推論を支える膨大な知識が必要です。初心者や見習いレベルの場合には、その両方が欠けています。
 論理的思考は日々の指導で、知識は継続した学習で、それぞれ身につけていきます。トレーナーは、見習いレベルの人材を、この二本立てで育成していく必要があります。ここでも、不適切なトレーナーや先輩に育成させると、本人も成長しないことになります。
 見習いレベルから初級職人レベルになるには、一、二年は要するかと思います。
情報工学系の修士課程を修了していれば、この見習いレベルの指導は必要ないかと思っていましたが、どうもそうではない人達も日本の大学を卒業した人達にはいるようです。ここで述べているように論理的にデバッグができて、説明ができないようでは、おそらく次の「レベル3:初級職人」の域には、一生到達しないかもしれません。

プログラマー”まだまだ”現役続行 (技評SE選書)

プログラマー”まだまだ”現役続行 (技評SE選書)



『RESTful Web APIs』読書会 終了 [プログラマー現役続行]

RESTful Web APIs

RESTful Web APIs


2014年1月21日(火)から始めた『RESTful Web APIs』読書会ですが、開催しない週があったり、転勤で勤務場所が変わったりして、かなり進捗が悪かったのですが、今日、終わりました。最終会の参加者は、私を入れて3名でした。翻訳が出ていない本の読書会でした。

アウトプット力が低下してきている? [プログラマー現役続行]

最近は、「検索の時代」になったため、大学でのレポートで、検索して、コピペして、仕上げる学生が多いのではないかと思います。確かに、大学で出される課題レポートであれば、検索して答えが見つかる可能性が高いと思います。しかし、企業内の文書作成では、そもそもネットで検索しても答えなどないものが多いです。たとえば、社内で作成されたソフトウェアフレームワークの仕組みを調べて、文書を作成する仕事が与えられたとして、ネットでは検索できません。

そうなると、フレームワークを調べる能力に加えて、それを分かりやすく文書にすることができないとだめです。しかし、残念ながら、そのような文章作成を学生時代行っていないため、レビューで「こんなことから指摘しなければならないのか」と思う低レベルの日本語の指摘もしなければなりません。例としては、「話し言葉」と「書き言葉」の違いとかです。たとえば、「機器へコマンドを送信する」ではなく「機器へコマンドを投げる」と、普段の会話で本人が使用している話し言葉でそのまま書いてきたりします。

ネットで検索すること悪いことではありませんし、昔と比べてはるかに多くの情報を簡単に調べたり手に入れたりすることができます。一方で、アウトプットは意識して行っていく必要があります。

初心者だからと言って、汚いコードを書くことが許される訳ではない [プログラマー現役続行]

いつも講演や教育で話をしている「ソフトウェアエンジニアの心得」の講演スライドの中に次の一文があります。
初心者だからと言って、汚いコードを書くことが許される訳ではない
会社で給与をもらいながらソフトウェア開発に従事する場合には、資産を残すことが求められます。
ソフトウェアエンジニアの責任は、何年も使われ続けるビジネス資産を作り出すことです。ソフトウェアエンジニアが、他人の書いたコードを理解することができない場合には、そのコードはあっさりと捨てられ、一から書き直されてもおかしくはないでしょう。残念なことに、このような書き直しは頻繁に起きています。コードを読みやすく保守性を高めることは、コードを正しく動作させることと同じくらい、あるいはそれ以上に重要です。正しく動作しないコードは、動作するように修正することはできます。保守できないコードは、がらくたに過ぎません。
Taligent’s Guide to Designing Programs
どこかの建築会社に自分の家の設計・建築をお願いして、完成したら、出来上がりがひどい箇所があった時に、そのことを指摘して、「経験の浅い新人が担当したのでそうなりました」という言い訳されたらどう思いますか?

プログラミング経験が浅いという事実によって、会社におけるソフトウェア開発で、汚いコードを書いて残すことが許される訳ではないのです。しかし、実際には、何が良いコードで何が汚いかを初心者が判断することは難しい訳です。そのため、新人が書いたコードであっても、開発組織としてレビューを行い、きちんとした品質に仕上げさせる必要があります。

このことは、コードに限った話ではありません。作成してもらう文書もそうです。当然、作成された文書をレビューして、説明不足や分かりにくい日本語表現などを指摘したりして修正させます。

ところが、最近は、大学でもそのような文書作成の指導を受けてこないようで、何度も何度も分かりにくい日本語を指摘されて、修正を指示された結果、文書作成そのものが終わらなかったり、完成までに非常に長い期間を要したりします。その場合、レビューでレビューアがOKを出さないので、自分の仕事(文書作成やコーディング)が終わらないのであり、自分の責任ではないと考える人がいたりします。

若手に対するレビューは、単にアウトプットの品質を担保するだけのものではありません。数年後には、その人が次の若手をレビューして指導できるようになることも期待しているのです。もし、数年後に次の若手を指導できるようにはならないと判断されたら、レビューを通した指導もされなくなるかもしれません。

【社内連絡】『Javaパフォーマンス』読書会参加者募集 [プログラマー現役続行]

Javaパフォーマンス

Javaパフォーマンス


ブログに書いていますが、社内向けの内容です。

JavaDay Tokyoの会場で中身を見たのですが、なかなか良さそうなので、社内で読書会を開催したいと思います。

希望者は社内の私のメールアドレスに、以下の件名のメールをください。

件名: Javaパフォーマンス』読書会参加希望

なお、同時に書籍の購入も手配しますので、購入希望の有無をメール本文に記入してください

開催日: 毎週、月曜日 朝7時40分から8時45分
開始日: 2015年4月27日(月)
場所: 私が勤務している海老名リコーテクノロジーセンターのC棟19Fの会議室
申込み〆切: 2015年4月17日(金)
対象者: リコー社員に限定しませんので、関連会社、業務委託、派遣の人も参加可です。
進め方: 最初から読んでいきます。

この読書会そのものは、非業務扱いです。また、他拠点を接続しての開催は行いません。

Java誕生10周年の頃 [Java]

Javaが誕生してから今年で20年になり、今日は、Java Day Tokyo 2015が開催されます。私も1996年からのJavaとの付き合いになるので19年が過ぎたことになります。

10年前の2005年には、日本ではJavaOne Tokyoが開催されて、Java誕生10周年が祝われました。JavaOne会場では、バースデーケーキも登場し、壇上でハッピーバースデイも歌われました。

P1000291.JPG
JavaOne Tokyo会場

P1000268.JPG
2005年のJavaOne Tokyo

前年の2004年には、Java SE 5.0が登場し、ジェネリックス、enum、アノテーションなどが追加されました。写真の左から2人目は、その5.0のコンパイラを一人で書いたNeal Gafter氏です。

この年には、Joshua Bloch氏とNeal Gafter氏が執筆した『Java Puzzlers』が出版されました。『Java Puzzlers』の日本語版は、このJavaOneに間にぎりぎり間に合い、会場では100冊が販売され、Joshua BlochやNeal Gafterがサインしていました。

P1000283.JPG
Joshua Bloch氏のセッション


Java Puzzlers 罠、落とし穴、コーナーケース

Java Puzzlers 罠、落とし穴、コーナーケース

  • 作者: ジョシュア・ブロック
  • 出版社/メーカー: ピアソン・エデュケーション
  • 発売日: 2005/11/14
  • メディア: 大型本

おそらく、日本版にだけ収録された「付録C」がなければ、もっと多くの部数が会場で販売されたはずです。しかし、付録Cは、日本語版に向けて新たに執筆された付録であり、英版には収録されていません。

JavaOneの前日には、Joshua Bloch氏とNeal Gafter氏、および、Java Puzzlersの翻訳レビューを手伝ってくれた人達とディナーを食べています。

P1000253.JPG
Joshua Bloch氏とNeal Gafter氏

テーブルの上には、私のTiger本があるので、その時に贈呈したのだと思います。この時以来、二人は来日していませんので、日本で二人と食事をしたのは、この時が最後です。写真を良くみると、Joshua Bloch氏は、『Java Puzzlers』のTシャツを着ています。Neal Gafter氏は、カエルのTシャツです。彼は、カエルが好きなので、カエルがプリントされたTシャツを着ていることが多いです。

Java SE 5.0に対応した『Effective Java, 2nd Edition』が発売されたのは、さらに遅れて2008年です。

P1010165.JPG
Book Storeで平積みされたEffective Java

写真は、2008年5月にサンフランシスコで開催されたJavaOne会場のBook Storeに平積みになった『Effective Java, 2nd Edition』です。

Java 8に対応した第3版については、まだ何も聞いていません。しかし、ある日突然、「Yes, it's Effective Java time again」というタイトルのメールが、Joshua Bloch氏から送られてくるのを楽しみにしています。

電子版『Java SE 8 実践プログラミング』 [Java SE 8 実践プログラミング]

Javaプログラマーなら習得しておきたい Java SE 8 実践プログラミング

Javaプログラマーなら習得しておきたい Java SE 8 実践プログラミング

↑紙の本へのリンクです

紙の本からしばらく経過しましたが、電子版が準備されています。今日時点では、まだ、Kindle版の準備はできていないようですが、現在、Google Playでは購入できます。

http://book.impress.co.jp/books/1114101010

Kindle版も含めて、順次、準備される予定です。

11年4ヶ月振りの徳島(2) [その他]

2日目(3月19日)

2日目もあいにくの雨でしたが、徳島県立博物館に行きました。博物館といっても、徳島県立近代美術館も含まれています。展示の最終日だった「国立公文書館展」を見て、他の常設展示を見て回りました。

P1040893.JPG
徳島県立博物館

昼食を併設のレストランで食べた後、徳島県には3店舗しかないスターバックスに行って休憩しようということで、沖浜店に行きました。ここの沖浜店は、昔住んでいたマンションの近くです。

スターバックス.jpg
スターバックス徳島沖浜店

徳島のデザインのスターバックスカードはないのかなと思いましたが、ありませんでした。1時間ほどゆっくりしてから、アスティとくしまへ行ってみたのですが、ここは様変わりしていました。18年前に徳島に住み始めた頃は、観光客が立ち寄る場所で、週末には少人数ですが阿波踊りが行われていました。今は、ほとんど観光客は来ない場所となっています。

この後、昔はなかった阿波おどり会館に行き、阿波踊りを見て、お土産を買った、ホテルへ戻りました。

3日目(3月20日)

3日目は天気もよく、昔はなかったゆめタウン徳島へ行って見ることにしました。

P1040914.JPG
ゆめタウン徳島

徳島市内には、このような大きなショッピングセンターはないので、週末は多くの人がこちらを訪れているのではないかと思います。ここでもスターバックスへも行きました。

11004609_959371267415484_7032960414358466685_o.jpg
ゆめタウン徳島店

スターバックスは、どの店に行ってもだいたいテーブルや椅子などが同じで統一されているのですが、ここの店舗はちょっと違って独自のものになっていました。

昼食を食べた後、次にバルトの庭に行ってみました。映画「バルトの楽園」の撮影の後のロケの設備がしばらく公開されていたのですが、すべて取り壊すのではなく、一部を移設したのがバルトの庭です。


バルトの庭.jpg
「バルトの庭」入り口

平日ということもあり、最初は私達夫婦二人でしたが、途中でもう一組が来られて4人だけで、無料のガイドさんの説明を聞いて回りました。この後には、ドイツ館に立ち寄りました。

ドイツ館.jpg
ドイツ館と道の駅
昔は、手前の「道の駅」はありませんでした。11年前にドイツ館へ行った時に、駐車場に車を止めてトランクから荷物を取りだそうとしたら、1台の車が近づいてきて運転席から「柴田さん」と声をかけられたました。平日で駐車場はガラガラだったのですが、声をかけてきた人は、当時、海老名(神奈川県)の同じ職場で一緒に仕事をしている人でした。まさか、徳島で会うとは思ってもいませんでした。今回は、そのような出会いはありませんでした。

ドイツ館やバルトの庭へ、これから初めて行かれる人は、「ベートーヴェン 歓喜の歌 交響曲第九番」が日本で最初に合唱された「板東俘虜収容所」のことを事前に知るために、映画「バルトの楽園」を見てから行かれるとよいかと思います。

バルトの楽園 [DVD]

バルトの楽園 [DVD]


この後、ホテルに戻りました。18時前に「とくぎんトモニプラザ」へ行き、18時から「第7回とくしまOSS勉強会」で2時間近く話をしました。今回は、「ソフトウェアエンジニアの心得」を1時間で話したので、かなり省略したものとなってしまいました。また、その後、Java SE 8の話を30分だけして、Q&Aを行いました。参加者は、20数名でした。

講演の後、懇親会ということで、9名の方が参加されて、遅くまで色々と話をしてホテルに戻ったのは11時30分を過ぎていたと思います。

4日目

4日目は、少し曇っていましたが、眉山に登りました。

P1040934.JPG
眉山からの徳島市街地の眺め

眉山に登った後、レンタカーを返すまで時間もあり、昼食をどこかで食べようということで、「木の花」という店に行きました。

木の花.jpg
木の花

この店は、昔住んでいた頃にはなかったのですが、住んでいたマンションから徒歩数分のところにありました。昼食後、空港へ戻って、レンタカーを返却し、3時30分の便で羽田へ戻りました。
前の10件 | -