« 2009年10月 | メイン | 2009年12月 »

2009年11月 アーカイブ

2009年11月03日

JavaによるGyazoクローン「Jyazo」

GyazoクローンをJavaで作成しました。
名前はJyazoとしました。
ソースとjarファイルはGithubに公開しています。
Gyazoとの違い
Javaによる実装のため、Mac OS X,Windows,Linux問わず動作するはずですが、開発環境がMacのため他の環境は試せていません。
GyazoはMacのscreencaptureコマンドを使っているため、キャプチャの範囲を選択した後にキャプチャされますが、Jyazoは全画面をキャプチャした後に範囲を選択し、選択範囲を切り抜いています。これは、リアルタイムで処理するのは遅すぎるためです。
マルチディスプレイ環境には未対応です。プライマリディスプレイのみキャプチャするようになっています。
Gyazoが内部的に持っているIDをJyazo独自のものにしています。
IDについて
上記の通り、IDはJyazo独自のものを設定しています。
Gyazoのページには、アップロードファイルの一覧を表示する方法が書かれていますが、多分この機能にIDが使われていると思います。
しかし、これまでこの機能に気付いておらず、Jyazo独自のものを実装していました。
Jyazoの開発終盤にこの機能に気付き、Gyazoで一覧表示を試して見ました。
しかしうまく動作していないようです。
このため、現時点ではJyazo独自のIDを採用したままになっています。
実行環境
Javaのバージョンは1.6以降です。これは、Java1.6から導入されたDesktopオブジェクトを使っているためです。
Gyazoクローンを作成しようとしている方へ
Gyazoの配布パッケージ内には、Gyazoサーバのソースも含まれています。
画像送信のテストを行なうときは、自分の環境にサーバを立てて行なうようにしましょう。
私は最初これに気付かずに、変なデータをGyazoサーバに多数送ってしまいました...。
増井さん、すいませんでした。
やり残し
Windowsの実行形式であるexeファイルの作成。何故か手元の環境でMavenのlaunch4jプラグインが正常に動作しないため保留。
Mac OS Xの実行形式であるappファイルの作成。作成方法はわかっているが、毎回作成するのは面倒なためMavenプラグインで実現したい。なければ作成せざるを得ないかも。
配布パッケージの作成の自動化。Mavenのassemblyプラグインで作成しようとしても、関係のないファイルまで同梱されてしまう。
マルチディスプレイ対応。手元の環境がマルチディスプレイでないため開発できない。awtのfullscreenは個別のディスプレイに対してのみ行なうはずなので、モニタが複数あるときはキャプチャするモニタを選択後に、キャプチャ範囲を選択する仕様になるはず。

2009年11月07日

Jyazoの残作業

やり残し作業の続き
> マルチディスプレイ対応。手元の環境がマルチディスプレイでないため開発できない。awtのfullscreenは個別のディスプレイに対してのみ行なうはずなので、モニタが複数あるときはキャプチャするモニタを選択後に、キャプチャ範囲を選択する仕様になるはず。

環境がないため未対応。

> Windowsの実行形式であるexeファイルの作成。何故か手元の環境でMavenのlaunch4jプラグインが正常に動作しないため保留。

使っていたlaunch4jのMavenプラグインを別のプラグイン「org.bluestemsoftware.open.maven.plugin:launch4j-plugin」に変更したら動作した。

> Mac OS Xの実行形式であるappファイルの作成。作成方法はわかっているが、毎回作成するのは面倒なためMavenプラグインで実現したい。なければ作成せざるを得ないかも。

「org.codehaus.mojo:osxappbundle-maven-plugin」というMavanプラグインを導入した。

> 配布パッケージの作成の自動化。Mavenのassemblyプラグインで作成しようとしても、関係のないファイルまで同梱されてしまう。

assembly識別子のtypoが原因。「include」を間違えていたため、「directory」で指定していたpath配下のファイル全てを同梱していた模様。
たまたま、発見した以下のページを読んで、スキーマを追加して見て初めてわかった事だけど、pom.xmlでは識別子のtypoに警告を発するけど、assemblyでは対応しておらず、オートコンプリートも動作しない。
Eclipse で補完されなくてやきもきしてたので。冒頭の assembly 要素を以下のようにすればおkです。

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd">
新規に行なった事
Linuxのshell scriptで実行ファイルを作成した。
jyazo
#! /bin/sh

shell_script_path=${PWD}"/"${BASH_SOURCE[0]}
jar_file_path=`expr ${shell_script_path} : '\(.*/\)[^\/]*$'`Jyazo-0.0.2-SNAPSHOT.jar
java -jar ${jar_file_path}
毎回、jarファイル名を変更するのは面倒なのでなんとかしたいところ。
仮に、Mavenプラグインが見つかればそちらに移行する予定。
sedコマンドの結果が変数に代入する方法がなく、かなりハマった...。

「#!」の名前は「shebang」

Linuxでよく使うファイル先頭行の「#!」の読み方をすぐ忘れる。
「shebang」と言って、シバンやシェバンと読む。
意味を辞書で調べると、「仕掛け」や「仕組み」という意味。
「#!」と「shebang」に関連性がなさ過ぎて覚えにくいよね。
いい加減に忘れないようにしたいので、絵を書いて覚えるメソッド発動。
題名『銃声に驚く彼女』
題名『銃声に驚く彼女』
よし!
覚えた!
2009/11/09 追記
Wassr経由の情報で、shebangはjargonファイルに載っていることが判明。
また無知を曝け出してしまった...。

「入門git」を読んだ

「あなたが読んだ『入門git』は銀色のgit本ですか? それとも小豆色のGit本ですか?」
「銀色のgit本です」
というわけで、頭文字が小文字の方の『入門git』を読みました。
大文字の方の『入門Git』と発売日が一ヶ月ちょっとしか違わないので、『入門ギット買った』とつぶやかれてもどちらの本か判断つかない状況ですね。
聞いた話によると、大きい方のGit本のほうが高度な内容らしいので、一番最初に手を出すのなら小さいgit本が良いかもしれません。
大きいGit本はまだ持っていませんが、周辺の評判も良いので近々購入予定です。

