2009-04-28

run GWT 1.6.x using 64-bit eclipse on 64-bit architecture


64-bit architectureを使っていると色々と面倒なことが多いです。が、大抵の場合はなんらかの対処法を誰かしらが実践しているので、頑張れば結構どうにかなります。今日はGoogle Web Toolkitを64-bit architectureで動かす方法について書きます。

僕が調べた限りでは、動かす方法は、大きくわけて2つあります。
1. eclipse 32-bit ver. を使って動かす。
2. eclipse 64-bit ver. に32-bit用のjreをインストールさせて動かす。

GWTのdiscussionでは、わりと1.の解決策を挙げている人が多いようですが、正直なところ、GUIがバグったり、どこでどうエラーが出ているのか明白でなかったりと、個人的にはかなり使いづらかったと感じています。それに比べて2.は上述のキャプチャにもあるように、GUIもはっきり描画されていて、エラー内容はほぼ全て64-bit命令にのみ集約されているので、この部分だけどうにかしてやればなんとか使えそうです。

というわけで、2.の解決策について書きます。参考にしたサイトは、以下のサイトです。
http://theworldofapenguin.blogspot.com/2008/05/google-web-toolkit-in-linux-64-bit.html

具体的な手順は上述のサイトを見ると分かるので、大まかな手順だけを書くと、以下のようになります。
1. jre 32-bit(self-extracting file)をダウンロードする。
http://www.java.com/en/download/manual.jsp

2. ダウンロードしたファイルを/opt/に移動させ、"sudo sh /opt/ダウンロードしたファイル名"でjreをインストール。

3. eclipse 64-bit ver.を起動し、window menu->preferences->java->installed JREsで、インストールしたjreを指定&チェック。

4. Project Explorer内のGWTプロジェクトを右クリック->properties->RUN/Debug Settings->プロジェクト名クリック->edit->JREタブをクリック->Alternate JRE->インストールしたJREを指定。

5. GWT projectを起動。

細かい部分はだいぶ端折りましたが、これで僕は動きました。

ただし、問題はまだ残ってます。問題とは、上述のキャプチャが示すように、警告が出力されていることです。この警告の内容が示すように、現在64-bit版のfirefox(iceweasel)+pluginを使っているため、GWTのデバッグ用browswerでは動作するけど、Complile/Browseしたときは動作しませんorz

tango! on GAEもやりたいし、今後ともGWTにはお世話になるつもりでいるので、いずれこの問題も解決させます。

とりあえず今日はここまで。ではでは。

追記:エラー内容

(GWT:4334): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so: wrong ELF class: ELFCLASS64
(GWT:4334): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so: wrong ELF class: ELFCLASS64
(GWT:4334): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so: wrong ELF class: ELFCLASS64
(GWT:4334): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so: wrong ELF class: ELFCLASS64
(GWT:4334): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so: wrong ELF class: ELFCLASS64
(GWT:4334): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so: wrong ELF class: ELFCLASS64
(GWT:4334): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so: wrong ELF class: ELFCLASS64
(GWT:4334): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so: wrong ELF class: ELFCLASS64
(GWT:4334): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so: wrong ELF class: ELFCLASS64
(GWT:4334): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so: wrong ELF class: ELFCLASS64
(GWT:4334): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so: wrong ELF class: ELFCLASS64
(GWT:4334): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so: wrong ELF class: ELFCLASS64
(GWT:4334): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so: wrong ELF class: ELFCLASS64
(GWT:4334): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so: wrong ELF class: ELFCLASS64
(GWT:4334): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so: wrong ELF class: ELFCLASS64
(GWT:4334): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so: wrong ELF class: ELFCLASS64
The server is running at http://localhost:8080/
LoadPlugin: failed to initialize shared library /home/yohei/.mozilla/plugins/libflashplayer.so [/home/yohei/.mozilla/plugins/libflashplayer.so: wrong ELF class: ELFCLASS64]

2009-04-26

A Direct Path to Dependable Software




A Direct Path to Dependable Softwareの要点を途中までメモってみました。

[注意]
1. 意訳+要約のため、かなり端折っている。
2. 微妙に意味の解釈が間違っている部分がある気がする。

※続きはImplementationから


Review articles
A Direct Path to Dependable Software
-Who could fault an approach that offers greater credibility at reduced cost?-

Daniel Jackson

Communications of the ACM
Vol. 52 No. 4, Pages 78-88
10.1145/1498765.1498787

※Introduction
ソフトウェアの信頼性の話
ーEx. シカゴ病院の薬のデータベースにバグがあり、情報が一夜で失われた。
ーこのような事件は電子投票/航空便の制御/核パワー/エネルギー配信でも起こるのでは?

組み込みソフトウェアの普及率の上昇につれて、大きなリスクを人々にもたらす。
ー特に医療分野において、ソフトウェアは人を生かすことも殺すこともできる。
ーー例)ペースメーカーとか
ーー1985-2005年までの、医療機器の欠陥による事故数は600,000。うち死亡者は30,000
ーー医療機器の欠陥事故の少なくとも約8%は、ソフトウェアによる事故。
ーーー組み込みソフトウェアが増えれば、ソフトウェアによる欠陥事故はもっと増えるだろう。

