December 19, 2009

Scala はじめました

Home

Scala にとても興味が湧いてきたので本を買って勉強を始めました。
そのうち勉強会とかやりたいです。

とりあえず今日は Scala をインストールしてインタープリターを少しだけ使ってみました。

Mac での Scala のインストール

MacPorts を使えば簡単にインストールできる。

sudo port install scala

Scala インタープリターの起動

scala とだけ入力して実行すると Scala インタープリターが起動する。
僕の環境だと以下のような感じになる。

% scala
Welcome to Scala version 2.7.5.final (Java HotSpot(TM) Client VM, Java 1.5.0_22).
Type in expressions to have them evaluated.
Type :help for more information.

scala> 

インタープリター中で日本語を使いたい場合は -Xnojline オプションを付ける。

Hello World!

とりあえず「Hello World!」を出力してみる。

scala> println("Hello World!")
Hello World!

変数の定義

Scala には var と val の二種類の変数がある。
var は Ruby にもあるようないわゆる普通の変数。
val は Java の final に似ていて、初期化後に別の値を代入することができない。

var の場合:

scala> var foo = "foo"
foo: java.lang.String = foo

scala> foo = "FOO"
foo: java.lang.String = FOO

val の場合:

scala> val foo = "foo"
foo: java.lang.String = foo

scala> foo = "FOO"
<console>:5: error: reassignment to val
       foo = "FOO"
           ^

val に値を再代入しようとすると怒られる。

参考

今この本を読んでいます。
わかりやすくかつおもしろいです。

October 21, 2008

JJUG Cross Community Conference 2008 Fall レポート2

これの続き。

DOMパフォーマンスチューニング入門

講師: amachang

JavaScript は遅い遅いといわれているけど
ベンチマーク取ってみると Rerl とか Ruby 並みの速度
遅いのは DOM に 関する処理

DOM 関連の処理を分解してみると、

  1. コンポーネントとの通信
  2. DOMノードの追加
  3. スタイルの再計算
  4. レイアウトの再計算

となる。

1 コンポーネントとの通信
XPConnect や COM との通信
IE が特に遅い
無駄なプロパティアクセスを減らすと良い
→ 変数に入れるなどして

2 DOMノードの追加
ノードに「変更されたフラグ」が立つ
「parent.appendChild(child)」とすると parent と child にフラグが立つ
(DOM に対する処理をすぐに実行するのではなくて後でまとめてやるためにマークを付けとく、みたいな感じですかね。)

3 スタイルの再計算
スタイルの再計算が行われるタイミングを把握しておく必要がある
スタイルの再計算はどんな時に行われるか

  1. 変更フラグが立っているノードがあるまま JavaScript が終了した時
  2. 変更フラグが立っている状態でスタイルの再計算が必要な処理を行った時
    offsetWidth プロパティの値を取得したり

処理の順番を意識する必要がある
スタイルの再計算が行われるエレメントを意識する必要がある
子ノードとか下にあるエレメントとかもスタイルの再計算が行われる

4 レイアウトの再計算
要素の幅、高さ、位置の計算がここで行われる
激しく重い
→ 親ノードにも影響を及ぼすことがあるので
基本、スタイルの再計算に気をつけていればいい

プロファイラのデモ
各メソッドの実行時間とか、呼び出し回数なんかが簡単に調べられる
(safari 4 にはプロファイラが搭載されるらしい)

質問タイム
Q: 再計算のタイミングを知るには
A: Webkit をデバッガで起動。ログを仕込んだりして調べる。

Q: Webkit のソース解読 Tips
A: Webkit の IDL ファイルを見ると良い

ギークなお姉さんができるまで

講師: べにぢょ (アルカーナ株式会社), purprin (エスカフラーチェLLC)

個人的にはあまり興味がわかない内容でした。
おもしろかったけど。
(というか、人の話を聞くのって基本おもしろい。退屈な話しかしない人もいるけど、自分が何を考えているのかということをちゃんと話そうとして話している人の話はだいたい面白い。)
purprin さんの話がもうちょっと聞けたらよかったかも。
Web デザインの話とか。