CVSやSVN等の集中型のバージョン管理システム(VCS)を使っていた人達だけでなく、これまでバージョン管理システムそのものを使った事がない人にもお勧めできる内容です。
大変わかりやすく、大変読みやすく仕上がっていました。
初版の1刷にも関わらず誤植も見当たらず(少なくとも私は気付きませんでした)、非常に丁寧に作られた印象を持ちました。
自分用メモ
小さいgit本を読んで知ったgitコマンドに、自分で調べたgitコマンドの使い方を統合したメモ。
小さいgit本の第5章までに対応している。
第6章以降のコマンドもまとめたかったのだけど、それぞれのコマンドの説明が長くなり過ぎて、メモのフォーマットにあわなくなってきていたのでここで一旦中断した。
機会があれば、残りのコマンドもまとめてみたいと思う。
(このメモだけ見てもgitの本質は理解できないので注意。)
[]は任意

ページャにlvを使っている場合、色分けがされない事がある。この場合、「lv -c」を環境変数等に設定する。

環境変数

GIT_PAGER
GIT_EDITOR

===============

git help [コマンド名]                           ヘルプ
git [コマンド名] --help                         ヘルプ
git help -a                                     全コマンド一覧

git init                                        カレントディレクトリにリポジトリを作成する

git config --global user.name "[ユーザ名]"                      ユーザ名設定する
git config --global user.email "[メールアドレス]"                   メールアドレス設定する
git config --global user.editor "[エディタ]"                        エディタ設定する
git config --global color.ui "auto"                             表示色分けする
git config --global i18n.commitencoding "[文字コード]"          コミットログの文字コードを設定する
git config --global i18n.logoutputencoding "[文字コード]"       ログ表示時の文字コードを設定する
git config --global alias.[ショートカット] "[サブコマンド]"     サブコマンドにショートカットを設定する
git config --global merge.tool "[マージツール]"                 git mergetool実行時に起動するマージツールを設定する

===============

git log                                         ログを全て表示する
git log -[出力するコミット数]                       コミット数を指定してログを表示する
git log --pretty=oneline                        1コミット1行でログを表示する
git log --pretty=format:"[フォーマット指定]"        指定されたフォーマットでログを表示する
git log --since "[時間]"                        指定した時間内のログを表示する
git log --after "[時間]"                        指定した時間内のログを表示する
git log --until "[時間]"                        指定した時間以前のログを表示する
git log --before "[時間]"                       指定した時間以前のログを表示する
git log [コミット名]                                最初から指定されたコミットを含む範囲のログを表示する
git log [コミット名]..                          指定されたコミット直後から直近のコミットまでの範囲のログを表示する(末尾省略はHEAD指定と同義)
git log [開始コミット名]..[終了コミット名]          指定された開始コミット直後から終了コミットを含む範囲のログを表示する
git log HEAD -1                                 先頭のログを表示する
git log HEAD^ -1                                先頭からひとつ前のログを表示する
git log HEAD^^ -1                               先頭からふたつ前のログを表示する
git log HEAD~1 -1                               先頭からひとつ前のログを表示する
git log HEAD~2 -1                               先頭からふたつ前のログを表示する
git log HEAD~2^^ -1                             先頭からよっつ前のログを表示する
git log HEAD^^~2 -1                             先頭からよっつ前のログを表示する
git log HEAD~5..HEAD~1                          先頭からいつつ前からひとつ前までの範囲のログを表示する

フォーマット指定例 "%h %s"
時間指定は"1 seconds","2 minutes","3 hours","4 days"や"2009-09-01"等が可能。
コミット名の部分にはタグ名やHEADも使用可能な模様。
"^"や"~"による相対指定はコミット名やタグ名に対しても可能。

git status                              ステータスを表示する

git add [ファイル名]                        ステージする
git add -i                              対話モードでステージング等を選択する
git add -p                              パッチモードでステージング等を選択する

git tag                                 タグ一覧を表示する
git tag [タグ名]                        タグを付与つける
git tag [タグ名] [タグを打つ場所]           場所を指定してタグをつける

git commit                              ステージからリポジトリにコミットする
git commit -a                           作業ツリーからリポジトリに直接コミットする
git commit -v                           エディタでコミットメッセージを入力する際、差分を表示する
git commit -m "[コミットメッセージ]"        コミットメッセージを指定してコミットする

git mv "[元のパス]" "[新しいパス]"      ファイルやディレクトリを移動する(リネームにも使用可能)
git rm "[パス]"                         ファイルを削除する

===============

git diff                                                                        作業ツリーとステージングエリアの差分を表示する
git diff HEAD                                                                   作業ツリーとリポジトリの差分を表示する
git diff --cached                                                               ステージングエリアとリポジトリの差分を表示する
git diff [コミット名やタグ名やブランチ名]                                           作業ツリーと指定された場所の差分を表示する
git diff [コミット名やタグ名やブランチ名] [コミット名やタグ名やブランチ名]              指定されたふたつの場所の差分を表示する
git diff --cached [コミット名やタグ名やブランチ名]                                  ステージングエリアと指定された場所の差分を表示する
git diff --stat [コミット名やタグ名やブランチ名]                                    作業ツリーと指定された場所の差分の統計を表示する
git diff --stat [コミット名やタグ名やブランチ名] [コミット名やタグ名やブランチ名]       指定されたふたつの場所の差分の統計を表示する


git checkout [ブランチ名]                                                       チェックアウトする
git checkout -b [新しいブランチ名]                                              現在のブランチからブランチを作成しチェックアウトする
git checkout -b [新しいブランチ名] [元にするコミット名やタグ名やブランチ名]         元にする場所を指定してブランチを作成しチェックアウトする
git checkout -f [ブランチ名]                                                        作業ツリーの状態を問わず、強制的にチェックアウトする
git checkout -f [ファイル名]                                                        作業ツリーの状態を問わず、強制的にチェックアウトする