今までは、プロセスやツール/技術などのやり方が信頼性ソフトウェアを作ると信じられていた。
ーしかし、それら信頼性の証拠を示すには、indirectなアプローチである。
ーーこの記事では、信頼性ソフトウェアである確たる証拠を示すdirectなアプローチを主張する。
ーこのアプローチの特長は、2つある。
ーー真実性の向上:やり方の効果による不慮の事故ではないという主張ができる。
ーーコストの削減:開発資源を”最も重要な部分”に焦点を当てて、開発できる。
ーーー必要十分な開発資源で開発ができるため、冗長なコストを削減できるということ。

[The Need for a Direct Approach]
Dependable System:人々が信頼することができるシステム
ー理性的な人/組織にとって、利益がリスクを上回るような証拠があるシステム
ーー証拠が無ければ、safeとは言えない

将来、突出したソフトウェア開発技術がソフトウェア品質の証拠を作り上げるかもしれない。
しかしながら、今日の技術は、そのような技術とは程遠いところに位置している。
ー今までの経験を元にソフトウェアの欠陥率を予期することは出来るが、それを0にすることはできない。

例えば、車における、組み込みソフトウェア以外の技術について考えてみる。
ーNational Highway Traffic Safety Administrationのデータベースには、
年間約40,000件の重大な事故が記録されている。研究者は、その事故データ情報を元に
どのようなデバイスが最も安全なのかを、事故情報を比較しながら研究できる。
例)結果として、シートベルトやエアーバッグが、安全な車のデバイスとして誕生。

一方で、ソフトウェアにはこのような比較できる情報が無い。
ーどのようなソフトウェアの効果が、安全をもたらしたのか、または事故原因をもたらしたのか、
見分けることは難しい。よって、ソフトウェア開発事業会社にとって、事故データベースを
使った自社システムの有用性を証明することは難しくなる。結果として、消費者の
システム購入の意思決定を強く左右するようなデータをあつめることができなくなる。

加えて、現状では、ソフトウェアによる事故データには十分の情報が備わっていないことが挙げられる。
会社は、自社の基本的な事故情報を保有しているが、政府は各会社のソフトウェア事故情報を集めたような
データベースを持っていない。結果として、ソフトウェア事故から学ぶべき一般的な教訓を得にくい現状がある。

この数十年の間、私たちはソフトウェア品質を著しく向上させる技術およびアプローチを開発してきた。
それらの技術およびアプローチとは、以下の4つを含んでいる。
1. よいプラットフォーム:安全プログラミング言語, 独立したアドレス空間のOS, 仮想マシーン
2. よいインフラの構築:configulation control, bug tracking, treacibility
3. よいプロセス:spiral/agile model, prototyping
4. よいツール:統合環境, 静的解析器, model checker
加えて、以下の5つの基盤的な技術を作り上げた。
1. 問題の構築化技術
2. デザインモデルの技術
3. Software Architectureの技術
4. 検証技術
5. テスト技術
しかしながら、これら全ての技術は誤って使われることが多く、また、成功を保証するものではない。
経験に基づくソフトウェア構築技術は、上述のギャップを埋め、科学的測定法の有用性を提供したが、
今でもなお、ソフトウェアシステムの品質の確たる証拠を、簡単に、かつ自信を持って突き詰める技術ではない。

たくさんの保証規格は、ベストプラクティスを強制するように仕向けた、
よく工夫された考案であったが、一方で、正反対の効果も持ちはじめていた。
ーベストツールの使用やソフトウェアの危険箇所に注意するように促していた代わりに、
厄介な要求を義務として課した。
ーー時代遅れで、統一的で、同じ技術を義務化した。
ーーー結果として、本当に価値があるのかよく分からない、同じような仕様書が増えた。
The Common Criteria security certification(MSがwindowsに対して取得した証書)
を取得するためにはコストがかかる。また、そのコストは、本質的なバグフィックスにかかる
コストよりも大きいため、会社に取っては有用性の低いことだと館が得られてきた。

政府は、基本的な証拠を元に、よくソフトウェアシステムを評価する立場に位置していた。
ーいくつかのプロセスに対して、いくつかのテストが任意に行われた。
ーその検証テストは時々、破滅的に失敗することがあった。
ーー例)パナマのFDA-certified radiation-therapyにおける悲劇的な事件(2001)
ーー最も効果の高いと言われている規格は高価な上に、その価値を評価することが難しい。

上述とは違うアプローチとして、"goal-based"または"case-based"検証がはやっている。
このアプローチは、従来のあるやり方を強制するというアプローチと違って、開発者が呼ばれる。
ーそこで、claimed dependability goalsを満たすシステムだという直接的な証拠を提供する。
ーーU.K., Ministry of Defenceはこのアプローチで、規格獲得プロセスを著しく簡単化した。

この直接的なアプローチは、アメリカの証明機関や規格付与機関において未だ採用されていない。
最近、いくつかの政府機関では、現状のアプローチのコストと効果について見直している。
ーこの研究によって推奨されているアプローチこそ、本記事の根幹を成すものである。


[Why Testing Isn't Good Enough]
ソフトウェア開発者のレパートリーの中で、テストとは決定的なツールである。
そして、自動化されたテストを行うことは、一つの技術的能力があることの印である。
ー例)欠陥を見つけるためのRegression Test
どんどんと増えていく広大なテスト領域を覆う唯一の方法は、機械の力を使うことである。
ー多くの研究者がこれを認めるようになってきている。
Edsger Dijkstraによる以下の提言がある一方で、
ー"testing can be used to show the presence of errors but not their absence"
テストすることが信頼性を証明する十分な証拠になる、と信じている人たちが増えている。

