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

Issue 3310 & 3778 [Google Web Toolkit]

Issue3310: Overloaded method causing runtime exception in web mode onlyを調査していたら、本来文法エラーのはずなのに、Eclipseではエラーにならないという現象を発見しました。まだ、EclipseのバグとしてEclipse開発側で管理されているかどうかは調べていません。簡単に言えば、Javaのソースコードレベルでは文法エラーとなるべき、メソッドのオーバーロードが、文法エラーにならずにコンパイルされてしまうという不具合です。

Issue3778: HashMap returns 'undefined' instead of nullは、HashMapgetメソッドで存在しないキーを指定すると、nullが返されるべきなのですが、それを文字列に変換させて表示すると、ブラウザー上では"undefined"となってしまう現象です。

JavaScriptへ変換されたgetメソッドは、キーが存在しないと、JavaScriptのundefinedを返しnullは返しません。したがって、そのまま文字列に変換すると"undefined"となってしまう訳です。

一応、私なりにパッチを作成してみたのですが、"null"や"undefined"をブラウザー上で表示したいようなケースは稀であり、もともとの設計通りの振る舞いということになって、現状のままとなっています。


書籍『Elements of Programming』 [本]

Elements of Programming

Elements of Programming


発売前に注文していたのが、昨日届きました。ざっとページをめくった程度ですが、気楽に読める部類の本ではなさそうです。

Be the Worst : 実践 [プログラマー現役続行]

