月別アーカイブ: 2006年3月

World Baseball Classicを見て思ったこと

  • 次回は日本で開催しないかなぁ
  • 米国はショックだったろうし、来年は運営方式が変わるんじゃないかな
  • やはり日本は、サッカーよりは野球が強いのでは。大事なところで点が取れる。

ちょっと日本の優勝がどう思われているか気になったので、例によってThe New York Timesを覗いてみたが、

http://www.nytimes.com/2006/03/21/sports/baseball/21classic.html

Despite having only two major leaguers, Japan won the tournament. Despite having no major leaguers, Cuba finished second. The United States feels it has the best players in the world. In this tournament, that was untrue. Japan, as the flying flags showed, was the class of this classic.

とある程度の評価は頂いているようだ。世論や他紙は分からないけれど。

Google Finance

気がついたらGoogle Financeなんて新サービスが始まっている。The New York Timesの「Google Offers Search Service on Finance」という記事で取り上げられていたので紹介。

http://www.nytimes.com/2006/03/21/technology/21google.html?_r=1&oref=slogin

Google said the initiative grew out of a survey it conducted 15 months ago, asking its users what kinds of new services they would find helpful. The response was dominated by two themes: maps and finance.

グーグルが市場調査(って言うのも変かな)を15ヶ月前に行っていたんだそう。これは意外だった。その結果のほとんどが地図と金融に関するものだった模様。この調査を元に、Google MapとGoogle Financeを開発したと思われる。ここからGoogleの開発の速度も窺える。

The site will focus on current and historical data for both public and private companies, and following a Google practice for its new offerings, it will not immediately carry advertisements.

“Our focus is on the user and the product,” said Marissa Mayer, Google’s vice president for search products and user experience. She said the company would consider revenue possibilities later.

この辺はいつも通りで、儲けは後からついてくるだろう、ということらしい。単純に考えればまた広告かなと思うが、とりあえずは広告を出さないようだ。この辺の展開も今後が楽しみ。

で、実際にhttp://finance.google.com/financeに飛んで使ってみた。記事に以下のようにあるが、

One feature the company emphasizes is the ability to track when news stories appeared along a timeline display of stock prices. It will also link to discussions on Web logs about specific companies.

チャートの所々にある旗みたいなマークと、右側に出現する関連記事とがリンクするようになっている。これで時系列でニュースと株価を照らしあわすことが出来るようだ。僕は株をやらないので、実践的にどのような使い道があるのかよく分からないが、色々と遊べそうだ。とりあえずYahoo!FinanceよりもUIは断然良いと思うのは僕だけか。

役員の名前や関連会社もずかずか下に出てくるし、何よりその会社について書かれたブログが出てくるのが面白い。今後はある会社について言及されたブログを探したいとき、ここから探すのがデフォルトになるかも。

コーディングはエンジニアリング

「ソフトウェアの仕様書は料理のレシピに似ている」が盛り上がりを見せている。僕と同じく、この業界にいる人が、たくさんネットを見て回っているのがよく分かる。

さて、業界構造がゼネコン業界に似たり寄ったりでおかしいことになっているのが事実だが、当のエンジニア達も、「いつかはこの下積みのコーディング生活から抜け出して、設計を手がけ、何百人の開発者を下に付けて…」なんてキャリアを思い描いているように見えるのですが、どうでしょう。僕はエンタープライズ系と言ってもパッケージベンダーで(受託開発ではない)、下請けに開発を発注したりということはないが、それでも上記のように考えている開発者が多いと思う。35歳限界説なんて言葉が生まれるのも、結局どこかコーディングを軽視しているからだろう。そんでもって軽視している奴に限って、コーディングの出来ないプログラマか、開発をまったく経験していない経営者やコンサルタントという訳だ。