私たちがテストに対して知っている経験は、この信条は間違っていることを指摘している。
ー小さいソフトウェアなら徹底的にテストできるが、一般的なソフトウェアは広大過ぎて
全てを徹底的にテストすることは難しい。
ーーソフトウェアを起動してすぐの入力と、いくつかの操作をした後の入力では意味が異なる。
ーーー全ての分岐を網羅的にテストすることは極めて難しい。

もう一方のアプローチは、テスト範囲を分散して、リスクの高いところを集中的にテストすることである。
ーしかしながら、信頼性を得られるために必要なテスト数は、想像以上に膨大である。
ー例)1,000の入力に対して99%の信頼を得るためには5,000のテストが必要。
5,000のテスト中でバグを10個発見したら、20,000テストが追加で必要になる。
ーー故に、バグの発見は自信の向上にはつながらない。

このような状況下では、テストでバグを発見すると、
さらに高いレベルでのテストが要求されるため、
テストにかかるコストはねずみ算式に膨れ上がる。

それにも関わらず、現存の証明方法の多くは、未だにテストに依存している。
ー自信でシステムを保証するためには"five nines"信頼性を達成する必要がある。
ーー100,000時間実行し続けてもバグが起こらないシステム
ーーーこのような信頼性の保証方法はとても現実的ではない。


[A Direct Path]
信頼性を保証するための直接的なパスとは、批評を実証することである。
ー何がシステムを構成するのか、何がシステムに信頼性をもたらすのかを考える。

システムとは、ハードウェア/ソフトウェア/使用者によって成り立つ製品のこと。
ー例)飛行機同士の空中衝突はパイロットの操作によって起こすこともできる。
ーーシステムは、人為的な事故をシステムの仮定から除いたとき、
設計全体のうちの、重要な部分にのみ設計を集中することができる。

信頼できるシステムとは、ある仕事を信頼して与えられるシステムのことである。
ー信頼できるシステムとは、証拠なしには成り得ない。
ーバグのないシステムではなく、失敗が起こらないことが証明されているシステムである。

信頼性は利益とコストのトレードオフである。
ー飛行機の空路制御や核パワー、電力の配備において、社会は寛容ではない。
ーーこのような重要な部分の技術には、多大なコストを掛けて、
大規模にソフトウェア開発を行い、また、その信頼性の証明を行わなくてはならない。
危険な状態は、その使用されたときの前後関係に依存する。
ー例)放射線療法の用量を計算するために、スプレッドシートのマクロ関数を使うことは危険
ー携帯のネットワークやGPSのようなシステムは、多くのアプリケーションによって使われているので、
そのシステムが壊れてしまったら、悲劇的な状況に陥る。

信頼性は、大規模なスケールにおいて、簡単に測定することができない。
ー多様な前後関係によって失敗は起こるので、測定を数値ではかることは難しい。
ー信頼性は、その用途によって必要十分なレベルが異なる。
ーー高い信頼性:放射線治療の用法計算、クレジットカードの数値計算
ーー低い信頼性:ネットショッピングにおいて、購入するためにストックした商品の紛失
ー高い信頼性が必要なシステムでは、機械が無断で重要な変更を行うことは許されない。

以上のことを具体化すると、以下の3つが要求される。
1. どの部品(software, physical, human)が信頼性を向上させるか決めること
2. 決定的なプロパティを確認すること
3. どのレベルの信頼性を満たすべきなのかを決定すること

[Properties and where they reside.]
決定的なプロパティは、具体的には以下の2つに分類される。
1. プロパティは個々の機能を関連付けて成り立つ
2. プロパティがいくつかの機能を横切るように使う

信頼性においては、プロパティに焦点を当てることは、個々の機能に焦点を当てるよりも効率的。
ープロパティは機能的に分類されている。また、個々の関数のまとまりの意味をもっている。
ーEx. データベースにおける決定的なプロパティ
ーーログイン時に使う関数をチェックするより、ログインの一連の流れをチェックした方が良い。

いくつかのソフトウェアシステムは、全体的な仮想サービスを提供する。
ーただし、物理的な干渉は除く。
システムの目的が物理的な現象を生成/制御/監視するようなとき、
決定的なプロパティを表現する語彙を形成しなくては成らない。
これは一見明らかに見えるが、そこにはソフトウェアへのインターフェースに関する
記述要求の長い慣習が存在する。
ー例)放射線療法のアプリケーションにおける決定的なプロパティとは以下のようなものではない。
ーー放射されるビームが有界の緊張を持つこと。
ーー正しい信号がビーム生成器に送られること。
ーービームの量の設定において、正しいコードが記述されていること。
ー放射線療法のアプリケーションにおける決定的なプロパティとは、
患者が過剰な放射線を浴びないことである。

そこには、ある終わりにおいて、システムの物理的な効果と繋がっている一連のイベントがある。
そのイベントには、ある他の終わりにおいて実行された、途中命令の周辺機器の信号がある。
決定的なプロパティが使われた現象を定式化していけばいくほど、
ユーザに対する基本的な配慮は弱まっていく。

