Akronの開発室（仮）

ブログ休止のお知らせ

2014-04-01T08:00:00.000+09:00

~~※　このエントリーは3ヶ月前に書かれ、3ヶ月後に自動投稿されるように設定されたものです。~~

~~現在、ブログ主が更新できない状態です。~~
~~忙しいだけかもしれないし、ネットにアクセスできない状態かもしれません。~~
~~もしくはもうこの世にいないかもしれません。~~

~~更新されるかどうかは不明です。~~
~~いつまでこのブログと関連ページが存在するかはわかりません。~~

~~必要であればJKaiUI Custom等をダウンロードして保存しておいてください。~~
~~なお、ライセンス等はお守りください。~~

~~最後に、今まで開発に協力してくれた方に感謝の言葉を述べたいと思います。~~
~~協力ありがとうございました。~~

OS X 10.9 Mavericksでの動作確認

2013-11-09T08:00:00.000+09:00

OS X 10.9が出たので早速インストールしてJKaiUI Customとkaiengine、jRenamerの動作を確認してみました。

結論から言うとどれも問題なく動作しました。

JKaiUIとjRenamerはもともとjavaで書かれた物なので問題ないと推測していましたが、問題はkaiengineでした。

ちなみに実際に接続して遊んでみた結果、以前と同様に遊べたことから問題ないと判断しました。

コンピュータへの雷対策

2013-10-19T08:00:00.000+09:00

最近、雷がすごい近くに落ちてヒヤヒヤしたので対策について調査してみた。

まず一般的なことをwikiにて調査。
・雷サージ
・サージ防護機器

２つを見ると、本格的な対策には避雷針、避雷器などが必要なようです。
日本では個人宅ではまず無いようです。
賃貸なら対策してあるのを選ぶのが一番いいかと思います。
高さ２０m以上なら法律上必要とからしいです。

さて、本格的な対策が無理な場合を考えます。

物理的な対策

雷の気配がしたらコンセントから機器を抜く

抜いているときに雷が落ちると感電死する可能性があります。

LANを可能な限り無線にする（LANからのダメージを防ぐ）

802.11acなら結構速い

雷サージ対策のテーブルタップを利用する

気休め程度と考えた方がいい

モバイルPCを利用

雷の気配がしたらコンセントから分離

ソフトウェア的な対策

バックアップを作成しておく

HDDなどにバックアップを保存し、電源から切り離しておいておく
外部のバックアップサービスを利用する

Dropboxなどを利用するのが一番簡単かも

その他

保険に入る

以上が私が考えた対策です。

javaアプリをWindowsのexe形式にする

2013-10-12T08:00:00.000+09:00

JavaアプリをExe化するLaunch4jの使い方と仕組み

上を参考にしました。

javaアプリをMac OS XのApp形式にする

2013-10-05T08:00:00.000+09:00

JAVAアプリをMac OS X用にApplication Bundle化する

上が参考になります。

Java 6ではJarBundlerをJava 7以降ではAppBundlerを用いれば楽なようです。

jRenamerを公開しました。

2013-09-28T08:00:00.000+09:00

jRenamer ver.0.1.0alphaを公開しました。
ファイル置き場においてあります。

jRenamerは名前の通りにリネームするソフトウェアです。
大量にあるファイルからある程度法則性のある名前をリネームする用途で作成されています。
jRenamerはJava 6以降で動作します。
また、本ソフトウェアはフリーウェアです。
現状、アルファ版のためバックアップをとるなど注意して利用してください。

使い方等はReadMeまたは起動後のメニューから見てください。

jKaiUI Custom ver.0.4.1の公開をやめました。

2013-09-21T08:00:00.000+09:00

必要ならver.0.5.1をご利用ください。

どうしても必要なら連絡くれれば渡します。

lombok（javaライブラリ）の紹介

2013-09-14T08:00:00.000+09:00

Javaでコードを書くのがだるすぎたけどLombok使ったら思いのほか楽しかった
を読んでみたところ便利そうだったので紹介します。

lombokはIDEなどで自動生成できるようなコードをコンパイル時に自動生成するようにすることでコード量を減らすのが目的のライブラリのようである。
具体的には以下のようなことができる。

C#, Objective-C のようなプロパティ（Getter, Setter）
toString, equals, hashCodeメソッドの自動生成
コンストラクタの自動生成
Scalaのようなval変数（型指定のいらない定数）
委譲するメソッドを自動生成

上で紹介したのはよく使いそうな機能である。
他にもいくつかあるのが興味があればここを参考にしてください。
使い方はここが参考になります。

