2011年12月3日土曜日

Languages on JavaVM

最近JavaVM上の言語をよくみるようになったので、メモ

Java
とりあえず
JavaFX
気づいたら増えていて、気づいたら消えていたような言語
Scala
割とRubyを意識してるように感じる文法。型システムが強いらしい。
Clojure
Lispの方言な感じ言語
Groovy
テストでよく使われてると聞いたが……
Ceylon
よく知らないがBetter Javaな方向らしい
Xtend
Eclipseでがんばっている言語。パーサフレームワークを強化したらこうなったっぽい?
Kotlin
JetBrain(InteliJのところ)が作っている言語。やっぱりBetter Javaな方向。

おそらく幾つかの漏れがあるはずなので、見つけ次第追記します。

これを全部フォローするのは大変そう

おまけ?

JRuby
RubyのJVM実装。それなりに良いらしい
Jython
PythonのJVM実装。JRubyほど話を聞かない。逆に.NET実装のほうではIronPythonしか話を聞かない

2011年10月15日土曜日

Ubuntuセッティング

ディレクトリ名を英語表記に


ターミナルから"デスクトップ"とか打ってられないので
"Desktop"にしたいわけです。

端末より以下を入力してあとはいい感じに。

LANG=C xdg-user-dirs-gtk-update

参考:
http://ubulog.blogspot.com/2007/10/ubuntu.html

2011年9月13日火曜日

Project Lambda 現状

延ばし延ばしにしていたProjectLambda後半の和訳ですが,どうやらそんな必要もなくなったかもしれません。
というのも,現在和訳中のLambda式の構文が代わってしまいました。
参考:InfoQメーリングリスト

マジで続きどうしよう……
あとブライアン,次に書くときはもうちょっと読みやすい文でお願いします。

2011年8月28日日曜日

和訳: Project Lambda (前半)

注:この文書はProject Lambdaの提案を和訳したものです。訳の正確性は保証しません。
この文章におかしなところがあればオリジナルを参照してください。

Brian Goetz 2010/10/10

この文書はJava言語にラムダ式を追加する案です。このスケッチはMark Reinholdによって 2009/12に作られた原案をもとに作られました。前のバージョンは2010年7月に発表されました。

2011年8月13日土曜日

Facadeパターン : 隠蔽 or not 隠蔽?

デザインパターンねたの続きです。

Facadeパターンというものがあるんですが、一言で言えば、
「複数の(低水準な)オブジェクトをまとめて扱えるような(高水準な)窓口用クラスを作る」
というものです。

HeadFirstデザインパターンから例を引用すると、
低水準なコンポーネントである
アンプ、スピーカー、プロジェクタ、照明、・・・
といったものを、
高水準クラスである"ホームシアター"で一気に調整する、とかそんな感じです。

HeadFirstデザインパターンでは、
Facadeを使うクラスが、Facadeクラスに低水準コンポーネントを渡す
という形で説明されています。
したがって、高水準な機能だけでは実現できないような"微調整"が必要なときには、
低水準コンポーネントに直接アクセスすることが可能である、と説明されています。
つまり、Java風擬似コードで言うとこうです。

class FacadeUser{
	...
	func(){
		...
		LowLevelComponent1 comp1 = new LowLevelComponent1();
		LowLevelComponent2 comp2 = new LowLevelComponent2();
		Facade facade = new Facade(comp1, comp2);
		...
	}
	...
}
class Facade{
	LowLevelComponent1 comp1;
	LowLevelComponent2 comp2;
	// constructor
	Facade (LowLevelComponent1 comp1,  LowLevelComponent2 comp2){
		this.comp1 = comp1;
		this.comp2 = comp2;
		...
	}
	...
}
一方、wikipediaなんかでは、
Facadeとなるクラスの中で、privateに低水準コンポーネントを作る、ということをしています。
したがって、Facadeを使う側は、直接低水準コンポーネントを触れない、というわけです
(setterやgetterを作れば別ですが)。
特に、日本語版wikipediaでは低水準コンポーネントを隠蔽する点にしっかり言及しています。
擬似コードだとこんなです。
class FacadeUser{
	...
	function(){
		Facade facade = new Facade();
		...
	}
	...
}
class Facade{
	private LowLevelComponent1 comp1;
	private LowLevelComponent2 comp2;
	// constructor
	Facade (LowLevelComponent1 comp1,  LowLevelComponent2 comp2){
		this.comp1 = new LowLevelComponent1();
		this.comp2 = new LowLevelComponent2();
		...
	}
	...
}

隠蔽するかしないかで、クラス図的にはほぼ同じでも、
正直相当違うんじゃないかと思うのですが、どうなんですかねえ。
どっちが正解とかそういうことは無いとは思うのですけども、
せっかく名前をつけている以上はっきりしておいてもらいたいなあと思います。

ま、そもそもFacadeパターンなんて、
わざわざ言われなくても勝手に使っているものにしか見えない、というそもそもの問題がありますが。
この辺の「何をいまさら」感は、Template methodパターンとどっこいどっこいでしょう。