評判の悪い事件は、ソフトウェアに近づけていくことによる、潜在的な恐ろしさを示している。
ー例)An Airbus A320 landing at Warsaw Airport in 1993

ー省略

[The dependability case. ]
信頼性に対する証拠は、ケースによって異なる。
ーそのケースに当てはまるかどうかは、開発によって異なる。
ーーしかし、ある重要な特徴がある。

1. ケースはサードパーティの証明機関によって評価される。
ー証明機関は開発者と顧客からなる独立した機関。
そのケースが正常なケースとチェックするための努力は、最小でなければ成らない。
ー信頼性できるケースは公式の証明のようなもの
ーー構成するのは難しいが、チェックするのは簡単。
評価を行う際に、システム開発や特定のアプリケーションにおける専門知識を必要としては成らない。

2. ケースは完全でなければならない。
ー決定的なプロパティの持つ主張については、ホールが一つもないということ。
ーー正当でない他のどの仮定も、ノートされる。
ーーー責任の所在をはっきりとさせるため。
ーー例)”コンパイラは正確なコードを生成する”というケースに置ける信頼性
ーー例)OSやミドルウェアは、決定的なプロパティにおいて生成されたメッセージを確実に運ぶ
ーー例)ユーザはある信頼されているプロトコルに必ず従う

3. ケースは正常でなければならない。
ー以下のようなことをすべきではない
ー例)網羅的ではないテストを元にした手続きに対して、完全な正確さを主張すること
ー例)保証されていない仮定を作ること
ー例)弱いメモリモデルの言語のプログラムにおいて、判断を下すこと???


[Implementation]
※続きはあとで。

Mexico flu: Your experiences, BBC




やっぱし、新種のfluということもあって、現状のワクチンではまだ十分ではないということか。というか、2chの情報の早さに嫉妬ww。

こういう状況になると、主観で語られている情報をよく目にするようになるけど、そういった情報を鵜呑みにすることは時間の無駄な浪費につながると思うので、できるだけ1次情報に近い情報だけを取得するように心がけたいものです。


【国際】豚インフルエンザ メキシコ死者81人に WHO「国際的緊急事態」と認定★3

4 名無しさん@九周年 [] Date:2009/04/26(日) 13:03:25 ID:cbOOB6El0 Be:
【4月25日付けのBBCニュースの意訳】 ※ニュースの一部 私はメキシコシティーで最も大きい病院で、専任の医師として働いていますが、悲しいことに状況は全くコントロールできない状態です。医師の実感としてよくわかるのですが、メディアは事実を報道しておりません。 実はこの6日以内に、この病院でインターンとして働いていた私の2人の同僚がワクチン接種を済ませていたのにもかかわらず、この新種のウイルスのために亡くなりました。そこで当局は正式な決議を待たず緊急処置として、全ての医療関係者ににワクチンを分配しました。本当の犠牲者数は200人以上なのにもかかわらず、公式に発表されている死者数は20人です。 パニックを回避しなければというのもわかりますが、これ以上犠牲者が増えることを防ぐためにも、今は真実を公表すべきだと思います。 http://news.bbc.co.uk/1/hi/talking_point/8018428.stm I work as a resident doctor in one of the biggest hospitals in Mexico City and sadly, the situation is far from "under control". As a doctor, I realise that the media does not report the truth. Authorities distributed vaccines among all the medical personnel with no results, because two of my partners who worked in this hospital (interns) were killed by this new virus in less than six days even though they were vaccinated as all of us were. The official number of deaths is 20, nevertheless, the true number of victims are more than 200. I understand that we must avoid to panic, but telling the truth it might be better now to prevent and avoid more deaths. Yeny Gregorio D?vila, Mexico City

2009-04-24

studying MINIX after haribote OS


はりぼて開発に一旦区切りを付け、今後はMINIX 3の勉強を始めることになりました。今日はそこに至った経緯についての報告。

はりぼてOSは、OS開発の実践的なノウハウを学べる非常に良い教材だと思います。難しいことを深く考えず、問題があればその都度乗り越えていくその実践的な開発方針は、純粋にOS開発を楽しむ機会を僕に与えてくれました。実際に、主観的ではありますが、はりぼてOSの拡張は本当に楽しめました。

一方で、OS学習者としてはりぼてOSの拡張経験を振り返って見ると、スタートからゴールまでの道のりが非常に遠回りになっていた開発だったと感じています。というのも、一度開発したシステムを再設計することがとても難しかったからです。例えば、もし僕がファイルシステムの理論を深く学んだ後で設計を始めていたら、開発期間を縮めることができただけではなく、そのファイルシステムの開発意義をもっと高めることができただろうと思っています。

以上のことから、OS学習者ならば、OS開発の実践的なノウハウだけではなく、理論的なノウハウも学ぶべきだと強く感じています。そして、僕がはりぼてOSの開発に一旦区切りをつけて、MINIX 3の勉強を始めた理由もここにあります。

まぁ、まだ第2章までしか読んでいないので確実なことは言えませんが、はりぼてOSの拡張を通して得た知識および経験と、これから学ぶMINIX 3の理論を対比させながら学ぶことで、ただMINIX 3を読んで得られる知識以上のものを身につけらるんじゃないかなぁ、と考えています。

長々とグダグダと書きましたが、そんな近況です。
ではでは。



P.S.
今朝方、S先生の飲み会参加が確定。