どうやってるのか少し興味がありjavassistとかを使ってるのかと思いソースを調べてみました。
ただ単純にAnnotation Processorで実現しているようである。

文字コード判別ライブラリ（java）

2013-09-07T08:00:00.000+09:00

文字コードの判別について調べていたのですが、思った以上に面倒そうなので、既存のものを利用することにした。

juniversalchardet

主要なのは判定可能。

迷惑メール対策

2013-08-31T08:00:00.000+09:00

メールを利用していればたいてい迷惑メールを受信したことがあると思う。
迷惑メールはかなり面倒な存在である。
これらの対策にはいろいろな方法が存在し、いろいろ提供されている。
プロバイダで提供しているもの、クライアントソフトで提供しているものなどがある。
今回は私が利用しているメーラー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にない場合は迷惑メールとする。
タグがない場合以外ではタグをつけない。

メーリングリストなどでは自分のアドレスが含まれない場合があるため。
他のフィルタでタグ付けされるように設定する。

例：

条件１：差出人または宛先、CC、BCCに次を含まない　自分のアドレス
条件２：タグが空

フォルダ振り分けルール

タグに基づいてフォルダ振り分けを行う

例：タグに次を含む

まとめ

迷惑メールフィルタでは基本的にメールの中身を見て過去のメールと似たものを迷惑メールと判定している。
この方法では、迷惑メールではないものを迷惑メールと判定してしまう場合がどうしても発生する。
そのような場合がなるべくなくなるような方法を考案している。
また、スマホなどでフォルダ分けした場合に受信ボックス以外を見れないなどの弊害をなくすことも考慮している。

この方法では欠点もある。
１つ目は設定が煩雑であること。
自分が送受信するメールのアドレスをある程度把握している必要がある。
また、送受信するアドレスが変化した場合にフィルタのメンテナンスが必要であること。
2つ目はフィルタリングが多段になるために処理が時間がかかること。

以上のような利点と欠点を持っているが、個人的にはかなり便利になった。
迷惑メールで困っている方の参考になれば幸いです。

Javaコーディング規約

2013-08-24T08:00:00.000+09:00

ここのがすごい参考になりました。
http://www.acroquest.co.jp/webworkshop/javacordingrule/javacordingrule.html

gmailに他のメールアドレスを統合

2013-08-17T08:00:00.000+09:00

gmailで他のメールを受信するようにすることでメールアカウントを統合できます。

やり方は以下を参照。
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

例では合計８つのアカウントを統合しています。
黒丸が統合先アカウント、白丸がgmail#1で受信するアカウント、黒四角がgmail#2で受信するアカウントになります。
この方法の問題点は段の低い方（例では黒四角）がより受信に時間がかかるということです。
なので、低い段には重要度が低いアドレスをおくといいです。

吉里吉里 KAGでのfor, foreachマクロ

2013-08-10T08:00:00.000+09:00

吉里吉里のKAGには繰り返しがありません。
そこでマクロを作ってみました。

そこそこうまくできたのですが、不満点というか欠点として繰り返し処理（for文の中身）を一連の流れの外に書く必要があります。
もっと使いやすくしたのですが現状ではここまでが限界でした。
もっといいのがある。もっと良くできる。など意見があれば連絡ください。

マクロの説明

最初に通常KAGで私が書くときの書き方を
次に、作成したマクロの使用例をいくつか書きます。
最後にマクロの中身です。

KAGでのfor文

０から９を表示するだけです。

for, foreachマクロの使用例

for文1
上の例と同じく０から９を表示します。
tf.iを増やしながら*doのラベルの処理を行います。
tf.iの初期値は０です。

for文2
こちらは２から９を表示します。
startでtf.iの初期値を指定できます。

foreach文１
foreach文の例です。
この例では配列内の数値が順番に表示されます。
listに配列もしくは配列の入った変数名を指定できます
tf.elemが各要素になります。

foreach文２
scenarioフォルダ内のファイルを表示する例です。

foreach文３
bgmフォルダ内のファイル一覧から再生リストを作成する例です。
listを指定しない場合はtf.listが操作される配列になります。
そうすることでtf.listとtf.iでtf.elemのかわりをすることができます。
tf.elemで書くと面倒な場合などで利用できます。
この場合、tf.elemにそのまま置き換えるとファイル名が変数名と判断されるためにエラーになるためにこのようにしています。
（tf.elemでもエスケープシーケンスを使って文字列扱いにすれば解決できます。）

foreach文４
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引数を追加するだけでおそらく可能です。