ここで言っておきたいのが、「レベルの高いコーディングは、エンジニアリングであるということ」だ。エンジニアリングの分野に従事していると考えれば、開発工程の下流に存在するエンジニアが邪険に扱われていることに違和感を覚えると思います。ちょっと前にid:umedamochoさんのところで盛り上がっていた「虚業という言葉について」じゃないけれど、実体の伴わないソフトウェアやWEBサービスに、やはり「エンジニアが物を創っている」という感覚を持てない人がたくさんいるんだな、と感じる今日この頃。だからなんとなく軽視されてしまうのでは。

ソケット通信でファイル転送その1

ソケット通信でファイル転送をするプログラムを作ってみようと試みている。とりあえず手始めとして、簡単な文字列を送るプログラムを作ってみた。本日はファイル転送までは手が回らず。

クライアント側のソースは以下。引数として、サーバのアドレスと、サーバ側プログラムが使用するポート番号、送信する文字列を指定する。

import java.net.*;
import java.io.*;
public class FileTranClient {
public static void main(String[] args) throws IOException{
if (args.length != 3)
throw new IllegalArgumentException("Arguments should be host,port and
    message");
  String server = args[0];
int serverPort = Integer.parseInt(args[1]);
  byte[] byteBuffer = args[2].getBytes();
  //Create Socket
  Socket socket = new Socket(server,serverPort);
  System.out.println("Connected to server");
  //Create OutputStream
  OutputStream out = socket.getOutputStream();
  out.write(byteBuffer);
  System.out.println("sent message : " + args[2]);
  socket.close();
}
}

サーバ側のソースは以下。引数として、このプログラムが実行されるポート番号を指定する。

import java.net.*;
import java.io.*;
public class FileTranServer {
public static void main(String[] args) throws IOException{
if (args.length != 1)
throw new IllegalArgumentException("An argument should be port");
int servPort = Integer.parseInt(args[0]);
//Create ServerSocket
ServerSocket servSock = new ServerSocket(servPort);
int recvMsgSize;
//int bufSize = servSock.getReceiveBufferSize();
int bufSize = 32;
System.out.println("Size of ReceiveBuffer : " + bufSize);
//Socket accepting loop
while(true){
System.out.println("Wait for accepting... ");
Socket clntSock = servSock.accept();
byte[] byteBuffer = new byte[bufSize];
System.out.println("Accepted client at " +
clntSock.getInetAddress().getHostAddress() +
" on port " +
clntSock.getPort());
//Create InputStream
InputStream in = clntSock.getInputStream();
//Read message and print it out
while((recvMsgSize = in.read(byteBuffer)) != -1){
System.out.println("Message : " + new String(byteBuffer,0,recvMsgSize));
System.out.println("Size    : " + recvMsgSize);
}
clntSock.close();
}
}
}

サーバ側にて、