2009-04-16

How to install jSpin in Linux




空気を読まずに連投です。スミマセンorz。jSpinをLinuxでインストールするドキュメントが、日本語のwebsiteでは一つも見当たらなかったので、一応メモしておきます。

[目的]
jSpinをLinuxでも動かせるようにする。

[OS]
Debian 2.6.26 amd64

[前提条件]
1. spinをインストールしている。
※spinをインストールしていない場合は、以下のサイトを参考にインストールする。
How to install free softwares in Linux: spin
2. JRE 1.5以上をインストールしている。


[インストール方法]
1. 以下のサイトの下部にあるjspin-*-*.zip (Portable zip file)をダウンロードする。
http://stwww.weizmann.ac.il/g-cs/benari/jspin/

2. 適当なフォルダ(Ex. "jspin")を作成し、そこにダウンロードしたzipを解凍する。

3. cdコマンドで作成したフォルダに移動し、"java -jar jSpin.jar"を実行。
→この時点で正常に動くはずです。

4. viまたはgeditでホームフォルダの".bashrc"を開く。
→Ex. "gedit ~/.bashrc"

5. エイリアスに、jspinの実行コマンドを追加する。
→#Alias definitions以降に、"java -jar (jspinのパス)/jSpin.jar"を記述する。
→Ex. alias jspin="java -jar ~/work/jspin/jSpin.jar"

6. 再起動し、端末から"jspin"を入力する。
→Ex. "jspin"

7. 無事にjspinが起動すればインストール完了。

以上です。