AVGの演出技術

2013-08-03T08:00:00.000+09:00

AVGの演出技術に調べていて大変参考になるものを見つけたので紹介しておきます。

http://hwm2.gyao.ne.jp/serio/games/direction.html

長いけどとても参考になります。
2011年が最終アップデートなので最近の情報がないのが残念な点です。
が、今でも十分に通用するでしょう。
もう一つ、残念な点に文字ばっかりというのがありますが版権の都合上しょうがないかと。
体験版探して自分で確かめるのが一番いいかも。
もちろん、時間とお金があれば製品版で確かめるのもありです。

というか、どれくらいゲームやったのかが気になる・・

Xlink kai仕組み３

2013-07-27T08:00:00.000+09:00

Xlink Kaiを解析した結果の説明の３回中の3回目です。

Kaiの通信は主に３つの系統に分かれると説明しました。
１つはチャットやアリーナの移動などのKaiのサーバーを介した通信です。
２つ目はPSP間の通信です。
３つ目はPM（Private Message）やり取りを行う通信です。

下の図はそれら３つの通信をまとめた図です。

今回は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をいろいろ解析した結果をまとめてみました。

Xlink Kai仕組み２

2013-07-20T08:00:00.000+09:00

Xlink Kaiを解析した結果の３回中の２回目です。

Kaiの通信は主に３つの系統に分かれると説明しました。
１つはチャットやアリーナの移動などのKaiのサーバーを介した通信です。
２つ目はPSP間の通信です。
３つ目はPM（Private Message）やり取りを行う通信です。

下の図はそれら３つの通信をまとめた図です。

今回は２つ目について主に説明していきます。
上の図で通信経路は矢印で表されています。
黄の矢印は２つ目に用いられる通信経路です。
ここで行われる通信は主に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のやりとりを行う通信について説明していきます。

Xlink kai仕組み１

2013-07-13T08:00:00.000+09:00

今更ながらXlink Kaiを解析した結果について３回に分けて説明していきます。

Kaiの通信は主に３つの系統に分かれます。
１つはチャットやアリーナの移動などのKaiのサーバーを介した通信です。
２つ目はPSP間の通信です。
３つ目はPM（Private Message）やり取りを行う通信です。

下の図はそれら３つの通信をまとめた図です。

今回は１つ目について主に説明していきます。
上の図で通信経路は矢印で表されています。
赤の矢印は１つ目に用いられる通信経路です。
ここで行われる通信は主にアリーナの情報を受け取り、アリーナ移動などのユーザー操作をサーバーに送信します。

ここで少し詳しく通信プロトコルについてみていきます。
KaiではTCPとUDPを使い分けています。
TCPとUDPがわからない人に簡単に説明すると、TCPが信頼性があり、UDPが信頼性がない通信ということだけわかればここではいいです。
すなわち、TCPではほぼ確実にパケットが相手に届くが、UDPでは届かない場合もあるということです。
各コンポーネント間の通信をみていきます。
KaiEngineとサーバー間の通信はTCP通信です。
User InterfaceとKaiEngine間の通信はTCPもUDPでもどちらの場合もあります。
しかし、これはコンピュータ内のローカルな通信です。
そのため、UDPでもほぼ信頼性があります。
よって、この１つ目の通信経路が信頼性がある経路であることがわかります。
それに対して、２つ目と３つ目の通信経路は信頼性がありません。
これについては次回以降に説明していきます。
１つ目の経路は信頼性があるといいましたが、実際チャットなどが相手に届かなかったことはないと思います。

先ほどUser InterfaceとKaiEngine間はTCP、UDPどちらもあり得ると書きました。
それは旧UIはUDP通信であり、Web UIと呼ばれるWebブラウザで操作を行うものはTCP通信なためです。

最後にセキュリティ関係の話を書いていきます。
２つ目、３つ目の通信ではサーバーを介さないkaiengine間の通信を行います。
これを行うには通信相手のIPアドレスが必要です。
この情報はサーバーからkaiengineに送られてきます。
kaiengineとサーバー間の通信は平文で行われてるため、この情報を簡単に手に入れられます。
すなわち、Xtagとその人の接続もとIPアドレスです。
IPアドレスがわかれば住んでいる大まかな地域などがわかります。
場合によっては細かい情報までわかるようです。
このようにXlink Kaiはあまりセキュリティ的にはよろしくないようです。

次回は２つ目のPSP間の通信について説明します。

MacでのWindowsキーボードの使用

2013-07-06T08:00:00.001+09:00