git branch [新しいブランチ名]                                                       現在のブランチからブランチを作成する
git branch [新しいブランチ名] [元にするコミット名やタグ名やブランチ名]                  元にする場所を指定してブランチを作成する
git branch -m [新しいブランチ名]                                                    現在のブランチ名を変更する 既存のブランチ名を指定しても上書きされない
git branch -m [元にするブランチ名] [新しいブランチ名]                               ブランチを指定してブランチ名を変更する
git branch -M [新しいブランチ名]                                                    現在のブランチ名を強制的に変更する
git branch -d [ブランチ名]                                                      ブランチを削除する マージの済んでいないブランチは削除できない
git branch -D [ブランチ名]                                                      ブランチを強制的に削除する


git merge [ブランチ名]              指定されたブランチへの変更を現在のブランチへマージする マージはステージングエリアに反映される
git merge --squash [ブランチ名]     指定されたブランチへの変更をひとつのコミットにまとめて現在のブランチへマージする マージはステージングエリアに反映される

git cherry-pick [コミット名]            指定されたコミットを現在のブランチへマージしコミットする
git cherry-pick -n  [コミット名]        指定されたコミットを現在のブランチへマージしステージングエリアに反映する git commitが必要 -mをつけない場合、最後にcherry-pickしたコミットのメッセージが表示される

git mergetool                       マージでコンフリクトが発生した場合に、コンフリクトを解消するためにマージツールを起動する 環境変数のmerge.toolが登録されていない場合は、環境に沿ったツールを起動する

git rebase [ブランチ名]             指定されたブランチと現在のブランチの分岐点の位置を、指定されたブランチの先端に移動する

git archive --format=[出力形式] --prefix=[ディレクトリ名etc.] [タグ名] > [出力ファイル名]               ファイルを出力する(出力形式にはzip等)
git archive --format=[出力形式] --prefix=[ディレクトリ名etc.] [タグ名] | gzip > [圧縮ファイル名]        出力したファイルを圧縮して保存(出力形式にはtar等)

git clone [リモートリポジトリ]                          リモートリポジトリから複製する
git clone [リモートリポジトリ] [複製先ディレクトリ名]       リモートリポジトリから複製先を指定して複製する

===============

対話モードでステージする
git add -i
1: [s]tatus             ステータスを表示
2: [u]pdate             ステージするファイルを選択する画面に遷移する
3: [r]evert             ステージングエリアから戻すファイルを選択する画面に遷移する
4: [a]dd untracked      新たにステージするファイルを選択する画面に遷移する
5: [p]atch              パッチモード ファイル内の変更(hunk)をするファイルを選択する画面に遷移する ファイルを選択した後にhunkを選択する画面に遷移する
6: [d]iff
7: [q]uit               対話モードを抜ける
8: [h]elp
ファイル選択では、選択されたファイルの横に*が表示される(選択時に数字の前に-をつけると取り消しが可能)
hunk選択では、hunkに対する処理を選択する
y:      変更を受け入れる
n:      変更を受け入れない
a:      以降のhunkを全て受け入れる
d:      以降のhunkを全て受け入れない
/:
e:
?:

===============

.gitignore              gitが無視するファイルを定義するファイル(定義を共有する場合)
.git/info/exclude       gitが無視するファイルを定義するファイル(ローカルリポジトリ単位)

2009年11月10日

できるだけ簡単にMacでローカルにGyazoサーバを立てる方法

「Gyazoの手軽さは便利そうだけど、パブリックな場所に公開されるのはちょっと...。」とお考えのあなた、良い方法ありますよ。
(MacOSXの基本的な操作と、ターミナルを使える人を対象とします。)
Gyazoには画像をアップロードするコードだけでなく、サーバ側のスクリプトも同梱されています。
(現行のバージョン0.3には含まれません。今回は0.2のものを使用します。)
そこでローカルにGyazoサーバを立ててみましょう。
方針は、できるだけOS標準機能を使い、ソースの修正も最小限に抑える方向となっています。
RubyのサーバであるWEBrickを使った方法は、以下のページに詳解されています。
参考にしたのは次のページ。
本来であれば、0.2に入っている「upload.cgi」を使えば良いのですが、Rubyの実装に変更があったためそのままでは動作しません。
「Digest::MD5.new(imagedata).to_s」の部分を「Digest::MD5.new.update(imagedata).to_s」に変更します。
(MacOSX 10.5の場合。これ以前のOSXでは修正が不要かもしれません。)
また、「upload.cgi」は、同一ディレクトリにファイルを保存するため、実行環境配下に画像ファイルが入ってしまいます。
これでは、画像ファイルが実行ファイルと認識されてしまうため、ブラウザから参照する事ができません。
(仕様的にcgiファイルでも受け取り実行環境に配置されてしまうため、セキュリティ的にも危険です。)
このため、画像を受け取る専用のアカウントを作成し、実行環境下でない「サイト」フォルダ(内部的にはSitesフォルダ)に保存するようにします。
さらに、ブラウザに通知する保存先URLも変更します。
GyazoはGNU GPLらしいので、上記の修正済「upload.cgi」を載せておきます。
こちらのファイルもGPLになります。
upload.cgi
#!/usr/bin/env ruby
# -*- ruby -*-
#
# $Date$
# $Rev$
#
require 'cgi'
require 'digest/md5'
require 'sdbm'

cgi = CGI.new("html3")

id = cgi.params['id'][0].read
imagedata = cgi.params['imagedata'][0].read
#hash = Digest::MD5.new(imagedata).to_s
hash = Digest::MD5.new.update(imagedata).to_s

dbm = SDBM.open('db/id',0644)
dbm[hash] = id
dbm.close

#File.open("data/#{hash}.png","w").print(imagedata)
File.open("/Users/gyazo/Sites/#{hash}.png","w").print(imagedata)