数日前に、「Be the Worst」(http://yshibata.blog.so-net.ne.jp/2009-06-22)という記事を書きました。その中で紹介したAct on It!アドバイスを週末の土曜日に実践しはじめました。オープンソース系で私にとって身近なのはGoogle Web Toolkitなので、Google Web ToolkitのIssuesリストを調べて、自分でも調査できるようなバグや課題がないかということで、取り組みはじめました。

JavaScriptは今まで勉強したことがないので、GWTC(Google Web Toolkit Compiler※1)のバグだと思われる場合には、生成されたJavaScriptのコードを調べて、Javaで書かれたソースコードを変更して確認してみたりということを行います。

生成されているJavaScriptの問題点が分かったら、GWTCをどのように修正すれば良いかを調べるのですが、簡単に分かる場合もあれば、全く分からない場合もあります。修正方法が分かれば、それを試してみて、正しく動作することを確認してから、自分で調べて分かった事柄とパッチを開発者向けのWikiに登録して終りです。後は、担当者が内容を確認してくれます。

土曜日に行う際の問題点は、Wikiに自分で調べて分かったことを夕方に書いても、Google Web Toolkitの開発チームは、米国のアトランタにいますので、すでに金曜日が終わっているため、担当者によるチェックが翌週になってしまうことです。

※1 Javaで書かれたソースコードをJavaScriptへ変換するコンパイラーです。

Yesterday Once More [音楽]

中学生の頃から耳にしているカーペンターズの「Yesterday Once More」は、今もその歌詞を聞くと、中学生の頃のことや色々なことが思い出されます。

音楽というのは、思い出と結びついていることが多いのではないでしょうか。曲が流れてくると、ある特定の場所やそこで過ごしたことが思い出されるような曲を多くの人が持っていると思います。チャゲ&飛鳥の「Say Yes」を聞くと、私は米国カリフォルニア州のPalo Altoで過ごした日々が思い出されます。

ソフトウェアエンジニアの成長カーブ [プログラマー現役続行]

最近良く話していることなのですが、社会人として働き始めた新卒技術者は、最初の数年は成長していきます。与えられた業務を遂行しながら、そのための学習もしていくからです。しかし、2、3年すると開発業務をこなせるようになり、特に新たな勉強をしなくても、日々、会社に行って開発業務が遂行できるようになります。

この状態、つまり、継続した学習をしなくなった状態で、10年とか経過すると、ソフトウェアの世界は大きく変化している可能性があり、新たな技術が登場し、その人の技量は相対的に今度は低下しはじめます。しかし、この時点で、新たなことを学習するのは困難だったりします。学習する習慣が無いわけですから、勉強しろと言っても、「なぜ、休みの日に勉強しなければならないのですか」ということになります。

そのような人に対して、マネジメントは、その人ができる仕事を与えて、何とか仕事をしてもらいますので、「新たなことを勉強しなくても、仕事はあるじゃないか」と本人は勘違いしてしまいます。この勘違いした状態になった人が声が大きかったり、(長く開発業務に従事しているという意味で)中堅だったりすると、その開発チームは全く成長しなくなってしまいます。

40代最後の年 [プログラマー現役続行]

今年の11月で、満50歳になります。1978年4月に九州工業大学に入学して、プログラミング言語演習でFortranを習ったのが、初めてコンピュータに触れた時でした。当時は、家に電卓もない時代で、高校三年生の時に物理の実験で電卓を使わせてもらったことを覚えています。

あれからすでに31年が過ぎ、コンピュータを取り巻く世界は、絶えず変化し続けています。先日、Google Developer Day 2009へ参加して思ったのは、若い人が多く参加しているのは当然なのですが、私と同年代の人が非常に少ない思いました。

日本の社会では、ずっとソフトウェアエンジニアであることは難しいのかなとか、もう、新しい技術には興味を持たなくなった人が多いのかなとか色々と考えてしまいました。

私自身は営業職でもないのに、1985年に結婚してからの18年間で、10回引っ越ししました。その都度、新しい職場で、新しい仲間とソフトウェア開発に従事したことになります。その中でも、米国での通算5年間の米国ゼロックス社駐在(職場は3ヶ所)や、短いですが日本オラクルとジャストシステムでの勤務経験は、私自身の考え方に様々な影響を与えたと思います。

若手の育成を強く意識しはじめたのは、日本オラクルの初代社長でした佐野力氏が私が入社した月の中途入社社員を集めて話をされた時です。内容はかなり自慢話が多かったですが、その中で、(正確には覚えていませんが)「5年後、10年後に日本オラクルを背負うのは、中途入社の皆さんではなく、新卒新人です。したがって、新卒新人は育てていきますが、みなさんは、即戦力として頑張ってください」という趣旨のことを言われたました。

この言葉を聞いてからすでに12年近くなりますが、その間、どれだけ多くの若手に良い影響を与えることができたのだろうかと思います。一緒に仕事をしたことがなくても、雑誌の記事や書籍、それに、講演を通して、良い影響を与えてることができていれば良いなと思います。

50代の次の10年間も、様々な人たちと一緒にソフトウェア開発に従事し、私自身の技量も伸ばしながら、多くのエンジニアの成長を後押しできればと思います。

若手の育成 [プログラマー現役続行]

情報系の学科を卒業しても、きちんとしたソフトウェア開発ができるようになるまで、多くの事柄を学んでもらう必要があります。その中のいくつかとして、以下の事柄があるかと思います。

① 1つのプログラミング言語を習得させる。
② 基礎知識を習得させる。
③ 読みやすいコードを書かせること。

新人だからと言って、負債となるような汚いプログラムを書いて良いということは決してありません。芸術の領域では、かなの練習を積んで、上手くなって、それで初めてお金を払う価値があるものを作り出せるようになります。一方、残念ながらソフトウェア開発では、全くの素人に物作りをさせてしまったりしていることが多いと思います。

このような状況ですが、それでも、新卒新人を育成してソフトウェアを開発していく必要がある訳です。そのために、きちんとしたソフトウェアを開発させるためには、かなりの指導が必要なのが現状ではないでしょうか。

開発組織では、このような指導を地道に行っていることに対して、評価をしていく必要があります。もし、評価しないとなると、指導しても評価されないということで、指導する側の人材も育つことなく、開発組織としては伸びていかないことになります。

拙著『ソフトウェア開発の名著を読む』の107頁では、『ソフトウェア職人気質』から次の引用をしています。
しかし本当の難点は、そのような開発者が学習を重ね、向上していくかどうかではなく、彼らとともに働く人たちが、学習と向上に対して彼らと同じ態度を持って臨むかという点にあります。要するに私たちが探しているのは、ソフトウェア開発のすべてに熟達しており、アプレンティスに持たせたいような作業習慣を持っている人なのです。そして探し出す際の鍵となる質問は、「彼はソフトウェア開発の技芸に対する自分の意気込みと熱意を、同僚に伝染させたことがあるだろうか?」ということです。
『ソフトウェア職人気質』
若手の育成というのは、単に指導するだけでなく、ここで述べられたような「伝染」をさせる活動だったりします。

ソフトウェア開発の名著を読む (技評SE新書 003)

ソフトウェア開発の名著を読む (技評SE新書 003)


ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series)

ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series)

  • 作者: ピート マクブリーン
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2002/03
  • メディア: 単行本


Be the Worst [プログラマー現役続行]


The Passionate Programmer

The Passionate Programmer

  • 作者: C Fowler
  • 出版社/メーカー: Pragma
  • 発売日: 2009/05/22
  • メディア: ペーパーバック