    //int bufSize = servSock.getReceiveBufferSize();
int bufSize = 32;

としてるところがポイントで、クライアント側から送られてきた文字列を1回32バイトずつ読み込むようにしてみた。ちなみにコメントアウトされてるほうでbufSizeを宣言すると、8192バイトずつ読み込まれるようになった。これはおそらく、僕のPCのデフォルト値なのだろう。
送信するメッセージは、以下の105バイトの文字列とした。

TokyoNagoyaOsakaNewYorkFukuokaSeoulSapporoSeattleLosAngelesChibaYokohamaKyotoNaraParisFlorenceAkitaAomori

以下に実行結果を示す。

クライアント側の実行結果。

Connected to server
sent message : TokyoNagoyaOsakaNewYorkFukuokaSeoulSapporoSeattleLosAngelesChibaYokohamaKyotoNaraParisFlorenceAkitaAomori

サーバ側の実行結果。

Size of ReceiveBuffer : 32
Wait for accepting...
Accepted client at 127.0.0.1 on port 1045
Message : TokyoNagoyaOsakaNewYorkFukuokaSe
Size    : 32
Message : oulSapporoSeattleLosAngelesChiba
Size    : 32
Message : YokohamaKyotoNaraParisFlorenceAk
Size    : 32
Message : itaAomori
Size    : 9
Wait for accepting... 

32バイトずつ文字列が読み取られている様子が目にみえた。次回はこれを改良し、ファイルの転送にまで繋げたい。おそらくファイルストリームとかいうやつを使うことで出来るのではないか。

今回Javaを勉強しているのだが、ネットワークなどについても何も知らないことに気付かされる。勉強しないとなぁ。

以下が参考にしている書籍。非常にわかり易く解説されていると思う。実例から理論的な説明まで載っているし、何より薄くて扱い易いところが○。大学の教科書として書かれたようで、手始めには適していると思う。ただファイル転送に関する話は載っていないようなので、また情報を探さないと。

TCP/IPソケットプログラミング Java編

TCP/IPソケットプログラミング Java編

Java本無料プレゼント

id:hyukiさんのエントリで、『増補改訂版Java言語で学ぶデザインパターン入門マルチスレッド編』無料プレゼントを行っている。僕も早速応募してみる。

ちょうどJavaの勉強中だし、d:hyukiさんの文章はわかり易くて好感が持てた記憶がある。これを機会にプレゼントの対象になっていない以下の本は購入しよう。

改訂第2版 Java言語プログラミングレッスン (上)

改訂第2版 Java言語プログラミングレッスン (上)

改訂第2版 Java言語プログラミングレッスン (下)

改訂第2版 Java言語プログラミングレッスン (下)

世界中を巻き込むイランの核開発その3

下院外交委が可決したのは「イラン自由支援法案」。対イラン制裁の柱だった「イラン・リビア制裁強化法」が8月に失効するのに伴う後継法の位置づけだ。
現行法からの主な変更点は(1)イランのエネルギー分野に投資を決めた企業の本拠がある国に対し米国の援助を停止(2)大統領が制裁の適用除外を認めた場合、6カ月ごとに再検討。「米国の安全保障に不可欠」が条件(3)官民を問わず投資に関与した金融機関も制裁対象に追加――など。制裁内容を強化するより対象を広げることに重点をおいた。

ほら来た。政府、民間商社ともにどう動くのか。米軍再編問題といい、牛肉輸入問題といい、最近の日米間はぎしぎししっぱなし。日米間摩擦というよりは日米間衝突という感じ。

まったくもって元気のないSONY

SONY関連の良いニュースを久しく聞いていない気がする。無論小さいレベルでは色々と製品発表なり何なりしてると思うが、全体的に見ての話である。
本日読んだ記事は以下。

http://www.nytimes.com/2006/03/15/business/15cnd-sony.html

Sony said today it would postpone release of its next-generation PlayStation video game console until November, a potentially costly move that the company portrayed as a marketing decision but that analysts said may reflect difficulty in containing high component prices.

「次世代ゲーム機戦争」なんて言葉は既に懐かしくなってるけど、Microsoftや任天堂の後塵を拝すのは屈辱だろうに、出荷遅延は痛いだろう。

Sony is also counting on these new technologies to make PlayStation 3 a success. With Blu-ray offering five times more capacity than current DVDs, and Cell boasting processing speeds dozens of times faster than its predecessor, PlayStation 3 promises a leap in graphics and realism that Sony hopes will dazzle consumers.

詳しくは知らないが、PS3がSONYの最新技術の結晶となる訳ですね。

SONYにはまた、日本を代表するクリエイティブなメーカーとして復活して欲しいものだが、その為の道のりを描き、実行するのは相当に難しい。

MacBook Proに刺激される物欲

その昔、PowerBook G3(Pismo)を使っていた時期があるのだが、久しぶりにMacのLaptopが欲しくなった。様々なところで賞賛の声を耳にするが、何といってもカッコいい。昔Pismo買ったのだって、結局カッコよかったからだった。プライベートで持つんだから、やはり愛着の持てるものでないと。

ASIN:B000B9NBN8

う〜ん、やはりスタイルが良い。いずれ手にしたいなぁ。久しぶりに欲しいものが出来た気がする。

アップルのホームページ
http://www.apple.com/jp/macbookpro/

PowerBook G4との比較
http://d.hatena.ne.jp/seihiguchi/20060301

ちょっと話は逸れるけど、ジョブスのプレゼンもカッコいい
http://pc.watch.impress.co.jp/docs/2005/0607/apple3.htm

世界中を巻き込むイランの核開発その2