#cgi.out { "http://localhost/#{hash}.png" }
cgi.out { "http://localhost/~gyazo/#{hash}.png" }
Gyazo専用アカウントの作成
アカウントの設定で次のようなユーザを作成します。
Gyazo専用クライアントの設置
Gyazo専用クライアントの設置
Gyazoサーバの設定
上記の「upload.cgi」はホームディレクトリに保存したと仮定します。
以下、ターミナルを使って設定していきます。
% cd /Library/WebServer/CGI-Executables
% mkdir gyazo
% sudo chown _www:admin gyazo 
% sudo chmod 755 gyazo
% sudo mv ~/upload.cgi .
% sudo mkdir db
% sudo chown _www:admin upload.cgi db
% sudo chmod 755 upload.cgi db
% cd /Users/gyazo
% sudo chown _www:admin Sites
% cd Sites
% sudo rm -rf *
% sudo rm -rf .*
これで完了です。
「Web共有」を起動して下さい。
Gyazoクライアントの改造
Gyazoクライアントを改造し、画像の送信先を変更します。
そのまま改造すると通常のGyazoと区別がつかなくなりますので、コピーしてからカスタマイズを行ないます。
Gyazoの実行用パッケージは、バージョンが0.2では「gyazo.app」、0.3では「Gyazo.app」となります。
両者の中身は基本的に同じですのでどちらを使用しても構いません。
ここでは、複製したGyazoを「local_gyazo.app」とします。
「local_gyazo.app」を右クリックし、「パッケージの内容を表示」を選択して下さい。
パッケージ内の「Contents/Resouces/script」というファイルをエディタで開いて下さい。
HOST = 'gyazo.com'
CGI = '/upload.cgi'
という部分を
HOST = 'localhost'
CGI = '/cgi-bin/gyazo/upload.cgi'
に書き変えて保存します。
実行
「local_gyazo.app」を実行しキャプチャしてみましょう。
「http://localhost/~gyazo/」で始まるURLがクリップボードにコピーされ、ブラウザに画像が表示されたのであれば、ローカルGyazoサーバの設置は完了です。

2009年11月14日

Mac版Gyazoでウィンドウを綺麗にキャプチャする方法

大袈裟な話じゃなくて簡単。
・Mac版のGyazoは画面のキャプチャにコマンド「screencapture」を使っている
・「screencapture」は「Shift+Command+3」や「Shift+Command+4」で使用しているスクリーンショットと同じもの
・Gyazoでは「Shift+Command+4」と同じ「screencapture -i」を実行する
・「screencapture -i」は選択範囲のキャプチャだけではなく、選択したウィンドウのキャプチャもできる
・キャプチャの範囲選択待ちの時にスペースを押すと、ウィンドウ選択に切り替わる
つまり、Gyazoを起動してスペースを押すとウィンドウの選択になります。
ウィンドウの選択はマウスをクリックするだけ。
範囲選択に戻すには、もう一度スペースを押して下さい。
このコマンドの素晴らしいところは、影の部分もアルファチャンネルを使ってキャプチャしてくれるところです。
ウィンドウ選択によるGyazoの結果
ウィンドウ選択によるGyazoの結果
透過させているウィンドウを範囲選択でキャプチャすると背景まで写り込んでしまいますが、ウィンドウ選択でキャプチャすると写り込みません。
範囲選択による透過ウィンドウのGyazoの結果
範囲選択による透過ウィンドウのGyazoの結果
ウィンドウ選択による透過ウィンドウのGyazoの結果
ウィンドウ選択による透過ウィンドウのGyazoの結果
影は不要という方は、Gyazoのパッケージ内の「/Contents/Resources/script」というファイル内の「screencapture」に「o」オプションを追加して下さい。
(ここは敢えてわかりにくく書いています。書いてある意味がわからない場合は、変更しない方が無難です。)
影なしオプションを追加したウィンドウ選択によるGyazoの結果
影なしオプションを追加したウィンドウ選択によるGyazoの結果
Windows版やLinux版でできるかどうかは不明です。
2009/11/14 追記
Twitterで以下のようなコメントをもらった。
@kanasan キャプチャ前に,cmd->Tabしてフォーカスうつしてから <Space>クリック したほうがさらに綺麗かと! http://bit.ly/4AxzlF
ウィンドウ選択によるフォーカスのあるウィンドウのGyazoの結果
ウィンドウ選択によるフォーカスのあるウィンドウのGyazoの結果
確かに!

2009年11月21日

LeopardでJava6を標準のJavaにする

LeopardにJava6のJDKを入れても、Java系のコマンドはJava5が実行されていた。
JyazoはJava6で導入された機能を使っており、本来ならJava5の環境ではコンパイルできないのだが、Eclipseが賢いのかMavenが賢いのかわからないが、ヨロシクやってくれていた。
しかし、Mavenのプラグイン、maven-release-pluginのrelease:prepareゴールを実行する必要が出てきた。
EclipseとMavenを連携させるm2eclipseというEclipseのプラグイン上で設定できれば良いのだが、設定方法がわからない。
terminal上から実行しようとしても、バージョンがあわないので怒られる。
仕方がないので、LeopardのJava環境がJava6にならないかと調べてみた。
細かい事は省いて重要な部分だけ。
% which java
/usr/bin/java
 ls -al /usr/bin/ | grep ja