『JavaからRubyへ』・アンド・ナウ

講師: 角谷 信太郎 (株式会社永和システムマネジメント), 高井 直人, 和田 卓人

Java から Ruby、EJB から Rails という流れの裏にどのような歴史があるのか、というようなお話
以下はスピーカーの方達のブログ記事。

YET ANOTHER GREEN IT

講師: 和田 卓人, 角谷 信太郎 (株式会社永和システムマネジメント)

息が合えばペアプログラミングってすごく楽しそうだなぁと見てて思った。
こういうセッションも楽しいですね。
他人が開発してるところとか普段そんなに注意深く見てないし。

Agileは現場に適用できるのか? ~オンナだらけのパネル・ディスカッション~

講師: 片山 智咲子 (Java Edge), きたむら (日本XPユーザグループ), 柳本芙友子 (要求開発アライアンス)

なにかこう、釈然としないディスカッションでした。
アジャイルという言葉の意味が人によってまちまちだなぁ、とすごく思いました。

java-jaプレゼンツ・第十一回 第2回チキチキ JJUG だよ全員集合 ライトニングトーク大会

おもしろかったです。
え?、西尾さんビーズの話して終わり?みたいな。

October 18, 2008

JJUG Cross Community Conference 2008 Fall レポート1

レポートっていうほどのアレでもないけど。

JJUG Cross Community Conference 2008 Fall というイベントに参加してきた。

その感想など。

CloudとAndroid 丸山 不二夫 (早稲田大学)

話題が多方面にわたって、ついていくのがやっと。
結局のところ、何がいいたいのかよくわからなかった。
んー、まあ、クラウドですよクラウド(よくわかってない)。
で、インフラが重要であると。
Google はクラウドを実現するためのインフラを作り上げた。
ネットワークが高速化するとコンピュータのあり方が変わってくる。
分散。
プログラムの組み方も変わってくる。
リレーショナルデータベースは時代遅れに。キー・バリュー型へ。

Android
携帯のオープン化の動きは非常に重要
携帯市場は巨大
デジタルデバイドの終焉
新しい市場の可能性

Hudsonによる継続的インテグレーション – 川口 耕介 (Sun Microsystems, Inc. senior staff engineer)

個人的にはこれが一番ささった。

マシンをフル活用せよ!
人件費に比べたらマシンのコストなんて安い。
自動化!

Hudson
Java 製の CI サーバー
ビルドやテスト等のタスクを自動化

このツールはすごーく便利そう。
UI もよさげだし。
もうちょっととっつきやすい名前だったらいいのになぁ。
あと CI(継続的インテグレーション)という言葉も堅苦しい感じがする。

続きはまた後で。

追記:
書いた

June 26, 2008

Ruby と Java について

desk.jpg

Ruby と Java についてあとで書く。

追記:

結論

どっちもやってみたらいいと思うよ!

いやほんと、これにつきる。
とりあえずそれぞれの言語にどっぷりつかってみるべき。

優劣

どちらの言語が優れているとか、そういうレイヤーの話って不毛なんですよ。
Ruby という言語のことを知らずして Ruby のことをとやかく言うことはできないよね。
逆に Ruby やってる人間はだいたい Java のことはよくわかってる。
むしろ、Java やってる人以上によくわかってるかもしれない。
(想像だけど)

適材適所

ていうか、適材適所ですよ。
Java を使うべき所で Java を使い、Ruby を使うべき所で Ruby を使う。
PHP を使うべき所では PHP を使う。
えーっと、だから逆に言うと、いくら Ruby がいいからといって、Ruby を使うべきではない所では Ruby を使うべきではないということ。
エンジニアたるもの、そのくらいの見極めができないとダメだと思う。

Ruby vs Java

