あけまして、おめでとうございます。

ひさしぶりに、更新してみまっす。今年の活動方針はこんな感じです。

その場の判断を適切にすること

自分は、事前に決めた情報・予定を優先して物事を進めてしまう習性があるのですが、その場の情報で、時には事前の情報を捨てて、適切な判断できるようになることを意識するようにしたいです。

もっとアウトプット

ついつい、アウトプットが面倒なってしまいがちなのですが、転職するときなどのためにも、アウトプットしましょう。できればソースコードを。

あとは、今年はひさしぶりに仕事で開発している製品が市場に出る予定なので、死なない程度にがんばる予定です。

それじゃ。

「棒ほど願って」水谷静夫  #IPSJ72

IPSJ72(2010/3/9) の「私の詩と真実」の水谷静夫 先生の講演についてのレポです。計算機の黎明期の雰囲気が感じられて、むかしばなし好きには、とっても楽しい講演でした。

水谷先生の「歴史的仮名遣いの方が例外処置が少ないので,現代仮名遣いより簡単に記述できる。」という言葉がとっても印象的でした。



以下、ログです。

  • 和田英一先生より、水谷先生の紹介。岩波国語辞典の編者としても有名。
  • 計算機との出会いについて
    • 1962 電気試験所 YAMATO の新聞記事を見た。
    • 当時、国立言語研究所に勤務していた。計算機が語彙調査に役立つ可能性があると思った。
    • アポなしで、電気試験所に飛び込んだところ、快く見せてくれた。
    • 電気試験所の人が、ー週間のセミナーを、国語研究所の4人のためにに開いてくれた。驚きだった。
    • YAMATOはカタカナの日本語入力ができた。
    • 4段活用の終止形を打ち消しにかえるプログラムを作成した。例 カク->かかない
    • コーディングミスは無かった。しかし、アル->アラナイ を見落とした。
    • このときに、はじめて、アルゴリズムはツレナイものだと思った。
  • 大学で教えるようになった。
  • 方法論
    • 語彙調査をするようになった。対象とするデータを変えると、よく使われる言葉が変わる
    • 上位50は、どんな文書でも同じ
    • 200-500が非常に特色が出る。
    • どういうデータをとったらいいか非常に困った。
    • 統計数理研究所でサンプリング、有意差検定を教わった
    • 友達が増えた
      • 論理学 吉田夏彦
      • にしむらひろひこ?
      • くろかわりゅうめい?
      • 一松信
  • SNOBOLとLSIP
    • 和田先生から、SNOBOLという言語の存在を聞いた。
    • SNOBOLで、クワイン? の String variable という概念を知った。
    • 引用符の論理的な性質が分かっていなかった
    • quotation の logical type を作った。
    • SNOBOLが嫌だったのは、ステートメント一つごとに飛び先を指定することができる。そのせいで、飛び先を間違えて、虫が多かった。
    • 飛び先を無くすことを考えた。
    • そのころ、和田先生からLISPを教わった。
    • リカーシブの考えは、言語学入れ子(ネスティング)だとわかった。
    • 言語学入れ子の概念を導入したのは、時枝誠記先生
  • 朱唇
    • 日本語のプログラミング言語
    • プログラムを書いていたらわかったはず。
    • YAMATOは、50音がコードと対応している。 そのうちやゆよが詰めてあったり、わをんだったり
    • 歴史的仮名遣いの方が簡単に記述できる。 例外処置が少ない
    • 現代仮名遣いは駄作だと思います。
  • まとめ
    • 計算機が私の学問を変えた。
    • 言語の構造を把握するために、アルゴリズムを考える
    • アルゴリズムが在れば、言語が変わった時に、影響範囲がわかるはず。
  • 質問
    • Q 藤堂先生と白川先生 について
      • A それぞれの説を、直にきいていると、ホントだと思えてくる。
    • Q 英語からの外来語について
      • A 全体としては、残念
      • 日本人が平均的に英語が上手くなれば大した問題でない。
      • リカーシブ 頭山的
      • 訳語をつくるときには注意してほしい
      • コンテキストフリー: 文脈自由ではなく文脈無用とすべき