lrwxr-xr-x    1 root   wheel           73  9 12 05:58 jar@ -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/jar
lrwxr-xr-x    1 root   wheel           79  9 12 05:58 jarsigner@ -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/jarsigner
lrwxr-xr-x    1 root   wheel           74  9 12 05:58 java@ -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java
lrwxr-xr-x    1 root   wheel           75  9 12 05:58 javac@ -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javac
-r-xr-xr-x    1 root   wheel        50976  2 20  2008 javaconfig*
lrwxr-xr-x    1 root   wheel           77  9 12 05:58 javadoc@ -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javadoc
lrwxr-xr-x    1 root   wheel           75  9 12 05:58 javah@ -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javah
lrwxr-xr-x    1 root   wheel           75  9 12 05:58 javap@ -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javap
-r-xr-xr-x    1 root   wheel        72336  2 20  2008 javatool*
lrwxr-xr-x    1 root   wheel           76  9 12 05:58 javaws@ -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javaws
「/usr/bin/」直下にはjava本体はなく、「/System/Library/Frameworks/JavaVM.framework/Versions/Current/」配下のコマンドにリンクが張られていることがわかった。
% ls -al /System/Library/Frameworks/JavaVM.framework 
total 72
drwxr-xr-x   12 root  wheel   408  9 12 05:59 ./
drwxr-xr-x  107 root  wheel  3638  1  4  2008 ../
lrwxr-xr-x    1 root  wheel    27  9 12 05:58 Classes@ -> Versions/CurrentJDK/Classes
lrwxr-xr-x    1 root  wheel    24  9 12 05:59 CodeResources@ -> Versions/A/CodeResources
lrwxr-xr-x    1 root  wheel    28  9 12 05:58 Commands@ -> Versions/CurrentJDK/Commands
lrwxr-xr-x    1 root  wheel    27  9 12 05:59 Frameworks@ -> Versions/Current/Frameworks
lrwxr-xr-x    1 root  wheel    24  9 12 05:59 Headers@ -> Versions/Current/Headers
lrwxr-xr-x    1 root  wheel    24  9 12 05:58 Home@ -> Versions/CurrentJDK/Home
lrwxr-xr-x    1 root  wheel    23  9 12 05:59 JavaVM@ -> Versions/Current/JavaVM
lrwxr-xr-x    1 root  wheel    29  9 12 05:58 Libraries@ -> Versions/CurrentJDK/Libraries
lrwxr-xr-x    1 root  wheel    26  9 12 05:59 Resources@ -> Versions/Current/Resources
drwxr-xr-x   14 root  wheel   476  9 12 05:59 Versions/
「Version」配下が怪しいですな。
% ls -al /System/Library/Frameworks/JavaVM.framework/Versions 
total 56
drwxr-xr-x  14 root  wheel  476  9 12 05:59 ./
drwxr-xr-x  12 root  wheel  408  9 12 05:59 ../
lrwxr-xr-x   1 root  wheel    5  9 12 05:58 1.3@ -> 1.3.1
drwxr-xr-x   3 root  wheel  102 11  3  2007 1.3.1/
lrwxr-xr-x   1 root  wheel    5  9 12 05:59 1.4@ -> 1.4.2
lrwxr-xr-x   1 root  wheel    3  5  9  2008 1.4.1@ -> 1.4
drwxr-xr-x   8 root  wheel  272  1  3  2008 1.4.2/
lrwxr-xr-x   1 root  wheel    5  9 12 05:59 1.5@ -> 1.5.0
drwxr-xr-x   8 root  wheel  272  1  3  2008 1.5.0/
lrwxr-xr-x   1 root  wheel    5  9 12 05:59 1.6@ -> 1.6.0
drwxr-xr-x   8 root  wheel  272  5  9  2008 1.6.0/
drwxr-xr-x   8 root  wheel  272  9 12 05:59 A/
lrwxr-xr-x   1 root  wheel    1  9 12 05:59 Current@ -> A
lrwxr-xr-x   1 root  wheel    3  9 12 05:58 CurrentJDK@ -> 1.5
古いバージョンのJavaも綺麗に整理されて配置されていた。「A」ディレクトリってなんでしょうな。
% ls -al /System/Library/Frameworks/JavaVM.framework/Versions/A/
total 528
drwxr-xr-x   8 root  wheel     272  9 12 05:59 ./
drwxr-xr-x  14 root  wheel     476 11 21 21:07 ../
-rw-r--r--   1 root  wheel    1524  7 31 09:35 CodeResources
drwxr-xr-x  37 root  wheel    1258  9 12 05:58 Commands/
drwxr-xr-x   4 root  wheel     136  6 27 18:09 Frameworks/
drwxr-xr-x  16 root  wheel     544  9 12 05:59 Headers/
-rwxr-xr-x   1 root  wheel  263120  7 31 09:35 JavaVM*
drwxr-xr-x  33 root  wheel    1122  9 12 05:59 Resources/
よくわからない。
まあ、「CurrentJDK」のリンク先を変更すればなんとかなるかもしれないので試してみる。
% cd /System/Library/Frameworks/JavaVM.framework/Versions/
% sudo rm CurrentJDK
% sudo ln -s 1.6.0 CurrentJDK
で、「maven-release-plugin」を実行してみたらエラーも起きずに動作した。
問題解消。

MavenとGitHubの連携

Mavenはプロジェクトのバージョンを「x.x.x-SNAPSHOT」のように管理するのが標準のようだ。
「SNAPSHOT」は開発中を示す。
Mavenで管理しているJyazoのプロジェクトのソースをGitHubで管理しようとすると、リリース時に次のようなオペレーションになってしまう。
pom.xml内に書かれているプロジェクトのバージョンから「-SNAPSHOT」を削除
git commit -aを実行
git tagを実行
git push origin masterを実行
pom.xml内のプロジェクトのバージョンを挙げて「-SNAPSHOT」を追加
git commit -aを実行
git push origin masterを実行
面倒くさい。
なんとかならないものかと調べていると、Twitterで以下のような情報を頂いた。
@kanasan 使ったことは無いんですが maven-release-plugin で何とかできるそうです。 [たいぷぴぃ]
そこでmaven-release-pluginを調べてみた。
まず、1.「リリースタグを付ける」などのリリース前準備を行うため、次のコマンドを実行します。

C:\work\6\webdb-webapp_1_0_x> mvn release:prepare

リリースバージョン名などを聞かれますので、デフォルトのままでよければEnterキーを押します。このコマンドでは、次のような作業が行われました。

   1. コミットしていないソースコードがないかチェック
   2. SNAPSHOTバージョンのライブラリに依存していないかチェック
   3. pom.xmlのバージョン設定「1.0.0-SNAPSHOT」を「1.0.0」に変更
   4. ビルド
   5. 変更したpom.xmlをバージョン管理(Subversion)にコミット
   6. バージョン管理へのリリースタグ付け(webdbwebpp-1.0.0)
   7. pom.xmlのバージョン設定を、次の開発バージョン「1.0.1-SNAPSHOT」に変更
   8. 変更したpom.xmlをバージョン管理(Subversion)にコミット
なるほど。これは良い。
しかし、Subversionとの連携については色々見つかったが、gitやGitHubとの連携については探しきれなかった。
検索範囲を日本語以外に広げて探していたら次のようなページが見つかった。
長文で最初は怖じ気づいたが、良く見ると書いていることはそんなに難しい内容ではないようだ。
gitのインストールやGitHubのアカウント取得方法とSSHのキーの登録、Mavenのインストールやpom.xmlの作成やGitHubでのレポジトリの作成等、非常に丁寧に細かく書いている様子。
で、Step 9.にMavenとGitHubを連携するための設定と思しき記述を発見。
これをもとに、手元のプロジェクトのpom.xmlに以下の設定を追記した。
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<!--略-->
  <scm>
    <connection>scm:git:git@github.com:Kanasansoft/Jyazo.git</connection>
    <url>scm:git:git@github.com:Kanasansoft/Jyazo.git</url>
    <developerConnection>scm:git:git@github.com:Kanasansoft/Jyazo.git</developerConnection> 
  </scm>