Windows用のキーボードをMacで利用する方法をメモしておきます。
利用するのはKeyRemap4Macbookとそれに付属のPCKeyboardHackです。

説明用キーボード

Realforce 91(JIS)

異なるキー

WindowsとMacのキーボードで異なるキーを示します。
対応するキーがある場合は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

これらは設定する必要のあるキーの候補です。
これらは上記のように４種に分けることができます。
１種目は同様な機能が割り当てられているキーで設定をする必要はありません。
２種目は Macでは認識しないキーです。
PCKeyboardHackで設定を行う必要があります。
３種目は印字と異なるキーが割り当てられているキーです。
４種目は認識はされますがMacでは使われないキーのために意味のないキーです。
３種目と４種目は必要であればKeyRemap4Macbookで別のキーを割り当てます。

設定例

今回はなるべくApple製のキーボード配列(JIS)に近くなるようにします。
変更するキーについてまとめておきます。

無変換：JIS_KANA
変換：JIS_EISUU
かな：Command_R
全角半角：Escape
Application：Fn
Escape：Eject

１−３は認識しないキーなのでPCKeyboardHackで設定します。
設定した状態の画面は以下。

下の方にある「for Japanese」下の３つの項目をチェックします。
今回はデフォルトで上記のキー設定になっているので他は変更しません。
もし必要ならば一番右の欄のkeycodeを下の表を見ながら変更しましょう。

４−６は KeyRemap4Macbookで設定します。
設定した状態の画面は以下。

以下のような項目をチェックします。

４：Change Backquate Key > Backquate to Escape
５：For PC Users > Change PC application Key > Application Key to Fn
５：Change F1..F19 Key & Functional Key > Change F1..F19 Key > Separately settings Fn+F1..F12 to Functiolnal
６：Change Escape Key > Escape to Eject

５の設定ではApplicationキーをFnキーに変えただけではうまく利用できないためにFnキーとFx(xは数字)キーの組み合わせで特殊機能を利用できるようにします。

最後に

KeyRemap4MacbookとPCKeyboardHackを用いてWindowsキーボードをMacで利用する方法を説明しました。
今回はApple製キーボード（JIS）に近くなるようしましたが、実は細かいところでまだ違いあります（Caps LockやCtlの位置など）。

OS X Serverを用いたTimeCapsuleもどきを構築

2013-06-29T08:00:00.001+09:00

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やヤフオクで４、５000円位で入手可能
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ではバックアップ先を複数指定可能

keynoteで接続線、曲線

2013-06-22T08:00:00.000+09:00

keynoteで図を書く必要がありました。
そのとき、パワポのようにオブジェクト同士を矢印つなげたり、曲線を書く場合にどうすればいいかを調べた結果です。

接続の線を作成する方法
ベジェ曲線の書き方

個人的にはこれができればパワポと同じように図が作成できます。
ただ、一つ問題として接続の線は同じオブジェクト間では一つしか線を作成できないようです。

ゲームエンジン比較

2013-06-15T08:00:00.000+09:00

ノベルゲームを作るかもしれないので、ノベルゲーム用エンジンをいくつか調べてみました。
そのときの個人的な比較を書いておきます。

比較対象は以下の７つです。

比較対象

比較項目

対応プラットフォーム
ライセンス
情報量
実績
開発環境
拡張性

前提

比較はプログラマ視点が基本です。
ゲーム作成は一人ではなく、プログラム素人のシナリオライターもスクリプトをいじることを考慮します。
デバッグでグラフィッカーや音声の人もいじる可能性もあります。

比較評価

1. 吉里吉里２

先に結論を書いておきますが採用する予定なのは吉里吉里です。

対応プラットフォーム：Windows系のみ
ライセンス：どのようなのでも無償
情報量：豊富
実績：有名なのいろいろ
開発環境：kkdeなるものがある。

コード補完、コードの色分けをしてくれます。
統合開発環境で初心者でも使いやすいです。

拡張性：TJSを使えば幅広い拡張が可能

2. NScripter(ONScripter)

対応プラットフォーム：Windowsのみ

（ONScripterで他のプラットフォームに移植可能）

ライセンス：商用は有料
情報量：多い
実績：十分
開発環境：さくらエディタなどで設定するとコード補完などが可能

プログラマはいいが他の人に設定してもらうのが面倒そう

拡張性：C++で書く必要がある。

ちょっと面倒

3. RealLiveMax

VitualArtsから無償貸与扱い。届け出が必要。

対応プラットフォーム：Windows系

更新されることはないと思うので新しいWindowsではどうなるかが不安なところ