朱唇のドキュメントと処理系をネットで公開して欲しいなぁ、と思いました。

Termtter で Twitter API proxy を使う。

http://termtter.org/で、Twitter API proxyを使うための設定。
ファイアーウォールの中で、Twitterにアクセスできなくて困っている人向けです。

config.host に twitter API proxy のFQDNを設定して、proxyを設定します。
twitterにポストされる内容を見られたくない人は、ssl を 有効にしときましょう。

#setting of Twitter API proxy
config.host = 'gtap.appspot.com'
config.proxy.host = 'proxy.example.com'
config.proxy.port = '8080'
config.enable_ssl = true
#
#以下は通常のTermtterの説明
config.user_name = 'eggman'
config.update_interval = 60
config.confirm = true
config.plugins.stdout.colors = [ :none, :red, :green, :blue, :magenta, :cyan, :pink ]
config.plugins.stdout.set_default( :show_as_thread, true ) # db plugin is required

Twitter API proxyのソフトは、何種類もありますが、ソースコードが短い(pythonで86行)という理由から、gtapを、自分のGAEに置いて使っています。
誰かが立てた、proxyよりも、自分でproxyを立てることをオススメします。

でも、このままだと、Termtterでsearchが使えないことです。あとで何とかする予定。

「先人に学ぶ」山本 卓眞@IPSJ72 2010/3/9

