円高だということもあって思い切ってFlickrExport for Apertureを買ったのはいいものの、品質が低すぎて正直返品したい。良くても100枚一度にアップロードできない。ネットワークが途中で切断されたりすると必ずクラッシュする。ひどいときにはたった5枚すらアップロードする前にクラッシュ。しかも、単にpluginがクラッシュするだけではなくてApertureを巻き込んでクラッシュするのでたちが悪い。Nikon D90を買ってから急激に写真の枚数が増えてきたので、安定したアップローダがやっぱりほしい。jUploadrが一番安定しているから1000枚単位の大量アップロードをするときにはまだこれを使っているけど、いくつか不満な点が。
その1。サムネイルを作る時間が長すぎるし、CPUを使いすぎる。jUploadrに写真をDrag & Dropすると写真のサムネイルを作って、その後、Photosetに入れたりするための操作ができるんですが、まずこのサムネイルを作るのにとても時間がかかる。1000枚単位の追加をするとCPUは20分ぐらい100%フル稼働でほかのことができない。そもそも、Apertureで整理した後なので、サムネイルを確認して一枚ずつ設定を変えることもないからサムネイル作成処理は僕にとって不要。ディレクトリ単位でアップロードの設定ができれば十分。個別にいじりたいときでもファイル名だけわかればとりあえずApertureで確認できるし、そのときに個別にサムネイルを作ってほしい。
その2。Photosetsへの写真追加に失敗することがある。今まで試した、FlickrExport for Aperture、1001、jUploadr、Flickr Uploadr 2.x/3.xのいずれでも、あらかじめ設定しておいたとおりに写真がPhotosetsに追加されずに全部の処理が完了されましたと表示されてしまうことがあって、結局あとからもう一度手動でOrganizerを使って整理するのが必須でした。1000枚単位の写真をWeb画面で整理し出すと大変なので、このあたりの処理が確実に実行されるか、再試行について詳しく設定できるようにしてほしい。
その3。未現像のRAW画像について設定ができない。これは仕組み上しょうがないんだけど、Apertureなどのような現像ソフトを使っている場合、RAW画像はAperture上で管理されていて、JPEGに書き出したファイルについてようやくjUploadrがファイルとして認識して、アップロードのタスクとして追加される。RAW現像にかかる時間もなかなか侮れなくて1000枚単位だと20分ぐらいはかかるし、いちいちRAW現像処理が終わったことを目視確認してからjUploadrにかけるなんてやってると、面倒くさい。なので、できればApertureなどであらかじめ指定したディレクトリにRAW現像するようにして、現像が終わったJPEGファイルからディレクトリに対して設定されたメタデータを元に随時アップロードするようにしてほしい。またアップロードができたJPEGファイルが完了後に自動削除されるオプションがあるとよりうれしい。
そんなこんなで前々から作ろうと思っていたFlickrへのバッチアップローダを作り始めました。Flickr APIは認証周りの実装が面倒くさいので敬遠していました。どうせ作るなら安定して使えるJavaで実装したいのだけど、JavaのFlickr APIライブラリは古かったりアップロードAPIが実装されていなかったりするのも今まで着手していなかった理由の一つ。でも今回は、今実家にいてすることがないので、がっつりと時間を使って実装に集中することができ、とりあえず認証まわりとアップロードまでのライブラリが作りあがりました。次は、UIとアップロード順序の管理をするあたりを作ります。アプリケーションの名前はj20000という名前にしました。
id:Yoshioriさんの作ってるやつの別実装。id:taichitaichiさんのとも別の視点で作ってみました。ポイントは次のような感じです。
- 一定時間しか保持しない、というよりは一定時間経過したエントリを隠す。
- タイムアウトしたエントリの自動削除機構までは含まない(Mapの使われ方によって削除のタイミングはニーズが読めない)。ただし、明示的な削除方法は提供する。
- 見えなくなる時間がわりと正確。ScheduledExecutorServiceを使って、正確なタイミングで削除されることを信頼しない。
この実装では、毎回Mapの操作に対してその時点でのスナップショットを作成します。snapshotの作成はわりと高価な作業ですが、それよりも時間に対して正確であることを目標としています。経験的に、Mapに数万エントリも入っていることはふつうの用途としてはまれなので、そこは目をつぶります。スレッドセーフとなるように気をつけましたが、テストはしていません。あ、全体的にテストはしていません。
import java.io.Serializable;
import java.util.ArrayList;
import java.util.Collection;
import java.util.HashSet;
import java.util.Map;
import java.util.Map.Entry;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicReference;
/**
* 指定時間以上経過したエントリを隠すマップ.
*
* @author takayuki
*/
public class TimeoutMap<K, V> implements Map<K, V>, Serializable {
private final long timeout;
private ConcurrentHashMap<K, ValueAndTime<V>> map
= new ConcurrentHashMap<K, ValueAndTime<V>>();
final class ValueAndTime<V> implements Serializable {
private V value;
private long time;
public ValueAndTime(V value, long time) {
this.value = value;
this.time = time;
}
public long getTime() {
return time;
}
public V getValue() {
return value;
}
}
final class EntrySetImpl<K, V> implements Map.Entry<K, V>, Serializable {
private K key;
private AtomicReference<V> value;
public EntrySetImpl(K key, V value) {
this.key = key;
this.value = new AtomicReference<V>(value);
}
public K getKey() {
return key;
}
public V getValue() {
return value.get();
}
public V setValue(V value) {
return this.value.getAndSet(value);
}
}
/**
* コンストラクタ.
* @param timeout タイムアウト(ミリ秒).
*/
public TimeoutMap(long timeout) {
this.timeout = timeout;
}
private ConcurrentHashMap<K, ValueAndTime<V>> snapshot() {
long t = System.currentTimeMillis() - timeout;
ConcurrentHashMap<K, ValueAndTime<V>> snapshot
= new ConcurrentHashMap<K, ValueAndTime<V>>(map);
for (K key : snapshot.keySet()) {
if (snapshot.get(key).getTime() > t) {
snapshot.remove(key);
}
}
return snapshot;
}
private Collection<V> snapshotOfValues() {
Collection<V> values = new ArrayList<V>();
Map<K, ValueAndTime<V>> snapshot = snapshot();
for (K key : snapshot.keySet()) {
values.add(snapshot.get(key).getValue());
}
return values;
}
/**
* タイムアウトしたキーのエントリを削除.
*/
public void gc() {
map = snapshot();
}
public int size() {
return snapshot().size();
}
public boolean isEmpty() {
return snapshot().isEmpty();
}
public boolean containsKey(Object key) {
return snapshot().containsKey(key);
}
public boolean containsValue(Object value) {
return snapshotOfValues().contains(value);
}
public V get(Object key) {
ValueAndTime<V> v = snapshot().get(key);
return v == null ? null : v.getValue();
}
public V put(K key, V value) {
ValueAndTime<V> prev = map.put(key,
new ValueAndTime(value, System.currentTimeMillis()));
return prev == null ? null : prev.getValue();
}
public V remove(Object key) {
return map.remove(key).getValue();
}
public void putAll(Map<? extends K, ? extends V> map) {
for (K key : map.keySet()) {
put(key, map.get(key));
}
}
public void clear() {
map.clear();
}
public Set<K> keySet() {
return snapshot().keySet();
}
public Collection<V> values() {
return snapshotOfValues();
}
public Set<Entry<K, V>> entrySet() {
Set<Entry<K, V>> entryset = new HashSet<Entry<K, V>>();
Map<K, ValueAndTime<V>> snapshot = snapshot();
for (K key : snapshot.keySet()) {
entryset.add(new EntrySetImpl(key, snapshot.get(key).getValue()));
}
return entryset;
}
}
追記: スレッドセーフにしたいなあと思って書いているといろいろ、ぼろが見つかりますね。gc()が実行されている間、put(Object key, V value)と、remove(Object key)の実行をブロックしないとエントリの欠落や削除漏れが出そうです。
この間買ってかなり気に入っているContour Design Shuttle Pro2。唯一気に入らないのが、このShuttle制御用の常駐アプリのアイコン。個人的に、Macにせよ、Windowsにせよ常駐系のアイコン表示はなるべくシンプルにしておきたいので、表示させるのは必要最小限にします。Windowsだとタスクトレイに多くて3つ表示させるぐらいですかね。MS IMEのメニューがタスクトレイに入らないのが気に入りません。Macはいまのところ8つです。Macの場合はことえりにしろATOKにしろ同じカテゴリにはいるし、アイコンもシンプルな単色で気持ちいいです。Contour Design Shuttle Pro2のアイコンも本当は出したくなくて設定を確認しましたがどうやらなさそう。それに常駐アプリがないとアプリケーションごとの設定切り替えができなくて不便です。
アイコンのデザインで気に入らないところは、形よりも色です。色はほかのMac OS Xアイコンと調和がとれるようにシンプルにしてほしい。そこで、/Applications/Contour Shuttle.app/Contents/Resources/ContourShuttleHelper.app/Contents/Resources/ContourShuttleMenu.app/Contents/ResourcesにあるShuttleMenu.tiffを編集してほかのアイコンにテイストを合わせることにしました。Mac OS X標準のアイコンは15%黒のアンチエイリアス付きで描画されているのでそれをまねして書きます。
サイズはほかのアイコンに合わせて1ピクセル小さくしました。ベースラインも1ピクセル下げてあります。
これで完成。テイストが合ったのでだいぶ気にならなくなりました。一件落着。
一応、作ったアイコンをおいておきます。
ShuttleMenu.tiff
9月から就職活動をしてみた経験と、アルゴリズムデザイン
安定マッチングとは大まかには、企業と就職希望者のようにお互いに自由な希望順位をもった者同士を安定的にマッチングさせることです。ここで、安定的といっているのは、ある希望者Aさんが、企業XにAさんの希望順位通り内定をもらったとします。その後、希望者Bさんの話を聞いていて気が変わって企業Yに興味を持つようになり、内定を辞退するようなことになると、収拾が付かなくなってしまいます。そこで、問題を捕らえるに当たって、希望順位は不動とすることで、マッチングの結果が安定します。
アルゴリズムデザインでは、安定マッチングの例を男女の結婚マッチングとして紹介しています。これは、就職希望の例だと企業Xが複数の希望者を採用しても良いので、アルゴリズムとして設計する難易度が上がってしまうため、男女の結婚のように1対1のペアとしてマッチングさせるアルゴリズムを最初に紹介しています。このアルゴリズムはGaleとShapleyによるものなので、GSアルゴリズムと紹介されています。
昨今の経済状況では、ある企業の採用枠は高々1人のことが多いので、転職エージェントはGSアルゴリズムが使えそうです。
GSアルゴリズムを使うとして、転職エージェントが行うことは次のようになります。
- 最初に、同数の企業と希望者がいて、まだ誰も内定もオファーももらっていないとします。
- 企業xが優先順位としてもっとも高く、まだオファーを出していない希望者aを選びます。希望者aが別の企業yから内定をもらっていない場合、希望者aは内定を受諾します。
- 希望者aが別の企業yから内定をもらっている場合、希望者aが企業xをより好むなら企業yの内定を辞退し、企業xの内定を受諾します。希望者aが企業yをより好むなら、企業xはオファーを出しません。
- すべての就職希望者にオファーを出していない、採用枠が埋まっていない企業が存在する間このプロセスを繰り返します。
これでしばらく操作を続ければ、企業と採用希望者の安定マッチングが得られます。
このGSアルゴリズムを使ったマッチングは、O(n2)で終了する優れたアルゴリズムです(その証明など詳しくはアルゴリズムデザインで確認してください)。安定マッチングが得られてよしよしと思うところですが、このアルゴリズムでは就職希望者の優先順位よりも企業側の優先順位がより優先されます。企業の優先順位と、就職希望者の優先順位がうまく合致する場合にはフェアな安定マッチングとなりますが、そうではない場合企業側の優先順位に基づいて安定マッチングが完了し、就職希望者は不満を持つかもしれません。
不況のさなか、就職希望者側にアンフェアに感じるマッチングであったとしても、満足すべきだろうと言い聞かされるかもしれません。しかしながら、就職希望者側の希望条件すらヒアリングしない転職エージェントが今回多かったような印象を持ったのは、やはり転職エージェントにとってのスポンサーが企業側だからのように見えて仕方がありません。
企業側とはネゴシエーションをしないし、就職希望者側を説得にかかるエージェントはまさにGSアルゴリズムでの安定マッチングを経験的に実践しているのでしょう。そういうエージェントに限って「あなたの将来を考えて」などと発言するのです。
Premiere ProではMotion-JPEGを読み込みできないようなので、仕方なくあらかじめPremiereで読み込めるようにQuickTime形式に変換することにしました。でもたくさんファイルがあると一つずつ変換するのは面倒くさいので、AppleScriptを作ることにしました。用途は違えど、だいたい同じような需要はあるもので、検索したらすぐ出てきました。今回は「ムービーをQuickTime形式へ変換するAppleScript (影羽連盟)」を参考にさせていただきました。ファイル名の変換のところで、ウチでは動かないところがあったのでその部分を修正しています。
on run activate set itemList to choose file with prompt "ムービーを選択してください" default location (path to home folder) with multiple selections allowed without invisibles my saveAsQuickTimeMovie(itemList) end run on open inputList my saveAsQuickTimeMovie(inputList) end open on saveAsQuickTimeMovie(movieList) activate tell application "QuickTime Player" launch activate stop every document close every document saving no repeat with aMovie in movieList open aMovie set new_file to (aMovie & ".mov") as string save self contained document 1 in new_file -- 独立再生形式で保存 close document 1 saving no end repeat quit end tell end saveAsQuickTimeMovie
オリジナルのソースでは独立形式にするか、参照形式にするかを選択しますが、ウチではとりあえず独立形式にしたかったのでダイアログを無くしました。あと、ファイル名を拡張子だけ変更するためにQuickTimeのドキュメント名からファイル名を取得していたのですが、Ricoh GX100のムービーだとドキュメント名が空になってしまい、うまく動作しませんでした。このため、新規ファイル名は強引に元ファイル名に “.mov”を追加するだけにしました。元スクリプトでは “.” ドットを探して拡張子を変えていましたが、このあたりでどうもディレクトリ名に “.”が入ってるとダメなケースがあるようでしたので、その問題も回避できるようになりました。
Premiere Pro CS4にはD90のDムービー(AVI形式)が直接インポートできないようです。これにはかなり困っています。わざわざQuickTime Proとかを使ってH.264等に変換しないとインポートできないんです。After Effects CS4なら大丈夫なのに・・・。もちろん、Final Cut Express 4でも大丈夫。
体験版ではAdobe以外の提供しているコーデックは使用できない、という制限があるので、体験版を使っていたときはてっきりこの制限に引っかかってインポートできないのだと思っていましたが、製品版を入れてもダメ。一度体験版時のバイナリをアンインストールして、入れ直してもダメ・・。調べてみると、デジカメのムービーにありがちなMotion-JPEGで圧縮されたファイルはサポートしていないみたい。うすうす気づいていましたが、Premiereは高価なHDカム向けのようですね。仕方ないので、D90で撮ったムービーはFinal Cut Expressで編集します。
12月19日に発売されたAdobeのCreative Suite 4 Production Premium。ビックカメラで取り置きしてもらって、昨日買ってきました。
Creative Suite 3 Web Premiumからのアップグレードということで、アップグレードＡというパッケージ。あんまりCS3からアップグレードする気はなかったんですが、動画の撮れるNikon D90を買ってからそろそろ動画もいじり始めようと思ってAfter EffectsとPremiere ProのためにProduction Premiumを選びました。結構最後まで、AppleのFinal Cut Studio 2にするか迷いました。値段で言うと、Production Premiumへのアップグレードが9万8千円、Final Cut Studio 2が14万8千円。結果的には、
Final Cut Expressという廉価版も併せて買ってしまいました。廉価版でもHD編集できるし、特にLiveTypeというタイトルを作るための機能が魅力的でした。別に何でもいいと思うなら、Macを買うと付いてくるiMovie HDやiDVD、Windowsのムービーメーカーで十分なんですが・・。
これは体験版で入れていたときのディレクトリ構成ですが、まさにAdobe一色となったアプリケーションフォルダ。
Illustrator CS3やPhotoshop CS3などをアンインストールして、すこし整理しました。Adobeに問い合わせたところ、Web PremiumからProduction Premiumへアップグレードした場合でも、Acrobat ProやDreamweaver CS3、Fireworks CS3等は「移行期間」ということで利用可能だとのこと。さて、早速昨日は一晩中さわっていたんですが、
ビデオ編集用にこういうのも買ってきました。Contour DesignのShuttle Pro2です。フレーム単位の調節をするならこういうコントローラがほしくなります。ドライバやプリセットが少し古いので、Premiere Pro CS4は直接認識しませんでしたが、少し設定をすれば使えるようになりました。ムービー編集以外でも、Apertureのプリセットなんかもあってなかなか便利です。左手側にはこのコントローラー、右手側にはペンタブのIntuos3 PTZ-930という構成で、どんどんエンジニアっぽくないデスクトップ環境になってきました。
cero_tさんのエントリ「[Tech]ストレージはSSDではなくRAMディスクにシフトしていくと思う」で、ちょっと違うかなと思ったのでコメント。
SSDがRAMディスクにシフトするという可能性は、MRAMとかFeRAMのような不揮発性RAMが主流になることを前提としてならアリかもしれませんが、その前提をおかないなら経済的な理由でナシだと思います。
DRAMはめちゃんこ電気を使います。いまやテラレベルのRAMを積めるハイエンドサーバの電気消費量の1/5〜1/3ぐらいがDRAMによる消費だとどっかでみたことがあります。特に、CPUが高周波数を目指さなくなってきたので相対的にRAMの消費電力がこれから目立つようになるはずです。最近のDRAM(FB-DIMMとか)は巨大なヒートシンクも付いてて冷却側でもエネルギーを使いそうですからね。
RDBMSの処理速度はトランザクションログのシーケンシャルな書き込みさえ高速化してやれば、データ本体は共有キャッシュによってすでにOracle/DB2らによってかなり高速化されています。最近クラウドとか言われているシステムだと、そのトランザクションログもRAM上で処理してしまうのでスループットは劇的にあがりました。最後のネックが外れたわけですね(そのかわり大事なトランザクションログが揮発的なところに載るというドキドキ感を伴いますが)。これも高速化だけの観点をもって論じれば、RDBMSはRAM上へ、と言えるでしょうけど前述の通り電気代まで考慮して成り立つかどうかはその使う人の財布の状況次第。
SSDは書き込みは一般に(HDDより)遅くて、読み込みは速い不揮発性メモリですから、WORM(Write Once, Read Many)となるようなトランザクションには向いていて、たとえば時間をかけて作って良いマスターデータのインデックスなんかには最適なストレージと言われています。でも、SSDの技術的な進歩は最近めまぐるしく、HDDよりもIOPS(毎秒あたりのI/O回数)が遙かに高いものが出たり、書き込み速度もファームウエアによる分散書き込みによってかなり高速化しているようです。
この流れからみると、HDDがSSDによってかなり置き換えられるのは間違いないでしょうね。こないだSunの出したStorage 7000シリーズのHybrid Storage Poolなんかは、そのへんのDRAM・SSD・HDDのバランスをハードウエア側でうまく吸収するので、完全移行するまでの段階、あるいは特定の用途ではこのようなハイブリッド型が生き残りそうです。
ネタもときしださんの「RDBMSの時代の終わりが見えてきた」で触れられている、ようにプログラミングのやり方が、変わりそうだ。というところには我々技術者は注目を払っておいた方がよいでしょう。SQLベースのRDBMSが完全になくなる、ということは無いでしょうけれど、かなり多くの利用シーンでGoogle(BigTables)、Amazon(SimpleDB)、Oracle(Oracle Coherence)、Microsoft(SQL Data Services)、楽天(Roma)のようなハッシュコードでアクセスするデータベースが使われていくと思います。大事なのはクラウドではなくて、環境的な変化に伴ったプログラミングパラダイムの変化。
別に大規模クラウドがなくても、CPUはマルチコア化・マルチスレッド化するから小規模なPCサイズのシステムでもクラウドみたいなアーキテクチャがそのうち作れるようになるかもしれない。そうなると、今まで高価だと思っていた処理が高価ではなくなるし、むしろ既存のやり方を守り通した方が高価になってしまう。クラウドみたいなバズワードだけ追ってると(あるいはバズワードの批判だけをしていると)こういうバランス感覚が磨けない。
高価であっても既存のやり方を踏襲するのは、そこに別の価値観（たとえば信頼性）があるわけで、COBOLは死んだとか、SQLはあと10年の寿命という固定観念を持つのは危険だと思う。もちろん自分の業種・業態と比較して、ビジネス上成立しない、っていう話ならどんどんやった方がいい。
きしださんは組み込み向けRDBMSが真っ先になくなると書いているけど、パフォーマンスの観点だけから論じるのは理論武装が足りてないと思います。組み込みだと、パフォーマンスだけじゃなくて消費電力とかプログラムサイズも大事だから、エンタープライズ用途と比べればバランスの取り方が大きく違う。組み込みには詳しくないから今後どうなるのか僕には見当が付きませんが･･･。
環境の変化に伴って「RDBMS？ナニソレ？」という世代の技術者はきっと出てくると思います。こうなるかどうかを決める大きな要素は価格だと思っています。RDBMSのほうが、ハッシュDBより高ければ、ハッシュDBを使うだろうし。これは、べつにシステムの規模とか利用企業の規模とかにあんまり関係なくシフトしていくと思っています。最初は小規模な予算の少ないプロジェクトが飛びつくでしょうけれど、金融危機などで大規模な構造改革をしなければならない状況におかれた大企業・大組織も、今まで持っていた価値観よりも価格を重視するようになると思うからです。特に目に付きやすい人件費までもがクラウドによって覆い隠されるならば、経営者にとってクラウドの方が都合が良くなるかもしれませんね。
クラウドコンピューティングは、手元にパソコン置いておくより、クラウド上においた方が安いならそれを使うでしょう。気にしておくべき点は、クラウドの利用料にはコンピュータとソフトウエアの価格と、土地代や、人件費、冷却、電気代等も含まれていることです。今まで別々に購入していたものが、専業の業者によって一括して提供されるようになります。業者からすれば、一括して調達した方が安く調達しやすいでしょうし、提供される価格もそれに反映されるでしょう。特に土地代が高くついてしまう日本のIT産業と電力会社にはこれからすこしずつ逆風が吹くかもしれません。
クラウドコンピューティングについて考えたときに、日本特有の問題として、セキュリティとか個人情報保護についての消費者からの抵抗感の程度が、サービスを提供するブランドにとって大事なんじゃないかと思います。現状、様々な報道から知る限り「自分の個人情報がどこにあるかさえ分からない」という状況に嫌悪感を感じる消費者はとても多いはずです。この嫌悪感に対しては、常に真摯に、丁寧に対応するしかないのでしょうけれど、多くの消費者から嫌悪感がなくなるためには、経済・社会全体として正常に動いている空気感が必要そうで、なかなか技術だけで解決される見通しはなさそうですね。だいぶタイトルと論点もずれてきたのでこの辺で。
1月にLeopardを買ってTigerからLeopardへアップグレード。5月にMac OS X 10.5(Leopard)からMac OS X 10.4(Tiger)へダウングレードして[blogs.sun.com]、9月にはまたLeopardに戻していましたが、やっぱりいよいよ調子が悪くなってきました。1月はアップグレードインストールだったので、それがいけないのかと思いましたが、9月は新規インストールで入れたのに調子が悪くなり、いよいよOS側の問題だということが分かりました。
ペンタブレットIntuos 3はほとんど反応しなくなるし、シャットダウンはできないし、スリープからの復帰もまともにできない。特にシャットダウンできないのにはイライラさせられます。もちろん、Terminal.appで、sudo shutdown -h nowなんてやれば電源を落とせますが、それってなんか違うような気がするんですよね。Adobe DistillerもLeopardにしてからおかしいし。そんなこともあってまたもや、Tigerに頼ることにしました。ただ、たまにはLeopardも使いたい。そこで、デュアルブートにすることを考えました。
まず、LaCieのLittle DiskのFireWireが付いてる方の外付けモバイルHDDを買ってきました。FireWireがあるので、ターゲットディスクモードでMac OS Xが起動できます(ただし、メーカーサポートはありません)。たまに使いたいLeopardはこの外付けディスクに、普段使うTigerは内蔵ディスクに入れることにしました。
あともう一つ。BootCampを使って、Windows XPを入れることにしました。WindowsのライセンスはXP Professionalとそのアップグレード版 Vista Businessを一つもっているんですが、VMware FusionやParallels、VirtualBox上で使うと、どうしてもオーバーヘッドが気になるのと、そもそもうちのMacBook Proは世代的にメモリが2GBしか詰めないので、メモリが足りなくなりがちです。そこで今回は、BootCampを使ってネイティブ起動して、快適なWindows上の開発環境を使うことにしました。まだJava SE 6 Update 10、というか、もうUpdate 11が出てたり、Update 12EAが出てたりと、世間に追いつけてないあたりを何とかしたいです。BootCampは初めて使ったので、XP SP3にするのに、BootCamp 2.1にアップデートしなければならないとは、知らずハマりました・・・。
とりあえず、これで内蔵HDD 80GBのうち、60GBがMac OS X 10.4.11(Tiger)、20GBがWindows XP SP3、外付けLaCieがMac OS X 10.5.5(Leopard)になりました。Windowsが外付けから起動できると便利なんですけどね・・・。I/Oデータのブログにあるとおり、BOOT革命のような専用ソフトを使えばできるそうですが、そこまでする気持ちにならなかったので今回は内蔵ディスクへのインストールで我慢しました。どこかのブログに書いていたと思いますが「21世紀の今になってもWindowsは外付けディスクからブートできないなんて！」というようなコメントにずいぶん共感を得てしまいました。
ところで、問題のIntuos3はインストール直後のMac OS X 10.5ではさくさく動きますが、10.5.5にアップデートしたとたんだめになったので、何かのバグなんでしょうねきっと。それともウチだけ？
リリース当時は結構さわっていましたが、今年はあまりさわっていなかったのでとりあえずインストールしました。NetBeans 6.5とプラグイン、あとProduction Suite (イラレ、フォトショ用のJavaFX書き出しプラグイン)はまた今度さわる予定です。インストールしたのはJavaFX 1.0 SDKです。コマンドラインからJavaFXアプリケーションの実行をサポートするためのコマンドとライブラリがインストールされます。
今のところJavaFX 1.0 SDKはWindowsとMac用に提供されていますが、以下Mac版の話として書いていきます。
Mac版のバイナリはdmg形式で配布されていて、開くとパッケージインストーラが利用可能になります。今回のJavaFX 1.0 SDKはSunのアプリケーションにしては珍しく、”Macらしい”アプリケーション構成になっています。インストールすると、/System/Library/Frameworks/JavaFX.framework/ というディレクトリが作成され、Mac用JDKとほぼ同様のディレクトリ構成でインストールされ、/System/Library/Frameworks/JavaFX.framework/Versions/Current/bin/javafxなどのコマンドが /usr/bin/javafxなどにシンボリックリンクされます。
インストーラの情報ではJava SE 6が実行環境として必要と出ますが、Mac版ではJDK 1.5.0_13以降 (Tigerでも実行可)が入っていればよいので、うちのMacのようにCore 2 Duo (64bit CPU)ではないのでJDK 6が使えないという悲しい環境でもJava FXは動作します。
ところで、インストーラで気になったのが使用許諾契約。
からっぽです。
どうしようもないので、同意しましょう。