  • 朝日新聞朝刊(3/14)国際欄

核不拡散条約(NPT)に加盟しないまま核開発を進めてきたインドと原子力協力で合意した米ブッシュ政権の核政策に対して批判が出ていることに対し、米国のグレッグ・シュルテ国際機関代表部大使は13日、ウィーンからテレビ電話で東京アメリカンセンターなどを結んで会見し「インドはNPTに加盟していないから、何ら条約義務違反を犯していない。世界最大の民主主義国家として原子力エネルギーにアクセスする権利がある」などと独自の論理を展開した。

思わず何回も読んでしまった。読み間違えたんじゃないかと。今でも朝日新聞の誤植かもしれないと思ってしまう内容。米国政府よ、いくらなんでもひどすぎるだろう。
「独自の論理を展開した」って言い回しが笑えた。今度使おう。

エンジニアの「驚かせたい欲求」

CNETにてブログ「Kenn’s Clairvoyance」を連載中の江島健太郎さんが、「創造的なエンジニアのための働く環境とは」というエントリの中で興味深いことを書いていたので、ちょっとそれについて考えてみたい。

http://blog.japan.cnet.com/kenn/archives/002625.html

こないだCNET編集長の西田さんとも話していて、エンジニアのタイプでも最もはっきり分かれていると思ったのは、この2類型。

(1)クリエイター・ギーク系

  • 小規模なベンチャーで新しいサービスを作りたいタイプの人
  • 会社の中で認められたいのではなく、会社の外で認められたい
  • 週末も趣味でコーディングしている
  • お金、ステータスにこだわらない

(2)プロフェッショナル・傭兵系

  • 大規模なプロジェクトで手際よく美しくコードが書ける人
  • 身近な人たち(会社、顧客、家族)を幸せにしたい
  • 「つくりたいもの」よりも「ビジネスになるもの」を優先
  • 安定収入、ステータス重要

これは非常に共感できる区分けである。確かにこの2類型ははっきりと分かれる。ちなみに僕は(1)に憧れる(2)タイプ(しかも未熟)だと思う。
さて本題だが、(1)のようなエンジニアを社内に抱えてるとして、絶対に用意してあげなければならない環境がある。それは「こそこそと社内の誰にも内緒で物を創れる環境」である。つまり何が言いたいのかというと、「驚かせたい欲求」を満たしてあげられる環境である。優秀なエンジニアは概してこの欲求が強いと思う。内緒で物を創り上げて、「さぁ驚け」とばかりにみんなの前に持ち出し、「おおすげー」という歓声を聞きながらほくそ笑んで、それを糧にさらなる開発や改良に乗り出す。そんなエンジニアである。
id:jkondoさんが日記の中で「ごにょごにょ」という言葉を使ってこの環境を表現していた。はてなの共通用語なのだろうか。

http://d.hatena.ne.jp/jkondo/20060225/1140856445

今日ははてラボのいわしをごにょごにょ改造しました。

大企業になってくると、とかく「今期の開発計画を立てて報告しろ」とか「仕様をまとめてから開発に取り掛かれ」とかごにょごにょから遠ざかる方向に進んでいく。大企業の大規模プロジェクトになると、どうしても「管理」というものに対してものすごいコストをかけなければならないので、ある面これはしょうがない部分があるのだが、この「ごにょごにょ」を開発計画の20%くらいには取り入れても良いのではなかろうか。つまり80%の力で計画通りのプロジェクトに参加し、あとの20%をごにょごにょさせるのである。エンジニアをクリエイティブに扱いたいなら一考の価値があると思う。