<!--略-->
  <build>
<!--略-->
    <plugins>
<!--略-->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-release-plugin</artifactId>
        <version>2.0-beta-9</version>
      </plugin>
<!--略-->
    </plugins>
<!--略-->
  </build>
<!--略-->
</project>
前のエントリーの通り、Eclipse上で実行する方法がわからなかったので、プロジェクト配下(同時にgit管理かでもある)で、以下のコマンドを実行した。
% mvn release:prepare
[INFO] Scanning for projects...
(略)
そうすると、途中で次のように聞かれる。
What is the release version for "Jyazo"? (com.kanasansoft.Jyazo:Jyazo) 0.0.3: : 
What is SCM release tag or label for "Jyazo"? (com.kanasansoft.Jyazo:Jyazo) Jyazo-0.0.3: : 
What is the new development version for "Jyazo"? (com.kanasansoft.Jyazo:Jyazo) 0.0.4-SNAPSHOT: : 
つまり、(1)「今からコミットするプロジェクトのバージョンの指定」、(2)「コミットにつけるタグの名前」、(3)「コミットした後にプロジェクトにつけるのバージョンの指定」。
ここまでのバージョンは「0.0.3-SNAPSHOT」だったため、(1)には「0.0.3」を指定した。
入力しなくても既定と同じだったのでそのままEnter。
(2)は余り考えずにそのまま既定値。
(3)も勝手にバージョンを挙げて「-SNAPSHOT」をつけたものが既定だったためそのまま。
たったこれだけで、最初に「面倒くさい。」と言っていた作業を全部やってくれた。
ちょっと感動して興奮した。
maven-release-pluginが直接GitHubにpushしに行っているようなので、一人で開発していたとしてもローカルリポジトリのソースは古くなっている点に注意。
後は、「Jyazo-0.0.3」タグのついているやつをpullしてパッケージ化してGitHubのDownloadのところにアップするも良し、「0.0.4-SNAPSHOT」をpullして開発を続けるも良し。
pullの仕方を忘れたので、銀のgit本見てくる。
関連するエントリー
2009/11/22 追記
考えてみたら、ローカルリポジトリと同期すればローカルは常に最新状態かも...。
でも、ローカルでつけられたタグはGitHubとどうやって同期するのかわからない...。
2009/11/22 追記2
「mvn release:prepare」を実行した後は「mvn release:perform」を実行して、パッケージ化したファイルを公開サーバに転送するらしい。
ところがJyazoは公開サーバを持っておらず、GitHub上でやりくりしようと思っていたので、pom.xmlには「distributionManagement」が存在しない。
このような場合、「mvn release:perform」は実行途中でエラーとなる。
「mvn release:perform」が正常に行なわれなかった場合、次の「mvn release:prepare」は何もしてくれない。
メッセージには「Release preparation already completed. You can now continue with release:perform, or start again using the -Dresume=false flag」と書かれていた。
「release:perform」を実行するか「-Dresume=false flag」をつけて実行し直すからしい。
そこで、「mvn release:prepare -Dresume=false」と実行してみたところ、GitHubと連携した。
(ローカルにも「SNAPSHOTのないバージョンのパッケージ」が生成されている。)
これは気付かないとちょっとはまりそうだ。

2009年11月27日

Jyazo 0.0.6 プロキシとマルチポストに対応したGyazoクローン

最新版のJyazoを公開しました。
マルチディスプレイには未対応なのですが、既存の動作とどう折り合いをつけようか悩んでおり、しばらく結論が出そうにないので現状で公開します。
公開後しばらく様子をみて、大きな問題がなければバージョンを0.1.0にあげようかと思っています。
以下、0.0.6のREADMEです。
README.txt for v0.0.6
Jyazo is licensed under the GPL.

Sorry. This file is only written in Japanese.


========================================
Jyazo
----------------------------------------

JyazoはJavaで実装されたGyazoのクローンです。
Windows, Mac OS X, Linux問わず実行できるはずです。


========================================
そもそもGyazoとは
----------------------------------------

画面のキャプチャ画像を簡単に公開・共有するサービスです。
詳細な情報は以下のURLを参照ください。
http://gyazo.com/


========================================
実行ファイル
----------------------------------------

各OS向けの実行ファイルを同梱しています。
「x.x.x」はバージョンを示します。

Windows用実行ファイル
Jyazo-x.x.x.exe
Mac OS X用実行ファイル
Jyazo-x.x.x.dmg内のJyazo.app
Linux用実行ファイル
Jyazo-x.x.x.jar

Linuxの場合、以下のようなシェルスクリプトを
jarファイルと同じディレクトリに保存し実行権限を追加しておくと
こちらのファイルから起動できるはずです。
(バージョン番号は適時書き変えて下さい。)

#! /bin/sh

shell_script_path=${PWD}"/"${BASH_SOURCE[0]}
jar_file_path=`expr ${shell_script_path} : '\(.*/\)[^\/]*$'`Jyazo-x.x.x.jar
java -jar ${jar_file_path}


========================================
Javaランタイム
----------------------------------------

JRE6(Java1.6)以上が必須環境となります。


========================================
Proxyサーバ対応
----------------------------------------

Proxyサーバに対応しています。
但し、Proxy認証には対応していません。
Proxyサーバの設定方法は、「設定ファイルの記述方法」を参照して下さい。


========================================
マルチポスト対応
----------------------------------------

キャプチャした画像を複数のGyazoサーバに同時に送信可能です。
また、マルチポストの送信先を簡単に切り換える事が可能です。
マルチポストの設定方法は、「設定ファイルの記述方法」を参照して下さい。


========================================
設定ファイル
----------------------------------------

