OS X 10.9が出たので早速インストールしてJKaiUI Customとkaiengine、jRenamerの動作を確認してみました。
結論から言うとどれも問題なく動作しました。
JKaiUIとjRenamerはもともとjavaで書かれた物なので問題ないと推測していましたが、問題はkaiengineでした。
ちなみに実際に接続して遊んでみた結果、以前と同様に遊べたことから問題ないと判断しました。
JKaiUI改良版 配布中
JKaiUI改良版をファイル置き場にて配布中です。
最新版はここから落とせます。追加機能の使い方の説明は落としたファイルのReadMeファイルを参照してください。
オリジナルのJKaiUIの使い方、Mac上でのXLink kaiの情報はMac de Kaiを参照してください。
JKaiUI改良版はまだ開発版です。オリジナルからそう多く変更していないので大丈夫だともいますが、ご利用は自己責任でお願いします。
2013年11月9日土曜日
2013年10月19日土曜日
コンピュータへの雷対策
最近、雷がすごい近くに落ちてヒヤヒヤしたので対策について調査してみた。
まず一般的なことをwikiにて調査。
・雷サージ
・サージ防護機器
2つを見ると、本格的な対策には避雷針、避雷器などが必要なようです。
日本では個人宅ではまず無いようです。
賃貸なら対策してあるのを選ぶのが一番いいかと思います。
高さ20m以上なら法律上必要とからしいです。
さて、本格的な対策が無理な場合を考えます。
まず一般的なことをwikiにて調査。
・雷サージ
・サージ防護機器
2つを見ると、本格的な対策には避雷針、避雷器などが必要なようです。
日本では個人宅ではまず無いようです。
賃貸なら対策してあるのを選ぶのが一番いいかと思います。
高さ20m以上なら法律上必要とからしいです。
さて、本格的な対策が無理な場合を考えます。
- 物理的な対策
- 雷の気配がしたらコンセントから機器を抜く
- 抜いているときに雷が落ちると感電死する可能性があります。
- LANを可能な限り無線にする(LANからのダメージを防ぐ)
- 802.11acなら結構速い
- 雷サージ対策のテーブルタップを利用する
- 気休め程度と考えた方がいい
- モバイルPCを利用
- 雷の気配がしたらコンセントから分離
- ソフトウェア的な対策
- バックアップを作成しておく
- HDDなどにバックアップを保存し、電源から切り離しておいておく
- 外部のバックアップサービスを利用する
- Dropboxなどを利用するのが一番簡単かも
- その他
- 保険に入る
2013年10月12日土曜日
2013年10月5日土曜日
javaアプリをMac OS XのApp形式にする
JAVAアプリをMac OS X用にApplication Bundle化する
上が参考になります。
Java 6ではJarBundlerをJava 7以降ではAppBundlerを用いれば楽なようです。
上が参考になります。
Java 6ではJarBundlerをJava 7以降ではAppBundlerを用いれば楽なようです。
2013年9月28日土曜日
jRenamerを公開しました。
jRenamer ver.0.1.0alphaを公開しました。
ファイル置き場においてあります。
jRenamerは名前の通りにリネームするソフトウェアです。
大量にあるファイルからある程度法則性のある名前をリネームする用途で作成されています。
jRenamerはJava 6以降で動作します。
また、本ソフトウェアはフリーウェアです。
現状、アルファ版のためバックアップをとるなど注意して利用してください。
使い方等はReadMeまたは起動後のメニューから見てください。
ファイル置き場においてあります。
jRenamerは名前の通りにリネームするソフトウェアです。
大量にあるファイルからある程度法則性のある名前をリネームする用途で作成されています。
jRenamerはJava 6以降で動作します。
また、本ソフトウェアはフリーウェアです。
現状、アルファ版のためバックアップをとるなど注意して利用してください。
使い方等はReadMeまたは起動後のメニューから見てください。
2013年9月21日土曜日
2013年9月14日土曜日
lombok(javaライブラリ)の紹介
Javaでコードを書くのがだるすぎたけどLombok使ったら思いのほか楽しかった
を読んでみたところ便利そうだったので紹介します。
lombokはIDEなどで自動生成できるようなコードをコンパイル時に自動生成するようにすることでコード量を減らすのが目的のライブラリのようである。
具体的には以下のようなことができる。
他にもいくつかあるのが興味があればここを参考にしてください。
使い方はここが参考になります。
どうやってるのか少し興味がありjavassistとかを使ってるのかと思いソースを調べてみました。
ただ単純にAnnotation Processorで実現しているようである。
を読んでみたところ便利そうだったので紹介します。
lombokはIDEなどで自動生成できるようなコードをコンパイル時に自動生成するようにすることでコード量を減らすのが目的のライブラリのようである。
具体的には以下のようなことができる。
- C#, Objective-C のようなプロパティ(Getter, Setter)
- toString, equals, hashCodeメソッドの自動生成
- コンストラクタの自動生成
- Scalaのようなval変数(型指定のいらない定数)
- 委譲するメソッドを自動生成
他にもいくつかあるのが興味があればここを参考にしてください。
使い方はここが参考になります。
どうやってるのか少し興味がありjavassistとかを使ってるのかと思いソースを調べてみました。
ただ単純にAnnotation Processorで実現しているようである。
2013年9月7日土曜日
2013年8月31日土曜日
迷惑メール対策
メールを利用していればたいてい迷惑メールを受信したことがあると思う。
迷惑メールはかなり面倒な存在である。
これらの対策にはいろいろな方法が存在し、いろいろ提供されている。
プロバイダで提供しているもの、クライアントソフトで提供しているものなどがある。
今回は私が利用しているメーラーThunderbirdでの方法を説明する。
Thunderbirdを前提にした説明になるが他の環境でも応用は可能である。
タグ付けの後にフォルダ振り分けを行う。
以下はその一例である。
この方法では、迷惑メールではないものを迷惑メールと判定してしまう場合がどうしても発生する。
そのような場合がなるべくなくなるような方法を考案している。
また、スマホなどでフォルダ分けした場合に受信ボックス以外を見れないなどの弊害をなくすことも考慮している。
この方法では欠点もある。
1つ目は設定が煩雑であること。
自分が送受信するメールのアドレスをある程度把握している必要がある。
また、送受信するアドレスが変化した場合にフィルタのメンテナンスが必要であること。
2つ目はフィルタリングが多段になるために処理が時間がかかること。
以上のような利点と欠点を持っているが、個人的にはかなり便利になった。
迷惑メールで困っている方の参考になれば幸いです。
迷惑メールはかなり面倒な存在である。
これらの対策にはいろいろな方法が存在し、いろいろ提供されている。
プロバイダで提供しているもの、クライアントソフトで提供しているものなどがある。
今回は私が利用しているメーラーThunderbirdでの方法を説明する。
Thunderbirdを前提にした説明になるが他の環境でも応用は可能である。
対象環境
- IMAP
- Thunderbird
方針
- 受信ボックス一カ所だけだけ見れば新着がすべて見れるようにする。
- 新着は受信ボックスのみ見ればよく手間が減る。
- スマホなどで利用するとき受信ボックスがアクセスしやすいものを考慮している。
- 例:iphone標準の「メール」
- 受信時に自動的にメールにタグをつける。
- フォルダ分けされていなくてもタグにて色分けさせメールの見分けがつけやすくする。
- 利用者は受信ボックスを見てタグ付けが問題なければタグに基づいてフォルダ振り分けを行う。
- 受信ボックスの件数を減らし、可読性をよくする。
方法
説明用の環境例としてgmailを用いる。- サーバー側での自動的なフィルタリング(迷惑メールフィルタも含む)は行わない。
- gmailではデフォルトで迷惑メールフィルタが動作するのでこれをオフにする。
- webブラウザでgmailにアクセスし、from欄に「*」を入力したフィルタを作成する。
- クライアント側で受信時に各メールにタグをつける。
- Thunderbiradのメッセージフィルタを利用する。
- フィルタを適用するタイミングを「メールチェック時と手動実行」にする。
- フィルタの設定は後述する。
- ユーザーは後にタグに基づいてメールをフォルダに振り分ける(フィルタリングルールを作って自動で行う)。
- Thunderbiradのメッセージフィルタを利用する。
- フィルタを適用するタイミングを「手動実行」にする。
- フィルタの設定は後述する。
メッセージフィルタルール
メッセージフィルタを用いてタグ付けとフォルダ振り分けを行う。タグ付けの後にフォルダ振り分けを行う。
以下はその一例である。
- タグ付けルール
- 信頼できるアドレス(完全一致)
- 例:差出人がアドレス帳にある
- ある程度信頼できるアドレス(ドメインなどでタグ付け)
- 通販サイトや企業、学校などからのメールを想定
- 例:差出人が次で終わる@apple.com
- 例:差出人または宛先、CC、BCCに次を含む
- メーリングリストなどでは件名に規則的なものがつかわれているばあいがある。
- 例:件名に次を含む
- 迷惑メール1
- 基本的にドメインを見て判定します。
- 例:差出人が次で終わる .mobi
- 末尾がcom, co.jp, jp, ac.jpなど決まったところ以外はだいたい迷惑メールの傾向がある
- orgなど他にもあるので自分のやりとりするアドレスの傾向を見て決める。
- 例:差出人が次で終わる @docomo.ne.jp
- 携帯からのメールは知り合いのアドレスを登録しておいて引っかからないようにする。
- PCメールに携帯メールは知り合い以外からはそこまで送られてこないと仮定している
- 迷惑メール2
- 自分宛ではないメール
- 自分のアドレスが差出人、CC、BCCにない場合は迷惑メールとする。
- タグがない場合以外ではタグをつけない。
- メーリングリストなどでは自分のアドレスが含まれない場合があるため。
- 他のフィルタでタグ付けされるように設定する。
- 例:
- 条件1:差出人または宛先、CC、BCCに次を含まない 自分のアドレス
- 条件2:タグが空
- フォルダ振り分けルール
- タグに基づいてフォルダ振り分けを行う
- 例:タグに次を含む
まとめ
迷惑メールフィルタでは基本的にメールの中身を見て過去のメールと似たものを迷惑メールと判定している。この方法では、迷惑メールではないものを迷惑メールと判定してしまう場合がどうしても発生する。
そのような場合がなるべくなくなるような方法を考案している。
また、スマホなどでフォルダ分けした場合に受信ボックス以外を見れないなどの弊害をなくすことも考慮している。
この方法では欠点もある。
1つ目は設定が煩雑であること。
自分が送受信するメールのアドレスをある程度把握している必要がある。
また、送受信するアドレスが変化した場合にフィルタのメンテナンスが必要であること。
2つ目はフィルタリングが多段になるために処理が時間がかかること。
以上のような利点と欠点を持っているが、個人的にはかなり便利になった。
迷惑メールで困っている方の参考になれば幸いです。
2013年8月24日土曜日
Javaコーディング規約
ここのがすごい参考になりました。
http://www.acroquest.co.jp/webworkshop/javacordingrule/javacordingrule.html
http://www.acroquest.co.jp/webworkshop/javacordingrule/javacordingrule.html
2013年8月17日土曜日
gmailに他のメールアドレスを統合
gmailで他のメールを受信するようにすることでメールアカウントを統合できます。
やり方は以下を参照。
https://support.google.com/mail/answer/21289?rd=1
gmailでの受信はpop3に対応している必要があります。
統合するとGmailを介しているだけ受信が遅くなります。
また、Webからアクセスしている場合からなら受信アドレスにあわせて送信アドレスを変更できます(設定が必要)。
しかし、メールクライアントソフトウェアを利用している場合はそれができない場合があります(Thunderbiardにて確認)。
1つの(無料)gmailアカウントで受信できるpop3アカウントの制限は5つです。
ただし、多段にすることで簡単にその制限をなくせます。
例:
例では合計8つのアカウントを統合しています。
黒丸が統合先アカウント、白丸がgmail#1で受信するアカウント、黒四角がgmail#2で受信するアカウントになります。
この方法の問題点は段の低い方(例では黒四角)がより受信に時間がかかるということです。
なので、低い段には重要度が低いアドレスをおくといいです。
やり方は以下を参照。
https://support.google.com/mail/answer/21289?rd=1
gmailでの受信はpop3に対応している必要があります。
統合するとGmailを介しているだけ受信が遅くなります。
また、Webからアクセスしている場合からなら受信アドレスにあわせて送信アドレスを変更できます(設定が必要)。
しかし、メールクライアントソフトウェアを利用している場合はそれができない場合があります(Thunderbiardにて確認)。
1つの(無料)gmailアカウントで受信できるpop3アカウントの制限は5つです。
ただし、多段にすることで簡単にその制限をなくせます。
例:
- gmail#1
- gmail#2
- yahoo#3
- yahoo#4
- yahoo#1
- yahoo#2
- hotmail#1
- icloud#1
例では合計8つのアカウントを統合しています。
黒丸が統合先アカウント、白丸がgmail#1で受信するアカウント、黒四角がgmail#2で受信するアカウントになります。
この方法の問題点は段の低い方(例では黒四角)がより受信に時間がかかるということです。
なので、低い段には重要度が低いアドレスをおくといいです。
2013年8月10日土曜日
吉里吉里 KAGでのfor, foreachマクロ
吉里吉里のKAGには繰り返しがありません。
そこでマクロを作ってみました。
そこそこうまくできたのですが、不満点というか欠点として繰り返し処理(for文の中身)を一連の流れの外に書く必要があります。
もっと使いやすくしたのですが現状ではここまでが限界でした。
もっといいのがある。もっと良くできる。など意見があれば連絡ください。
次に、作成したマクロの使用例をいくつか書きます。
最後にマクロの中身です。
for文1
上の例と同じく0から9を表示します。
tf.iを増やしながら*doのラベルの処理を行います。
tf.iの初期値は0です。
for文2
こちらは2から9を表示します。
startでtf.iの初期値を指定できます。
foreach文1
foreach文の例です。
この例では配列内の数値が順番に表示されます。
listに配列もしくは配列の入った変数名を指定できます
tf.elemが各要素になります。
foreach文2
scenarioフォルダ内のファイルを表示する例です。
foreach文3
bgmフォルダ内のファイル一覧から再生リストを作成する例です。
listを指定しない場合はtf.listが操作される配列になります。
そうすることでtf.listとtf.iでtf.elemのかわりをすることができます。
tf.elemで書くと面倒な場合などで利用できます。
この場合、tf.elemにそのまま置き換えるとファイル名が変数名と判断されるためにエラーになるためにこのようにしています。
(tf.elemでもエスケープシーケンスを使って文字列扱いにすれば解決できます。)
foreach文4
tf.list以外を利用したときはlistに変数名を指定します
まず、[eval exp="mp.val=Scripts.eval(mp.list)"]の行です。
KAGのマクロでは引数は文字列で渡されるようです。
そこでScripts.eval()で変数名から中身の配列への参照を得ています。
次に[call target="&mp.func"]の行です。
func引数に指定された文字列のラベルにジャンプします。
ジャンプ先の最後のreturnタグで戻ってくることを想定しています。
またKAGにおいてマクロは呼び出し元のコンテキストで実行されるようです。
すなわち、storage引数が呼び出しもとファイルと同じ物となります(forマクロと呼び出し元は異なるファイルと仮定)。
そのため、このコードでは呼び出し元と同じファイル中のラベルをfunc引数に指定する必要があります。
違うファイルのラベルを呼べるようにするにはstorage引数を追加するだけでおそらく可能です。
そこでマクロを作ってみました。
そこそこうまくできたのですが、不満点というか欠点として繰り返し処理(for文の中身)を一連の流れの外に書く必要があります。
もっと使いやすくしたのですが現状ではここまでが限界でした。
もっといいのがある。もっと良くできる。など意見があれば連絡ください。
マクロの説明
最初に通常KAGで私が書くときの書き方を次に、作成したマクロの使用例をいくつか書きます。
最後にマクロの中身です。
KAGでのfor文
0から9を表示するだけです。for, foreachマクロの使用例
for文1
上の例と同じく0から9を表示します。
tf.iを増やしながら*doのラベルの処理を行います。
tf.iの初期値は0です。
for文2
こちらは2から9を表示します。
startでtf.iの初期値を指定できます。
foreach文1
foreach文の例です。
この例では配列内の数値が順番に表示されます。
listに配列もしくは配列の入った変数名を指定できます
tf.elemが各要素になります。
foreach文2
scenarioフォルダ内のファイルを表示する例です。
foreach文3
bgmフォルダ内のファイル一覧から再生リストを作成する例です。
listを指定しない場合はtf.listが操作される配列になります。
そうすることでtf.listとtf.iでtf.elemのかわりをすることができます。
tf.elemで書くと面倒な場合などで利用できます。
この場合、tf.elemにそのまま置き換えるとファイル名が変数名と判断されるためにエラーになるためにこのようにしています。
(tf.elemでもエスケープシーケンスを使って文字列扱いにすれば解決できます。)
foreach文4
tf.list以外を利用したときはlistに変数名を指定します
for, foreachマクロの実装
重要な部分だけ説明します。まず、[eval exp="mp.val=Scripts.eval(mp.list)"]の行です。
KAGのマクロでは引数は文字列で渡されるようです。
そこでScripts.eval()で変数名から中身の配列への参照を得ています。
次に[call target="&mp.func"]の行です。
func引数に指定された文字列のラベルにジャンプします。
ジャンプ先の最後のreturnタグで戻ってくることを想定しています。
またKAGにおいてマクロは呼び出し元のコンテキストで実行されるようです。
すなわち、storage引数が呼び出しもとファイルと同じ物となります(forマクロと呼び出し元は異なるファイルと仮定)。
そのため、このコードでは呼び出し元と同じファイル中のラベルをfunc引数に指定する必要があります。
違うファイルのラベルを呼べるようにするにはstorage引数を追加するだけでおそらく可能です。
2013年8月3日土曜日
AVGの演出技術
AVGの演出技術に調べていて大変参考になるものを見つけたので紹介しておきます。
http://hwm2.gyao.ne.jp/serio/games/direction.html
長いけどとても参考になります。
2011年が最終アップデートなので最近の情報がないのが残念な点です。
が、今でも十分に通用するでしょう。
もう一つ、残念な点に文字ばっかりというのがありますが版権の都合上しょうがないかと。
体験版探して自分で確かめるのが一番いいかも。
もちろん、時間とお金があれば製品版で確かめるのもありです。
というか、どれくらいゲームやったのかが気になる・・
http://hwm2.gyao.ne.jp/serio/games/direction.html
長いけどとても参考になります。
2011年が最終アップデートなので最近の情報がないのが残念な点です。
が、今でも十分に通用するでしょう。
もう一つ、残念な点に文字ばっかりというのがありますが版権の都合上しょうがないかと。
体験版探して自分で確かめるのが一番いいかも。
もちろん、時間とお金があれば製品版で確かめるのもありです。
というか、どれくらいゲームやったのかが気になる・・
2013年7月27日土曜日
Xlink kai仕組み3
Xlink Kaiを解析した結果の説明の3回中の3回目です。
Kaiの通信は主に3つの系統に分かれると説明しました。
1つはチャットやアリーナの移動などのKaiのサーバーを介した通信です。
2つ目はPSP間の通信です。
3つ目はPM(Private Message)やり取りを行う通信です。
下の図はそれら3つの通信をまとめた図です。
今回は3つ目について主に説明していきます。
上の図で通信経路は矢印で表されています。
青の矢印は3つ目に用いられる通信経路です。
ここで行われる通信は主にPMに用いられます。
まず、プロトコルについて説明します。
User Interfaceとkaiengine間の通信はUIによります。
kaiengine間の通信はUDPです。
よってPMのやりとりに信頼性がありません。
文字化けについてまとめて書いておきます。
文字化けには主に3つほど原因があります。
1つめはWeb UIで日本語などを表示できない問題です。
フローティングパネルは文字エンコーディングを指定をうまくできないようです。
2つめはPMにおけるkaiengineで送信する文字エンコーディングの問題です。
7.4.18以前ではshift-jisが7.4.22以降ではutf-8が用いられます(正確にはOSなどにも依存する)。
通常のチャットではサーバーが変換してくれるために文字化けはありませんがPMではサーバーを介しないために文字化けが発生してしまいます。
3つめはMac OSのkaiengineのバグです。
Web UIとkaiengineで通信するとき日本語エンコーディングは変な変換がなされるようです。
ちなみに、ある一定の変換をすれば元のバイナリに変換できます。
以上、Xlink Kaiをいろいろ解析した結果をまとめてみました。
Kaiの通信は主に3つの系統に分かれると説明しました。
1つはチャットやアリーナの移動などのKaiのサーバーを介した通信です。
2つ目はPSP間の通信です。
3つ目はPM(Private Message)やり取りを行う通信です。
下の図はそれら3つの通信をまとめた図です。
今回は3つ目について主に説明していきます。
上の図で通信経路は矢印で表されています。
青の矢印は3つ目に用いられる通信経路です。
ここで行われる通信は主にPMに用いられます。
まず、プロトコルについて説明します。
User Interfaceとkaiengine間の通信はUIによります。
kaiengine間の通信はUDPです。
よってPMのやりとりに信頼性がありません。
文字化けについてまとめて書いておきます。
文字化けには主に3つほど原因があります。
1つめはWeb UIで日本語などを表示できない問題です。
フローティングパネルは文字エンコーディングを指定をうまくできないようです。
2つめはPMにおけるkaiengineで送信する文字エンコーディングの問題です。
7.4.18以前ではshift-jisが7.4.22以降ではutf-8が用いられます(正確にはOSなどにも依存する)。
通常のチャットではサーバーが変換してくれるために文字化けはありませんがPMではサーバーを介しないために文字化けが発生してしまいます。
3つめはMac OSのkaiengineのバグです。
Web UIとkaiengineで通信するとき日本語エンコーディングは変な変換がなされるようです。
ちなみに、ある一定の変換をすれば元のバイナリに変換できます。
以上、Xlink Kaiをいろいろ解析した結果をまとめてみました。
2013年7月20日土曜日
Xlink Kai仕組み2
Xlink Kaiを解析した結果の3回中の2回目です。
Kaiの通信は主に3つの系統に分かれると説明しました。
1つはチャットやアリーナの移動などのKaiのサーバーを介した通信です。
2つ目はPSP間の通信です。
3つ目はPM(Private Message)やり取りを行う通信です。
下の図はそれら3つの通信をまとめた図です。
今回は2つ目について主に説明していきます。
上の図で通信経路は矢印で表されています。
黄の矢印は2つ目に用いられる通信経路です。
ここで行われる通信は主にPSPが通信するデータを中継するだけです。
先にどうやってKaiが動作しているかを大雑把に説明します。
通常はPSP同士が通信しているるわけなのですが、PSPの替わりにWifiアダプタと接続するようにします。
PSP間の通信は暗号化されていないアドホックモードですのでSSIDさえあっていれば簡単にできます(というかそういう風に設計したのではないでしょうか)。
あとはWifiアダプタで受信したパケットを取得しネットワークを介して中継するだけです。
パケットの取得はパケットキャプチャと呼ばれ、OSで用意されていますのでそれを利用しています。
普通はライブラリ(winpcap, libpcapなど)が提供されているのでそれを利用するようです。
取得したパケットはトンネリングという技術を用いてKaiengineからKaiengineへ送信します。
トンネリングは新しい送信先と送信元の情報をつけて送信する方法です。
トンネリングされたパケットを受信したKaiengineはあとはWifiアダプタを用いてPSPに送信します。
送信するだけと書きましたが、おそらくWifiアダプタは中継モードと呼ばれるものになっています。
中継モードとは文字通り自分以外からのパケットを中継するモードです。
中継モードでは送信元が自分以外のパケットを送信できるのに対して、通常は送信できません。
おそらく中継モードがXlinkモードとその他での差異だと推測できます(おそらく他にもあります)。
ということでXlinkの動作とパケットキャプチャ、トンネリング、中継モードが主要な技術要素であることを説明しました。
次に通信プロトコルについて見ていきます。
PSPとWifiアダプタの通信はEthernet(Wifi)パケットをブロードキャストで行っているようです。
ちなみにイーサネットより上の階層のプロトコルはオリジナルになっています(TCP/IPではない)。
kaiengine間UDPは通信になります。UDP通信の方が即応性があるために用いられています。
しかしながら、信頼性はないのでパケットを損失し、ラグやワープが発生することがあります。
ここで、なぜアリーナでプレイをしてはいけないかを説明しておきます。
少し上でPSPとWifiアダプタはブロードキャストで通信していると説明しました。
ブロードキャストというのは不特定多数に送信する方法です。
そのため、グルーピングがそのままではできないのでSSIDによりグルーピングを行っています。
モンハンで言えば集会所ごとにSSIDを変えています。
しかし、パケットキャプチャでは受信時にEthernetパケットとして受信するためにSSIDの情報が失われます。
そのため、この方法はXlinkではできないようです。
そこでKaiでは部屋を用意しているわけです。
仕組み上、ブロードキャストは誰宛かわからないのでkaiengineは部屋(アリーナ)にいるすべての人にパケットを送信します。
そのため部屋(アリーナ)にいる人数が多くなるほど負荷が多くなることになります。
とくにモンハンなどではクエにいくと通信量が増えます。
ここでどのくらいの負荷増加になるか計算してみます。
一人分のプレイ時の負荷増加分をΔとします。
プレイ人数をXとします。
アリーナ内の人数をαとします(自分たちも含めて)。
このときの負荷増加分はX×Δ×α
ΔをMHP3rdで計測したところ5KB/sec位でした。
X=4, α=100だとします。
すると全体の負荷増加分は2MB/secと結構な値になります。
この値は全体の負荷です。
個人の負荷は20KB/secになります。
これが多いか少ないかは回線にもよるので何とも言えませんが、アリーナでプレイをすると他人の負荷になってしまいます。
そのため、アリーナでのプレイは基本的に避けるべきです。
ただし、人数が少ないときはたいした負荷でもないので負荷的には別に問題ないです。
最後にセキュリティの話を書いておきます。
kaiengineはパケットキャプチャをしてそのパケットを送信していると説明しました。
このときkaiengineはキャプチャした通信を内容を見ずにすべて送信します。
これはwifiアダプタを正しく選択していれば問題ないのですが、間違っていた場合に面倒なことになります。
たとえば、LAN内通信に用いているNIC(Network Interface Card)が選択された場合に、LAN内での通信が漏れることになります。
また、正しくアダプタが選択している場合でもPSPから送らなくてもいい情報が送信されている場合もあります。
実際に送信されているのを確認したのものとしてPSPに設定しているニックネームがあります。
もし本名などを設定しているなら変更した方がいいでしょう。
次回最後の3つ目のPMのやりとりを行う通信について説明していきます。
Kaiの通信は主に3つの系統に分かれると説明しました。
1つはチャットやアリーナの移動などのKaiのサーバーを介した通信です。
2つ目はPSP間の通信です。
3つ目はPM(Private Message)やり取りを行う通信です。
下の図はそれら3つの通信をまとめた図です。
今回は2つ目について主に説明していきます。
上の図で通信経路は矢印で表されています。
黄の矢印は2つ目に用いられる通信経路です。
ここで行われる通信は主にPSPが通信するデータを中継するだけです。
先にどうやってKaiが動作しているかを大雑把に説明します。
通常はPSP同士が通信しているるわけなのですが、PSPの替わりにWifiアダプタと接続するようにします。
PSP間の通信は暗号化されていないアドホックモードですのでSSIDさえあっていれば簡単にできます(というかそういう風に設計したのではないでしょうか)。
あとはWifiアダプタで受信したパケットを取得しネットワークを介して中継するだけです。
パケットの取得はパケットキャプチャと呼ばれ、OSで用意されていますのでそれを利用しています。
普通はライブラリ(winpcap, libpcapなど)が提供されているのでそれを利用するようです。
取得したパケットはトンネリングという技術を用いてKaiengineからKaiengineへ送信します。
トンネリングは新しい送信先と送信元の情報をつけて送信する方法です。
トンネリングされたパケットを受信したKaiengineはあとはWifiアダプタを用いてPSPに送信します。
送信するだけと書きましたが、おそらくWifiアダプタは中継モードと呼ばれるものになっています。
中継モードとは文字通り自分以外からのパケットを中継するモードです。
中継モードでは送信元が自分以外のパケットを送信できるのに対して、通常は送信できません。
おそらく中継モードがXlinkモードとその他での差異だと推測できます(おそらく他にもあります)。
ということでXlinkの動作とパケットキャプチャ、トンネリング、中継モードが主要な技術要素であることを説明しました。
次に通信プロトコルについて見ていきます。
PSPとWifiアダプタの通信はEthernet(Wifi)パケットをブロードキャストで行っているようです。
ちなみにイーサネットより上の階層のプロトコルはオリジナルになっています(TCP/IPではない)。
kaiengine間UDPは通信になります。UDP通信の方が即応性があるために用いられています。
しかしながら、信頼性はないのでパケットを損失し、ラグやワープが発生することがあります。
ここで、なぜアリーナでプレイをしてはいけないかを説明しておきます。
少し上でPSPとWifiアダプタはブロードキャストで通信していると説明しました。
ブロードキャストというのは不特定多数に送信する方法です。
そのため、グルーピングがそのままではできないのでSSIDによりグルーピングを行っています。
モンハンで言えば集会所ごとにSSIDを変えています。
しかし、パケットキャプチャでは受信時にEthernetパケットとして受信するためにSSIDの情報が失われます。
そのため、この方法はXlinkではできないようです。
そこでKaiでは部屋を用意しているわけです。
仕組み上、ブロードキャストは誰宛かわからないのでkaiengineは部屋(アリーナ)にいるすべての人にパケットを送信します。
そのため部屋(アリーナ)にいる人数が多くなるほど負荷が多くなることになります。
とくにモンハンなどではクエにいくと通信量が増えます。
ここでどのくらいの負荷増加になるか計算してみます。
一人分のプレイ時の負荷増加分をΔとします。
プレイ人数をXとします。
アリーナ内の人数をαとします(自分たちも含めて)。
このときの負荷増加分はX×Δ×α
ΔをMHP3rdで計測したところ5KB/sec位でした。
X=4, α=100だとします。
すると全体の負荷増加分は2MB/secと結構な値になります。
この値は全体の負荷です。
個人の負荷は20KB/secになります。
これが多いか少ないかは回線にもよるので何とも言えませんが、アリーナでプレイをすると他人の負荷になってしまいます。
そのため、アリーナでのプレイは基本的に避けるべきです。
ただし、人数が少ないときはたいした負荷でもないので負荷的には別に問題ないです。
最後にセキュリティの話を書いておきます。
kaiengineはパケットキャプチャをしてそのパケットを送信していると説明しました。
このときkaiengineはキャプチャした通信を内容を見ずにすべて送信します。
これはwifiアダプタを正しく選択していれば問題ないのですが、間違っていた場合に面倒なことになります。
たとえば、LAN内通信に用いているNIC(Network Interface Card)が選択された場合に、LAN内での通信が漏れることになります。
また、正しくアダプタが選択している場合でもPSPから送らなくてもいい情報が送信されている場合もあります。
実際に送信されているのを確認したのものとしてPSPに設定しているニックネームがあります。
もし本名などを設定しているなら変更した方がいいでしょう。
次回最後の3つ目のPMのやりとりを行う通信について説明していきます。
2013年7月13日土曜日
Xlink kai仕組み1
今更ながらXlink Kaiを解析した結果について3回に分けて説明していきます。
Kaiの通信は主に3つの系統に分かれます。
1つはチャットやアリーナの移動などのKaiのサーバーを介した通信です。
2つ目はPSP間の通信です。
3つ目はPM(Private Message)やり取りを行う通信です。
下の図はそれら3つの通信をまとめた図です。
今回は1つ目について主に説明していきます。
上の図で通信経路は矢印で表されています。
赤の矢印は1つ目に用いられる通信経路です。
ここで行われる通信は主にアリーナの情報を受け取り、アリーナ移動などのユーザー操作をサーバーに送信します。
ここで少し詳しく通信プロトコルについてみていきます。
KaiではTCPとUDPを使い分けています。
TCPとUDPがわからない人に簡単に説明すると、TCPが信頼性があり、UDPが信頼性がない通信ということだけわかればここではいいです。
すなわち、TCPではほぼ確実にパケットが相手に届くが、UDPでは届かない場合もあるということです。
各コンポーネント間の通信をみていきます。
KaiEngineとサーバー間の通信はTCP通信です。
User InterfaceとKaiEngine間の通信はTCPもUDPでもどちらの場合もあります。
しかし、これはコンピュータ内のローカルな通信です。
そのため、UDPでもほぼ信頼性があります。
よって、この1つ目の通信経路が信頼性がある経路であることがわかります。
それに対して、2つ目と3つ目の通信経路は信頼性がありません。
これについては次回以降に説明していきます。
1つ目の経路は信頼性があるといいましたが、実際チャットなどが相手に届かなかったことはないと思います。
先ほどUser InterfaceとKaiEngine間はTCP、UDPどちらもあり得ると書きました。
それは旧UIはUDP通信であり、Web UIと呼ばれるWebブラウザで操作を行うものはTCP通信なためです。
最後にセキュリティ関係の話を書いていきます。
2つ目、3つ目の通信ではサーバーを介さないkaiengine間の通信を行います。
これを行うには通信相手のIPアドレスが必要です。
この情報はサーバーからkaiengineに送られてきます。
kaiengineとサーバー間の通信は平文で行われてるため、この情報を簡単に手に入れられます。
すなわち、Xtagとその人の接続もとIPアドレスです。
IPアドレスがわかれば住んでいる大まかな地域などがわかります。
場合によっては細かい情報までわかるようです。
このようにXlink Kaiはあまりセキュリティ的にはよろしくないようです。
次回は2つ目のPSP間の通信について説明します。
Kaiの通信は主に3つの系統に分かれます。
1つはチャットやアリーナの移動などのKaiのサーバーを介した通信です。
2つ目はPSP間の通信です。
3つ目はPM(Private Message)やり取りを行う通信です。
下の図はそれら3つの通信をまとめた図です。
今回は1つ目について主に説明していきます。
上の図で通信経路は矢印で表されています。
赤の矢印は1つ目に用いられる通信経路です。
ここで行われる通信は主にアリーナの情報を受け取り、アリーナ移動などのユーザー操作をサーバーに送信します。
ここで少し詳しく通信プロトコルについてみていきます。
KaiではTCPとUDPを使い分けています。
TCPとUDPがわからない人に簡単に説明すると、TCPが信頼性があり、UDPが信頼性がない通信ということだけわかればここではいいです。
すなわち、TCPではほぼ確実にパケットが相手に届くが、UDPでは届かない場合もあるということです。
各コンポーネント間の通信をみていきます。
KaiEngineとサーバー間の通信はTCP通信です。
User InterfaceとKaiEngine間の通信はTCPもUDPでもどちらの場合もあります。
しかし、これはコンピュータ内のローカルな通信です。
そのため、UDPでもほぼ信頼性があります。
よって、この1つ目の通信経路が信頼性がある経路であることがわかります。
それに対して、2つ目と3つ目の通信経路は信頼性がありません。
これについては次回以降に説明していきます。
1つ目の経路は信頼性があるといいましたが、実際チャットなどが相手に届かなかったことはないと思います。
先ほどUser InterfaceとKaiEngine間はTCP、UDPどちらもあり得ると書きました。
それは旧UIはUDP通信であり、Web UIと呼ばれるWebブラウザで操作を行うものはTCP通信なためです。
最後にセキュリティ関係の話を書いていきます。
2つ目、3つ目の通信ではサーバーを介さないkaiengine間の通信を行います。
これを行うには通信相手のIPアドレスが必要です。
この情報はサーバーからkaiengineに送られてきます。
kaiengineとサーバー間の通信は平文で行われてるため、この情報を簡単に手に入れられます。
すなわち、Xtagとその人の接続もとIPアドレスです。
IPアドレスがわかれば住んでいる大まかな地域などがわかります。
場合によっては細かい情報までわかるようです。
このようにXlink Kaiはあまりセキュリティ的にはよろしくないようです。
次回は2つ目のPSP間の通信について説明します。
2013年7月6日土曜日
MacでのWindowsキーボードの使用
Windows用のキーボードをMacで利用する方法をメモしておきます。
利用するのはKeyRemap4Macbookとそれに付属のPCKeyboardHackです。
対応するキーがある場合はWindowsのキー:Macのキーという表現になっています。
これらは上記のように4種に分けることができます。
1種目は同様な機能が割り当てられているキーで設定をする必要はありません。
2種目は Macでは認識しないキーです。
PCKeyboardHackで設定を行う必要があります。
3種目は印字と異なるキーが割り当てられているキーです。
4種目は認識はされますがMacでは使われないキーのために意味のないキーです。
3種目と4種目は必要であればKeyRemap4Macbookで別のキーを割り当てます。
変更するキーについてまとめておきます。
設定した状態の画面は以下。
下の方にある「for Japanese」下の3つの項目をチェックします。
今回はデフォルトで上記のキー設定になっているので他は変更しません。
もし必要ならば一番右の欄のkeycodeを下の表を見ながら変更しましょう。
4−6は KeyRemap4Macbookで設定します。
設定した状態の画面は以下。
以下のような項目をチェックします。
今回はApple製キーボード(JIS)に近くなるようしましたが、 実は細かいところでまだ違いあります(Caps LockやCtlの位置など)。
利用するのはKeyRemap4Macbookとそれに付属のPCKeyboardHackです。
説明用キーボード
Realforce 91(JIS)異なるキー
対応するキーがある場合はWindowsのキー:Macのキーという表現になっています。
- 表示は異なるがMacで同じような機能が割り当てられているキー
- Windows:Command_L
- Alt:Option_L
- Back Space:Delete
- Delete:Forward Delete
- 認識しないキー
- 無変換
- 変換
- かな
- 認識するが表示と異なるキー
- 全角半角:`
- Print Screen:F13
- Scroll Lock:F14
- Pause:F15
- Insert:Help
- Macで意味のないキー
- Application
これらは上記のように4種に分けることができます。
1種目は同様な機能が割り当てられているキーで設定をする必要はありません。
2種目は Macでは認識しないキーです。
PCKeyboardHackで設定を行う必要があります。
3種目は印字と異なるキーが割り当てられているキーです。
4種目は認識はされますがMacでは使われないキーのために意味のないキーです。
3種目と4種目は必要であればKeyRemap4Macbookで別のキーを割り当てます。
設定例
今回はなるべくApple製のキーボード配列(JIS)に近くなるようにします。変更するキーについてまとめておきます。
- 無変換:JIS_KANA
- 変換:JIS_EISUU
- かな:Command_R
- 全角半角:Escape
- Application:Fn
- Escape:Eject
設定した状態の画面は以下。
今回はデフォルトで上記のキー設定になっているので他は変更しません。
もし必要ならば一番右の欄のkeycodeを下の表を見ながら変更しましょう。
4−6は KeyRemap4Macbookで設定します。
設定した状態の画面は以下。
以下のような項目をチェックします。
- 4:Change Backquate Key > Backquate to Escape
- 5:For PC Users > Change PC application Key > Application Key to Fn
- 5:Change F1..F19 Key & Functional Key > Change F1..F19 Key > Separately settings Fn+F1..F12 to Functiolnal
- 6:Change Escape Key > Escape to Eject
最後に
KeyRemap4MacbookとPCKeyboardHackを用いてWindowsキーボードをMacで利用する方法を説明しました。今回はApple製キーボード(JIS)に近くなるようしましたが、 実は細かいところでまだ違いあります(Caps LockやCtlの位置など)。
2013年6月29日土曜日
OS X Serverを用いたTimeCapsuleもどきを構築
Mac OS X Server 10.6を手に入れたので、それと古いMac miniを用いてTimeCapsuleもどきを作ってみました。
利点
- 自由にHDDを変更、追加可能
- 古いハードウェアを再利用可能
- 再利用すれば費用が安い
- OS X Serverの他の機能もついでに利用可能
欠点
- 消費電力が増える(推測)
- 3.5inch HDDを用いる場合、筐体上部を外した状態でおいておく必要がある。
- 3.5inch HDDを用いる場合、外部から電源を持ってくる必要がある
- 分解が必要
材料
- Mac mini (Early 2006 MA205J/A)
- 玄人志向 Mac mini風HDDケース
- Western Digital製2TB 3.5inch HDD
- SATA延長ケーブル
- SATA延長線
- Mac OS X Server 10.6 Snow Leopard Server
- amazonやヤフオクで4、5000円位で入手可能
- Mac miniが新しければ新しいバージョンのOS X Serverでも可
ハードウェア変更手順
- Mac miniを分解
- HDDを取り外す
- DVDドライブを取り外す
- Mac miniをHDD, DVDドライブがない状態で組み立て
- 筐体上部は戻さない
- HDDケースを開く
- HDDをセット
- HDDにケースから電源ケーブルを接続
- Mac miniとHDDをSATA延長線とSATA延長ケーブルで接続
- SATA延長線をMac mini側に接続
- 接続先の基盤は固定されておらず不安定なので接続するときは注意しながら行う
- 延長線とHDDを延長ケーブルで接続
- 変更終了
- 利用時はHDDケースの電源を先に入れておく必要がある
ソフトウェア変更
- Mac OS X Serverをインストール
- サーバー側でTimeMachineサーバーをオンにする
- サーバー環境設定 > Time Machineで簡単に設定可能
- クライアント側でTimeMachineのバックアップ先を指定
- システム環境設定 > Time Machineで簡単に設定可能
- OS X 10.8ではバックアップ先を複数指定可能
2013年6月22日土曜日
keynoteで接続線、曲線
keynoteで図を書く必要がありました。
そのとき、パワポのようにオブジェクト同士を矢印つなげたり、曲線を書く場合にどうすればいいかを調べた結果です。
接続の線を作成する方法
ベジェ曲線の書き方
個人的にはこれができればパワポと同じように図が作成できます。
ただ、一つ問題として接続の線は同じオブジェクト間では一つしか線を作成できないようです。
そのとき、パワポのようにオブジェクト同士を矢印つなげたり、曲線を書く場合にどうすればいいかを調べた結果です。
接続の線を作成する方法
ベジェ曲線の書き方
個人的にはこれができればパワポと同じように図が作成できます。
ただ、一つ問題として接続の線は同じオブジェクト間では一つしか線を作成できないようです。
2013年6月15日土曜日
ゲームエンジン比較
ノベルゲームを作るかもしれないので、ノベルゲーム用エンジンをいくつか調べてみました。
そのときの個人的な比較を書いておきます。
比較対象は以下の7つです。
ゲーム作成は一人ではなく、プログラム素人のシナリオライターもスクリプトをいじることを考慮します。
デバッグでグラフィッカーや音声の人もいじる可能性もあります。
先に結論を書いておきますが採用する予定なのは吉里吉里です。
VitualArtsから無償貸与扱い。届け出が必要。
LiveMakerとそんなにかわらないので略。
7. ADV+++
吉里吉里を採用した理由はkkdeの存在が大きいです。
解凍するだけでほぼすべての開発環境ができます。
それにコード補完、コードの色分けなどが利用できて便利です。
個人的にはRen'pyが利用したいのですが、英語があまり得意そうではないシナリオ担当のために現状では厳しいと判断しました。
個人的に勉強してノウハウたまったら利用したいです。
LiveMaker / Yuuki!Novel等はGUIで開発できるのでスクリプトを書いたことがない素人が利用するには良さそうです。
スクリプトのみでもすべてできるか確認してみたんですが、よくわからなかったので今回は不採用にしました。
スクリプトを操作できないと他のプログラムから利用などで不便な場合があるからです。
他にシナリオ担当にスクリプトになれてもらおうというのも理由にあります。
NScripter, RealLiveMaxはC++で拡張書かなくてはいけないようで少し面倒なのでやめました(もっとも吉里吉里でもこだわるならC++でプラグインを書く必要があります)。
ADV+++は初心者でもプロでも幅広く利用できるようになっているようです。
個人的にはアセンブリ風言語で書く必要があるのが不採用の最大の理由です。
Javaなど高級言語利用してきた私としてはアセンブラのようなので書きたいとは思いませんし、個人的にはすごい読みづらいです。
参考
http://ja.wikipedia.org/wiki/%E3%82%B2%E3%83%BC%E3%83%A0%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%B3
そのときの個人的な比較を書いておきます。
比較対象は以下の7つです。
比較対象
比較項目
- 対応プラットフォーム
- ライセンス
- 情報量
- 実績
- 開発環境
- 拡張性
前提
比較はプログラマ視点が基本です。ゲーム作成は一人ではなく、プログラム素人のシナリオライターもスクリプトをいじることを考慮します。
デバッグでグラフィッカーや音声の人もいじる可能性もあります。
比較評価
1. 吉里吉里2先に結論を書いておきますが採用する予定なのは吉里吉里です。
- 対応プラットフォーム:Windows系のみ
- ライセンス: どのようなのでも無償
- 情報量:豊富
- 実績:有名なのいろいろ
- 開発環境:kkdeなるものがある。
- コード補完、コードの色分けをしてくれます。
- 統合開発環境で初心者でも使いやすいです。
- 拡張性:TJSを使えば幅広い拡張が可能
- 対応プラットフォーム:Windowsのみ
- (ONScripterで他のプラットフォームに移植可能)
- ライセンス: 商用は有料
- 情報量:多い
- 実績:十分
- 開発環境:さくらエディタなどで設定するとコード補完などが可能
- プログラマはいいが他の人に設定してもらうのが面倒そう
- 拡張性:C++で書く必要がある。
- ちょっと面倒
VitualArtsから無償貸与扱い。届け出が必要。
- 対応プラットフォーム:Windows系
- 更新されることはないと思うので新しいWindowsではどうなるかが不安なところ
- ライセンス: どのようなのでも無償
- 情報量:少なめ
- 実績:商用に利用されていたので
- 開発環境:さくらエディタでコード補完等可能
- 拡張性:C++で書く。
- 拡張しなくても豊富な機能があるらしい
- 対応プラットフォーム:Windows, Mac OS X, Linux, Android
- ライセンス: 無償(MITライセンス)
- 情報量:日本語情報は少なめ、英語は十分にある。
- 実績:海外での実績はそこそこある
- 開発環境:既存のプログラム言語pythonを利用しているので流用可能
- 拡張性:pythonで書かれたものを流用可能
- 他言語で利用できるように設計されているが日本語で一部問題がある場合がある。
- 対応プラットフォーム:Windows
- ライセンス: どのようなのでも無償
- 情報量:そこそこ?
- 実績:フリーのゲームは結構ある模様。詳細は不明
- 開発環境:GUIで作成できます。
- 拡張性:少ないかも。詳細不明
LiveMakerとそんなにかわらないので略。
7. ADV+++
- 対応プラットフォーム:Windows系、Mac OS X系など
- ライセンス: カンパウェア
- 情報量:少なめ(有料のコミュニティに入るのが必須かも)
- 実績:プロが作ったもの
- 開発環境:不明
- アセンブリ風言語で開発
- 拡張性:できない?詳細不明
まとめ
採用予定なのは吉里吉里2です。吉里吉里を採用した理由はkkdeの存在が大きいです。
解凍するだけでほぼすべての開発環境ができます。
それにコード補完、コードの色分けなどが利用できて便利です。
個人的にはRen'pyが利用したいのですが、英語があまり得意そうではないシナリオ担当のために現状では厳しいと判断しました。
個人的に勉強してノウハウたまったら利用したいです。
LiveMaker / Yuuki!Novel等はGUIで開発できるのでスクリプトを書いたことがない素人が利用するには良さそうです。
スクリプトのみでもすべてできるか確認してみたんですが、よくわからなかったので今回は不採用にしました。
スクリプトを操作できないと他のプログラムから利用などで不便な場合があるからです。
他にシナリオ担当にスクリプトになれてもらおうというのも理由にあります。
NScripter, RealLiveMaxはC++で拡張書かなくてはいけないようで少し面倒なのでやめました(もっとも吉里吉里でもこだわるならC++でプラグインを書く必要があります)。
ADV+++は初心者でもプロでも幅広く利用できるようになっているようです。
個人的にはアセンブリ風言語で書く必要があるのが不採用の最大の理由です。
Javaなど高級言語利用してきた私としてはアセンブラのようなので書きたいとは思いませんし、個人的にはすごい読みづらいです。
参考
http://ja.wikipedia.org/wiki/%E3%82%B2%E3%83%BC%E3%83%A0%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%B3
2013年6月8日土曜日
乾電池アダプタ、スペーサー
乾電池には単3、単4などのサイズによる規格がある。
小さいものにアダプタをかぶせて大きい規格の電池として利用するのがアダプタもしくはスペーサーと呼ばれている。
単4を単3として利用するスペーサーの例である。
これらは何に使うかというと主に2つの利用方法がある。
一つは現状ではあまり見かけない単2や単1などの乾電池を替わりをさせるためでる。
もう一つは、軽量化をはかるためである。
重量的に「単3 > 単4+スペーサー」であるために単3を単4で置き換えて軽量化可能である。
実際にエネループ、上であげたスペーサーの重量を計測してみた。
結果
結果より11g、40%ほど軽量化できていることがわかる。
軽量化はできるがサイズが小さい電池を用いるために電池の容量が小さくなる。
すなわち、電池切れまでの時間が短くなる。
以下、容量の比較をしてみる。
エネループ単3:1900mAh
エネループ単4: 750mAh
容量は60%減である。
重さに比べ容量の減少の方が大きい。
そのため、大きい電力を必要とする機器ではあまりよろしくない場合があると思われる。
小さいものにアダプタをかぶせて大きい規格の電池として利用するのがアダプタもしくはスペーサーと呼ばれている。
単4を単3として利用するスペーサーの例である。
これらは何に使うかというと主に2つの利用方法がある。
一つは現状ではあまり見かけない単2や単1などの乾電池を替わりをさせるためでる。
もう一つは、軽量化をはかるためである。
重量的に「単3 > 単4+スペーサー」であるために単3を単4で置き換えて軽量化可能である。
実際にエネループ、上であげたスペーサーの重量を計測してみた。
結果
- エネループ単3:26g
- エネループ単4:12g
- スペーサー:3g
結果より11g、40%ほど軽量化できていることがわかる。
軽量化はできるがサイズが小さい電池を用いるために電池の容量が小さくなる。
すなわち、電池切れまでの時間が短くなる。
以下、容量の比較をしてみる。
エネループ単3:1900mAh
エネループ単4: 750mAh
容量は60%減である。
重さに比べ容量の減少の方が大きい。
そのため、大きい電力を必要とする機器ではあまりよろしくない場合があると思われる。
まとめ
容量の問題もあるが電池2つの場合20gくらい軽量化できるため、よく持ち運ぶ物で利用したい。2013年6月1日土曜日
Lion, Mountain LionにJDK 5をインストールする方法
JDK 6上で作成したJavaプログラムはJava 5以前でもそのまま動くと思ってたんですが、そうではないらしい。
ということで今回はMountain LIonにJDK 5をインストールする方法を探していたら見つけたスクリプトを紹介します。
スクリプト:https://gist.github.com/bric3/1163008
ダウンロードからインストールまでほぼ自動でやってくれます。
ということで今回はMountain LIonにJDK 5をインストールする方法を探していたら見つけたスクリプトを紹介します。
スクリプト:https://gist.github.com/bric3/1163008
ダウンロードからインストールまでほぼ自動でやってくれます。
2013年5月25日土曜日
jkaiUI Custom ver.0.5.1-jdk5(Leopard PPC用)を公開しました
Mac OS X Leopard(PPC)にてjkaiUI Custom ver.0.5.1などが動かないという報告が来たので修正したバージョンを公開しました。
ファイル置き場の方においてあります。
主な修正点は以下になります。
基本的に10.5 Leopard(PPC)用です。
Intelではjavaのバージョンを1.6にして通常のver.0.5.1をご利用ください。
/Applications/Utilites/JavaPreferencesで変更できます。
javaのサポートは現バージョン(java 1.7)以外はサポートされなくなるようです。
そのためセキュリティ的に利用はおすすめできません。
もし利用するときはブラウザでJavaプラグインをオフにすること推奨します。
最後に、報告とログの採取に協力してくれた方には感謝をいたします。
ありがとうございました。
ファイル置き場の方においてあります。
主な修正点は以下になります。
- チャット画面において右クリックメニューからSearch with Google機能を除去
- チャット画面において右クリックメニューからopen URL機能を除去
基本的に10.5 Leopard(PPC)用です。
Intelではjavaのバージョンを1.6にして通常のver.0.5.1をご利用ください。
/Applications/Utilites/JavaPreferencesで変更できます。
javaのサポートは現バージョン(java 1.7)以外はサポートされなくなるようです。
そのためセキュリティ的に利用はおすすめできません。
もし利用するときはブラウザでJavaプラグインをオフにすること推奨します。
最後に、報告とログの採取に協力してくれた方には感謝をいたします。
ありがとうございました。
2013年5月18日土曜日
PlanexがXlink kaiのサポート(スポンサー)をやめた模様
Xlink kaiのスポンサーからPlanexが降りるようです。
以下、情報元
http://www.teamxlink.co.uk/forum/viewtopic.php?p=235774
もう人があまりいないので宣伝効果が薄いと判断されたのかも。
Xlink Kai自体はユーザーがいる限りサービスを続けるようです。
ただ、いくつか影響がある模様。
現状での影響として日本国内のサーバがなくなったことがあります。
人が少ない状況ではそれほど大きな影響ではないでしょう。
他に、メインサイトの移転がされているようです。
また、将来的にコンソール(ゲーム機)、接続元の位置、コンソールのハードウェアベンダーによってアクセスが制限されるようになるかもしれないようである。
以下、情報元
http://www.teamxlink.co.uk/forum/viewtopic.php?p=235774
もう人があまりいないので宣伝効果が薄いと判断されたのかも。
Xlink Kai自体はユーザーがいる限りサービスを続けるようです。
ただ、いくつか影響がある模様。
現状での影響として日本国内のサーバがなくなったことがあります。
人が少ない状況ではそれほど大きな影響ではないでしょう。
他に、メインサイトの移転がされているようです。
また、将来的にコンソール(ゲーム機)、接続元の位置、コンソールのハードウェアベンダーによってアクセスが制限されるようになるかもしれないようである。
Apple Wireless Keyboardのキートップ交換
キーボードはRealforce 91以外にもApple Wireless Keyboard(JIS)を利用している。
Apple Wireless Keyboard(JIS)は仮名入力用のひらがなも印字されているためにごちゃごちゃした感じを受けます。
USキーボードを利用すればいいんですが、USキーボードには英数、かなキーがないのが個人的には痛いです。
そこでUSキーボードのキートップをJISキーボードに移植してみました。
今回はキートップ自体をいじらずにいつでも戻せるようにという方針で行いました。
この記事ではキートップの外し方等は説明しません。
しかし、記号関係はかなりの違いがあります。
また、キー自体の大きさが異なる物もあります。
そのために、すべてのキートップをそのまま入れ替えるわけにはいきません。
第一段階ではそのまま入れ替えても支障のないキートップ(A-Z)を入れ替えます。
以下がその状態の写真です。
キートップの交換だけでは印字されたものと実際に入力されたキーが異なる物になってしまうためにKeyRemap4Macbookを利用します。
第二段階を行うとKeyRemap4Macbookで所定の設定を行っていないと、印字と入力がずれる問題があります。そのため、そのような環境で利用する可能性がある場合はあまりおすすめしません。
入れ替えの前にKeyRemap4Macbookの設定を行います。
次に入れ替え作業です。
入れ替えの作業はKeyRemap4Macbook付属のEventViewerなどで入力を確認しながら印字と入力が一致するように配置すれば大丈夫です。
ただし、4つの例外があります。
例外は以下。
個人的にはすっきりして満足。
キー配列が変わるので慣れるまでがたいへん。
Apple Wireless Keyboard(JIS)は仮名入力用のひらがなも印字されているためにごちゃごちゃした感じを受けます。
USキーボードを利用すればいいんですが、USキーボードには英数、かなキーがないのが個人的には痛いです。
そこでUSキーボードのキートップをJISキーボードに移植してみました。
今回はキートップ自体をいじらずにいつでも戻せるようにという方針で行いました。
この記事ではキートップの外し方等は説明しません。
説明用環境
Mac OS X 10.8材料
- Apple Wireless Keyboard(JIS) 単3電池を3個必要なモデル
- Apple Wireless Kayboard(US)ジャンク
使用ソフトウェア
- KeyRemap4Macbook
第一段階
JISとUSではアルファベットの位置は同じです。しかし、記号関係はかなりの違いがあります。
また、キー自体の大きさが異なる物もあります。
そのために、すべてのキートップをそのまま入れ替えるわけにはいきません。
第一段階ではそのまま入れ替えても支障のないキートップ(A-Z)を入れ替えます。
以下がその状態の写真です。
第二段階
第二段階では記号関係も入れ替えます。キートップの交換だけでは印字されたものと実際に入力されたキーが異なる物になってしまうためにKeyRemap4Macbookを利用します。
第二段階を行うとKeyRemap4Macbookで所定の設定を行っていないと、印字と入力がずれる問題があります。そのため、そのような環境で利用する可能性がある場合はあまりおすすめしません。
入れ替えの前にKeyRemap4Macbookの設定を行います。
- Preferencesを開く
- For japanese > Change Keyboard Layout > Use Japanese Keyboard as US Kayboardをチェック
次に入れ替え作業です。
入れ替えの作業はKeyRemap4Macbook付属のEventViewerなどで入力を確認しながら印字と入力が一致するように配置すれば大丈夫です。
ただし、4つの例外があります。
例外は以下。
- 「1」キー
- キーの形が違うために交換できない
- 「`」キー(2つめ)
- 「`」キーは2つ存在する。キートップが足りなくなるためにJISキーボードのキートップを適当に利用する。
- 「\」キー
- USキーの内部形状(パンタグラフ)が違うために90度回転した状態でになる
- 「`」キー
- 同上
感想
個人的にはすっきりして満足。
キー配列が変わるので慣れるまでがたいへん。
2013年5月11日土曜日
Extended Collections Libraryを紹介
Extended Collections FrameworkなるものをGitHubにて公開しています。
もっと使いやすいCollectionsが欲しかったので壮大な(そうでもないかも)一人プロジェクトで作っていました。
現在はjavassistを用いた方法を考えているので放置中。
以下その説明。
githubにあげたReadMeほぼそのまま。
主に以下の3つのコレクションを目指している。
Objective-C, Scala, Xtend, haskellなどの影響を受けている。
いるかどうかはわからないが複数人で利用する場合は劇薬になる場合があるかもしれないので要注意。
またJavaにてインターフェースを拡張する場合のコンセプトコードでもある。
ucollectionの実装はほぼ完成(現状ではjava.util以下のクラスのみ)。
ただし、テストとテストコード, JavaDocが未完成。
他はまだまだ実験段階。
またはNetBenasのプロジェクト形式なのでantでもビルド可能。
guavaに依存。
それぞれのパッケージは以下。
これはクラス名を同名にすることにより実現している(パッケージは異なる)。
例:共存する場合
例:入れ替える場合
拡張インターフェースはjava.util以下のインターフェースを継承している。
そのため拡張実装クラスはjava.utilのインターフェース型の変数にも代入可能。
拡張実装クラスはjava.util下のクラスを継承している(EnumSet以外)。
そのため、java.utilの実装クラス型の変数にも代入可能
拡張実装クラス、短縮名クラス、同名クラスは継承関係になっている。
java.utilクラス=>拡張実装クラス=>短縮名クラス=>同名クラス
左が親、右が子の関係である。
このような関係のため次のような結果になる。
ただし、3つのクラスは4つのインターフェース(java.util、拡張、短縮、同名)をすべて実装しているためにインターフェースを介した場合は同じように利用可能である。
4つの実装クラス(java.util、拡張、短縮、同名)は中身が同じならequalsメソッドでは等価になるように設計されている。
実装上はjava.utilのものと同じ。
スタティックファクトリーメソッドなどが追加されている。
もっと使いやすいCollectionsが欲しかったので壮大な(そうでもないかも)一人プロジェクトで作っていました。
現在はjavassistを用いた方法を考えているので放置中。
以下その説明。
githubにあげたReadMeほぼそのまま。
Extended Collections Framework概要
Java Collections Frameworkを拡張したフレームワークを目指している。主に以下の3つのコレクションを目指している。
- Java Collections Frameworkにメソッドを追加したコレクション:collections with utilities(ucollection)
- 関数型のようなコレクション:functional collections(fcollection)
- 動的に内部動作を最適化するコレクション:dynamic collections(dcollection)
Objective-C, Scala, Xtend, haskellなどの影響を受けている。
いるかどうかはわからないが複数人で利用する場合は劇薬になる場合があるかもしれないので要注意。
またJavaにてインターフェースを拡張する場合のコンセプトコードでもある。
ucollectionの実装はほぼ完成(現状ではjava.util以下のクラスのみ)。
ただし、テストとテストコード, JavaDocが未完成。
他はまだまだ実験段階。
利用方法
NetBeansプロジェクト形式で配布されるのでNetBeansでビルドしてください。またはNetBenasのプロジェクト形式なのでantでもビルド可能。
ライセンス
修正BSDライセンス。ucollectionについて
ucollectionの設計目標
- 各インターフェースを拡張し、よく使うメソッドを呼べるようにする。
- 各インターフェース、各実装クラスはJava Collections Frameworkと互換性を持たせる。
- 各インターフェース、各実装クラスはJava Collections Frameworkと共存可能。
- 各インターフェース、各実装クラスはJava Collections Frameworkの対応クラスと容易に入れ替え可能
- 短い名前を用意する。
guavaに依存。
ucollectionの使い方
Java Collections Frameworkと共存性を持たせるためにパッケージが4つに分かれている。それぞれのパッケージは以下。
- yuu.akron.ucollection:拡張実装クラスと短縮名クラス群
- yuu.akron.ucollection.another:java.util下のクラスと同名のクラス群
- yuu.akron.ucollection.interfaces:拡張インターフェースと短縮インターフェース群
- yuu.akron.ucollection.interfaces.another:java.util下のインターフェースと同名のインターフェース群
これはクラス名を同名にすることにより実現している(パッケージは異なる)。
例:共存する場合
例:入れ替える場合
拡張インターフェースはjava.util以下のインターフェースを継承している。
そのため拡張実装クラスはjava.utilのインターフェース型の変数にも代入可能。
拡張実装クラスはjava.util下のクラスを継承している(EnumSet以外)。
そのため、java.utilの実装クラス型の変数にも代入可能
拡張実装クラス、短縮名クラス、同名クラスは継承関係になっている。
java.utilクラス=>拡張実装クラス=>短縮名クラス=>同名クラス
左が親、右が子の関係である。
このような関係のため次のような結果になる。
ただし、3つのクラスは4つのインターフェース(java.util、拡張、短縮、同名)をすべて実装しているためにインターフェースを介した場合は同じように利用可能である。
4つの実装クラス(java.util、拡張、短縮、同名)は中身が同じならequalsメソッドでは等価になるように設計されている。
実装上はjava.utilのものと同じ。
スタティックファクトリーメソッドなどが追加されている。
2013年5月4日土曜日
自作シェルコマンド紹介
自作シェルコマンドをGitHubにて公開しています。
ベンチマークの結果をグラフにするために作成したコマンドです。
以下がそのリスト。
各コマンドはMac OS Xにて動作を確認しています。他のOSでは動くかどうかは無保証です。
また、自由に利用してもらってかまいません。
そして、利用は自己責任です。
標準の出力先は標準出力。
現在の対応ベンチマークソフトはxbench, CrystalDiskMark, CrystalMarkの3つ。
ネット上あげるために作成したがgoogleドキュメントの方が利用しやすいために中途半端になっている。
これもブログにあげるために作成したがgoogleドキュメントを使えばほとんど出番無し。
ただし、たいしたことやってないのに汎用性は高いので残してあります。
オプション無しだとcsvファイルの全要素を走査して全体の幅、各列の幅を決定します。
そのため、かなり低速です。
また、幅が大きくなると見づらくなります。
そういうときは-sオプションで列の幅を指定してください。
各列の幅以上の要素は途中でぶつ切れになります。
ベンチマークの結果をグラフにするために作成したコマンドです。
以下がそのリスト。
- bench2csv
- csv2graph
- csv2html
- printCSV
それぞれ簡単な解説
詳しい解説は各コマンドの使い方が-hオプションでみれるのでそれを参照してください。各コマンドはMac OS Xにて動作を確認しています。他のOSでは動くかどうかは無保証です。
また、自由に利用してもらってかまいません。
そして、利用は自己責任です。
bench2csv
各ベンチマークソフトの結果テキストからCSV形式にできる。標準の出力先は標準出力。
現在の対応ベンチマークソフトはxbench, CrystalDiskMark, CrystalMarkの3つ。
基本的な使い方
- bench2csv -c xbench.txt > xbench.csv
- xbenchの結果(自動判別)をCSV形式でファイルに出力
- bench2csv -cm xbench_multi.txt > xbench.csv
- 複数結果が格納されたテキストからCSV形式でファイルに出力
- bench2csv -c -f x Sample > xbench.csv
- フォルダ内の複数のXbenchの結果のファイルからCSVファイルを出力
csv2graph
CSVファイルをgnuplotを用いてグラフ画像に加工します。ネット上あげるために作成したがgoogleドキュメントの方が利用しやすいために中途半端になっている。
csv2html
CSVファイルをhtmlファイルの表形式に変換してくれる。これもブログにあげるために作成したがgoogleドキュメントを使えばほとんど出番無し。
ただし、たいしたことやってないのに汎用性は高いので残してあります。
printCSV
デバッグ用CSVファイルをコンソール上にテーブル形式で表示します。オプション無しだとcsvファイルの全要素を走査して全体の幅、各列の幅を決定します。
そのため、かなり低速です。
また、幅が大きくなると見づらくなります。
そういうときは-sオプションで列の幅を指定してください。
各列の幅以上の要素は途中でぶつ切れになります。
基本的な使い方
- printCSV -s 7 xbench.csv
- bench2csv -c xbench.txt | printCSV
2013年4月27日土曜日
トラックボールネタ
トラックボールの関連のネタを見つけたので紹介しておきます。
一つ目はベアリング化するものです。
M570は3点のシリコンボールによってボールが支えられているんですが、それをベアリングで支えるように魔改造しています。
記事を読み限りではそこまで難しくなく快適になりそうなのでそのうちやってみたいです。
2つめはチャタリングする故障を自力で直す方法です。
チャタリングとは簡単に言うとボタンを一回押したときに複数回押されたように動作してしまう状態です。
これはボタンの部品が故障した状態なので、これを交換すればいいわけです。
それで記事では交換しているんですが、半田吸い取り器などが必要なようで初心者にはあまりおすすめはできません。
また、分解していない限りは3年保証で交換できるのでこんなことをする必要はほとんどないでしょう。
3つめはM570はチャタリングなどで結構あたりはずれがあるという記事。
私が購入した初期の頃はそんな情報がまだ出そろってなかったんですが、結構多い模様。
3年保証なので交換が面倒でなければ大丈夫。面倒な人は注意した方がいいです。
4つめは TM-250の赤い玉と交換してみたという話。
記事中では交換するとスムーズになるとかならないとかぐだぐだです。
個人的にやってみた感じではプラシーボ効果はあるのかも。
TM-250を持っていて赤玉のぶつぶつに嫌悪感がない人は一度やってみてもいいかも程度にみてください。
ちなみに、TM-250にM570の青い玉を入れるとまともに動作しません。
私個人はM570を2台持っていて、それぞれ別のマシンにつないでいるのですが、それを区別するために1台入れ替えています。
以上。
2013年4月20日土曜日
アクティビティモニタのすすめ
アクティビティモニタはWindowsで言うタスクマネージャーまたはリソースモニターに相当する物です。
CPUの使用率、メモリの状況、ディスクの動作、ネットワークの通信状態などを見ることができます。
CPUやメモリなどはプロセス(プログラム)ごとの状況を見ることが可能です。
他にも、プロセスを終了させたり、各プロセスの詳細な情報を集めることもできます。
ここでは、一般的な使い方と今回のメインであるDockアイコンに情報を表示する方法を説明します。
表示するには
これを用いることでコンピュータの状態を常時監視できます。
これによって問題を早期に発見できる場合があります。
起動時に自動で起動させておきたい場合は、
また、自動起動時にウィンドウを表示しないようにする場合は、
まず、アクティビティモニタを開いて下のタブを切り替えながら原因がCPUの使いすぎなのか、メモリの使いすぎなのか、または別の理由なのか見当をつけます。
それに対応した項目で上のリストをソートします。
これで原因のプロセスを絞ることができます。
場合によっては右上の方のドロップボックスでリストに表示するプロセスを変える必要があります。
次に2のプログラムを停止する場合の説明です。
停止するプログラムがわかってると仮定します。
わかっているならば、該当のプロセスをクリックして選択し、左上のプロセスを終了をクリックします。
その後出てくるダイアログで終了、もしくは強制終了でプログラムを停止できます。
CPUの使用率、メモリの状況、ディスクの動作、ネットワークの通信状態などを見ることができます。
CPUやメモリなどはプロセス(プログラム)ごとの状況を見ることが可能です。
他にも、プロセスを終了させたり、各プロセスの詳細な情報を集めることもできます。
ここでは、一般的な使い方と今回のメインであるDockアイコンに情報を表示する方法を説明します。
場所
/Applications/Utilities/Activity Monitor.app日本語表記では
/アプリケーション/ユーティリティ/アクティビティモニタ.appです。
Dockアイコンに情報を表示
アクティビティモニタのDockアイコンには以下のいずれかの情報を表示できます。- 現在のCPU使用率
- CPU使用率の履歴
- ネットワークの使用状況
- ディスクの動作状況
- メモリの使用状況
表示するには
- Dockアイコンを右クリック
- Dockアイコン選択
- XXXを表示をクリック
これを用いることでコンピュータの状態を常時監視できます。
これによって問題を早期に発見できる場合があります。
起動時に自動で起動させておきたい場合は、
- Dockアイコンを右クリック
- オプションを選択
- ログイン時に開くをクリック
また、自動起動時にウィンドウを表示しないようにする場合は、
- システム環境設定を開く
- ユーザーとグループを開く
- アカウントを選択
- ログイン項目のタブをクリック
- リスト上のアクティビティモニタの左のチェックボックスをチェックする
一般的な使用方法
一般的にアクティビティモニタを使うときは以下の2つの場合です。- コンピュータが重いと感じた場合に原因を特定する場合
- フリーズしているプログラムなどを停止する場合
まず、アクティビティモニタを開いて下のタブを切り替えながら原因がCPUの使いすぎなのか、メモリの使いすぎなのか、または別の理由なのか見当をつけます。
それに対応した項目で上のリストをソートします。
これで原因のプロセスを絞ることができます。
場合によっては右上の方のドロップボックスでリストに表示するプロセスを変える必要があります。
次に2のプログラムを停止する場合の説明です。
停止するプログラムがわかってると仮定します。
わかっているならば、該当のプロセスをクリックして選択し、左上のプロセスを終了をクリックします。
その後出てくるダイアログで終了、もしくは強制終了でプログラムを停止できます。
2013年4月13日土曜日
LAN内通信高速化(ジャンボフレームの導入)
普段NASを設置していてファイル移動は主に有線LANを用いて行っている。
このような人にはLANの高速化は利便性が向上する。
以降、高速化の方法としてジャンボフレームの導入について説明していきます。
それを取り払ったのがジャンボフレームである。
パケットのサイズが大きくなるとヘッダ(送信先や送信元などの情報)によるオーバーヘッドが減り通信の効率が良くなる(ただし送信量が多いときなど)。
ジャンボフレームは正式な規格ではないため基本的には初期状態ではオフになっている。そのため自分で設定する必要がある。
ただし、高速化はできるが正式な規格に含まれていないためトラブルに合う可能性もあることに注意したい。
たとえば、PCとNASがハブを介して通信している場合はそれら3つがすべて対応していなければならない。もちろん、ギガビットイーサである必要がある。
ここではMACでの設定方法について説明する。
NASの設定方法は各機器の説明を参照してもらいたい。
ハブなど設定ができない機器は最初からオンであるようである。
なおWindowsではNICドライバの設定で可能なようである。
MACでの設定方法
計測はよく使うプロトコルで行いましょう。
今回は以下の3つについて説明していきます。
今回はddコマンドを用いました。
送受信ファイルのサイズは1GByte。
Windows, Macではおそらく最初から利用できます(ファイアウォールの設定が必要かもしれません)。
私の環境での結果です。
今回の計測ではジャンボフレーム7000での結果です。
受信ではデータを保存しないようにしているために保存先のデバイス(HDDなど)に依存していません。
ジャンボフレームなし
送信速度:4.08 MiB/s
受信速度:5.13 MiB/s
ジャンボフレームあり
送信速度:7.65 MiB/s
受信速度:6.71 MiB/s
SMBではNAS(ジャンボフレーム7000)が通信相手です。
AFPではMAC(ジャンボフレーム9000)が通信相手です。
この方法では設定を変更した後、再起動が必要な場合があります。
SMB
ジャンボフレームなし
送信速度:2m5.415s
受信速度:1m26.023s
ジャンボフレームあり
送信速度:1m34.159s
受信速度:0m51.539s
AFP
ジャンボフレームなし
送信速度:27.489s
受信速度:6.336s
ジャンボフレームあり
送信速度:26.830s
受信速度:6.019s
AFPは効果が少ないかもしれません。
LAN内でSMB, FTPをよく利用する人はできるだけ導入するといいでしょう。
AFPは効果を検証してみた方がいいかもしれません。
このような人にはLANの高速化は利便性が向上する。
以降、高速化の方法としてジャンボフレームの導入について説明していきます。
概要
1ギガイーサにおいて過去の規格と互換性を保つために送信できるパケットのサイズが制限されている。それを取り払ったのがジャンボフレームである。
パケットのサイズが大きくなるとヘッダ(送信先や送信元などの情報)によるオーバーヘッドが減り通信の効率が良くなる(ただし送信量が多いときなど)。
ジャンボフレームは正式な規格ではないため基本的には初期状態ではオフになっている。そのため自分で設定する必要がある。
ただし、高速化はできるが正式な規格に含まれていないためトラブルに合う可能性もあることに注意したい。
準備
ジャンボフレームを導入するには通信経路のすべての機器が対応していなければならない。たとえば、PCとNASがハブを介して通信している場合はそれら3つがすべて対応していなければならない。もちろん、ギガビットイーサである必要がある。
導入方法
通信経路上の機器でジャンボフレームをオンにすればいいだけである。ここではMACでの設定方法について説明する。
NASの設定方法は各機器の説明を参照してもらいたい。
ハブなど設定ができない機器は最初からオンであるようである。
なおWindowsではNICドライバの設定で可能なようである。
MACでの設定方法
- システム環境設定を開く
- ネットワークを開く
- 左側の欄で有線LANを選択する(Ethernetと表示されている)
- 右下の詳細を開く
- ハードウェアタブを開く
- 構成を手動、速度を自動設定、MTUをカスタムにし、下の欄を9000にする。
効果計測
実際に通信速度が向上したか計測してみます。計測はよく使うプロトコルで行いましょう。
今回は以下の3つについて説明していきます。
- FTP
- SMB
- AFP
準備
計測の前に送受信のファイルを準備しておきます。今回はddコマンドを用いました。
送受信ファイルのサイズは1GByte。
FTP
まず、計測を行う前に通信に用いる端末でFTPを利用できる用にします。Windows, Macではおそらく最初から利用できます(ファイアウォールの設定が必要かもしれません)。
私の環境での結果です。
今回の計測ではジャンボフレーム7000での結果です。
受信ではデータを保存しないようにしているために保存先のデバイス(HDDなど)に依存していません。
ジャンボフレームなし
送信速度:4.08 MiB/s
受信速度:5.13 MiB/s
ジャンボフレームあり
送信速度:7.65 MiB/s
受信速度:6.71 MiB/s
SMB/AFP
計測前に共有フォルダをマウントしておきます。SMBではNAS(ジャンボフレーム7000)が通信相手です。
AFPではMAC(ジャンボフレーム9000)が通信相手です。
この方法では設定を変更した後、再起動が必要な場合があります。
SMB
ジャンボフレームなし
送信速度:2m5.415s
受信速度:1m26.023s
ジャンボフレームあり
送信速度:1m34.159s
受信速度:0m51.539s
AFP
ジャンボフレームなし
送信速度:27.489s
受信速度:6.336s
ジャンボフレームあり
送信速度:26.830s
受信速度:6.019s
結論
ジャンボフレームを導入するとFTPとSMBは高速になるようです。AFPは効果が少ないかもしれません。
LAN内でSMB, FTPをよく利用する人はできるだけ導入するといいでしょう。
AFPは効果を検証してみた方がいいかもしれません。
2013年4月6日土曜日
ホームポジション型トラックボール 再挑戦
少し前にホームポジション型トラックボールに挑戦して断念したんですが、すこしひらめいたので再挑戦してみました。
あとはlenovoのThinkpadシリーズのトラックポインタが同じような考え方によるものです。
残念ながらPanasonicではもう作ってないです。
トラックポインタは個人的にはセンシティブなので、慣れるまでが大変そうだけど慣れたら使いやすい気がします。
これらについて気がついたんですが、それからさらにひらめきました!
別に親指型トラックボールじゃなくてもいいよねっと。
前回挑戦したときに実は親指型だと親指で操作するのを前提にしているので、角度調整が難しいと感じていました。
親指で操作するように設計されているので、受け皿は左の方が開くようになってます。
そのため、受け皿とキーボードが干渉していました。
干渉をなくすために角度をずらすと、思った方向に操作できなくなります。
干渉をなくすための高架化なんですが、高さを調整するのが結構面倒でした。
あまり高くすると使い難いのでぎりぎりの高さ調整が必要です。
ただ、これらの問題はおそらく親指型ではないトラックボールを使えば、影響が少なくなるのではないかと考えました。
先に書いておきますがOSはOS Xにて挑戦してます。
本2冊とトラックボールの上にキーボードを置いているだけです。
本と本の間をトラックボールのUSBケーブルが通るようになっています。
右側の本は手を置くために手前に寄せてあります。
ただし、リストレストには勝てないでしょう。
もう一つの工夫点として、トラックボールのボタンを利用せずにキーボードのキーを使うようにしています。
これにより、部品数を減らすことができました。
使用ソフトウェアは上に書いた通りです。
カスタマイズするキー設定を下にまとめておきます(これらのキーはMACでは基本使われない)。
左ボタンのクリックは無効にできないようだ。
KeyRemap4Macbookの補助ソフトウェア。
変換、無変換、KANAキーにほとんど使われないキーコードを割り当てます。
今回はF17, 18, 19を利用します。
また、スペース+ボールを動かすことでチルトホイールのようなに動作する機能を追加します。
手を置く位置は左手はASDF無変換、右手はJKL+ボールになります。
変換、KANAキーはホームポジションからだと人差し指、中指、もしくは親指を移動して来て押すことになります。
これは少しばかり不便なので改良する必要があります。
ホームポジションから右手はスペース、変換、KANAキーの位置に移動させれば、比較的入力しやすくなり、ほぼ片手でマウス操作が可能になります。
オリジナルと比べて個人的によくなった点をあげてみます。
ひらめいた!
ホームポジション型トラックボール自体は昔PanasonicのLets noteシリーズでトラックボールをつんでいたんですがあれとほぼ一緒。あとはlenovoのThinkpadシリーズのトラックポインタが同じような考え方によるものです。
残念ながらPanasonicではもう作ってないです。
トラックポインタは個人的にはセンシティブなので、慣れるまでが大変そうだけど慣れたら使いやすい気がします。
これらについて気がついたんですが、それからさらにひらめきました!
別に親指型トラックボールじゃなくてもいいよねっと。
前回の教訓
前回挑戦したときに実は親指型だと親指で操作するのを前提にしているので、角度調整が難しいと感じていました。
親指で操作するように設計されているので、受け皿は左の方が開くようになってます。
そのため、受け皿とキーボードが干渉していました。
干渉をなくすために角度をずらすと、思った方向に操作できなくなります。
干渉をなくすための高架化なんですが、高さを調整するのが結構面倒でした。
あまり高くすると使い難いのでぎりぎりの高さ調整が必要です。
ただ、これらの問題はおそらく親指型ではないトラックボールを使えば、影響が少なくなるのではないかと考えました。
再挑戦
そこで今回は人差し指トラックボールを利用して挑戦してみました。先に書いておきますがOSはOS Xにて挑戦してます。
材料
- Realforce 91 UBK
- ケンジントン SlimBlade Trackball
- 高さ調節用の本(厚さ3cm位)×2
使用ソフトウェア
- Trackball Works
- KeyRemap4Macbook
- PCKeyboardHack
外観
本2冊とトラックボールの上にキーボードを置いているだけです。
本と本の間をトラックボールのUSBケーブルが通るようになっています。
右側の本は手を置くために手前に寄せてあります。
ただし、リストレストには勝てないでしょう。
ソフトウェア設定
もう一つの工夫点として、トラックボールのボタンを利用せずにキーボードのキーを使うようにしています。
これにより、部品数を減らすことができました。
使用ソフトウェアは上に書いた通りです。
カスタマイズするキー設定を下にまとめておきます(これらのキーはMACでは基本使われない)。
キー設定
- 変換(スペースの右):クリック
- 無変換(スペースの左):中央クリック
- KANA(変換キーの右):右クリック
- スペース+ボールを動かす:チルトホイール(上下左右移動)
Trackball Worksの設定
誤クリックを減らすためにトラックボールのボタンを無効にします。左ボタンのクリックは無効にできないようだ。
PCKeyboardHackの設定
通常Macではそのままでは認識されないキーに他のキーをマッピングできるソフトウェアです。KeyRemap4Macbookの補助ソフトウェア。
変換、無変換、KANAキーにほとんど使われないキーコードを割り当てます。
今回はF17, 18, 19を利用します。
KeyRemap4Macbookの設定
F17, 18, 19に対応したクリックを割り当てます。また、スペース+ボールを動かすことでチルトホイールのようなに動作する機能を追加します。
使い方
手を置く位置は左手はASDF無変換、右手はJKL+ボールになります。
変換、KANAキーはホームポジションからだと人差し指、中指、もしくは親指を移動して来て押すことになります。
これは少しばかり不便なので改良する必要があります。
ホームポジションから右手はスペース、変換、KANAキーの位置に移動させれば、比較的入力しやすくなり、ほぼ片手でマウス操作が可能になります。
感想
今回作成してみて思ったよりいい感じにできたと感じました。オリジナルと比べて個人的によくなった点をあげてみます。
- 分解が不要
- ボールの高さのために分解により高架化の高さを下げるのは難しい
- トラックボールの本体に容易に乗せることができた
- 部品数の減少による組み立てが容易に
- キーボードの重さによりトラックボールを固定が不要
- 解体、組み立てが自由自在
- ホームポジション上のクリック、右クリックの入力が不便
- 今回用いなかったトラックボールのボタンを使うことを前提としてキーボード上のボタンの配置を再検討
- 親指で操作するには今回用いたトラックボールのボールは重い。
- 別のトラックボールを検討
- 高架化すると腕を置くところがなく不安定
- やはりリストレスト?
- 台のような物を作成すればいけるかも
2013年3月30日土曜日
おすすめMacソフトウェア
知り合いがMac買ったというので、個人的なおすすめアプリをまとめたのを書きました。
そのときのものを元に公開用に書いてみました。
そのときのものを元に公開用に書いてみました。
ブラウザ
- Firefox
- Google Chrome 速さを求めるなら。
- KeyRemap4MacBook
- キー入力をいろいろカスタマイズできる。キー入力だけでなくマウスのカスタマイズも可能。中央ボタンにエクスポゼ(misson control)などは個人的にはおすすめ。他にWindows用キーボードを利用するときなどは便利。
- XtraFinder
- Finderを機能強化する。タブを利用できるようにしたりWindowsのように動作するようにできる。たまに不安定。
- AppCleaner
- Windowsで言うアンインストーラのような物。ファイル名やフォルダ名から判断して削除候補をあげてくれる。
- Carbon Copy Cloner
- HDDイメージを作成可能。シェアウェア。バックアップなどに利用可能。
- Remote Desktop Connection Windowsにリモートアクセスする場合に。
- StuffIt Expander 圧縮ファイル解凍ソフト。Macのものより多くの形式に対応。
- TimeMachineEditor
- タイムマシンがバックアップする間隔を指定可能。バックアップばかりしてると感じたら利用を考えてみるべき。
- Trim Enabler 純正SSD以外を利用するなら。
- iText Express
- TextWrangle
- CotEdito
- mi
- Emacs
- MacVim
- MacVim-KaoriYa
- IntelliJ IDEA 12 CE
- Eclipse
- NetBeans
- dropbox 一番便利なクラウド
- googledrive googleサービスと連携するときに便利
- skydrive
- evernote
- 便利なメモアプリ。ただし無料だと1つの端末でしかログインできない(最近は変わってるかも)
- 辞書 国語、英和、和英が入ってるので便利
- アクティビティモニタ dockに入れてCPU仕様履歴を表示すると便利
- Automator
- 簡易なプログラムを作るときに便利。コマンドをアプリケーションでくるむことができる。いろいろなスクリプトを利用可能
- VMware Fusion
- 仮想化ソフト。安定性とVMware Playerとの連携を求めるなら
- Parallels 仮想化ソフト。速い動作を求めるなら。
- VirtualBox 仮想化ソフト。無料。不安定?。
- CrossOver
- Windowsエミュレータ。MS Officeを動かすならこっちの方が軽い。対応ソフトは少ない。Windowsいらず。
- Xen
- CrossOveerのサポートなし版(もともとこっちが源流)。無料。ただし導入は面倒かも。
- MacPorts コマンドをよく使うなら。
- Homebrew コマンドをよく使うなら。
- Skitch ペイントソフト。簡単な図を編集する場合は便利。
- Thunderbird
- メーラー。Mac標準のメーラーに不満な場合に。mozilla系は基本クロスプラットフォーム(Windows, Linux, Macなど)で利用できる。プロファイル(設定)の移行なども簡単にできる。
- VLC
- 動画再生ソフト。Quicktimeより多くの形式を再生可能。Quicktimeがあわない場合はこっち。
- Xbench ベンチマークソフト。
- Handbrake Macでよく利用される動画エンコード用ソフト。
2013年3月23日土曜日
トラックボール+KeyRemap4Macbook
KeyRemap4MacbookというOS X用のキーボードカスタマイズツールがあります。
キーボードカスタマイズツールですが、実はマウスボタンの機能もカスタマイズできます。
これを利用するとトラックボールやマウスが非常に便利になります。
今回は私が使用しているトラックボールLogicool M570(おそらく他のものやマウスでも応用可能)で利用している方法を紹介しようと思います。
インストールするとメニューバーに正方形のアイコンが表示されていればインストールできています。
LCCでもボタンのカスタマイズは可能です。
しかしながら、 KR4Mで一括してカスタマイズした方が手軽です。
また、KR4Mでは設定のプロファイルのような物をいくつか作成しておき、瞬時に切り替えることなどが可能なために便利です。
そこでKR4Mでカスタマイズしやすいように以下のようにボタンに機能割り当てをします。
システム環境設定から設定画面を開きます。
デバイスを選択して、設定ボタンを押します。
各デバイスの設定画面が開きます。
左上のボタンタブを選択します。
開いた画面の割り当てられたアクションを各ボタンごとに選択し、右下の詳細欄でボタンに割り当てる機能を指定します。
下に親指戻るボタンの設定例を示しておきます。
KR4Mではメニューバーのアイコンから「Open KeyRemap4Macbook Preferences」で設定画面を開きます。
開いた設定画面でKR4Mの設定を行っていきます。
KR4Mでは、はじめから用意されている設定(組み込み設定)が豊富に用意されています。
また、自分でカスタマイズした設定を追加もできます。
今回の例では両方必要なのでそれぞれ順に説明します。
例では「右クリックを押しながらカーソルの移動:チルトホイール(上下左右に移動)」が組み込み設定であり、他の4つはカスタマイズ設定です。
組み込み設定はとても簡単です。
Change Keyで好きな設定のチェックボックスをチェックするだけです。
「右クリックを押しながらカーソルの移動:チルトホイール(上下左右に移動)」の場合は
Pointing DeviceカテゴリのCursorMove to ScrollWheelカテゴリのRightClick+CursorMove to ScrollWhellをonにします。
自分でカスタマイズした設定はXMLファイルを編集することで追加できます。
XMLファイルはMisc&UninstallタブのOpen private.xmlを押すことでファイルをFinderで表示してくれます。
それを開いて編集してください(Safariなどで開くときは右クリックからOS X標準のテキストエディットで開いてください)。
開いたら編集していきます。
どのように書けばいいか公式のマニュアルがあります(英語のみ)。
今回の例でのXMLを載せておきます。
XMLファイルについて簡単な説明を載せておきます。
編集後、ファイルを保存します。
KR4Mの設定画面を開き、右上のReloadXMLボタンを押します。
編集内容が反映されるので必要な設定をonにします。
これで設定は完了です。
最後に動作確認をします。
設定によってはあまり出番はありませんが、どのボタンが押されたかやボタンが押された位置、どのキーが押されたかを表示してくれるEventViewerがKR4Mに付属しています。
それを用いて、想定したように動作しているか確認してください。
起動はKR4Mの設定パネルのMisc&Uninstallのタブからできます。
キーボードカスタマイズツールですが、実はマウスボタンの機能もカスタマイズできます。
これを利用するとトラックボールやマウスが非常に便利になります。
今回は私が使用しているトラックボールLogicool M570(おそらく他のものやマウスでも応用可能)で利用している方法を紹介しようと思います。
説明用環境
- OS X 10.8
- Logicool M570
使用ソフトウェア
- KeyRemap4Macbook 8.0.0
- Logicool Control Center
- (OS Xキーボードショートカット設定)
カスタマイズ概要
各ボタンに割り当てる機能をまとめておきます。- 右クリック:変更無し
- 中央クリック:Mission Control
- 左クリック:変更無し
- 右クリック+左クリック(同時押し): Launchpad
- 進むボタン:(Mission Controlの)左の操作スペースに移動
- 戻るボタン:(Mission Controlの)右の操作スペースに移動
- 右クリックを押しながらカーソルの移動:チルトホイール(上下左右に移動)
手順
1,インストール
まず、KeyRemap4Macbook(KR4M)とLogicool Control Center(LCC)をダウンロードとインストールしてください。KR4M
KR4Mインストール後、再起動を要求されるので再起動します。インストールするとメニューバーに正方形のアイコンが表示されていればインストールできています。
KR4Mアイコン |
LCC
LCCはシステム環境設定にアイコンが追加されます(一番下の行にあります)。システム環境設定内のLCC |
2,LCCの設定
LCCでもボタンのカスタマイズは可能です。
しかしながら、 KR4Mで一括してカスタマイズした方が手軽です。
また、KR4Mでは設定のプロファイルのような物をいくつか作成しておき、瞬時に切り替えることなどが可能なために便利です。
そこでKR4Mでカスタマイズしやすいように以下のようにボタンに機能割り当てをします。
LCCボタン割り当て機能
- 左ボタン:クリック クリック
- 右ボタン:クリック 右クリック
- ホイールボタン:クリック 中央ボタン
- 親指戻るボタン:高度なクリック ボタン番号4
- 親指進むボタン:高度なクリック ボタン番号5
手順
システム環境設定から設定画面を開きます。
デバイスを選択して、設定ボタンを押します。
デバイス選択画面 |
左上のボタンタブを選択します。
開いた画面の割り当てられたアクションを各ボタンごとに選択し、右下の詳細欄でボタンに割り当てる機能を指定します。
下に親指戻るボタンの設定例を示しておきます。
親指戻るボタンの設定例 |
3,KR4M設定
KR4Mではメニューバーのアイコンから「Open KeyRemap4Macbook Preferences」で設定画面を開きます。
設定画面を開く |
開いた設定画面でKR4Mの設定を行っていきます。
KR4Mでは、はじめから用意されている設定(組み込み設定)が豊富に用意されています。
また、自分でカスタマイズした設定を追加もできます。
今回の例では両方必要なのでそれぞれ順に説明します。
例では「右クリックを押しながらカーソルの移動:チルトホイール(上下左右に移動)」が組み込み設定であり、他の4つはカスタマイズ設定です。
組み込み設定
組み込み設定はとても簡単です。
Change Keyで好きな設定のチェックボックスをチェックするだけです。
「右クリックを押しながらカーソルの移動:チルトホイール(上下左右に移動)」の場合は
Pointing DeviceカテゴリのCursorMove to ScrollWheelカテゴリのRightClick+CursorMove to ScrollWhellをonにします。
組み込み設定 |
カスタマイズ設定
自分でカスタマイズした設定はXMLファイルを編集することで追加できます。
XMLファイルはMisc&UninstallタブのOpen private.xmlを押すことでファイルをFinderで表示してくれます。
それを開いて編集してください(Safariなどで開くときは右クリックからOS X標準のテキストエディットで開いてください)。
private.xmlを開く |
開いたら編集していきます。
どのように書けばいいか公式のマニュアルがあります(英語のみ)。
今回の例でのXMLを載せておきます。
XMLファイルについて簡単な説明を載せておきます。
- (1)のnameタグはカテゴリ名です。
- (2)のnameタグは設定名です。
- (3)のidentifierタグは識別子のようなものです。他の機能とかぶらないようにすればいいようです。通常はprivate.「機能を表す文」のようにすればいいようです。
- (4)のautogenタグは設定の中身です。
- --PointingButtonToKey--はボタンにキーを割り当てるための機能です。
- --SimultaneousKeyPresses--はボタンやキーを同時押しした場合の動作を割り当てるための機能です。
- 構文:機能、変更前ボタン、変更後ボタン(各ボタン、キーは複数の場合あり)
編集後、ファイルを保存します。
KR4Mの設定画面を開き、右上のReloadXMLボタンを押します。
編集内容が反映されるので必要な設定をonにします。
これで設定は完了です。
カスタマイズ設定 |
4,動作確認
最後に動作確認をします。
設定によってはあまり出番はありませんが、どのボタンが押されたかやボタンが押された位置、どのキーが押されたかを表示してくれるEventViewerがKR4Mに付属しています。
それを用いて、想定したように動作しているか確認してください。
起動はKR4Mの設定パネルのMisc&Uninstallのタブからできます。
EventViewer起動ボタン |
EventViewer |
2013年3月16日土曜日
トラックボールLogicool M570 スクロールホイール静音化?
ホームポジション型親指型トラックボールを作成するという記事を見つけました。
普段、トラックボールを利用している身として気になったので、触発されて実際に試してみました。
しかしながら、これ結構な手間がかかるということがわかりました。
なので、残念ながら今回は断念。
ただ、その過程にてTM-250を分解しているときにスクロールホイールの「かりかり」っとなっている理由がわかりました。
「かりかり」は個人的に気になっていたので現在利用しているM570でも同じだと推測し、原因を除去してみました。
※分解するとメーカー保証(3年間)がなくなります。
M570はここを参考に分解しました。
スクロールホイールはTM-250と違って、筐体の上の方に取り付けられています。
「かりかり」を取り除くにはホイールの溝に金属部品がひかかっているのでこれをとる必要があります。
分解手順
ホイールを外すときは筐体を破損しないように力加減に注意してください。
戻すのは逆順に行えば問題ありません。戻すときはホイールに傷をつける可能性があるので注意が必要です。
以上でハードウェア的な行程は終了です。
あとは好みでLogicool Control CenterやSetPoint等でスクロールホイールの速度、加速度を調整してください。
ホイールの感覚がかなり変わるのでだいたいの人は調整は必要だと思われます。
私の場合は速度と加速度両方とも少しあげました。
慣れない最初のうちは少し気持ち悪く感じます。
自分にあわないと感じたら素直に戻すのをおすすめします。
普段、トラックボールを利用している身として気になったので、触発されて実際に試してみました。
しかしながら、これ結構な手間がかかるということがわかりました。
なので、残念ながら今回は断念。
ただ、その過程にてTM-250を分解しているときにスクロールホイールの「かりかり」っとなっている理由がわかりました。
「かりかり」は個人的に気になっていたので現在利用しているM570でも同じだと推測し、原因を除去してみました。
※分解するとメーカー保証(3年間)がなくなります。
M570はここを参考に分解しました。
スクロールホイールはTM-250と違って、筐体の上の方に取り付けられています。
「かりかり」を取り除くにはホイールの溝に金属部品がひかかっているのでこれをとる必要があります。
分解手順
- 電池カバーのふたと電池、ボールを外す。
- 一部ゴムに隠されている底面のねじ(T6)をはずす。
- 電池格納部のねじをはずす。
- 筐体上部と下部を分離する。
- クリックする部分を外す。筐体上部の中央にある爪を2つ外す。
- マイナスドライバなどでホイールの溝にかかっている金属をはずします。
- ホイールをはずします。
- ホイールを斜めにして、どちらかに隙間を作ります。
- ホイールを逆方向に斜めにするようにすると比較的うまくいきます。
- 最後に金属部品を外して、ホイールを元に戻します。
ねじの場所 |
スクロールホイール(上から):赤丸は金属部品 |
スクロールホイール(下から):赤丸はひっかかっている部分 |
スクロールホイール:ひっかかりを外した状態 |
分解後 |
戻すのは逆順に行えば問題ありません。戻すときはホイールに傷をつける可能性があるので注意が必要です。
以上でハードウェア的な行程は終了です。
あとは好みでLogicool Control CenterやSetPoint等でスクロールホイールの速度、加速度を調整してください。
ホイールの感覚がかなり変わるのでだいたいの人は調整は必要だと思われます。
私の場合は速度と加速度両方とも少しあげました。
慣れない最初のうちは少し気持ち悪く感じます。
自分にあわないと感じたら素直に戻すのをおすすめします。
2013年3月9日土曜日
Clonerベンチマーク
JavaにてdeepCopyを実装しようとしていてClonerライブラリがあるというので、ベンチマークしてみました。
また、 独自実装したdeepCopyを実装するためにdeepClonableインターフェース(deepCloneメソッドのみ)を作成しました。
さらに、それを実装した拡張ArrayList、拡張Stringクラスを実装しています。
グラフの横軸が拡張ArrayListの要素数です。
縦軸がコピーにかかった時間[秒]です。
中身は拡張Stringクラスです(正確にはList<List<String>>)。
結果はjvmに2GByteメモリを割り当てて計測しています。
グラフ上では見えず難いですが、cloneの結果は横軸と重なっています。
ここからは計測に利用したプログラムの説明を載せていきます。
計測プログラムで用いている各クラスなどを以下に示します。
コピーするのはList<List<List<String>>>型(ArrayList, Stringはそれぞれ拡張した物なので注意)です。
java.util.ArrayListのclone実装(java SE 6)
Serializableを利用したdeepCopy実装
拡張ArrayListのdeepCopy実装:各要素に対してdeepCopyメソッドを実行
拡張StringのdeepCopy実装:イミュータブルなので自分を返す
比較対象
- 通常のcloneメソッド(シャローコピー)
- 自分で実装したdeepCopy
- Serializableを利用したユーティリティ(DeeCopy)
- ClonerライブラリのDeepCopy
また、 独自実装したdeepCopyを実装するためにdeepClonableインターフェース(deepCloneメソッドのみ)を作成しました。
さらに、それを実装した拡張ArrayList、拡張Stringクラスを実装しています。
結果
グラフの横軸が拡張ArrayListの要素数です。
縦軸がコピーにかかった時間[秒]です。
中身は拡張Stringクラスです(正確にはList<List<String>>)。
結果はjvmに2GByteメモリを割り当てて計測しています。
グラフ上では見えず難いですが、cloneの結果は横軸と重なっています。
簡単な考察
- clone > 独自実装 > Serializable > Clonerライブラリの順で速い
- 通常はcloneメソッドでなんとかする
- deepCopyがどうしても欲しいなら、使用頻度やパフォーマンスと相談して3つのどれか選択すればいい
- cloneはグラフではわからないが要素数に比例している。ただし、他よりかなり高速
- 独自実装をうまくやると高速
- Serializableを用いた方法ではSerializableを実装していないと利用できない制約がある。
- Clonerには制約はない。
- Clonerが遅いのは内部でリフレクションを用いているためである。ただし、コピーするクラスによってはリフレクションの使用を抑え速くなるように工夫されている。
- コピーしたオブジェクトによってはこれと異なる結果になる可能性もある。
ここからは計測に利用したプログラムの説明を載せていきます。
計測プログラム
計測プログラムで用いている各クラスなどを以下に示します。
- com.rits.cloning.Clonerクラス:Clonerライブラリ
- yuu.akron.ucollection.another.ArrayListクラス:拡張ArrayList
- yuu.akron.ucollection.interfaces.another.Listインターフェース:拡張Listインターフェース
- yuu.akron.ulang.DeepCloneUtilsクラス:Serializableを利用したdeepCopyユーティリティクラス
- yuu.akron.ulang.S.Sメソッド:java.lang.Stringクラスを拡張Stringクラスに変更する静的メソッド
- yuu.akron.ulang.Stringクラス:拡張Stringクラス
コピーするのはList<List<List<String>>>型(ArrayList, Stringはそれぞれ拡張した物なので注意)です。
java.util.ArrayListのclone実装(java SE 6)
Serializableを利用したdeepCopy実装
拡張ArrayListのdeepCopy実装:各要素に対してdeepCopyメソッドを実行
拡張StringのdeepCopy実装:イミュータブルなので自分を返す
登録:
投稿 (Atom)