ライセンス：どのようなのでも無償
情報量：少なめ
実績：商用に利用されていたので
開発環境：さくらエディタでコード補完等可能
拡張性：C++で書く。

拡張しなくても豊富な機能があるらしい

4. Ren'Py

対応プラットフォーム：Windows, Mac OS X, Linux, Android
ライセンス：無償（MITライセンス）
情報量：日本語情報は少なめ、英語は十分にある。
実績：海外での実績はそこそこある
開発環境：既存のプログラム言語pythonを利用しているので流用可能
拡張性：pythonで書かれたものを流用可能

他言語で利用できるように設計されているが日本語で一部問題がある場合がある。

5. LiveMaker

対応プラットフォーム：Windows
ライセンス：どのようなのでも無償
情報量：そこそこ？
実績：フリーのゲームは結構ある模様。詳細は不明
開発環境：GUIで作成できます。
拡張性：少ないかも。詳細不明

6. Yuuki!Novel

LiveMakerとそんなにかわらないので略。

7. ADV+++

対応プラットフォーム：Windows系、Mac OS X系など
ライセンス：カンパウェア
情報量：少なめ（有料のコミュニティに入るのが必須かも）
実績：プロが作ったもの
開発環境：不明

アセンブリ風言語で開発

拡張性：できない？詳細不明

まとめ

採用予定なのは吉里吉里２です。
吉里吉里を採用した理由は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-06-08T08:00:00.000+09:00

乾電池には単３、単４などのサイズによる規格がある。
小さいものにアダプタをかぶせて大きい規格の電池として利用するのがアダプタもしくはスペーサーと呼ばれている。
単４を単３として利用するスペーサーの例である。

これらは何に使うかというと主に2つの利用方法がある。
一つは現状ではあまり見かけない単２や単１などの乾電池を替わりをさせるためでる。
もう一つは、軽量化をはかるためである。
重量的に「単３　＞　単４+スペーサー」であるために単３を単４で置き換えて軽量化可能である。

実際にエネループ、上であげたスペーサーの重量を計測してみた。

結果

エネループ単３：26g
エネループ単４：12g
スペーサー：3g

結果より11g、40%ほど軽量化できていることがわかる。

軽量化はできるがサイズが小さい電池を用いるために電池の容量が小さくなる。
すなわち、電池切れまでの時間が短くなる。

以下、容量の比較をしてみる。
エネループ単３：1900mAh
エネループ単４： 750mAh

容量は60%減である。
重さに比べ容量の減少の方が大きい。
そのため、大きい電力を必要とする機器ではあまりよろしくない場合があると思われる。

まとめ

容量の問題もあるが電池2つの場合20gくらい軽量化できるため、よく持ち運ぶ物で利用したい。

Lion, Mountain LionにJDK 5をインストールする方法

2013-06-01T08:00:00.001+09:00

JDK 6上で作成したJavaプログラムはJava 5以前でもそのまま動くと思ってたんですが、そうではないらしい。
ということで今回はMountain LIonにJDK 5をインストールする方法を探していたら見つけたスクリプトを紹介します。

スクリプト：https://gist.github.com/bric3/1163008

ダウンロードからインストールまでほぼ自動でやってくれます。

jkaiUI Custom ver.0.5.1-jdk5（Leopard PPC用）を公開しました

2013-05-25T08:00:00.000+09:00

Mac OS X Leopard(PPC)にてjkaiUI Custom ver.0.5.1などが動かないという報告が来たので修正したバージョンを公開しました。
ファイル置き場の方においてあります。

主な修正点は以下になります。

チャット画面において右クリックメニューから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プラグインをオフにすること推奨します。

最後に、報告とログの採取に協力してくれた方には感謝をいたします。
ありがとうございました。

PlanexがXlink kaiのサポート（スポンサー）をやめた模様

2013-05-18T14:30:00.000+09:00

Xlink kaiのスポンサーからPlanexが降りるようです。

以下、情報元
http://www.teamxlink.co.uk/forum/viewtopic.php?p=235774

もう人があまりいないので宣伝効果が薄いと判断されたのかも。

Xlink Kai自体はユーザーがいる限りサービスを続けるようです。
ただ、いくつか影響がある模様。
現状での影響として日本国内のサーバがなくなったことがあります。
人が少ない状況ではそれほど大きな影響ではないでしょう。
他に、メインサイトの移転がされているようです。
また、将来的にコンソール（ゲーム機）、接続元の位置、コンソールのハードウェアベンダーによってアクセスが制限されるようになるかもしれないようである。