初回のJyazoの実行時に、ユーザのホームに
「.jyazo」 ディレクトリ(フォルダ)が作成されます。
「.jyazo」ディレクトリ配下にある「setting.properties」が設定ファイルになります。
同ディレクトリに設定ファイルのサンプル「setting-sample.properties」が
ありますので、マルチポスト機能の設定がそちらを参考にして下さい。
「.jyazo」ディレクトリを削除し、再度Jyazoを実行すると、
「.jyazo」ディレクトリが再生成されます。


========================================
ローカルGyazoサーバの構築方法
----------------------------------------

以下のURLに記事を書きました。
http://www.kanasansoft.com/weblab/2009/11/local_gyazo_server.html
ローカルGyazoサーバの構築方法はこれだけではありませんが、
参考になれば幸いです。


========================================
キャプチャ機能について
----------------------------------------

現バージョンではマルチディスプレイ環境には対応していません。
キャプチャの対象はプライマリモニタだけになります。
GyazoではOS標準のキャプチャ機能を使用していますが、Jyazoではキャプチャ機能も作り込んでいます。
Jyazoを実行した直後に取得したキャプチャ画像を使い回しています。
これは、画面をキャプチャしながら選択範囲をリアルタイムで描画すると処理が遅すぎるためです。


========================================
IDについて
----------------------------------------

Gyazoで使用しているユーザ(もしくは端末)を識別するために使用しているIDは、
時間(最小単位が秒)を元に算出しているため、
Jyazoではナノ秒まで取得しIDを作成しています。
但し、時間解像度はそこまで高くないため、末尾には0が並びます。
また、IDの最後に「_by_Jyazo」を付加しています。


========================================
開発者の方へ
----------------------------------------

ソースファイルは、GitHubに公開してます。
http://github.com/Kanasansoft/Jyazo

ライセンスは、Gyazoと同様にGPLを採用しています。

JyazoはJava初心者が作成しています。
コード内に稚拙な部分があるかと思います。
改善点がありましたらどうぞご指摘ください。

Apache Mavenのバージョン2系を利用しています。
pom.xmlも同梱していますので、
利用しているプラグイン等が一度に取得可能です。

Jyazoの実装はJava6の標準ライブラリのみで行なっており、
サードパーティ製のライブラリは使用していません。
ただし、コンパイルやパッケージングは、
Maven2を通してサードパーティ製のライブラリを
利用しています。


========================================
設定ファイルの記述方法
----------------------------------------

初回実行直後の設定ファイルは、
Gyazoと同じ動作になるように記述されています。
設定ファイルを書き変える事により
Proxyサーバ対応、マルチポストが可能となります。

設定ファイルの記述方法は、
JavaのPropertiesファイルと同様です。

一度のJyazo実行で複数のGyazoサーバにマルチポストする設定のことを
JyazoではPostSetと読んでいます。
PostSetを複数準備すると、キーボードからPostSetを選択できるようになります。
例えば、自端末にGyazoサーバをlocalhostとし、Gyazoの公式サーバをpublicとします。

一番目のPostSet
publicにのみ画像をポスト
二番目のPostSet
localhostのみに画像をポスト
三番目のPostSet
publicとlocalhostに画像をマルチポスト

設定ファイルには、サーバの設定、PostSetの設定、
更に使用するサーバをJyazoに通知するための設定と
使用するPostSetをJyazoに通知するための設定があります。
また、Jyazo起動時に、PostSetを判別し易いように、
見た目を変更する設定もあります。

以下、設定ファイルを記述していきます。
完成版はユーザのホーム配下の「~/.jyazo/setting-sample.properties」に
出力されています。

まず、サーバの設定を行ないます。

post_sets.server.[サーバID].url=[GyazoサーバのURL]
post_sets.server.[サーバID].use_proxy=[Proxy使用の有無]
post_sets.server.[サーバID].proxy_host=[ProxyサーバのURL]
post_sets.server.[サーバID].proxy_port=[ProxyサーバのPort]

公式のGyazoサーバのIDをpublicとすると以下のような記述になります。
Proxyサーバ「192.168.0.100:8080」を使用することを想定しています。
(Propertiesファイルでは「:」のエスケープが必要な点に注意してください。)

post_sets.server.public.url=http\://gyazo.com/upload.cgi
post_sets.server.public.use_proxy=yes
post_sets.server.public.proxy_host=192.168.0.100
post_sets.server.public.proxy_port=8080

同様に、時端末に構築したローカルGyazoサーバの設定をします。
ローカルGyazoサーバのIDは「localhost」とします。
自端末のため、Proxyサーバは使用しません。

post_sets.server.localhost.url=http\://localhost/cgi-bin/gyazo/upload.cgi
post_sets.server.localhost.use_proxy=no
post_sets.server.localhost.proxy_host=192.168.0.100
post_sets.server.localhost.proxy_port=8080

これでふたつのサーバ、publicとlocalhostの設定が終わりました。

それでは、PostSetを3つ作成していきます。

post_sets.post_set.[PostSetID].name=[PostSet名(キャプチャ時に画面に表示)]
post_sets.post_set.[PostSetID].text_size=[PostSet名表示の文字サイズ]
post_sets.post_set.[PostSetID].text_color=[PostSet名表示の文字色]
post_sets.post_set.[PostSetID].select_area_color=[キャプチャ時の選択範囲矩形の色]
post_sets.post_set.[PostSetID].unselect_area_color=[キャプチャ時の選択範囲外の色]
post_sets.post_set.[PostSetID].server_ids=[ポストするサーバID(スペース区切りで複数指定可能)]

まず、公式GyazoサーバのみにポストするPostSetを設定します。
PostSetのIDをpublic_onlyとしました。
色の指定は、「アルファ値・赤・緑・青」各16進法2桁の計8文字となります。
キャプチャ中にデスクトップが見にくくなるため、アルファ値は低めに設定して下さい。

post_sets.post_set.public_only.name=Public Only
post_sets.post_set.public_only.text_size=96
post_sets.post_set.public_only.text_color=33ff0000
post_sets.post_set.public_only.select_area_color=33ff6666
post_sets.post_set.public_only.unselect_area_color=33ff9999
post_sets.post_set.public_only.server_ids=public