2011年7月24日日曜日

Iteratorパターン

注意:

  • この記事は適当に書かれています。あとでドリーが綺麗にまとめてくれます。
  • この記事はC#erな人が書いています。

現在デザインパターンを勉強中なのですが,さて,デザインパターンの中で一番を選ぶとしたら一体なんなのでしょうか。私が思うにそれはIteratorパターンでしょう。Iteratorパターンはプログラムを書く中で,最もよく使われ,最も直接目にすることはなく,今でも最もHOTなパターンです。

このパターンは集合に対し統一的にアクセスする時によく使われる実装を形式的にまとめたものでした。しかし今ではJavaを初めとし様々な言語でその実装を隠蔽しforeachとして利用できるようになっています。



Iteratorパターンは何故よく使われるのか,それは集合に対して汎用的に利用できるパターンだからでしょう。しかし最近ではメソッドチェーンと呼ばれるプログラムの書き方が流行り,集合に対する操作は今まで以上にエレガントに表現されるようになりました。

http://www.atmarkit.co.jp/fdotnet/chushin/comparedataproc_01/comparedataproc_01_01.html

今までのプログラムと見た目がぜんぜん違う!でも大丈夫,内部的には普通にIteratorパターンが使われています。Iteratorは不滅です。Javaはエレガントな言語じゃないので今まで通りifと一緒に拡張for文(Java5.0より追加された構文)を使ってください。



Iteratorパターンはよく内部イテレータと外部イテレータに分けて説明されます。多くの言語では外部イテレータの利用が言語レベルでサポートされています。では内部イテレータはどこで使われるのでしょうか。実は別のパターン,Observerパターンに姿を変えて利用されることがあります。

Observerは例えばマウス座標の監視などに使われます。でもよく考えるとObserverは連続で通知されるマウスの座標というデータを順に処理しているだけです。そう,これはIteratorパターンと同様なのです。Iteratorパターンがデータをpullして処理しているのに対し,Observerは向こうからデータがpushされる,ただそれだけの違いです。
さて,そんな事が真面目に研究されているプロジェクトがあります。その名もReactiveExtension.ちょっと調べてみるとpull型をpush型に変えるだけでこれだけの違いが現れるのかとびっくりします。

発端の映像はこちら(英語でココだけ見ても普通のことしか言ってないように見える)
http://channel9.msdn.com/blogs/charles/erik-meijer-rx-in-15-minutes
Reactive Exntensionがむっちゃ詳しいブログ
http://neue.cc/

ここらへんを見るとウヒョーとなれること,請け合いです。

2011年7月18日月曜日

デザインパターン絶賛考え中

誰かさんが部屋に置いていったオライリーの「Head First デザインパターン」を読んでます。
いやーこれは良い本ですね。
まだ斜め読みレベルですが、よく出来た本だと思います。
でも手元にあるのが第一刷だからか、怒涛の誤植祭りになってます。
修正がかかっているでしょうし、新しいのを改めて手に入れようかなとも思っています。
あるいは、英語のペーパーバック版のほうが値段が安いのでそっちにしようかな・・・

とりあえず、この本を(一週間かけて)読み終わってから、
頭の中でデザインパターンをまとめてみたいと思います。

とりあえず、今考えているのは、Strategy/State/Commandパターンについてです。
この本には、StrategyとStateは双子だと書いてあるみたいです(まだそこまで読めてませんが)。
デザインパターンを読み解く」では、
これにあわせてCommandも一緒だと指摘してあります。
確かに、ある関数(手続き/処理/アルゴリズム)をひとつのオブジェクトとして扱って、
交換や再利用などを楽にする、という方向性としては近いものを感じます。

手続きを状況に応じて入れ替える、というイメージだとStrategyに、
状態に応じて処理が切り替わっていくというイメージだとStateに、
それぞれをコマンドとみなして、キューにつんで実行していく、というイメージだとCommandになる、
というイメージを今のところは持っています。

Commandはともかく、Strategy/Stateではひとつの関数だけでなく
複数の関連する関数群をオブジェクトとしてまとめる、ということもあるでしょう。
その意味では、"Factory Methodを一まとめにしてオブジェクトにする"という
Abstract Factoryも、若干近い趣があるかもしれません。

まあ、まだまだ考え中です。

2011年7月12日火曜日

くいずです(JavaScript apply編)

くいずです
pushを じっこう したとき あらーと で でる もじれつ なーんだ

var x =" World";
var o = { x: "He" };
 
function f(m){
 for(var i = 0; i < arguments.length; i++){
  m+=arguments[i];
 }
 m = this.x + m;
 alert(m)
};
function push(){
 f.apply(o,new Array("l","o",this.x));
};
こたえ
こんなの一発で理解できたらすごいです。
元ネタ、というか参考サイト

2011年7月10日日曜日