東大で開催されている、情報処理学会の全国大会に行って、「先人に学ぶ」山本 卓眞 の講演を聞いてきた。(https://www.gakkai-web.net/gakkai/ipsj/72program/html/event/event/9.html)
山本氏は、富士通でリレー計算機を、池田敏雄と共に開発した人 (山本卓眞 - Wikipedia)

講演で、気になったトピック

  • 技術と営業の経験法則
      • 技術のユニバック
      • 営業のアイビーエム
      • 技術の日立東芝
      • 販売の松下
    • 全部、営業が強い会社が勝っている。
    • 強い営業が、鼻の高い技術者をやりこめるぐらいあれば、会社が発展する。
  • コンピュータ部門で、ソフトウェアの人材が不足していた
    • 新たにソフトウェア技術者を採用することができない。
    • 社長に社内社内動員をお願いした。
    • 社内の他部署からは、恨まれた。
    • 結果的に、これが社内の構造改革となった。

2010/3/5の講演で中島聡@UIEJも言っていたが、日本のメーカーが、ソフトウェアの会社
にチェンジすることができるかどうか、というのは興味がある。
現状を見ていると、ほぼ無理としか思えないんですけど、もしかすると、もしかするかもと
期待している。そういう観点から、各社の動向を探りましょ。

  • その他のトピック
    • 日本軍のコックビットは油と埃まみれ、アメリカ軍のコックピットはキレイ。
    • 池田敏雄は、演算回路の設計に注力していた。コントロール系は周りがサポートしていた。
    • 岡田完二郎 - Wikipedia
    • Q 世界に通用するソフトがあまりない。日本人がソフト開発に向いているのか
      • A
      • 世界に通用するという発想がない。
      • お客さんがうるさいから、そっちばかりを見ていた
      • ソフトウェアアーキテクトとプログラマを分けて考えるべき。
      • 経営者がしっかりした意思を持つべき
      • ソフトウェア出身の経営者が出ていない
    • Q 海外の工場はうまくいかないのか
      • A
      • 情報関係は変化がはげしい。自動車とは異なる
      • 執念深さが足りない 技術の問題よりも、経営者の問題

池田敏雄の本を、最初に読んでから随分経ったので、読み返してみよう。なにか発見がありそう。

富士通川崎工場で4月に開催される「富士通桜まつり」に行って、FACOM 138A を見に行きたいです。(via リレー式計算機 FACOM 128B/138A 竹下世界塔の計算機よもやま話/ウェブリブログ)

定年したエンジニアの方々は、ぜひとも昔話をブログに書いて欲しい。自分も定年後に備えて、ネタ貼作らなくっちゃ。

Tombloo アメブロでオリジナルの画像をポストする

アメブロでサムネイル画像じゃなくて、オリジナル画像をポストしたい方向けです。

	{
		name : 'Photo - ameblo entry',
		ICON : 'http://www.ameba.jp/favicon.ico',
		check : function(ctx){
			return ctx.href.match('http://ameblo.jp/.+/entry-');
		},
		extract : function(ctx){
			return {
				type      : 'photo',
				item      : ctx.title,
				itemUrl   : ctx.target.src.replace(/t(\d+)_/, 'o'),
				pageUrl   : ctx.href,
			};
		},
	},
  • その後で、ツール→TomblooTomblooのリロードする。
  • entry-数字.htmlのときのみ有効です。画像を右クリックすると「Share - Photo - ameblo entry」のメニューが出ます。

パッチにするやり方がよくわかりません。

(追記)
パッチの書き方を、Tombloo アメブロでオリジナルの画像をポストする - MCSG SYM - たんぶら部 - Tumblove -で教えてもらった。

さらにちょっと修正してみた。
やっぱり、個別記事からポストしたい。月別のページなどから、間違えてポストしたくないのです。

(function() {
Tombloo.Service.extractors.register({
	name : 'Photo - Ameba blog',
	ICON : 'chrome://tombloo/skin/photo.png',
	check : function(ctx){
		if(!ctx.onLink)
			return false;
		return ( ctx.href.indexOf('//ameblo.jp/') > -1 && ctx.href.indexOf('/entry-') > -1);
	},
	extract : function(ctx){
		ctx.target.src = ctx.target.src.replace(/(\/t[0-9]+_)/, "/o");
		return Tombloo.Service.extractors['Photo'].extract(ctx);
	},
}, 'Photo', false);
})();

gistにも置いておいた。http://gist.github.com/318375
gistのページのrawを右クリックして、TomblooTomblooパッチのインストール でどうぞ。
Tomblooのバージョンによっては上手くインストールできないようです。
その場合は、手動でダウンロードして {ProfD}\tombloo\script に置いてください。

デブサミ2010 アーキテクチャに憧れろ - 『ソフトウェアアーキテクトが知るべき97のこと』著者パネルディスカッション

デブサミ2010に行ってきた。

  • force.com おもしろそうです。開発するだけなら無料だし。ラーニングカーブが良いらしい。
  • Googleの講演、全部、英語だと30%ぐらいしかわからないなぁ。
  • パネルディスカッションすごく良かったです。わりとまじめにログを取ってしまったので、どうぞ。

アーキテクチャに憧れろ - 『ソフトウェアアーキテクトが知るべき97のこと』著者パネルディスカッション

S 鈴木雄介 司会
N 伊藤直也  
E 江島健太郎
O 小野和俊

■自己紹介
N オーソドックスなWebアプリケーション
  マネージメント中心 todoの管理ではなく、何を作るかを決めることをしている。
  うごメモはてなで、こどもが人力検索はてなにポイント欲しさに押し寄せてきた。その対策を考えた。
E lingr, microblog, iphone
  COMETで実装のさきがけ
  iPhone 同士のゲーム対戦  FW内で、P2P  UDPでやる。
  bluetoothの上でEthertする。
  TCP/IPの永続的コネクションを直接張る。
O エンタープライズのパッケージベンダー
  SIは絶対やらない。ライセンスビジネス
  Full Swing, Silverlight
  クラウドと社内データの連携
N クラウドがどれぐらい使われてるか
O 丸山先生
  2009 疑問から関心に変わった年
  2010 関心から受容の年
  今までできなかったことができる期待感
 抵抗感もある。
 人のスキルの話
  職人的な人がゼロスタートしなきゃいけない分抵抗がある。
E クラウドについて
N 自前主義
 結構ジレンマなんですよね。
  強みがブレーキになるかもしれない。
  どこをクラウド側にするか
  クラウドを構築する可能性もある。
 スケーラビリティ
E lingr はVPS上で動いている。
  以前は、SFのデータセンタを使っていた。
  それでも、品質が低い。よっぱらいがケーブル切断

過去の失敗
N MVCフレームワークの出始めに作った hatena1 という自社製フレームワーク 
  中途半端なフレームワークなので
  今でもいまいち。
 2001年くらい セオリーが分かっていなかった。
E コミュニケーションの問題
  仲間内でグランドデザインを分かってもらうための道具
  こっちとあっちで思っている方向が違う
  スケールするかは、想像の世界
 オーバーコミットして、全然使わない機能
  形が無いので、できあがってみるまで、分からない事が多い

 シンプルにはじめる。
 要らないものはいれない、今必要なものだけを入れる。
  ついでにいれようというところを止める。

 そこで、メンバー間がぶつかるところ
  とにかくシンプルにしておくと、合意しやすい。

O 標準化=エスペラント語
  エスペラント語みたいなアプローチをとったこと。
  あまりにも、現実と離れすぎると、受容されない。
  すべてのデータがXMLとXSLTで、一環した世界ができる
  しかし、パフォーマンスが遅い。
  あまり理想に走りすぎた結果
 これから標準化で
  一回作ったモノを別ノモノに変えるのは大変でした。

美しいアーキテクチャ
N XHTMLとかいいですね。 棒読み
  ユーザーさんの声を聞いている。
  美しいとかいってられない。
 うごメモユーザーのため、とりあえず見れるようにする。

O きしかん
  iPadが
  Flashが無いのは理想を求めている。ギリギリの半dな

S GoogleがIE6をさぽーとしないのも
N Windows, Perl アーキよりも後方互換性をとることで長く使われてきた。
  そこから、学ぶこともある。 
  2ndlife 一週間でいやです。だれもメンテできなくて困っている。
 うつくしさをもとめない。

S Microsftは互換性を気にしているのに、評判が悪い
  Appleは最近

E 標準というのは、枯れたもの
  理想を求めた標準化は失敗する。

N ユーザーからの問い合わせが多い。
  あえて日本のケータイを使っている。
  10人いて、naoya以外はiPhone
  ほしいけど、ガラケーでがんばっている。
 そんなに新しいもの好きではない。
 若いエンジニアが、古いアーキを批判されると、イラッとする。そこを理論的に説明しなければいけない。

O チームマネージメントは後で直せるけど
  アーキテクチャは後で直せない

N シングルトンクラスというグローバル変数

教育や学習について
O それを適用するソフトウェアのライフサイクル
  自社のメイン製品で実験されると、会社がつぶれちゃう。
  一度作りきりのPjで実験すべき。
 他から依存していないモジュールで工夫するのは意図的にやる。


近未来と未来のアーキ
E モバイルは面白い
  スマートフォン ネットに常時接続した端末をみんなが持っている。
  それでルールが変わる。 ダイレクトにコミュニケーションができる。
  音声みたいなもので、みんなが常に繋がっているようなもの。
 位置情報、AR
  分散したコンピューティングパワーを使う

O リキャプチャーが面白い
  人間かの確認
  Googleが買収した。
  OCRで読めなかった文字 (10台異なった)
 Google Book Searchで役に立つ。
 人間グリッド
  Amazon Mechanial Te が自動的に

  自然に使っているだけなのに、知性を生むようなアーキテクチャ

N 改札の発電

N 社会的なアーキテクチャ
  twitterを使うようになったのか、コミュニケーションのアーキテクチャがある。
  teccrunch Googleは技術は強いが、社会的アーキテクチャをハンドルできるリーダーがいない。

  技術的なリーダーは出揃っている。
  社会的アーキテクチャは、専門性が体系化されていない。
  ハックするのが、今後のエンジニアリングでは重要


S マクドナルドのイスと冷房
 硬いイス、冷房の温度
  それって、善か悪かが難しい

N リニューアル前はITの人
  リニューアル後はトップに乗るITの話題を絞るようにした。
 そうすると、見てる方からすると偏りが減ったように見える。相乗効果
 印象を変えるために、システムを変えた。

  広告の位置

E 制度設計
  政治家がやっていること、サービスをやっている。
  企業内システムでも、同じようなことがいえる。
  作っておわりの場合が多い。
  そういうものが何故つくられているのか。使っているところを見るしかない。

O ビジネス、お金のながれが変わっている。
 最初に大きいお金、あとは安いメンテナンス費
  今は、最初は無料で使える。
  エンタープライズは naoya が行っていた手前の段階
  ユーザービリティ、レスポンスが考慮されていない。
 だめだったらすぐ
  
N 人の流れをデザインするのは誰?

O コンサルタントがいない。
  高速化、UIにはコンサルタントがいる。
  ソーシャルウェアユーザービリティ コンサルタントは
  naoya が名乗ればよい。

O 成功者が、上がった状態でアドバイス

N 社会的アーキテクチャは エンジニアリングと関連することが多い
  だからハードルが高い。

N ゲームだと、すでに確立されているんじゃないか。
 RPGが面白いのを発見した人はすごい。
  論理的には、数字があがるだけじゃないか。

O ブラウザ三国志
  だれが払うのかと思ったが、次の月に23000円払った
  原価というそういうレベルじゃない。
  感情を刺激してお金を払ってしまう
  すがすがしい気持ちで払った。

S Super Mario Wii ではまっている新人。
 なにが面白いのか
  協力してやるのが面白い。
  ほかは変わらない。
  最初はケンカしながら進める、最後の方は協力して進める。
  任天堂の設計デザイン

N ゲームの設計をするディレクタになれるのは
  デザイナかエンジニアだけ
  ものづくりの経験がある。
 今後は流行るソフトウェアが作るのが難しくなる。

S 個人の資質がでてくる。
  わかって

N ユーザーに関心がある人はセンスが良い場合が多い
 エンジニアリングが得意
  サービスを作るのが得意
E メンタリティが違う、両方同時にできる人がいない
O CEでは、スーパーマリオをジャンプするプログラムを作らせる。
 それを作るのが難しい。
  単純なジャンプを作ってくる人はだめ
  ほとんど分かる。

N プレゼンテーションをしてもらう
 最初の2週間は自社のフレームワークでサービスを作る。
  最後のレビューでボコボコにする。
  作ったサービスで見極めできる、ユーザビリティと、コードのもずーる
  ペアプロ

O ペアプロをやってみる。
  情報を自然に提供する形になる。
 半年間だけペアプロをやったことがある。結果的に良かった。

E みんな優秀なので、一緒にやってて学ぶことも多い
  ペアプロ苦手

O ペアプロだとカッコつけるじゃないですか。
  ストレッチなる。

N ペアプロやると、設計をきれいにするのが難しい。
 イディオムだときれいになる。
  システム全体から見る場合は、キーボードから手を離す必要がる。

O ペアプロからペアホワイトボード

E 一番難しいのは名前を考えること 一人で考えたい

N 設計の一貫性は一人が良い
  大きな設計はセンスが良い人に任す。
  その後は、

O 対等じゃないペアプロが多い
  ベテランと新人の組み合わせ
 
N 気持ち悪いですね。

S 3人とは価値観が似ている。
  3人ともナルシスト
  ブログに書かずにいられない。
  ユーザー寄りの視点がある。

会場からの質問
Q 車輪の再発明

O あるものを使って、ないものを作る ポリシー
  車輪の再発明は勉強になるけど、作らない。
  それは、先人に感謝して。
  過去に
  勉強したいときに意図的

E 小野さんに同意
  見つけられない人がいる。
  語彙が足りなかったり、 トレーニングすべき
  あるものを使って付加価値を付けるのがビジネス。

  下から革命が起きることがある。それは専門的なエンジニア、研究者
  それが無いなら、ソース呼んで勉強するのが良い

N 費用対効果を
  作っても
 コストが掛からず、既存のものを上回る可能性があれば作る。
  一人が1ヶ月で作れるだろう。
 作ってよかったのは、全部わかる。
  フレームワークに任すか、任さないかがすぐに分かる。
 既存のフレームワークの場合は、まず判断をググったりするので、そこで時間をロスする。

E 結構作られいない車輪がある。
  UNIXでは定期実行にはいまだにcronを使う
  一分以内に繰り返す場合は自分
 実はちゃんと、考えると未開拓分野がある。
  
 
O 組み合わせるだけでもダメ。
  付加価値をつけて競争力が必要

Q 情報収集の方法と時間について

N 1日に10回ぐらい見る
  ある程度は、常識的に抑えておく必要がある。ニュースサイトみたり、使ってみたり
  情報収集

E コアな本を読んでいるイメージがあるけど
N 継続的にやっているからそう見えるだけ

N 東京にいるとき、情報収集しすぎた。
 流行のサービスをすぐ作っちゃうようにんた。
  必要なアーキテクチャはすごく枯れたものが多い
  1970, 1980の技術
  継続的に学習するだけでよいのではないか

E あまりやっている気はないが
  ひとつ意識しているのは、本質的なものを学習すること
  今やっていることに、かかわる事で、興味をもったものを掘る

O サンマイクロの同僚のはなし。
  その場で調べる能力は必要。
  あまり情報が入ってくると、発信ができなくなる。
  リアルな知り合いが何に興味をもったかを気にしている。


N 役割分担がある
  会社ですごく好きな人がある。4000件feedを読む人。
  データマイニングとかは、学問的な知識が必要

S 情報収集はしていない。
  建築やデザインの勉強をしている。
  あえてITを入らないようにfollowしている。
  


PS 今回、小野さんがどんな仕事しているか始めて分かった。

Nvidiaの開発拠点 in アジア

Nvidiaの求人情報から、アジアの各拠点がどんな開発をしているか調査してみた。



Nvidiaのアジアでの開発拠点は7つある。それぞれの役割

Taiwan, Taipei
Mixed signal、Mask、ソフトウェア:
Taiwan, Hsinchu
Production、Test Program:
China, Shanghai
アーキテクチャ開発、セル設計、:
China, Shenzhen
ボード設計、システム設計、ソフトウェア:
India, Bangalore
ハードウェア検証、CAD, DFT, Formal Verification, :
India, Pune
Driver, toolchain, Sofrware QA:
India, Hyderabad
Tegra architecture, Software:
  • インドは、ソフトウェアの開発と、ハードウェアの検証、DFT設計を行っている。
  • 台湾と中国は、ファウンドリ関連とOEM/ODM向けの開発を行っている。
  • 上海は、中国のトップレベルのインテリを囲い込むためかな。
  • コスト削減のために、DFTを頑張っている。C++で書いたchip上のプログラムとテスタがTclを使って接続する。
  • やっぱり、インドのソフトウウェア開発力を活用しているのがキーなんだろうなぁ。
  • GPU開発をはドライバが肝なんだけど、日本メーカーはドラバを開発できなくて撤退している気がするよ。
  • NVIDIAのエンジニアの80%はソフトエンジニアと聞いたことがあります。ほんとですかね。
  • 日本でのNVIDIAの求人もあるよ。
    • MOBILE FAE Japan, Tokyo
    • PS3 DEVELOPER TECHNOLOGY ENGINEER