[追記 2009/05/17]
jspinのディレクトリ内にある"config.cfg"の中身を変える必要があります。
具体的には、僕の場合、以下のような内容に変更させたら直りました。
(参考サイト:http://chaos.ece.mcgill.ca/?q=jSpinLinux)

#jSpin configuration file
#Thu Sep 06 11:21:50 IDT 2007
VERIFY_OPTIONS=-a
FONT_SIZE=14
PAN_OPTIONS=-X
WIDTH=1000
INTERACTIVE_OPTIONS=-i -X
WRAP=true
SELECT_BUTTON=120
#path of "spin"
SPIN=/home/yohei/work/Spin/Src5.1.7/spin
LR_DIVIDER=400
CHECK_OPTIONS=-a -v
VERIFY_MODE=Safety
VARIABLE_WIDTH=10
MSC=false
# displayed directory when opening
SOURCE_DIRECTORY=/home/yohei/
TAB_SIZE=4
RAW=false
C_COMPILER_OPTIONS=-o pan pan.c
COMMON_OPTIONS=-g -l -p -r -s
TRAIL_OPTIONS=-t -X
MAX_DEPTH=2000
TRANSLATE_OPTIONS=-f
C_COMPILER=gcc
DOT=dot
MIN_DIVIDER=50
FONT_STYLE=0
HEIGHT=700
SINGLE_QUOTE=false
PAN=pan
RANDOM_OPTIONS=-X
FONT_FAMILY=Lucida Sans Typewriter
POLLING_DELAY=200
SELECT_TEXT=true
STATEMENT_WIDTH=18
SELECT_HEIGHT=70
PROCESS_WIDTH=7
FAIRNESS=true
MAX_STEPS=250
SELECT_NO_TEXT=10
TB_DIVIDER=500

以上です。

Java on Google App Engine



Google App Engine、Java獲得 - JRubyとRails、Groovyも動作

とうとう、Google App Engineがjavaに対応したようです。

個人的には、これは非常に嬉しいニュースです。理由は、今までずっと放置していたweb application "tango!"がウェブ上にアップできるようになるかもしれないからです。

Javaが使えるサーバを見つけるため、今までに何度か国外のサーバも探してみたけれど、やっぱしそう簡単には見つかりませんでした。正確には、Javaが使えるサーバはそれなりにあるんだけど、月額費用が一般的なPHPやPythonに対応しているレンタルサーバの値段より10培近い値段だったので、コストパフォーマンスが見合っていなく、断念していました。

しかしながら、今回のGAEのjava対応によって、この問題が解決するかもしれません。未だ正式には「Google App EngineがGoogle Web Toolkitに対応した」という発表はないけど、javaが使えるのであれば、GWT on GAEもできると思っています。そして、GWT on GAEができるなら、tango!の正式なリリースも可能かもしれません。("かもしれない"と述べたのは、Communication機能とかComet機能とかを駆使して、hanging RPCを無理やり実装しているから、javaが使えるからといって必ずしも動くとは限らないと考えたから。)

ともあれ、やる価値は十二分にあると思うので、そのうちtango! projectが再開するかもしれません。というか、確実の自分の気分次第なんですが(笑)...まぁ、時間見つけて頑張ってみます。

P.S.
一応、同じような考えを持っている人は一杯いたみたいです。
というか、GWT + GAE = GAEWTになるのかw

Java day : GWT 1.6 + App Engine for Java !

Google Web Toolkit News - onGWT.com


おまけ:
"Please add java support"祭り
吹いたwwww

2009-04-15

Background ver.002




内容を少しだけ更新。

-----------------------------
Index
・今
・学部時代にやってきたこと
・身を置いている所
・目標
・成果
・告知
・その他
-----------------------------
※2009年04月28日作成


【今】
・OSの研究
・国際インターンシップに向けた出発準備
・TOEFL iBT 80点突破
・ムフフ

【学部時代にやってきたこと】
『自作OSの制作』
企画:yasu_ninety9
開発:yasu_ninety9
広報:yasu_ninety9
オレオレ詐欺乙(笑)。昨今、一部の人たちに大変有名な、はりぼてOSの拡張を行いました。目的は、自作OS入門の読者向けに拡張例を提示することで、これから拡張する人を応援すること。ひいては、OS学習者および開発者が増えることを期待しています。したがって、ただ拡張結果を配布するだけではなく、”どうやって拡張したのか?”, ”どういった開発計画を立てたのか?”といったドキュメントも多くは配布しています。ご興味がある方はLet's access!
http://www.arukou.sakura.ne.jp/yasulab/os/

『開発したWeb Applicationの発表@Yahoo! Japan』
僕とイギリス留学中の友達を中核にして、コツコツ開発してきたweb application ”tango!”をyahoo! Japanで発表しました。僕ら以外にも、色々な方々が開発およびデザインに参加してくれました。手伝ってくれた皆Thanks!しかしながら、結果から言えばyahoo! japanでの発表では入賞できませんでした。原因は明らかに僕のプレゼン力不足。生まれてきてごめんなs(ry。いやいや、でも"tango!"はまだまだ発展途上ッスよ!プレゼンの失敗など次で挽回すれば良いのさ!Googleさんが提供するGWT on GAEという素晴らしい開発環境も整ったことだし、tango!もこの流れに便乗して進化する次第であります!
http://www.arukou.sakura.ne.jp/yasulab/tango/

『TOSHIBA summer intern(R&D), 予備校@AGOS』
2008年夏はsummer internの季節!
平日:TOSHIBAのsolution部門で新技術の調査・開発。
週末:予備校@AGOSでTOEFLのR/LとWritingの勉強 + そこそこ重いassignments / week。
結論:死亡フラグ。

『Berlitz pronounciationの修了』
得たモノ:何度発音のテストをしても講師には"Almost"と言われ続けることに対する忍耐力。
分かったこと:素直にアメリカ語学留学しとけばよかったorz。一人でひたすら勉強するのは自分の性に合わないらしい。

『早大山岳アルコウ会HP & データベース"WAK DB"の作成』
joomlaとDBQで作りました。CMSだと制作が楽だわぁ。2008年4月現在、β版のため、正式な運用には至っていないけど、1,2年後には立派なDBになっていて欲しいな。
WAK database(仮)
http://www.arukou.sakura.ne.jp/component/option,com_dbquery/Itemid,28/

『アジア大学ビジネスアイデアコンテスト』
2007年3月に北京大学で行なわれた
"2007 KT&G Asian Students' Venture Forum
-Business Idea Contest-"に第3位入賞。チームメンバーは当時全員1年生。何故かみんな怒Sか度Mな人だった。そんな両極端な6人で結成されたチームの成果。みんな凄い奴らだ。同期だし、俺も負けてらんないわ。あと、シンガポール人は頭良すぎ!
http://asiansvf.com/

『第1回 日韓学生未来会議 企画・運営・指揮』
2007年2月の大企画。途中から組織に加わったんだけど、なんか気付いたら色々やってました。人生初の大企画&運営でした。今は他の事をやっていて、あまり顔を出せないけど、今の自分が積極的に行動できるのは、この会議をやり通したからなんだろうな、と思う。後輩達が受け継いで繋いでいく第2回以降の会議にwktk。
http://www.jksff.org/

『フランス語学留学』
2007年2月からフランスでフランス語勉強してました。フランス蝶最高!でもフライト時間長すぎだよワトソン君!今でもフランス語は大好きだし、もっと使えるようになりたいけど、最近は英語に若干浮気気味だったり。とりあえず、パリ近郊はお腹いっぱいだから南仏に行ってみたい!

『Internship -擬似プロジェクト-』
2007年9月に大阪まで行ってシステム開発の擬似プロジェクトに挑戦した。擬似プロジェクトでは、2年生のくせに何故か3,4年生のメンバー率いて頑張っとりました。最後まで自分のことを3年生だと思ってた人は数知れず。年齢詐称乙。しかし、結果は惨敗。工程管理とスケジュール管理でヘマを犯しました。おかげでシステム設計書とマニュアルが納品できなかった。すごく・・・悔しいです・・・。ただ、学んだことも多かった。とりあえず、中小SIerでは働きたくないな、と思いました。

『南アルプス縦走』
2007年8月、頼れるメンバーと南アルプスの上から下まで長期縦走しました。でも2006年8月も南アルプスを上から下まで長期縦走してたから、実は今回で2回目。ただし、今回はスタート地点が北岳→仙丈ケ岳に、ゴール地点が椹島→畑薙ダムにグレードアップしており、距離と山中拍数が結構伸びてます。結果的には、泊数は12泊13日ぐらいだったかな(多分)。予備日も使う予定だったんだけど、メンバーの体力が皆キモ過ぎるレベルで結局一日も停滞しなかった。あ〜、でも最近は山に登ってないな。おかげさまでメトボリックなお腹と化しました。


【身を置いてる所】
日韓「JKSFF」執行部広報OB
山岳「早大山岳アルコウ会」
BC「ドリーマーズ」
FC「FCアトレティコ・ラッセーラ」創設者&幹事
地域「地域スポネット『すぱんく』」スタッフ
BC「『すぱんく』スポーツ開放」管理人代理
BC「clubジョーダイ君」
英語サークル「WRESS」


【でっかい目標】
・Googleインターン選考に合格。そして、ゆくゆくはNEETへ昇華。

【最近の大目標】
・TOEFL ibt 80点以上。
・インターン先からreferenceを貰えるだけの功績を残すこと。

【他最近の目標】
・英語で不自由なくdiscussion出来る
・GPAをもっと高くする

【最近の成果】
・サーバ構築が出来たような気がする。
・WindowsからDebianへ移行。
・基本情報技術者合格

----- 以下、壮大な蛇足 -----

【告知1】
現在FC『アトレティコ・ラッセーラ』の代表やっとります。入部からマッチメイク、宣伝・告知等など興味がありましたらお気軽にお尋ね下さい。
HP→http://www.geocities.jp/atletico_l/
Mixi→http://mixi.jp/view_community.pl?id=1946980
SNS→http://soccersns.jp/team/1884/


【告知2】
『北区立赤羽中学校体育館バスケット開放参加者募集』
現在、東京都北区立赤羽中学校体育館の夜間バスケット開放を行っております。で、僕がその管理人だったりします。

興味のある方はコチラ↓。
質問等は僕に直接メッセージでも可。

「赤羽中学校バスケットボール開放」
http://mixi.jp/view_community.pl?id=1947170


【告知3】
『地域スポネット「すぱんく」の参加者募集』
僕の地元である東京都北区には「すぱんく」という地域スポーツネットワークの団体があります。「すぱんく」では学校や公立の施設を利用して、住民の皆様に文化的な活動や健康的なスポーツ活動を楽しんでいただく「場」を提供しています。

現在はサッカー、フットサル、バスケットボール、バトミントン、卓球、ダンスなどの種目を取り扱っているので、興味のある方、体を動かしてみたいと思っている方、是非お気軽にお尋ねください。

公式web→http://www.web-spank.com/
Mixi→http://mixi.jp/view_community.pl?id=1942881



【趣味】
自分が聴いてる曲の紹介とか音楽観とか色々書いてあります。まぁどんな曲を聴いてるかってのは参加してるコミュニティ見てくれても分かうわ何するんだやm…

あと、音ゲー全般(特にドラムマニア)が得意だったりします。


【生息地】
『Cafe Miyama』
十中八九来ればいます。教科書やらPCやらプリントやら色んなものを散らかして勉強してます。そんな明らかに邪魔でしかない僕にも優しいMiyamaの店員には、きっとインテルはいってるに違いない。


【注意】
ログイン時間が『5分以内』になっていることが多いと思いますが、それは暇なんじゃなくて忙しい最中でもMixiを見るという心の余裕を常に持たせて、自分n(ry


【思考回路】
好奇心>>>>>(越えられない壁)>>>>>羞恥心


【座右の銘】
かけてよし!
(゚Д゚ ):. _ 
r'⌒と、j   ヽ
ノ ,.ィ'  `ヽ. /
/       i!./
(_,.         //
く.,_`^''ー-、_,,..ノ/


かぶってよし!
/(*゚Д゚) 
/ :::У~ヽ
(__ノ、__)


まるまってよし!
'⌒⌒'⌒ヽ  
(゚Д゚* ),__)


お布団サイコー!!
( ゚∀゚ ):. _ 
r'⌒と、j   ヽ
ノ ,.ィ'  `ヽ. /
/       i!./
(_,.         //
く.,_`^''ー-、_,,..ノ/



どうみてもモフモフです。
本当にありがとうございました。

2009-04-13

How to install VPNClient for Debian




無事、無線LANのデバイスドライバのインストールも終わり、先ほど友達の助力を経てVPNClientの導入にも成功しました。今日はその導入過程のメモを記します。内容は、以前投稿したHow to install VPNClient for Linuxのdebian versionです。

[目的]
Linux(debian)で早稲田大学理工学部の無線アクセスポイント"waseda"を使えるようにする。

[動作環境]
OS: Debian 2.6.26-1-amd64
ブラウザ:Iceweasel 3.06 (多分firefoxでも同様に動作するはずです)
※おそらくUbuntuでも、同様の操作でVPNClientが使えるはずです。

[前提条件]
早稲田大学の学籍番号を所持していて、waseda-net portalにログインできる。

[過程]
1. "システム->システム管理->アプリケーションの追加と削除"で、vpncをインストール。
→要:ネット接続

2. 端末を起動し、管理者権限を得る。Ex. "# su"

3. 端末上で"# gedit /etc/vpnc/example.conf"を入力し、example.confの内容を、以下の内容に書き換える。

IPSec gateway vpn.wireless
IPSec ID ※Waseda-net portalのマニュアルを参考
IPSec secret ※Waseda-net portalのマニュアルを参考
IKE Authmode psk
Xauth username ※自分の学籍番号(英字は小文字で、ハイフンは省略)

※ 米印をつけたところには適宜適切な内容を入力する。

4. 無線LANアクセスポイント"waseda"に接続する。

5. 端末上で"vpnc /etc/vpnc/example.conf"を入力する。
→パスワードを求められるので、waseda-net portalのパスワードを入力。

6. 無事にプロセスIDが画面に表示されていたら、VPNClientの起動に成功。

最後に、ブラウザ上で、FoxyProxyなどのadd-onを利用して、早稲田のプロキシを刺せば無事ネットに接続できると思います。

以上です。

2009-04-12

Goodbye Windows, Hello Linux


昨日、長年使いつづけたWindows XPにサヨナラして、Linux(Debian)をインストールしました。

本当はXPとデュアルブートするつもりでいたんだけど、パーティションの設定で間違った設定をしてしまい、デュアルブートに失敗してしまいましたorz。外付けHDDにバックアップをとっているから、もう一回やり直してもいいんだけど、正直面倒臭いし決心が鈍るので、このままdebianオンリーのラップトップとして使用していきたいと思います。

debianにしてみて嬉しかったことは、処理がめちゃくちゃ早くなったということ。早くなった主な要因は、今までの使っていたWindows XPでは使いこなせていなかったであろう64bit版アーキテクチャを、debianでは使いこなせていることだと思っています。例えば、youtubeやニコニコ動画などの動画サイトでは、Adobe Flash Playerを使って動画を再生する場合が多いと思いますが、このAdobe Flash Playerは、2008年11月より、Linux版において、64bit対応Adobe Flash Playerを先行公開しています。

アドビ、Linux対応64ビット「Flash Player」のアルファ版をリリース

64-Bit Linux Adobe Flash Player: Surprisingly good

上述の記事が示すように、64bitに対応するだけで処理がかなり早くなるようです。これがOSレベルで対応しているdebian -amd64- であれば、処理がめちゃくちゃ早くなるのも頷けます。

一方で、悲しかったことは、いくつかのアプリケーションが使えなくなってしまったこと。例えば、Windows XPで愛用していたGoogle Desktopのサイドバーが使えなくなったことが痛々しい。64bit対応のLinux版Google Desktopが最近リリースされたけれど、正直元々早かったからどう早くなったのかワカランw。むしろ、Linux版ではデスクトップ検索だけが実装されていて、サイドバーが実装されていないことに落胆orz。まぁ、いずれLinux版でも実装されると思うから、それまでの間はiGoogleのガジェットで代替しようかな。

まだまだやることが一杯。まず、何より、無線LANのデバイスドライバがない。早く無線使えるようにしないと、Miyamaに行っても何もできなくなってしまう。これは正直かなり死活問題だわw。あとClauchみたいなコマンドライン型のランチャーも用意しないとなぁ。

とまぁ、こんな感じで今は過ごしています。早くLinuxを使いこなせるようになりたいわぁ。

2009-04-04

Distributed and Ubiquitous Computing




春休みも終盤。ようやく研究室配属の結果が決まりました。
正直、配属の結果にかなり満足しています。

僕の研究室はタイトルの通り、分散ユビキタスコンピューティングです。平たくいえば、OSとかwiiみたいな新たなユーザインターフェースとかを研究している研究室です。そのうち、僕はOSの研究チームに入りました。この研究室を志望した理由は大きく分けて3つ, 興味と学習範囲と環境です。

興味については、以前のブログを見ていただけたら分かるように、元から非常に高いです。OSを設計することを、よく色々な例にたとえられますが、僕としては"街"の設計に近いんじゃないかなぁと思います。街にはたくさん人がいて、人がそれぞれ何かの役割を持っていて、人同士で時には間違いを指摘したり修正したり、とそんなイメージをOSに持ってます。うまく設計することは簡単なことではないけれど、うまく設計する価値は非常に高いと思ってます。まだうまく言えていないけど、そういったことから非常にOSに興味を持っています。

この興味が高い理由にも繋がるけど、研究のために必要な学習範囲が半端じゃないです。例えば、CPU, memory, register, compilerなどなど非常に多くのアーキテクチャの中身を知らなくてはいけません。また、中身を知っているだけではなく、それらをソフトウェアでどう管理していくかもわからなくてはいけません。さらに、ただソフトウェアで管理するだけではなく、ユーザがイライラしないように使いこなせるような品質・機能を提供しなければなりません。このように、結構勉強する範囲が広いです。 逆にいえば、OSが分かればコンピュータのperspectiveが理解できると思っています。だから、OSを深く理解できていれば、きっとどんな設計にも実装にもOSで学んだ知識が応用できる、というメリットがあると思っています。

最後に、研究する環境が非常に良いです。研究室の設備も十分に良いのですが、それ以上に中にいる人達の技術と向上心が高い。例えば、昨日はプチ懇親会があったのですが、途中から技術の話に代わって、しまいには輪講に使う本の決定会議にまで至りました。もちろん、これらの話の主体は同期の4年生です。

配属前夜は、色々なところから勧誘があったり面白い話があったりして、どの研究室にするか死ぬほど悩んで胃を痛めました。しかし、それは十二分に報われたと思います。僕は周りのに比べてまだまだスキルが劣っている方なので、これからさらに勉強を進めていき、周りに追いついていけるようにならなくてはなりません。でも、そういう気持ちにさせてくれる環境は、結構凄い財産なんじゃないかなぁ、と思う今日この頃。

というわけで、さっそく486アーキテクチャの勉強にとりかかります。では。

P.S.
生息地がCafe Miyamaから研究室に変わりました。でも、あの雰囲気は好きだし、時々は顔出すかなぁー。