デザインパターンを(真の意味で)理解するために

デザインパターンを一通り勉強しようと、
日本語、英語問わずいろいろなウェブサイトを眺めているのですが、
いろいろとデザインパターンに対する疑問がわいてきました。

たとえば、有名なGoFの23パターンについて、
パターンの"粒度"もまちまちだし(一般的過ぎるものから、非常に限定された問題にのみ使えるものまで)、
分類の仕方もほかのやり方があるだろう、と感じました。

先人の知恵は示唆に富むものであることは重々承知なのですが、
深い理解のために知識を再構成することは非常に重要だと思うのです。
しかしながらウェブ上だと、
GoFの23パターンをずらずら説明しておしまい、みたいなところが多く見えます。
「もうちょっとなんか考えてから説明しろよ」と正直思ってしまいます。
で、いろいろ探して、参考になる(と現時点で思っている)次の2つを見つけました

デザインパターンを読み解く
Relationships between Design Patterns

前者は日本語のサイト、後者は英語で書かれた論文です。
どちらも、沢山あるデザインパターンの本質を考察し、
その位置づけや関係性を再構成しようとしています。
別にわかりやすくそれぞれのパターンを解説しているわけではないですし、
その解釈もこの両者で一致しているわけではありません。
しかしながら、このような努力は非常に素晴らしいものだと思いますし、
表面を舐めただけの解説よりも256倍ためになります。

今度からこれらのサイトを参考にしていきながら、
デザインパターンについてちょっと考えていきたいと思っています。
他にも参考になるものが見つかると尚良いのですが。
書籍のほうがまだマトモなのですかね?

2011年7月5日火曜日

Awesome Inc.のブログアーカイブの横幅がおかしい件について

このブログは、Bloggerに元からあるAwesome Inc.というテンプレートを使っているのですが、
右にある「ブログアーカイブ」のレイアウトがというか横幅が細くなってしまい、
下の画像のようにかわいそうなことになっていました。

こういうの我慢できないんで修正しました。

2011年7月4日月曜日

SyntaxHighlighter ( with Autoloader ) 導入記

ドリーです。
このブログにSyntaxHighlighterを入れました。
JavaScriptをつかってコードの色づけをしてくれる良さげな奴です。
公式ページはこちら。
http://alexgorbatchev.com/SyntaxHighlighter/

いやーなかなか苦労しました。なのでやり方をメモしておきます。
まず基本的に読み込むべきは
  • shCore.css
  • look and feel用CSS
  • shCore.js
  • 各言語用.jsファイル
です。

2011年7月3日日曜日

Yash を使う

どーも、まじかんとです。
拙作の yet another shell (yash) というシェルは私のお気に入りです。Bash では何となく不満な人、zsh は重すぎて嫌になっちゃう人、yash をお試しになってはいかがでしょうか。Yash はデフォルト状態では使いづらいとおもいますが、いろいろ設定すると割と使えると思いますよ。
シェルってなにそれ? という人も、まずは yash をインストールして私がいつも使っている設定ファイルで設定してみてください。シェルをカスタマイズするということがどういうことか何となくでもわかると思います。
Yash はどんな環境で使えるの? → 最近の Unix 系環境なら大体使えます。Linux, Mac OS X, Cygwin, ...
Yash のインストール法は? →
  1. 配布ページから yash-(バージョン番号).tar.gz というのを適当にダウンロードして、適当に展開。
  2. あとは中に入っている INSTALL.ja をよく読んで頑張ってください(ぉぃ)。Yash をコンパイルするためにはまず curses と libintl というライブラリを入れないといけないのですが、環境によってやり方が違うので細かいことは私に聞いてください。
  3. ホームディレクトリの中に .yashrc というファイルを作って、いろいろ設定を書きましょう。私の設定ファイルをコピペしてそれをいじるとよいかもしれません。

Abstract Factory PatternでHello World

100行ぐらいになりました。

2011年7月2日土曜日

SyntaxHighlighter導入してみました

どうにかこうにか動くまでになりました。
導入の顛末については別記事に書きます。

  function foo(){
    alert("bar");
  }

投稿時の使い方などは「もっと読む」へどうぞ。

bashのTabで大文字・小文字を区別せずに補完する

bashのTabで大文字・小文字を区別せずに補完するには、
~.inputrcファイルに次の行を加える
set completion-ignore-case on

D.O.R.Y. 始動

ドリーです。

ここ"D.O.R.Y. : Dory Offers a Room for You"は、
自由気ままにコンピュータ、プログラミング、その他知りたいことを学ぶ場です。
みんなで何かを作るのもよし、ひとりでちまちま勉強するのもよし。
みんなで背中を押し合って学んでいきましょう。

この動きの早いIT業界でこの先生きのこれるように、
とりあえずいろんなものに飛びついてみる、というのが隠れ目的です。

「もっと面白く、もっとくだらなく」が唯一のルールです。
とりあえずHello Worldを書くことからはじめます。