同様に、ローカルGyazoサーバのみにポストするPostSetの設定です。
IDはlocalhost_onlyとしました。
ここでは、文字サイズと各種色指定を省略しています。
省略された場合、既定として設定された値(後述)が使用されます。

post_sets.post_set.localhost_only.name=Localhost Only
post_sets.post_set.localhost_only.server_ids=localhost

次に、公式とローカルのGyazoサーバにマルチポストするPostSetの設定です。
PostSetのIDはpublic_and_localhostです。
複数のサーバにポストするために、server_idsにサーバIDをスペース区切りで複数指定しています。

post_sets.post_set.public_and_localhost.name=Public and Localhost
post_sets.post_set.public_and_localhost.text_size=96
post_sets.post_set.public_and_localhost.text_color=330000ff
post_sets.post_set.public_and_localhost.select_area_color=336666ff
post_sets.post_set.public_and_localhost.unselect_area_color=339999ff
post_sets.post_set.public_and_localhost.server_ids=public localhost

ここまでで、サーバとPostSetの設定が完了しました。
使用するサーバとポストセットをJyazoに通知するために以下の行を追加します。

post_sets.post_set_ids=[使用するするPostSetID(スペース区切りで複数指定可能)]
post_sets.server_ids=[使用するサーバID(スペース区切りで複数指定可能)]

ここまでの設定を通知する場合は次のようになります。

post_sets.post_set_ids=public_only localhost_only public_and_localhost
post_sets.server_ids=public localhost

ここまででマルチポストの設定は完了です。
PostSetを切り換えるには、
Jyazo起動後の範囲選択待ちの画面でキーボードの数字キーを使用します。
Jyazoに通知した順に、「1」キーから割り当てられていきます。
PostSetは最大10つ設定でき、10番目のPostSetは「0」キーに割り当てられます。

最後に、PostSetで文字サイズや色を指定しなかった場合に使用される既定の値を設定します。

post_sets.text_size=[PostSet名表示の文字サイズ]
post_sets.text_color=[PostSet名表示の文字色]
post_sets.select_area_color=[キャプチャ時の選択範囲矩形の色]
post_sets.unselect_area_color=[キャプチャ時の選択範囲外の色]

ここでは以下の用に設定しました。

post_sets.text_size=96
post_sets.text_color=3300ff00
post_sets.select_area_color=3366ff66
post_sets.unselect_area_color=3399ff99

以上が設定ファイルの記述方法となります。
ここで作成した設定ファイルと同一の設定をもつサンプルファイルが、
Jyazoの初回起動時に
「~/.jyazo/setting-sample.properties」に出力されています。

2009年11月29日

TokyuRuby会議01(TokyoRuby会議02)に行ってきました

参加者に抽選でLTの発表枠があたるという地獄のような(嘘)TokyuRuby会議01に行ってきました。
スライドも準備して練習して、いつ抽選に当たっても良いようにしていました。
会場説明を含む、全ての発表がLT形式で行なわれ、銘打ってはいなかったと思うのですが実質LT大会でした。
発表も難易度が高めのものや領域の範囲が狭いものが多いという印象です。
自分のスキルよりも難易度が高い場合、できるだけ多くのキーワードを覚えておいて、後から調べるメソッド発動。
で、自分のLTですが、見事にはずれたのですが、予定よりも進行が早く、希望者全員に発表の機会が与えられたので、立候補してきました。
結果、惨敗。
3分枠の中で、1分をデモに使おうと考えてたので、2分で終わる予定だったのですが、スライドの途中で「残り20秒」と言われ焦ってデモ。
Rubyで作られたGyazoをローカルに立てた時の、公式Gyazoとはまた違った便利さと、その問題点、それらの解決策の自分の回答としてJyazoを紹介し、デモを通じてそれを説明するつもりだったのですが、本題に入る前に時間切れ。
重要な事をほとんど話せずに終わってしまいました。
3度目のLTで油断していたのと、Gyazoの知名度を見誤っていたため、サラッと終わらせるつもりのスライドに説明を割いてしまったのが敗因か...。
発表に使ったスライドをアップしておきますが、デモが重要だったのでスライドを見てもあまり意味がないかも...。

2009年11月30日

Keynoteで文字が光っているようにする方法

自分が作ったスライドで、ハローのように文字が光っているように見える効果がある。
このやり方を聞かれたので細かく説明してみる。
Keynoteには文字やオブジェクトを光らせるような効果はない。
じゃあ、どうやっているのかと言えば実は単純で、影を使っている。
影の色を選択できるアプリケーションであれば、この方法は使えるはず。
Keynoteでこれをやる場合のコツは、文字を太くしておくこと。
Keynoteの影の総量は、対象となるオブジェクトの面積に依存するようなので、細い文字を光らせてもあまり見栄えがよくない。
普段、自分が使っているのはヒラギノ系の中では一番太い「ヒラギノ角ゴ StdN」というフォント。
これに「オフセット 0px/ぼかし 100px/不透明度 100%」の影を設定する。
どうしても細いもの、例えば矢印などにこの効果を適応したい場合は、ぼかしを少なめにしておくとなんとかなる場合もあるが、うまくいくかどうかはケースバイケース。
使用している色もちょっと工夫している。
まず、よく使われる色の中でも、青はまわりの黒と同化してしまって目立たない。色を明るくして水色にするとちょっと安っぽくなったと感じた。
このため青系統の色は使用していない。
残りの色も少し弄っていて、黄色は強過ぎて文字が見えにくいので少しくすんだ感じに、黄色をくすませたことで赤の原色よりの発光が気になったためマゼンダよりにしている。
そもそもこの配色は、Ruby@関西で見た角谷さんのスライドの文字色に影響を受けていたりするのは内緒の話。
自分は使っていないが、応用例として次のようなものがある。
また、更に応用例としてこんな方法も。
文字そのものを光らせた場合と、文字が入っているオブジェクトを光らせた場合では発色がちがう。
そして両方を適応すると強く発光しているようにみえる。
この場合、オブジェクトに含まれる文字は全て発光してしまうが、一部の文字に重ねて適応し発光の強さの違いを利用したのがこれ。
文字のサイズをばらつかせると更に効果的になる。
以上。
Google

タグ クラウド