2012年3月31日土曜日

@HIROCASTER さんに刺激されて書いてみた、新社会人Javaプログラマー向け、失敗しないんじゃないかなと思う書籍

こんにちわ。

春ですね。

幸せな気分になる季節です。

なぜって、素敵なスーツ姿の新入社員と思しきお姉様桜が見頃の季節だからです。

みけです。

新社会人向けの絶対に失敗しない書籍


僕が触発されたHIROCASTERさんのエントリー

新社会人Webプログラマ向け、絶対に失敗しない参考書・推薦書

をどうぞ。

Javaプログラマー向け


P系言語は色々と書かれていたんですけど、Javaがないやってことで、

こっからがこのエントリーの本番。

JavaはとにかくIDEが重要

というわけで、JavaはとにかくIDEをどれだけ手になじませるかが重要です。

そこで次の三冊。







の本はEclipseの定番中の定番。

閉鎖環境では大抵Eclipseが使われていることが多いので、

これを読んでおきましょう。

なお、私のような不良社会人がIntelliJ IDEAという

イケナイ有償のIDEを進めてくることがあります。

本当にイクナイですね~。


真ん中の本はNetBeansの本。

NetBeansはOracleがリリースしているJavaのIDEです。

JavaEE開発する場合は、こちらの方が充実していることが多いようです。(棒

(NetBeans未使用なオレがなんてことを言う)


の本はGoogle Appengine + Slim3の本ですが、

実はEclipseを効率良く使う方法が色々と掲載されています。



いや、そもそもJavaがアレで…

まあ、このあたりがいいでしょう。








の本は幅広く抑えた一冊という感じ。僕も時おり読みます。


真ん中の本はJavaの仕様の本。この本を読まないと何も始まりません。

なお、このブログの執筆者はこの本を読んだことは…おっと消しゴムが落ちてしまった…


の本はJavaのコードをより良くするための本です。コード書く時に迷ったら読んでいます。

会社用と自宅用の二冊を準備しておくことが望ましいです。


品質

ドクター・ペッパーを買ったはずなのに、コカ・コーラが出てきたら嫌ですよね。

だから、品質はすごい大切です。

そのためにはプログラムは動かして試さないといけません。

そのためにはソフトウェアは動くことが求められます。








の本はHIROCASTERさんの紹介にもあった本です。

一回くらいは写経して、最後あたりにがっかりしてみるのもいいかもしれません。


の本はJUnitに絞った本です。

結構、現場でのシーンに即して書かれた本なのでお勧めです。

特にDbUnitの使い方やJUnit4で書かれているあたりは実用性が高いです。


よりイケてるJavaプログラマーになるために

やっぱりGroovyですよ。ということで…




Groovyで日本の本といえば、この一択です。

Groovy in Action忘れてた…orz



チケット管理


きっと入社した会社ではチケット管理していますよね。

チケット管理について学んでおきましょう。

会社で使っていなかったとしたら、

もう少しで会社が滅びる可能性があるので

チケット管理を導入するために学んでおきましょう。








の本は最もイケてるチケット管理システムJIRAの本です。

JIRAは徹底的に気の利いたチケット管理システムです。

一度触ると他のチケット管理なんて…ってなってしまいます。

一部ノイズが入ってしまいました。

なんたって、Javaでできているんですよー。


真ん中の本は比較的良くできているオープンソースのチケット管理システム

Redmineの有効な活用の仕方が書かれた本です。

ちょうど私が仕事の進め方ってって考えている時に出版された本で、

非常に参考になりました。


の本はまた別の比較的よくできているオープンソースのチケット管理システム

Tracの本です。

まあ、素のままTracを使う人はいないので、Trac Lighteningとか使うと思いますが、

Tracでのチケット管理全般について書いてあると思います。

思いますというのは、僕が読んだことがないからです。

僕が持っているのは

Trac入門 ――ソフトウェア開発・プロジェクト管理活用ガイドなので、

これを紹介したかったのですが、絶版になっているのかAmazonで入手不可っぽいです。



その他の書籍を会社や僕はオススメしているよ。ってのがあれば、

Twitterで教えてください。
(文章パクリ)

2012年3月30日金曜日

推論に関する覚書き2[『系統樹思考の世界』の読書メモ]

前回のポストは時間の関係で途中で投稿しました。

観察されたデータを絶対的なものとするか、

それとも

仮説を絶対的なものとしてそれに見合うデータを待つか

という二つの立場に対して柔軟な立場をとるのが3.アブダクションです。



3.アブダクション


データを批判的に検討しつつ、データが仮説に対してモル証拠としての価値を擁護する(三中、同著、p.64)

理論の「真偽」を問うのではなく、観察データのもとでどの理論が「より良い説明」を与えてくれるのかを相互比較する


というのが、アブダクションの立場です。

例えば次のような例が挙げられます。
  • 観察データ : 二つあるパソコン用のディスプレイが両方とも何も映らなくなった。
    • 仮説1 : 電源ケーブルが外れた
    • 仮説2 : グラフィックカードが壊れた
    • 仮説3 : 両方のディスプレイが壊れた

この観察データからは仮説の1が「真に」正しいのか、

それとも仮説の2が「真に」正しいのか問うことがナンセンスです。


なぜなら、観察データは個々の場合によって異なるからです。

こういった個々のケースを推論するような場合には、

従来の演繹法や帰納法などのように

データと仮説との関係性に強さを与えるのではなく、

もっとデータと仮説との間の弱い関係性が必要です。


今、手元にあるデータから最も当てはまりそうな、

いい感じの仮説をとりあえずは採用するスタイルの推論を

アブダクションと呼びます。


そして、アブダクションという推論は終わることなく続けられます。

というのも、アブダクションという推論は「真偽」の絶対的な確定行為ではなく、

どの説が最もよくデータに当てはまるかを

テストし、一時的に採用するという

一時的な仮定行為だからです。


例に戻る

先の例においては、皆さんも行う通り、

最初の観察データの後、

とりあえず電源ケーブルを見たり、

他のディスプレイに変えたり

他のパソコンに繋げてみたりといった

新たなデータを取得してみて、

どの仮説が適切であるかを推論していきます。


これが例えば、開発であった場合などは

  • 観察データ:画面のボタンを減らしたら、業務効率が上がった
    • 仮説1 : タブを押す回数が少なくなったから
    • 仮説2 : ユーザーがシステムのUIに不慣れであった。

このような仮説が立てられます。

もし、この後に、「ユーザーはUI操作に習熟している」というようなデータが得られれば、

仮説1の方が妥当でありそうですから、

  • いらない機能が多かった

とシステムに対して新たな事実を発見することができそうです。


そうなれば、その機能はいらないのか、

必要だけど普通のユーザーは使わないので、

特別なユーザーだけ使えるようにする

といった選択が出てくると思います。


まとめ


こうして見てみると、アブダクションという推論過程は

いわゆるアジャイル的なプラクティスに近いものが

あるのかと思われます。


ウォーターフォール型開発は、

真の仕様とは何であるかを定義して、

(演繹的もしくは経験的に真を決定してから、)

開発するようなスタイルでです。

「真」に到達したときに開発は終わります。


これに対してアジャイル型開発は、

変化を受け入れ、もしかしたら学習をして

開発していくスタイルです。

開発にはおそらく終わりはないでしょう。

なぜなら、すべてのリリースが一時的な仮定行為なのだから。



もしかしたらアブダクション的なスタイルの

開発というのもありかもしれませんし、

それでユーザーの価値が向上するなら、

取り組んで見る価値があるかもしれません。


こぼれ話


実は『系統樹思考の世界』という本を読み進めていくと、

アブダクションという推論様式はAIを開発する過程で研究されたという記述が出てきます。


AIは機械が人間のような振る舞いを見せるために

学習するという部分を研究する必要があったのでしょう。


そうするうちに研究の結果が他の分野へも派生して行って、

昨今のアジャイルプラクティスの勃興につながったのではないか

な~んて仮説が出てきたりしますね。

(逆かもしれませんが…)

2012年3月28日水曜日

推論に関する覚書き[『系統樹思考の世界』の読書メモ]

ここで推論という言葉を用いているが、

この推論とは、科学における推論の様式であって、

型推論とか、このブログを御覧になっている人が

手に熱くなるような推論ではないので、ご注意を。

推論の三様式


  • 演繹法
  • 帰納法
  • アブダクション


おそらく、最後のアブダクションを除いて最初の二つは

まともに高校を卒業しているはずなら聞いたことのある

推論様式であると思うし、詳しく説明する必要はないでしょう。


1.演繹法


前提となる主張から、ある主張を導き出す方法。


例えば、

  • 「波長Xの光が目で観測可能である」→「波長Xの光は可視光」
  • 「三角形Pが正三角形である」→「三角形Pは二等辺三角形である」
  • このテストが通る場合、このテストに含有されるこのテストは検証されたことと同等とみなして良い

という感じ。

この推論形式の最高峰はスピノザの『エチカ』における神の存在証明ですね。

この本は面白いから読んでおいたほうが良いです。

唯物論的に神の存在を証明しているので。

「神なんかいるわけ無いじゃん、馬鹿じゃないの、死ぬの?

ニーチェもそう言っているし」という輩はとにかくこの本を読め。


それと最近はやりの形式証明手法言語Alloyとかはこのパターンに

含まれるのかな(棒:Alloy知らない



2.帰納法


経験法とも言います。

蓄積された観察データ元に普遍的な法則を発見する方法。


例えば、

  • 数値0について当てはまる法則が、ある自然数kについて当てはまる時にk+1でも問題が無いので、この法則は正しい
  • ある放射性物質から発せられる単位時間あたりの放射線量がXXからYYに減少したから、この放射線の半減期はZZ年である
  • このテストが動いているのだから、このプログラムは問題なく動いている


これらは直感的に訴えかけるものがあり、この論証スタイルは非常に人気があります。

TDDや、プログラムのテストなどはこの方法が大前提となっています。


しかし、データから推論する過程そのものは

論理的にも心理的にも大きく訴えるものがあるものの、

データそのものが間違っているかどうかは、

訴えるものからは別に検討されなければなりません。


三中はこのように述べています。

「データと理論の間にはどのような関係があるのか」という問題です。これまで説明してきたように、「経験に照らす」ことが科学にとっては不可欠です。しかし、その主張は、私たちが得る「経験(データ)」が完全無欠であるということを意味してはいません。むしろ、仮説や理論がまちがう可能性がある一方、観察データもまた誤りや不確かさを含んでいるかもしれないという現実的な状況のもとで、…(中略)…データに照らして整合的な仮説は「真」であり、矛盾する仮説は「偽」であるという解釈は、データがつねに完全無欠であるという前提を置いています。しかし、その前提はしばしば破られます。だからこそ、仮説や理論の「真偽」を言うことはきわめて難しいのです。


三中信宏『系統樹思考の世界』(講談社現代新書、2006年、pp.59-60)


データを絶対視する立場からすれば、

仮説や学説はその下僕であり、

データを不安視する立場からすれば、

仮設や言説にはデータは何の役にも立たない。


言い換えると、

JUnitの結果を絶対視する立場から見れば、

仕様はその下僕であり、

JUnitの結果を不安視する立場から見れば、

仕様にはJUnitは何の役にも立たない。



まあ、でも、そんな両極端ではうまく行かないわけで、次のような立場が生じる。


3.アブダクション



おっと、だれかお客が来たようだ…

2012年3月26日月曜日

java-ja温泉行ってきました。

こんちは。

java-ja温泉行ってきました。

感想を140文字程度で…それって、ブログ書く必要なくね???

java-jaの人たち


みんなPythonやってました。Javaやっている人殆どいませんしたw

参加者の面々


ドワンゴ多すぎだろ、おいw

勉強になったこと


javascriptをdisるためにjavascriptを書いている人とか、pypyについて熱く語ってくれる人とか面白い人多いですね。

僕もEclipseをdisるためにEclipseを勉強したくなりました。

やましろさん


PHPに関するお話、面白うございました。「もう、動いてんだよ、問題ある?」

よしおりさん


すごい面々の中、司会進行などお疲れ様でした。

Java的に


concurrent utilを使えば、FxJsJUnitうまく行くのではとアドバイスをいただきました。

よしおりさん、太一さんありがとうございます。

あとでフォローします。




以上。

政治

昨日から頭に思いついていることをことごとく書いていくエントリー。

次は政治。


これまでの政治を見ていると一つの共通点にたどり着くことができる。


それは、


現在の既得権益を代表するものが第一党になる


ということ。


例えば自民党は経営者や農協といった既得権益団体を代表するものであったし、

民主党政権は労働組合を代表するものである。


では、次に第一党になるための既得権益とは何か?


二つ考えられる。

一つ目は日本人と外国人という枠組みで考えた時の既得権益を所有している方を代表する団体。

つまり、日本のナショナリズムを煽る団体。あるいはネオナチのような団体。


二つ目は現在の貧富の差が拡大している状況での既得権益を所有している方を代表する団体。

つまり、自由主義商業といえばいいのか、様々な規制緩和を許容する団体、あるいはブルジョワを代表する団体。


さて、政治家の皆さん、どっちにつくのでしょうか?

読書と価値

教育ママとか教育パパとかはびこる世の中において、

僕は子供たちにたくさんの物語を読んでおいてもらいたいと

思っています。

具体的には?

って聞かれると困るんですが、

というのも手持ちのネタが少なくて…

『ヴェニスの商人』とか『若きウェルテルの悩み』とか『罪と罰』、『カラマーゾフの兄弟』とか。

もっと、子供同士の友情と葛藤を描いた話があれば、それも読んで下さい。


理由ですが、

人生で訪れるであろう好機を逃さないために、

いろいろなシミュレーションを立てておいて欲しいと思っています。


私はそれほど本を読む人ではなかったので、

そういうシミュレーションがうまく立てられないのかと思っています。


ベンヤミンの『歴史哲学テーゼ』をあえて誤読すると、

ヘーゲルの前進的な弁証法ではなく、

過去の別の選択肢を展開すること、

ここに今目の前に起こっていることに対する様々な選択肢に

どのように対処するかをシミュレートする機会があるのかと思います。


もう一つ、本を読むときのアドバイス、

ロマン主義的に読まないで欲しいです。


人間の苦悩の中に真実があるとか訳の解らんことをほざいて本を読むのではなく、

ドミトリーならドミトリーにとって胸を叩くことにいかなる価値があったのか、

そしてアリョーシャがそれを思い出した時の胸を叩く価値の再発見についても

シミュレートして欲しいのです。

価値とは他者と交換されることで初めて生み出される概念です。

苦悩そのものは交換できません。

胸の肉1ポンドは血を含めて肉1ポンドであることそれが交換条件であり、交換価値です。

その価値、私はそれを物象化と読んでいますが、その価値が何であるかを

しっかり見極めつつ、本を読んでもらいたいと思うわけです。


これまでのキャリアと今後のキャリアについて

こんにちわ。

2012/03/07の291のことで英語の文献を読もうと英語でLTしたmikeです。

そろそろ企業も新入社員を入れる頃ですので、

SIとかITサービスとか、まあ、そういうのにかかわらず、

情報系産業に入る方に入るまでに読んでおいたほうがよいよと私から言える本をいくつかピックアップします。

(これは既に前日のエントリーに書いちゃいましたね。)

っと、その前に、私自身のキャリアを明確にして置かなければなりませんね。

なぜなら、その過程に英語というのが入ってくるからです。


私自身のキャリア



1年目

私は元々VBのプログラマーとしてこの業界に入った後、

初めてのプロジェクトが即解散、

その後、HTML + JS on JRunでプロトタイプを作るという仕事をやるという

散々なキャリア(?)を経ていました。

お陰で、Javascriptは好きな言語になりましたが、

まあ、SIerってプログラムを教えられる人が居ないんですね。

Javascriptをかけてもグローバル空間を汚染しまくる汚いコードばかり書いていました。

当然レビューしてくれる人もいませんでした。

ブラウザーはIE6でした。

ajaxが導入される少し前までのJavascriptでブラウザー上でできることは大概出来たと思います。



2年目

PHPライクな謎のパッケージ言語を1ヶ月で5ks作るとかいうよくわからない仕事した。

しかもそのPHPライクなパッケージソフト、UIがイカれたほどいけてなくて、

自分のJavascriptテクならかなりイケてるUI作れたんですが、

COBOLしか知らないベンダーのオッサンから、「君、状態遷移図を書けるの?」という圧力を

政治的にPMから流し込まれていけてないUIのまま作らざるを得なくなった…

こんなクソいUIに数百万とるのかと思うと、非常に心が痛みました。


3年目

Javaを教えてくれる人が居ないのに、Javaのプロジェクトに配属。

IDEとかも教えてくれない環境でJavaのコードを書くという、

何その苦行ということをやった。

そして設計書?仕様書がめちゃくちゃ間違えてて、

かつ変更対象のクラス群が密結合していて、死ぬかと思った。

この頃に真面目にJavaの勉強をしました。

『Thoughtworks アンソロジー』のルール3、ルール7にそぐわないコードがたくさんありました。

重複しているコードもたくさんありました。

というわけで、リーダーに向かって throw new HeighlyComplexClassDesignException()してみたら、

catch(Exception e){}

されました。


この苦行の後に、インドネシア、中国と作成したシステムの導入支援の仕事で海外に出かけるようになります。

インドネシアには1.5ヶ月、中国には2週間いたので、だいたい2ヶ月ほどは海外で生活していました。

英語はこの時にしゃべるしかないという感じで、とにかくしゃべっていました。

この経験、というか英語で生活したという自信はかなり強いものです。

日本人は完璧主義な人が多いので、

語彙でもなんでもちゃんと知らなければ使っては行けないとか考える傾向があります。

必要無いです。

もちろん、高度なビジネストークをする上では欠かせません。

でもコミュニケーションにはヴァーバルなコミュニケーションと、

フィジカルなコミュニケーションがあります。


4年目、5年目

この頃は上記のシステムのいわゆるSEをやっていました。

製造業、小売業、流通業、在庫管理といった多くのドメインの業務知識はこの頃に身につけました。

会計の知識もこの頃に身につけています。

多分、いやゆるエンプラエンジニアとしてはほぼ無敵状態を誇っていたと思います。


6年目

いわゆるリーマンショックがあって、ユーザー企業が投資を控える時期でした。

特にスキルアップしていませんが、

後から考えるとこの時期に色々と技術の変化があったように思います。

ajaxとかCIとか、アジャイルとか。

このころ不勉強だったことは今でも後悔しています。


7年目、8年目

いきなりもっとレガシーなプロジェクトに配属されます。

ツイッターなどでよくあげられる悪いSIerの典型的なプロジェクトでした。

  • 年月日フォルダーによるバージョン管理
  • VSSならまだしも、CVSを使っているのに、ソースの払い出し管理をするチームがある
  • 朝会が長い
    • 会議で誰がいつまでに何をやるということが決定されない。
    • 自分がやったことをアピールするのが目的の報告ばかりで、何をして欲しいのか、何をしたいのかわからん奴ばっか。
    • こういう状態にいら着いたオレが、お前ら自分の意見言えねーのかと煽ったら、余計萎縮する。
    • 萎縮させたとかで、オレ怒られる。
      • 連絡することないなら、会社来るな!朝会参加するな!給料返せ!
      • 夕方6時になったら「さあ、今日の仕事取り掛かるか」ドヤァとか発言する輩。
        • そうならないための朝会だろ。もう少しプロ意識持てよ。もう少しサポートする相手にプロ意識持たせろよ!お兄さん怒るぞ。
  • 悪い報告は最後の方に出てくる。つまり御前会議。
  • テストは手動でやる。
  • ただしテストのカバレージの算出を報告書として求める。←むりだろ
  • デグレの観点でテスト項目を上げることと言いながら、その旧仕様を明文化したドキュメントがない
  • WF型の開発だが、仕様変更はどんどん受け入れる
  • ISO9001対策のための作業がサビ残で行われる
  • 設計を担当するべきSEが基本的な業務知識がなさすぎて、開発二次請け会社に丸投げ
  • ビルドツールがEclipse
  • システムが縦割り、そしてそれを当たり前として受容した若手が縦割りの枠組みを当然と思ってしまう。
  • 開発者のHTMLの能力が低くてUIが最悪。Javascriptの知識もなさすぎてよりUIが最悪になる。
  • apache-commonsとかlog4jといったデフォルトで使うようなオープンソースライブラリーが一切禁止。責任が取れないため。
  • 改善案を取り入れますと言っておきながら、すべて上位マネージメント層が握りつぶす。
    • 属人的スキルになっている部分を誰でもできるようにするべきというSI的な発想の意見も、属人的スキルを持っている人が移動する意志がないので、必要ないと却下。
  • 古くからいる人がどんどん偉くなっていく。新しく配属されてスキルもある人はシカトされるか、干される。干されたパターンが多い。この組織は私とは異なるGroovy/Scala/Java/PHP/Rubyの使い手を使えない奴として手放した。(後日談ですが、この社員は会社やめました。)
  • 品質管理上の問題があることを報告しても、これまで大丈夫だったからといって何も改善しない。
  • ソースコードがコメントだらけで、ソースを読めない。不要なコードの削除も禁止。

9年目、実質会社をやめた年

上のような状況を社長にも訴えるけど、改善の見込みがない。
もう、この会社、潰れるしかないと考えて転職。

ちなみに、この会社、Mavenとかを入れても使えないようなネットブロックがなされていたり、
ツイッターの分析をするプロダクトを作りますという案件でも、メンバーの誰もがツイッターをやろうとしない。
  • ツイッターに繋がらないので、自分の端末固定でツイッターつながるようにするためにかかった期間1週間。
これからはクラウドに対応しますとか言っても、Google Docsなどのクラウドサービスを使うことができない。
マシンの選択に関しても、開発をしっかりやっていくとなると、Windows機でもまあできるけど、
環境構築するためのコストを考えると、Macの方が圧倒的にコストは低いので、Macを導入しようとしても、
セキュリティの関係上導入はできない。

会社の経営陣の構造をなんとなく把握。
親会社の低級社員が事業部長、担当部長として投入される。
大した成績を上げなくても、親会社の取締役や、監査役、親会社の別の小会社の社長に就任できるなどの、
たんなる待ち時間を調整する期間。

生え抜き社員で優秀な社員でも(ちなみにこの社員はJavaのことは全然知らない)事業部長代理止まり。
で、上がつっかえているので、社員の昇進はもはや絶望的。

私のようにあちこちふらふらしたエンジニアは昇進をすることはありえない。
特定のプロジェクトで7年くらい頑張ると昇進ができる。

別に昇進することがエライわけではないけど、
昇進すればするほど、マネージメントの能力のみが必要になって、
技術には徹底的に疎くなる。
その結果、地に足の付いた提案ができなくなる。

社員は徹底的に信用されておらず、Core-i7のCPUが出てきた時に、Pen-4のCPUとかザラにある。
たまにいいマシンが会っても、Core2Duo。メモリは当然2GB。

私のマシンにはApache + Trac + Sqlite3 + Jenkins / Apache + Redmine + MySQL / mongoDB / PostgreSQL / など入っていて、
とても上に上げたようなスペックで仕事をすることは不可能。

この上で先に上げたツイッターの情報解析の調査をやるものだから、

MeCab + YamCha + Chasen + Caobchaなどを搭載したVMを起動して、ビルドをかましたら、2日もかかる始末。

家のマシン(Xeon + 8GB)でやったほうが時間がかからないので、それでやって、その資料をメールで送ったら、
メールサーバーがまさかの妨害。1日のムダ。

東日本大震災の影響もあって、自宅勤務OKとなったので、申し込んだら、
名前だけの制度で会社に来なければ、出社扱いにならんとか。。

これらすべての状況に呆れて、
休憩室で大の字で会社を罵っていたら、
「頼む、そんな本当のことは言わないでくれ」とわけわからんことを言う人事部。

とっとと潰れてくれと思って、最後何とか心を許していた上長に相談、退社という運びになりました。

TOPGATE


わかめさんに誘われて、トップゲートに入社。

実はGoogle AppsとかSalesForce.comの既存のアプリを売っていくという方向に関心のあった私には、

非常に魅力的な職場でした。

ただ、まあ、いろいろと体調不良が発生して、1月~3月はほとんど働けない状態になりました。

これは私はすでに社長と話していて、3月いっぱいで会社を辞めることにさせて頂きました。



2012/03/26色々と事実関係が異なるもんで修正しました。
関係者の方にはご迷惑をおかけいたします。



今後


今後ですが、4月の中旬を目安に会社を立ち上げようとしています。

会社の名前ですが、次のどれかを考えています。
  • 株式会社ジーアスター
  • ジープロダクト株式会社
  • 株式会社無職

3.はネタですが…

事業計画

7月位までは赤字営業を続けていく形になると思います。

というのも社名から明らかなように、
Gで始まる会社です。

私の好きなGroovyをメインにやっていこうと思っています。

そのために、Grails、Spring(Grailsのコア)、Spring Roo(Grailsの代替)を抑えたいと思っています。
その関係上、4~6月はほとんどなにの営業もできないと思っております。

一方で、GはGoogleのGでもありまして、
GAE + Android / iPhoneでアプリを開発しようとも考えております。

このアプリについては、大体イメージはできているので、
後は実装するだけですが…大丈夫かな…????

一応、設計上はGAEの課金に大きく足元を掬われないような設計になっていると勝手に考えています。

また、コンサルタントとして、各種勉強会の開催なども行おうと思っております。

特に数学、物理関連の勉強会をやろうと思っています。
興味の有る方はぜひカンパとともに来て下さい。

まあ、初年度は赤字でしょうね。

最終的にはG*なプロダクトで色々と遊んで稼ぎたいと思います。



以上、そんなわけで、今後も変わりないお付き合いをおねがいいたします。

2012年3月25日日曜日

JavaFX + JUnit で javascriptのunit testできるようにしてやるんで、これからハマっていってやんよ - 3

ども。

あいかわらず、ハマっています。

現状のコード


かなりひどいことになっています。





とにかく、ページをロードした時の同期を図るのがかなりしんどいです。

JUnit / JavaFX / WebView 3つのスレッドを管理しないといけないので、

これがかなりきつい。

ExecutorServiceを使うといいのでは?

と、java-ja温泉でよしおりさんに教えてもらったので、

改善していこうと思います。


2012年3月20日火曜日

反復不可能な観察行為に関する覚書き[『系統樹思考の世界』の読書メモ]

歴史学が「二級科学」であるとされる理由について


  • 歴史学には直接的な実験や観察に対応するものがない。
  • 実験科学における仮設や理論に対する経験的な実験・観察が歴史学に存在しない。

と言われているため。


実験科学における直接的な実験や観察が寄与するところ


理論T「物質Aに物質Bを反応させると物質Pが生成される」というテーゼについて

理論Tに対しては半理論T'「物質Aに物質Bを反応させると物質Pが生成されない」が存在する。


実験

物質Aに物質Bを反応させると物質Pが生成した


推論過程

科学者がここで半理論T'を採択する場合には、

  • 物質Aを物質Bと作用させるためには触媒Nが必要であった
  • 実験環境には◯◯という条件が必要であった
  • 実験は正しく行われなかった

という、付随する説明が求められる。(説明があっても十分ではないが…)

そのため、科学者は理論Tを採用する。


真偽

意外と罠が多い「真偽」。




2012年3月19日月曜日

これまでITと無関係なところにいたのになんとかSIerに入社をこぎつけることの出来た新社会人がとりあえず一年目のうちに読んでおきたい本を適当に見繕ってみた(ただし、まじ適当)

こんちは。

エビリファイという薬を処方されて飲んだ結果、

椅子に座ってコーディングする集中力がなくなって、

無性に身体を動かしたくなっているみけです。

ちなみに、このエビリファイという薬、効能を見ると、統合失調症と書かれていて、

え、オレ統合失調症だったの?!と驚いている次第です。


本題


そんなに本を読んでいるわけではないので、

じつはあまりおすすめできる本がないというのが、

本当のところです。

なので、これまで私が読んできた本でおすすめのもの、

現場で使えそうなもの、最低限ITを売り物にしている人がリテラシーとして読んでおきたいものを挙げてみます。


コンピューター科学の基礎的なところ


なぜコンピューターは動くのか



最低限、CPUとはどういうことをやっているのか、

I/Oとは何か?CPUキャッシュとかメモリとかそういうのはなんのためにあるのか?

そういうコンピューターにまつわる基本的なことは覚えておくことが大事です。

なぜ大事か???

そんなことオレに聞くな(テキトー)


マスタリングTCP/IP



SIerの現場というのは大量のパソコンが置いてあって、

それがネットワークにつながっている。

そして、それが閉鎖環境なら外のネットワークにはつながっていないが、

閉鎖環境でなければ外の膨大なネットワークにつながっている。

IPv4という限りある資源でどうやって通信を成功させているのか、

また、IPアドレスというのはどのようにして取得されるのか?

なぜブラウザーでは繋がるのに、curlコマンドでは繋がらないのか?

こういったネットワークに関する基礎知識がないと、

SIerという人を大量に一箇所に集めた環境で働くには苦労を強いられることまちがいなしです。


つながらないからといって、適当に線を繋ぎ直すとか、

そんなサイコロに運命をかけるようなエンジニアにはならないようにしましょう。


これならわかるSQL 入門の入門



システムというとなんともごっついものを想定しますが、

単純に言えば、データ(データのなかにビジネスフローも含まれる)と画面がほぼ全てです。

で、大概の障害とかはデータの不整合が原因で発生するものが殆どです。

なので、データを操作する言葉=SQLは確実に覚えておいたほうがよいです。

しかも、副問い合わせとか複雑なSQLよりも、

もっと単純なSQLをちゃんと使いこなせるようになっておくことが望ましいです。


現場では、凄まじく複雑なSQLが頻繁に出てきます。

条件句の中になんか他のリストを取得するようなSELECT文があったり、

JOINの相手にすでにJOINされた結果が含まれていたりとか…


こういうのは皆さんの先輩がシンプルなSQLを覚えるべきところを、

どっかでとち来るって複雑なSQLが書ける人こそ世界一ィィィィィ(by シュトロハイム)のような完治が難しい勘違いをしたまま、

データベースを設計してしまったからです。


一つの出来事、一つの事実を一つのテーブルに入れるという単純明快な理論を無視して

データベースを設計したため、複雑にSQLを書かないといけなくなってしまったという状態なのです。


そうならないためにもシンプルなSQLが書けるように、シンプルなSQLしか書かないように最初から訓練しておきましょう。


併せて読みたい

データベース設計論 T字形ER―関係モデルとオジブェクト指向の統合をめざして



シンプルなSQLの先にあるのがシンプルなデータベース設計ということでT字型ER図です。

この手法の特徴はひとつのテーブルには一つの事実、あるいは出来事しか入れないということを徹底していることです。

残念なことに、テーブルの数は半端なく増えます。






もっと、もっと、よんで欲しい本があるんだけど、とりあえず、ここまで。

2012年3月18日日曜日

自然科学の5つの基準

ふとした興味で三中信宏『系統樹思考の世界』という本を読んでいます。



この本の要旨は、生物の進化を記述する記法として系統樹を用いているが、

この記法を非生物のそれにも当てはめることができないだろうかという試みが書かれています。

更には、生物を分類する時に類とか科のように分類し系統立てて認識するが、

同様の試みを非生物に対しても行えないだろうかということが書かれています。

動機


本自体の存在は数年前に知っていたのですが、

最近ふと気になって買いました。

デブサミの最終日の打ち上げで、

@snskさん

じゃ、次回のAndroidテスト祭り、オレが探索的テストのデモやってみようか!

と述べており、その手順を聞いているうちに、ふと系統樹を思い出したというのが、

その気になった理由です。

内容


まだ、全体280ページ中、50ページ程度しか読んでいないので、なんとも言えませんが、

元々大学でアビ・ヴァールブルグとか読んでいた関係上、だいたいどういった方向に議論が進むのかは、

想定しています。

今日、ブログに残しておきたいこと


読んでいる途中に、自然科学の五基準という用語で

書かれていた項目が、我々プログラマーがUnit Testのために必要な条件と一致しているように思えたので、

それを残しておきたいと思いました。


というわけで、以下、自然科学の五基準

  • 観察可能であること
    • ある現象に関する仮説なり理論をテストするためには、それが直接的に観察できなければならないという基準
  • 実験可能であること
    • ある化学反応(炎色反応のような)や物理現象(重力のような)に代表される自然界の過程に関しては、実験することによってはじめて科学的な知見が得られるという基準
  • 反復可能であること
    • ある自然現象に関する知見が正しいものであれば、同じ実験結果はいつでもどこでも誰がやっても確実に得られるという基準
  • 予測可能であること
    • 自然現象に関するある主張から導かれる予測を現実のデータに照らしてみることにより、その主張の正しさがテストできるという基準
  • 一般化可能であること
    • 現象に関する普遍的な法則性(万有引力の法則のように)として定式化できるという基準

(引用:三中信宏『系統樹思考の世界』, 講談社現代新書, p.38, 2006年)


1.の観察可能であることというのは、逆に観察可能でない場合にはテストは出来ません。

2.の実験可能であることというのも同様で、テストすると書いてあったりしますが、実際にそのコードを実行することができなければテストは出来ません。

3.の反復可能であることというのも、我々は誰がやっても同一のテスト結果に至るようにテストを実施できないとテストとしての信頼が確保できません。

4.の予測可能であることというのは、テストに際して、あるデータを投入したら、これこれのデータが出力されるような形で記述できていなければ、テストは行えません。

5.の一般化可能であること、これは定式化(仕様化)され得ないものについてはテストが実施できない(何が正しいのかわからない)ということから明らかです。


さて…


ここで三中が自然科学の基準としてこれらの項目をあげていますが、

これは、歴史学、ひいては生物進化学というものが科学たりうるのかという問いに対して、一般的な基準として示したものです。

三中の専門は生物進化学ですので、進化学、つまり歴史学が科学であることを説明付けなければなりません。

しかし、例えば、北京原人とアウストラロピテクスなどと行った人類の祖先っぽいものにかんして、

観察可能ではない(絶滅している)、実験可能ではない(サンプルが手に入らない)、

反復可能ではない(進化というのは非可逆の過程)、予測可能でない(どのように進化するかは想定できない)、

一般化可能でない(北京原人は絶滅したのに、アウストラロピテクスは進化に成功しているのを根拠付けて一般化できない)

といった理由で、進化学というものは歴史学と同様に科学という立場から見れば、

まったく根拠のないでたらめな学に成り下がってしまう可能性があるわけです。


これは探索的テストという、一般定式化がなされない方法論に対して、

テスト方法としてどうなのというような問いに対する答えのようなものが期待できるのではないか、

そして、探索的テストという属人的なテスト手法を体系化できる糸口があるのではないかという

そのような期待がこの本の中に込められているのではないかと思えるわけです。



最近流行っている分野でログ解析など大量データの分析をする機会が増えてくると思われます。

それにともなって、博物的に取得できる大量のデータを用いて、ユーザーなどの心理分析をする際に、

我々は系統樹としてユーザー心理 = 歴史を再現する必要が増えてくると思います。

ログ解析といった分野や探索的テストという方法論があるようでまだ方法論が確立していない分野に対して、

三中が述べるように系統樹思考を適用させることができるか、

それがこの分野でのチャンスではないかと思います。


気になった皆様も一読されてみてはいかがでしょうか?



2012年3月16日金曜日

最近勇気づけられた言葉 - The word encouraged me recently.

@snskさんの言葉です。


ガチに超すごいプログラマーになるのには才能が必要だけど、テスターになるためには努力が重要。


子供の頃からベーシックを触ってプログラムの基本的な制御構造などは理解していたけど、

それほどのめり込まなかった私は、多分、スーパープログラマーとして生きるには、

才能の片鱗もないのかなと思っています。

そんな中、デブサミの打ち上げで@snskさんのこの言葉、

非常に励みになります。

だから、私、テストエンジニアーでもいいと思っているんです。


思想的に


私が比較的考えが近いなと思っている思想家が何人か居ます。

クルト・ゲーデルが結構近い考えを持っていると勝手に認識しているのですが、

彼の基本的なスタンスは他の誰かのアイデアを徹底的に自分のものとし、

そのアイデアを徹底することでアイデアの単一矛盾点を明らかにする事。

ジャック・デリダなんかもそうですね。

テストも同じだと思っていて、仕様・設計を徹底的に継承することで、

仕様・設計に内在する不可避なものを明るみに出すという、

そのようなテストができるようになりたいと思うことがあるわけですよ。

まあ、嫌がられますけどね。

2012年3月13日火曜日

砕蜂刑軍軍団長閣下のこれまでのアイコン

ども、

最近Twitterのアイコンを毎日頑張って変えております。

テーマはマンガ『Bleach』の二番隊隊長の砕蜂さんです。

二点ほど、砕蜂さんのアイコンを選定するときの基準を設けております。

  • 夜一さんとの絡みは採用しない
  • やらしい画像は使用しない

夜一さんとの絡み


まあ、これは設定上避けようのないものなのですが、
砕蜂さんのツンデレな所
もとい隊長としてのプロ気質に惚れ込んでおりますので、
夜一さんには出てもらわないようにしております。

気丈な砕蜂さんを気に入っておる次第なのです。

やらしい画像は利用しない


砕蜂さんの画像を探していると、
袴の横から紐が出ている画像を散見します。

ツイート上でエロオヤジ全快のツイートをしていますが、
あまり二次元にはエロを求めていないので、
これは避けています。


というわけで、

これまでの砕蜂さんギャラリー


初回の砕蜂さん。



クールな砕蜂隊長です。

冷静に状況を分析してしかるべき対応を練っているという様が見て取れると思います。




















二回目の砕蜂さん



なんかクールでいいですね。

実は結構お気に入りです。


















三回目の砕蜂さん



これもクールビューティーという感じです。

結構気に入っているんですが、身体全体を表示しようとすると、

髪型の部分があまり強調されなくて非常に悩ましいです。




















四回目の砕蜂さん



モノトーンにGradleマークということで、

クールな感じに仕上がりました。

これも結構お気に入りです。

















五回目の砕蜂さん



雀蜂雷公鞭を出した砕蜂さん。

かっこいいのですが、色使い過ぎで何がなんだかわからないあたりが残念でなりません。























六回目の砕蜂さん




どうも、その辺からパクってくる砕蜂さんの画像は、

元々砕蜂さんが白黒というモノトーンな色のため、

いろいろ脚色をつけやすいので、

全体的に色が増えてしまう傾向があります。

そのためか、 Gradleアイコンがよくわからん結果になってしまって、

ちょっと残念(´・ω・`)。



さて、次回はどうしようかな???

2012年3月10日土曜日

エンジニアのための英語入門

こんちわ。

春眠暁を覚えずなミケでやんす。

今日は適当に英語が身近に感じられるための本を紹介しようと思います。

英会話




スティーブ・ソレイシィのこの本が比較的読みやすくてお勧めです。

英単語帳だと単語数が2,000とかよくあるけど、目標としての数値として四桁というのは一人の人間には少し大きすぎる感じがします。

この本なら目標は100なので、達成不可能な数字ではないと思います。

実際、休日の午後3時間くらいで読むことができると思います。

この本は声に出しながら読むといいでしょう。

これで会話をする時に結構話ができるようになります。


英語全般


英語全般と書いていますが、これは読む・書くの力を指しています。

これは月並みなのですが、本をたくさん読むに限るわけです。


とはいえ、どういう本を読めばいいかというと、結構難しくて、

ロマン主義の小説なんか読んでも、なんの特にもならないし、

シェイクスピアなんかは古すぎてお話にならないし、

読む本を選ぶというのはかなり難しいわけです。


そこでバランスがいい本となると、

英語の教師として悩みに悩んだ末、選んだリーダーを読むのがそこそこいい気がします。




これは東京大学の教養学部前期課程(1~2年)で用いるリーダーっぽいのですが、

幅広い分野をカバーしつつ、そこそこレベルの高い単語を扱っているし、

英語に頻出な表現が散りばめられているので、妥当なリーダーと言えます。


ここで、高校以来英語の勉強なんかしたことないよという人へのアドバイスですが、

この本を読むときは辞書なんか持たずに一気に読みましょう(一つの章につき目標10分以内)。


辞書は言葉の使い方が色々と書いてあって、読み物としては面白いものですが、

本を読むときに参照するようなものではありません。


文章を読み終わった後、どうしても気になった単語があったら、

辞書で調べるくらいに留めておくとよいでしょう。


若干ビジネスより


このあたりを読んでおけば、まず間違いは無いです。



ドラッカーですね。ビジネスマンなら必読の読み物です。

だから、邦訳を読まずに英語で読みましょう。


結論


だいたいここらへんに上げた本が読めるようになったら、

技術書のたぐいは簡単に読めるようになります。

後はお好きなジャンルの本を積極的に英語で読みましょう。






2012年3月9日金曜日

JavaFX + JUnit で javascriptのunit testできるようにしてやるんで、これからハマっていってやんよ - 2

どーも、季節性鬱症がかなりひどくてやる気が0なミケです。


ツイッターでJavaFXの同期がむずいとつぶやいていたら、@skrbさんから



こんなツイートをいただきました。

JavaFXとJUnitのThreadについて丁寧に解説されていて、動作できたようです。

というわけで、コピペプログラマーとしてはコピペしないわけにはいきません。

早速Jettyも使ってunit testできるようにしましょう。


@BeforeClassで起動するWebサービス


JUnitのテストコードの中でServerを持っているのが大分辛くなってきたので、

Serverのコードは外に出すことにしました。

まだ、試作段階なので、Handlerクラスなども固定でしか動きません。




一応、サーバーのアドレスとかポートも設定できるようにしておきたいので、

コンストラクターで指定できるようにはしてあります。

ただし、現段階では使っていません。


TestBrowser


JavaFXのWebEngineを使ってテストコードを走らせるクラスです。

@skrbさんのブログの内容をそのままコピーしています。

なお、一部分を変更しています。

どうやら@Testメソッドを実行時に、画面のロードが完了していないなどの同期の部分で

失敗したため、javascript上でロードしたことをマークするようにして、ロードが完了するまでは待機するように

改造してあります。




なかなか、ソースが読みづらくてごめんなさい。試作段階ということで許しておくれ。

Threadの同期と非同期は難しいですね。

@skrbさんには非常に感謝しております。



実際のテストコード


実際のテストコードです。

これは単純に数値を計算するfunctionを呼び出しているだけです。




なお、@BeforeにてApplication#launch(Class<T extends Application>, java.lang.String[])

第二引数でサーバーのURLを渡してあります。

これは、アプリケーション側でgetParameter()メソッドを使うと取得することができます。

サーバーのポートなどの問題でURLを変更することはよくあるので、

この辺は可変にしておきたかったです。



実行結果


実行結果は次のような感じになります。



お気づきな方もいると思いますが、doStringTestの方は@Ignoreしています。

これ、@Ignoreを外すと、2つ目のテストが今は動かない状態なんです。



これはTestBrowserの部分の作りがまだまだ粗いため、2つ目のテストが実行できない状態になっているからですね。

TestBrowserの起動を@BeforeClassに移動して、

@Before毎にページを読み直すような仕様に変更しようと考えています。


とりあえず、今はこんな感じです。


どうやら…


@skrbさんの周囲で、

JRubyのなひさんJenkinsの川口さんといった

錚々たる面々のお方から反応があったらしく、

意外と面白そうなプロダクトになりそうな気がしてきました。


Seleniumと比べて


SeleniumなどのUIテスト系と比べて、僕がこのFxJsJUnitでやりたかったのはjavascriptのunit testなので、

実はUIはあまり気にしていないんです。

なので、縦幅がいくつとかはあまり興味がなくて、

純粋にjavascriptの関数に対してTDDを実施していけるような状態にしたいというのが第一の目標です。

あと@skrbさんのブログにあったとおり、

GUIは別に表示しなくてもいいという点からいくと、

Seleniumのように画面がポコポコ生まれなくていいというのが強みかなと思っていたりします。

あとはwebkit搭載なので、巷に最近溢れているブラウザー(Chrome/Android用のブラウザ/Safari)に対応できるので、

モバイル系のアプリにも対応できるテストツールになりうるかもしれません。


いずれにせよ、もう少し安定して動かせるようにしたいところです。


なお、コードはgist( https://gist.github.com/2001562 )上にあげていますので、ぜひご意見等いただければ幸いです。

あと、そのうちちゃんとしたプロジェクトとしてgithubにプロジェクトを作りたいと思っています。







2012年3月8日木曜日

"291 things every developer should know"でLTしてきた

デベロッパーが知るべき291のことというイベントに参加してきました。

ニコニコ生放送でも放映されていたようです。

  • 監訳者の紹介とコメント
  • 監訳者たちがデベロッパーとして課題だと思っていることを議論する
  • 読者達による98個目の知るべきこと(LT)
という内容でした。

当日のtogetter@sinyaa31さんによって既にまとめられています。


当日の議論


同じテーブルに座らせてもらった@sue445さんいわおさん澈さんと議論しました。

1.チームワーク

まあ、メンバーの他の人に仕事してもらいやすいようにやりたいよねっていった感じの話をしましたが、

他の人(他者)っていうのは何だろうという、エマニュエル・レヴィナスばりの問いが立てられた所で終わってしまいました。

チームワークというのは、今眼の前にいるメンバーだけのことではなくて、

どこの誰だかわからない人も含めてチームメンバーではないのかという意味ですね。

そういえば、『プログラマー97』本で、恥ずかしいテストデータを作らないというのがあったと思いますが、

これはまさに、どこの誰だかわからない人も含めたチームメンバーのために仕事をする

というのに当てはまる気がします。

また、どこの誰だかわからない人をメンバーとして考えるという点で行くと、

最近よく言われるソーシャルコーディングというのも含まれると思います。


PM、アーキテクト、プログラマーあえて一番重要な役割を選ぶならどの人?

これは答えは出ませんでした。

この3つの役割がうまく回ってこそのプロジェクトであり、プロダクトだろうということで。

ちなみに私の中での勝手な物理的形態ですが…
  • PM … デリバリー
  • アーキテクト … 品質
  • プログラマー … 製品
という感じです。


少子化、国際化、ユーザー企業の意識の変化におけるプログラマーの生きる道

内容的には一番シビアなものでした。

ソフトウェアは価格の叩き合い、運用コストについても価格の叩き合い、データセンターは土地が大きい所(アメリカ)が有利という中で、

日本の情報産業というのは生き残れるのか?もし生き残るとしたらどのようにして生き残るべきなのか?

少子高齢化という現状において、日本の労働力をどのように支えていくのか?

また、外国人労働者の占める割合が極端に低い日本でどのように労働力を確保するのか?

一つ一つが重たい内容だったと思います。


私はわずかではありますが、英語が話せますので、海外に行ってやっていくという自信はあります。

したがって、それほどこの問題への自分への影響はないのかなと考えています。


ただ、まあ、社会問題として考えるなら、結構私は極論を走っていて、

「どんどん外国人を受け入れればいいじゃないの?」と思っていたりします。

イタリア系ブラジル人なアレッサンドラ・アンブロジオみたいなお姉様大歓迎でございます。

人口が少子高齢化で減ってしまう分、補給しなければ、サービスが廃れていくわけですし、新たなサービスの創出などもできないわけで、

小さな島国といえど純血度を下げてでも、海外の人口を受け入れなければやっていけないのではないかと思っています。


まあ、そうは言っても、これには高度に政治的な判断もあるでしょうし、

言葉の問題もあるでしょう。

なので、私が考えるほど単純な問題ではないと思っています。


懇親会 + LT


LTでお話をさせて頂きました。

実は私97本のうちのひとつ『97 things every Project Manager should know』だけは英語版で持っていて、

邦訳が発売される前に既に読んでいました。

そのようなことを元に、英語で英語の本を読もうというようなテーマでLTをしました。


しかし、英語の本を見ていると、

日本では某◯山先生が注目したことによってオワコン感たっぷりなSpring Rooに

cookbookとか出ていたりして、海外と日本とで技術の流行(?)に差があることがよくわかります。

Groovyなんかも同様で、やはり英語の文献は数が多いですね。

Groovyは日本だとマイナーな言語ですが、海外ではそうでもないみたいです。


懇親会の方

オライリーの方がいらっしゃったので、Gradle本とRoo本の翻訳をやりたいんですけどと申し出てみました。





オライリー・ジャパンでは薄い本についての翻訳は今対応を検討しているところだそうですが、

もし面白い本であればいってくださいとの回答でした。

この辺の本の邦訳があるといいなと思ったりするんですけどね






実は英語の本を漁っていると面白そうな本ばかりで、逆に最近の日本の書籍に興味を持てなくなりつつあったりします…

2012年3月6日火曜日

JavaFX + JUnit で javascriptのunit testできるようにしてやるんで、これからハマっていってやんよ - 1

こんちわ。

大分暖かくなって来ました。

暖かくなってくると、旅に出たくなります。

特に、春なら鹿がお勧めです。

ついでに勉強会にも参加しましょう。

というわけで、


鹿駆動勉強会



とかいうのにエントリーすることになりました。

能楽堂でLTをするらしいです。


で、ネタ


JavaFX1のときはあまり惹かれなかったんですが、

JavaFX2になって、Webkit搭載となったので、

おお、JUnitでjavascriptのテストできんじゃね~と思ったので、

試してみることにしました。

まあ、その辺の経緯はtogetterにまとめてます。


事前にJavaFXとThreadにハマった言い訳を書いておく


もともと業務SEだったオレなので、

JavaのGUIとかはあまり触ったことがないというか、

ほとんど触ったことがないというか、

Javaを勉強した時にチョコっと触っただけです。はい。

なので、かなりクソいコードになっています。

サーバーサイドのJavaは書いたことありますです。



テスト対象のJavascript




特に大したことのないコードです。

数字を返す関数、文字列を加工して返す関数、オブジェクトを返す関数です。



テスト戦略???


テスト対象のJavascriptは大したことのないものですが、

ajaxアプリケーションのテストもやっていきたいので、

サーバーを立てていこうと思います。

JUnitでテストサーバーを立てる場合、

以前のエントリにも書きましたが、

Jettyエンベデッドサーバーを用いていきます。

サーバーが立ち上がった後で、ブラウザを立ち上げて、javascriptのテストをしていくという流れになります。

したがって、書いていくJUnitのコードは次のようになります。

  • @BeforeClassにてJettyサーバーを立ち上げる。
  • @Beforeにてブラウザーを立ち上げる。
  • @TestにてJavascriptのテストを実行する。
  • @Afterにてブラウザーを終了させる。
  • @AfterClassにてJettyサーバーを終了する。


JUnitのコード


次のような感じです。




なお、ハンドラーをJUnitに書くと若干読みづらくなるので、ハンドラーは別クラスにしてあります。





ハマる様子をとくと見よ


さて、JsJUnitを実行してみるとこんな感じになる。





JavaFXのWebViewはJavaFXのThreadで立ち上げなければならないらしいだって(´・ω・`)



さて、まだまだハマるのだが、それは後日。

The next work of Art in the age of Informational Reproduction - 3

前回は突然「アウラ」の話をしてしまったわけだが、

昨今の芸術作品と言われているものは、

複製技術による編集というテクニックがかなりの部分を占めていることを否定することはできない。

映画 = 役者の身体 + 編集


第一回でも例に上げたのですが、映画というのが最も典型的な例で、

例えば、ここのサイトにあるように

とくに、いつもながら織田裕二はじつにいい。毎回完璧に役作りをしてくるし、表情やセリフの言い回しだけでこちらを引き付けて離さない。


というのはたんなるヘボ役者であるか、映画作りについて全くわかっていない者のセリフと思わざるを得ない。

映画というのは人間の無意識的な身体を切り取る装置であり、

人間の意識的なものはこの上なく邪魔なものでしかない。

もし、映画に出演する役者が役作りをちゃんとやると宣言するなら、

その映画の監督を務める人その役者に対して、「君は舞台で役作りをするといい」と述べたほうがいい。

映画と演劇というのを混同しないほうが良い。


例えば、クリント・イーストウッドの映画『トゥルー・クライム』というのは時間の映画である。


クリント・イーストウッドの演じるスティーブ・エベレットが死刑執行の現場に間に合うかどうかという

緊迫感を盛り上げているのは、

クリント・イーストウッドの運転する車が失踪するシーンと、

イザイア・ワシントン演じるフランク・ルイス・ビーチャムの死刑執行場のシーンとの

短いショットの切り替えという効果によって生じるのだ。


このような緊迫感の盛り上げは演劇では再現できない。

このような表現こそ映画の表現であり、ヘボ役者が頑張って役作りしても役に立たない本当の映画の魅力なのである。


他にも笠智衆が演技が下手くそで、訛りが取れないのを、日本の親父に仕立て上げたのが、小津安二郎である。

小津安二郎が笠智衆にゆっくり喋ってくれればよいということを伝え、

笠智衆に演技をさせなかった小津の手法が、笠智衆を日本を代表する親父に仕立てたということも忘れてはならない。


また、役者の驚く顔を撮影するためにヒッチコックなども考えてみるといい。

ヘボ役者の驚く顔よりも、人間の本当に驚く顔のほうが明らかに驚きを表現できるだろう。


ここで述べてきたように映画とは、編集と役者の身体(特に無意識的な動作)というのが本質と見てよいだろう。


さて、アウラ


役者がほんとうに驚いたという一瞬はフィルムによって収められ、それらは複製されるのみである。

しかし、その当の役者が驚いたというほんの一瞬、そのものは一回限りにものである。

複製された驚きの顔には一回限りというものがない。

一方で、役者がほんとうに驚いた瞬間というのは一回限りのものである。

この一回限りの瞬間にあるなにものか、これをベンヤミンは「アウラ」と名付けている。


複製された驚きの顔は一回限りというものがない。したがって、「アウラ」は消失している。

一方、ほんとうに驚いた一瞬というものには一回限りという性質がある。これは「アウラ」に満ちている。


『複製技術時代の芸術作品』においては、「アウラ」の消失についての議論が行われている。
(なお、三島憲一によると、この議論は非常に中途半端で『写真小史』の方が徹底したものであるらしいが)

ではベンヤミンは「アウラ」の消失によって何を説こうとしていたのか?

続く。


2012年3月4日日曜日

実は悩んでいる。

多分、私をTiwtterでフォローしていただいている方は最近の私の生活ぶりをよくご存知であると思う。

どいういう生活かというと、冬になってから、一日の睡眠時間が平均20時間程度になっているのである。

ちなみに一日の睡眠時間が平均20時間程度というのはどういう状態かというと、おおよそ次のような感じである。

  • 朝10:00頃目が覚める
  • 朝食を食べるとすぐに強烈な眠気が襲ってくる。(10:30くらい)
  • 寝ると次に起きるのが13:00くらい。
  • 一応昼ごはんを食べてみるが、すぐに眠くなる(13:30)
  • 寝ると次に起きるのが夕方18:00くらい。
  • お腹は空いていないので、ネットにつなげて何らかの作業をするが、1時間くらいで力尽きて、寝る(19:00)
  • 次に起きるのが22:00くらい。ネットにつなげて何らかの作業をする。やはり1時間くらいで力尽きる。(23:00)
  • 次に夜中の1:00くらいに起きる。これも1時間くらいが限度。

実際にはこれらは日によって流動的なので、実際にこのような感じの生活をしているわけではないが、
だいたい似通ったものである。

そうすると、気になるのが、会社へ務めているのかとか、
社会人としてどうなのかという心配が発生する。

実際、多分、私のトップゲート内での信用はガタ落ち状態だと思う。


季節性うつ病?!


このような生活をしていると、
社会から孤立し、
社会からは必要のない存在であると認識し、
社会人として失格である
という至極当然なダメ烙印というのが自分の頭の中で何度も繰り返される。

人間、自分にこのような烙印を何度も繰り返し強制的に頭で描いていると、
本当に自分はこのような人間なのであると自己暗示されてくる。

すると、時折、自殺したい衝動に駆られてしまうこともある。
とはいえ、自殺なんかしたら痛そうだし、苦しそうだしで、実行には移せない。

また、繰り返し頭の中で、この思考を繰り返していると、
本来考えるべき問題も考えることができなくなってくる。

ちなみに、これは春とか夏などでは発生しない。

冬限定なのである。

これは一般的に季節性うつ病の症状と一致している。


季節性うつ病状態でのアイデア


社会人としては不健全な状態の冬季期間の状態だが、
実は結構色々といいと思えるアイデアが出てくるのが不思議である。

  • ITエンジニアへの高校レベルの数学教育勉強会を開催したら、結構集まりそう
  • GAE + Androidで汎用的な学習参考書アプリが作れそう。
  • 最近postしているベンヤミンとかの思想系の読書が捗る
  • JavaFXをjavascriptのテストのフレームワークとして利用できないかというアイデア。

例えば、『不完全性定理』で有名なクルト・ゲーデルも彼の精神状態が不安定な時ほど、
いい仕事をしていたと言われている。

クルト・ゲーデルの生涯を見ていると、結構自分と似ているところがあったり、
他の人のアイデアを少し改良して提示してみるというスタイルも同じだったりして
非常に親近感がわく。
…まあ、そんなことはどうでもいいんだが…。


発達障害


実は私はこれまでもこんな冬になると途端に人間の生活から撤退してしまうものだから、
まともな人間関係が築けたことがないのであって、
こういう状態をどう対処していけばいいのかを相談する友人なども存在しない。


また、その一方で、好調な時でも、
計画性がないとか、コミュニケーションが上手くないとか、行間を読めないだとか、
言われたことの半分位を理解できていないだとか、自分が伝えたいことがうまく言語化できないだとか、
が発生する。

また比較的多くの人が共有できているコンテキストとは逆方向のコンテキストをいつの間にか共有してると思い込んでいて、まあ、後でトラブルになったり。

考えが適当なのは前からだけど、本当に場当たり的に適当に返したりしていて、何を考えているか相手に理解してもらえなかったり、
その結果、「で?」と言われて、何を返して欲しいのかがわからなくて答えに屈したり。


なんかここらへんの状況がどうも最近よく言われる『大人の発達障害』という症状に似通っていて、
まあ、「発達障害」なんていうと、普通の人に劣っているところがあって、それはそれでしゃくにさわったりする。


で、悩んでいるのが


そこでですよ、私自身、非常に悩んでいるのが、そして何年も違和感を抱きつつなんとかごまかしてきたけど、
もはやこの歳では確信するに至った悩みというのが、

私は一般的な社会人として生活できないのではないか?

ということなんですよ。

例えば、人月計算。
これは人間という存在が工学的に計測可能であり、時間に伴う変化を起こさない前提でなされる議論である。
しかし、こと私に関しては、時間に伴う変化は激しいし、その出力は安定しない。

例えば、企業の雇用
これは先の人月計算と同じだが、春夏秋冬を通じて、人間の能力が一定値であることを前提とした雇用契約を行なっているのだが、
私は明らかに春夏秋くらいは大丈夫かもしれないが、冬はどうしようにもない。

例えば、資本主義的な議論
マルクスの資本論においては、季節に関する言説は出てこない。
これはまぐれではないと思っている。
貨幣における交換とは季節とは関係なく行われる。


というわけで、資本主義的な社会において前提としている人間観、
常に一定の出力を有し、それを元に計画を立て、その計画・出資からさらに資本を産み出す人間、
このような人間、つまり一般的な社会人という枠組みに私は入ることができないのではないかということ。


つまり、人間として不的確な人間であるこの私が人間として生きることは可能なのであるかという問い。

これが今私をして悩ませている問題なのである。


親友?


何それ美味しいの?

というくらい、人付き合いは悪い。

これも、春出会って、冬になると音信不通になるとか、
面と向かった時に特に喋る言葉が思いつかないので、
相手方からは「何を考えている人かわからん、キモイ」、私からは「どういう人なのかわからなかった」
という結果になり、友情的なものは何一つ生み出せないし、
信頼関係を作り出すこともできない。

したがって、自分がこれからどうすればいいのかという問題には常に一人で回答を出してきたし
(一般的な社会人でないので、その回答は一般的なそれとは相反する回答であったわけだし)

要は親友などだれひとり居ないのである。


親は?


こういう場合は、親に相談するのが、まあ一般的になるのだろう。
だが、残念ながら私は親をあまり信用していない。

これは小学6年生くらいのころからもう信用していない。
いや、もっと前、5歳くらいの頃から信用していない。

5歳くらいの時、私はビートたけしが好きで、『オレたちひょうきん族』を非常に好きであった。
父親はビートたけしが大嫌いで『オレたちひょうきん族』が放映されると、ジャイアンツの番組にチャンネルを変えた。
父親は言う「たけしのようなくだらない人間は大嫌いだ」。
私は思う「たけしは確かにくだらない言動で笑いを誘うが、笑いを取れるというのはある人間の心理を理解した上で安心を与えられる能力のことである」と。
父親は言う「たけしはくだらない」。
私は思う「たけしは修行時代に多くの映画を見て、おそらく本もたくさん読んだ。たけしはかなりの教養人である。」と。

私は比較的西欧の思想が大好きで、マルクス、ベンヤミン、フロイト、ジル・ドゥルーズ、ハイデガーなどのおやじの世代の人が繰り返し読んできたであろう思想の類が非常に好きである。
だが、父親は父親の世代が繰り返し議論し、共通の教養となっているべきこれらの思想について、なんらの思想を持たない。
会話が全く合わないのである。

うちの家族は今母親を十年前に亡くし、父・姉・私の状態なのであるが、多分全員バラバラである。
ちなみに遺伝的な部分ではどうあるかというと、姉は父に似て、骨格の作りだとかがかなり似ている。
私は母に似ていると感じている。
そして、母の家系は癌で亡くなる家計である。
おそらく、私は人生の早い段階で癌でなくなるであろう。

ちょっと話がずれた。
小学6年生の頃から信頼していないという話しに戻そう。

私達家族は私が小学5年生までは広島に住んでいた。
小学6年になる段階で、引越しをするという決定を父親が決定した。
それは父親はいずれ関東に戻る。その時に姉の進路の心配して千葉に戻るという決定を下したのだ。
それは全く構わない。姉は千葉に戻ればいい。それに母親がついていくのも全く構わない。
私はそれでも広島に残りたかった。
私は広島県民として広島の誇りを持ちつつあった。
広島の小学校を卒業したい、広島の中学校を卒業したい、広島の高校を卒業したい。
これは広島で物心がついた子供が思う当然の願いだった。
私はこの引越には猛反対で、3日間粘って、抵抗した。
無理矢理という形で私は広島から引き剥がされた。
この頃からアイデンティティを私は失ったといって過言でないだろう。

私には故郷はない。
これがひどいアイデンティティの喪失であるというのは否めない事実だと思っている。
アイデンティティに支えられた自我というのはあるのではないかと思う。
しかし私にはそのような自我はない。

第一者に左右され、反論も許されず、なんの発言も効力を持たないそんな自我があるだろうか?
これは自我の成長を妨げる一因だと思っている。
まあ、いずれにせよ、このことが私の認識している「大人の発達障害」に関連があるかどうかは定かではない。
ただ、なんの発言も効力を持たないと認識した人間が何らかの意見を求められて、自分の考えを伝えることができるだろうか?
おそらくできないだろう。

実際、千葉に戻ってからの私は中学生の時に、自分の考えがどうしても言語化できないという深刻な事態が発生しているということは認識していた。


まあ、というわけで、悩みを相談するに、私は自分の親族に頼れない。
信頼していないからだ。



結論


今、現在トップゲートの加藤社長との信頼関係はズタボロであると考えてもらっていいだろう。
それは私の冬に発生する季節性うつ状態、安定しない精神状態、発達障害、これらが元になっていることに違いはない。

そして、これは加藤社長とだけの問題でなく、他の会社に就職するにせよ、どうするにせよ、
私は今の自分の置かれた身体的状況を受け入れつつ社会に容認されていくようにしていかなければならない。

だから、私自身は独立しようかと本気で考えている。
会社のスタンスとして、私の身体的な状況を最優先として出来うる範囲の仕事を行う。
冬は何もしない。

こんな会社を作るべきなのかどうか本当に悩んでいる。

なんの特殊な、尖った技術なしに。







2012年3月3日土曜日

Gradle + Groovy + Ideaをやってみよう

簡単なGradleのbuild.gradleファイルを作成してみた。

ビルドスクリプト


このbuildスクリプトはGoogle-guiceとh2データベースとjunitを入れるだけの簡単なプロジェクト。



読めば大体わかりますね。
javaとgroovyを使って、IntelliJ IDEAで開発できて、jarを最終的に吐き出すプロジェクトです。

GradleをMavenと比較して残念なところに、generate-archetypeみたいに、いい感じのディレクトリツリーを作ってくれるコマンドがないので、
とりあえず、ideaタスクの後に自作して強引に作るようにしています。


Tasks


Gradleでどのようなタスクがあるかを一覧表示します。



gradle tasksというコマンドがそれです。


プロジェクトの作成


では、ideaプロジェクトを作成しましょう。




gradle ideaコマンドとgradle structureコマンドを打つことでプロジェクトの構造が出来上がります。

実際にはideaタスクの後にstructureタスクを割りこませる方法があるんですが、忘れた…orz


プロジェクトの取り込み


では、作成したプロジェクトをideaで取り込みます。


Open Projectを選択します。

先程作成したgradle-study2.iprファイルを選択します。



こんな感じに依存性を解決したideaプロジェクトが作成されます。



GroovyでJUnit


JUnit4はPOJOまたはPOGOでできるので、GroovyでもJUnit4のテストを書けます。

では早速やってみましょう。

パッケージ作り忘れたので、src/test/groovyディレクトリで、[Alt + Insert]を押します。(MacではCtrl + n)




ここで「pa…」と入力すると、packageが選択できます。


適当にパッケージ名を入れましょう。



パッケージができたら、作成したパッケージのところでまたもや[Alt + Insert]。(MacではCtrl + n)

GroovyClassを選択します。



適当なので適当にクラス名を入れます。



早速、@Beforeから書いて行きましょう。



IDEAの素晴らしいところは、あの忌々しい[Ctrl + Space]を入れなくてもどんどん補完してくれる所




さらには依存性が解決している範囲で、あの忌々しい[Ctrl + 1]を入力しなくても、[Alt + Enter]で勝手にimport文を作ってくれるあたり。


なんか適当にlistとかいうフィールド、インスタンスを作ってみましたが、
これはフィールドとして設定しましょう。

listが初出の場所にカーソルを当てて、[Ctrl + Alt + f]、(Macの場合は[コマンド + alt + f])

でいい感じにフィールドを作成してくれます。



適度にスコープを選択して、defで割り当てましょう。


おもむろにテストを書いてみましょうか。

なんか、何もしていないのにアノテーションですら自動補完してくれます。



JUnit4をJavaでやるときはもちろん、org.junit.Assert.assertThatあたりを用いますが、
Groovyでテストをするときは、そんなもん使いません。

assertだけで十分です。


テストわざと間違えていますが…

テストを実行するのは、[alt + shift + F10]です。

何のテストを実行したいか選択して下さい。

メソッド単位で実行できます。



さて、実行結果です。
もちろんテスト間違えているので、どうなるか気になりますね。

テスト実行結果。



何がどういう値で、何が間違っているかがちゃんと表示されるんです。

これはGroovyだからできるんです。Power Assertと言います。

これはGroovyだからできるんです。Power Assertと言います。

大事な事ですから二度言いました。

これはGroovyだからできるんです。Power Assertと言います。


これがJUnitのassertThatなどだったら、expected<4> but got <3> くらいしか出してくれません。


この親切さ。これはGroovyだからできるんです。Power Assertと言います。


こいつはテストを直しておきます。



POJOのテスト


POJOもテストしましょう。もちろんテストはGroovyでやっちゃいます。


とりあえず、誰でも思いつきそうなPOJOでPersonというクラスを作ります。


メンバーはintのageとStringのfirstNameとlastNameです。

getterとsetter作らないとですね。


何もない所で、[alt + insert]を押します。(Mac版ちょっとど忘れ)



とりあえず、メンバー全部選択しましょう。



まあ、このあたりはeclipseでもやれるので、どうということはないですね。



じゃあ、テストを書きましょう。もちろんGroovyで。

Groovyでは特にコンストラクターが指定されていなければ、内部のフィールドに値を一気に代入させることができます。



ほんまかいな?と思うので、assertをかけてみましょう。




さ、テストを実行しましょう。


ほれ、ノープロブレム!!!!



Gradleに戻って


とりあえず、テストを落ちるようにしておきます。




では、gradleでテストを実行します。

テスト実行結果




さて、テストが2つコケたらしいですね。

では結果をhtmlファイルで見てみます。

これがレポートファイルです。


これらの詳細を見ることができます。




ちゃんとテストがどういう点が悪くてfailしたのか一目瞭然ですね。

というわけで、Gradle、あの複雑なpomを書かなくても、いい感じで、ココまでやってくれるのですから、今はAnt + Ivyだけどという人は是非トライしてみましょう。