実際の所、Ruby を仕事でバリバリ使ってる人ってまだ結構少ないと思う。
Ruby が好きとは言っても、ほとんどの人が仕事では Ruby 以外の言語(Java, PHP, Perl とか?)をメインに使っているんじゃないかな。
だから例えば、Ruby を知らない Java 屋さんが、Ruby プログラマと何らかの形で張り合おうとした場合、Java 屋さんは圧倒的に不利。
Rubyist は相手のことをちゃーんと把握してるから。
それに比べて Java 屋さんは Ruby のことを何にもわかっちゃいない。
この状況でどちらが勝つか。
考えるまでもないですね?

冗談はさておき。
どのプログラミング言語を使えるのか、という程度のことで他人との間に軋轢が生まれてしまうような状況ってのが実にくだらないと思うのです。
自分の考えが正しくあるためには、相手の考えが間違っていなくてはならない、みたいなね。

ああ、
もうちょっとまともな文章かけるようにならないと。

February 26, 2008

ScriptConsole – スクリプトを手軽に実行するためのツール

スクリプトを手軽に実行するためのツールを作ってみました。
ファイルに保存するまでもないような、ちょっとしたスクリプトを書くときなんかに便利です。

ダウンロード

ScriptConsole.jar

仕組み

内部的には、一時ファイルにスクリプトの内容を保存してスクリプト実行用のコマンドを直接叩いてるだけです。
Ruby とか PHP とか、その他にも、システムにインストールされていればだいたい動くと思います(なんせコマンド叩いてるだけなんで)。

動作イメージ:

ScriptConsole4.png

スクリーンショット

ScriptConsole1.png

ScriptConsole2.png

実行の仕方

実行方法は以下のようにコマンドプロンプト等から実行するか、

java -jar ScriptConsole.jar

もしくは jar ファイルをダブルクリックして直接実行できるような環境になっていればダブルクリックして実行してください。

あ、java 1.5 じゃないとたぶん動かないと思います。

ソースコード

http://svn.jugyoo.org/public/ScriptConsole

July 28, 2007

読書: JavaからRubyへ

これ読みました。

JavaからRubyへ ―マネージャのための実践移行ガイド JavaからRubyへ ―マネージャのための実践移行ガイド
角谷 信太郎

オライリー・ジャパン 2007-04-21
売り上げランキング : 204750

Amazonで詳しく見る by G-Tools

誤字が多いのが気になりますが、大変面白かったです。

いやー、ほんと、システム開発っていろいろあって面白い。
一体何が真実なんだか。
ま、なんにせよ、選択肢は複数あった方が良い。
テクノロジーでは解決できない問題もたくさんあるだろうけど。

Martin Fowler氏へのインタビューより引用。

Q : Javaはどこで道を誤ったのでしょうか?
Java界は、スキルの未熟な開発者にもシステムを台無しにされないようにすることに力点を置きすぎています。結果から言えば、この考えは破綻しています。銃で自分の足を打ち抜かないようにするという考え方は魅力的ですが、現実に私たちが目にしているものは理想からは程遠いものです。あまりにも複雑でひどいJavaアプリがそこら中に転がっています。

全体的に、Javaは複雑すぎるのです。「銀の弾丸はない」 [略] というのは、本質的複雑性と偶発的複雑性とを区別するということです。たとえば、給与支払システムの開発では、給与支払の業務ルールは本誌的な複雑性です。しかし、Javaの労力のほとんどを占めているのは偶発的複雑性です。EJBの大失敗はこの最たる例です。EJBは、それ自体がとんでもなく複雑なフレームワークであるばかりでなく、私たちが経験してきたアプリケーションのほとんどにとって複雑すぎます。SpringとHibernateはEJBに比べれば格段に進歩していますが、それでもまだ、偶発的複雑性に満ち満ちている印象を拭えません。
– p.28

「本質的複雑性」と「偶発的複雑性」っていうのは良い表現だなぁ。