先日紹介した書籍ですが、4項目として、「Be the Worst」があります。その冒頭で次のように述べられています。
Legendary jazz guitarist Pat Metheny has a stock piece of advice for young musicians, which is "Always be the worst guy in the every band you're in."
つまり、技量的に自分が最も下となるようなグループに属しなさいということです。それにより、自分の技量が向上するということです。つまり、
The people around you affect your own performance. Choose your crowd wisely.
そうは言っても、そのような開発組織を渡り歩くのはなかなかできないと思います。それで、本の中のAct on It!セクションででは、次のようなことをやってみてはと述べられています。
Find a "be the worst" situation for yourself. You may not have the luxury of immediately switching teams or companies just because you want to work with better people. Instead, find a volunteer project on which you can work with other developers who will make you better via asmosis. Check for developer group meetings in your city, and attend those meetings. Developers are often looking for spare-time projects on which to practice new techniques and hone their skills.
さらに続けて、
If you don't have an active developer community nearby, use the internet. Pick an open source project that you admire and whose developers appear to be at that "next level" you're looking to reach. Go through the project's to-do list or mailing list archives, pick a feature or a major bug fix, and code away! Emulate the style of the project's surrounding code. Thurn it into a game. Make your design and code so indistinguishable from the rest of the project that even the origianl developers eventaully won't remember who wrote it. Then, when you're satisfied with your work, submit it as a patch. If it's good, it will be accepted into the project. Start over, and do it again. If you've made decisions that the project's developers disagree with, either incorporate their feedback and resubmit or take note of the changes they make. On you next patch, try to get it in with less rework. Eventually, you'll find yourself to be a trusted member of the project team. You'll be amazed at what you can learn from a remote set of senior developers, even if you never get a chance to hear their voices.
Internetとオープンソースの普及により、個人でもこのような活動ができる時代になったということでしょう。

Issue 3710 [Google Web Toolkit]

現在リリースされているGoogle Web Toolkit 1.6.4で、次のようなメソッドを作成すると、正しくJavaScriptへ変換されません。
private int value;

public long getAsLong() {
    return value;
}
これは、int型の値をlong型としてreturn文で返すようなコードが、正しいJavaScriptへ変換されないからです(Issue 3710)。

JavaScriptでは、Java言語のlong型に相等する型がないため、double型の配列を使用して注意深く実装されているのですが、return文において適切な変換を行うコードが生成されいませんでした。正しく変換されていないという事実までは調べて報告したのですが、残念ながらコンパイラーをどのように修正するかまでは分かりませんでした。

すでにコンパイラーの修正は行われていますが、リリースはされていません。したがって、その修正を利用するには、Google Web Toolkitのリポジトリーからソースコードを持ってきて、自分でビルドしなければなりません。

自己啓発が組織を導く [名言]

一人ひとりの自己啓発が、組織の発展にとって重要な意味をもつ。それは、組織が成果をあげるための道である。成果に向けて働くとき、人は組織全体の成果水準を高める。彼ら自身および他の人たちの成果水準を高める。
P.F.ドラッガー
ソフトウェア開発組織が発展するためにも、一人ひとりのソフトウェアエンジニアが、自分自身の技量を高めるために、継続した学習を継続し、新たな技術や新たな開発プロセスを実践して、良いものを取り入れて高品質のソフトウェアを開発していくことです。その結果として、その開発組織の水準は高まっていくと思います。

このような組織作りは、簡単ではありません。私自身、若手のエンジニアを育成して、組織として質の高いソフトウェアを開発する技術者集団を目指して、10年近く様々な活動をしてきました。
金を残す人生は下、事業を残す人生は中、人を残す人生こそが上なり。
後藤新平
残念ながら、会社での評価は、後藤新平の言葉とは全く逆になっていることが多いのではないでしょうか。

教育や講演で述べていることですが、作成されたソフトウェアは、「資産」とは限らないのです。一見すると機能している家のようには見えるけど、欠陥だらけの住宅のような「負債」だったりします。作り手がきちんと作らない(ソフトウェアの場合には、きちんと作れないレベルの人が作ったりする)と、作成にも多くの費用を要し、完成後(?)も多くの修理費を必要とします。

ソフトウェア開発では、単なる個人の単価で評価されるべきものではなく、作成されるソフトウェアの品質で評価されるべきであり、開発組織も組織として高品質のソフトウェアを開発できることを目指すべきだと思います。たとえ、それが外部から評価されなくてもです。