プログラマって、複雑なものに惹かれる本能を持ってる気がする。
「こんな複雑なことをやってのけちゃう俺すげー!」みたいな。
それがバッドノウハウにつながったりもする。
あとは、焦り。
「この新技術をマスターしないと時代に乗り遅れる!」みたいな。
そういうのが問題を生んだりする。

以下、その他諸々コピペ。

EJBはだんだん良くはなっていますが、それでもまだ難しすぎます。 [略] EJBは象を撃つ大砲のなかでも最高級品なのです。しかし、筆者の知るEJB開発者のほとんどは、EJBをWebインターフェイスを備えたリレーショナルデータベースアプリケーションの開発に使っています。どんなに贔屓目に見ても、EJBに適しているのは、分散トランザクションのような高度な機能が要求されるニッチな分野です。
– p.30

[略] Javaで言語を拡張するために(Dependency Injectionアスペクト思考プログラミングといったバズワードや、XMLベースの設定を利用するような)厄介で複雑な方式が必要不可欠なのは、動的言語のような方式ではJavaの拡張が難しいからです。
– p.52

要は、DIって「苦肉の策」的なものなんじゃないかなぁ。

Javaの良くないところは、もっと素朴なテクノロジを使うべきユーザに対しても、エンタープライズフレームワークを使うように働きかけていることです。
– p.60

Javaは言語の選択肢としては安全かもしれません。しかし、正しいフレームワークの選定は、たとえ専門家であっても難しいのです。
– p.68

確かに、Javaにおいてはフレームワークの選択は非常に難しい。

ていうか、RubyがJavaに取って代わるかはどうでもよく、現時点でのJavaの問題点をきちんと把握しておくことが重要だな、と思った次第。

January 20, 2007

設定、設定、設定

それでも僕は設定を書くね (arclamp.jp アークランプ)

たぶん、これからのエンタープライズ開発では「ロジックコンポーネントを書く人」と「それを使う人」が今まで以上に明確に分離してくるはずです。そのためには「それを使う人」が、いわゆる設定ファイルの記述やSOAのビジュアルツールみたいに痒いところに手が届かない方法ではなくて、スクリプトや宣言的記述のように”良い感じ”に書けるようになるようになる必要があります。

やっぱ XML でプログラミングってのはキツいと思う。

SOA の失敗はエンドユーザーには難しく開発者として大雑把過ぎる中途半端なツールにあったわけです。これはビジョンや問題設定が理想論過ぎてしまったことが原因です。そこからのゆり戻しとしてRonRを捕らえると、設定の重要性が増すなかで「いかにいい感じに設定するのか」という挑戦として僕には見えています。

SOAについてはよくわからない。
よくわからないものがよくわからないままに失敗していたのね。

アークランプ氏が「設定、設定」っていうのがどうも引っかかる。
結局はプログラミングでしょ、どれも。

この辺の話って、どれも抽象的すぎる気がして好きになれないな。
あーだこーだ考えてるよりもプログラミングしたほうが有意義な気がする。
そういえば最近仕事以外でプログラミングしてないなぁ。

ふと思ったけど、良いものを作ったからといってそれが普及するかどうかはまた別の話だと思う。
万人受けする魅力がないとだめなんじゃないかなぁ。Railsみたいな。

そういえば最近、 Spring がなかなかすごいと思い始めている。
なんと言っても便利。
RMI とか JMS とか使うのがすごく楽。
ていうか、これらに関しては Spring 使わない普通のやり方が面倒くさすぎるだけなんだけど。

Java ってライブラリはたくさんあって良いけど、言語としては柔軟性がないというか融通がきかない部分があるので Spring 等の DI コンテナでそこを補わないともうだめなんだろうなぁ、というのが今のところの僕の認識。
それにしても、XML であんなプログラミングチックな設定をがりがり書くなんて、どこか間違っている気がするんだよなぁ。

追記:
天使やカイザーと呼ばれて: DIコンテナの設定ファイル書くの?書かないの?
この記事がなかなかわかりやすくて参考になった。
うまく問題を切り分けていてすばらしい。