2013年11月12日火曜日

OCN モバイル ONEの通信量を知りたい。

GL04PとOCNのSIMカードを利用してから3週間くらい経過しました。
使用感覚としては、容量の上限である1日30MBを超えたあたりから速度が落ちるためか、だいぶ待たされる感じがします。

ただし、通信状況が悪いためか、30MBを超えたためかは判断が難しく、どちらの影響でWebページの読み込みが遅いのかはわかっていません。

Wi-FiのSSID毎の使用量を確認することができれば、自分に必要な通信量が見えてくるかもしれないですが。。。
1ヶ月で1GBあればいいのか、1日30MBあればいいのか。データがないので判断できません。

個人的な感想ですが、携帯のキャリアへ支払うパケット定額の料金を支払うくらいなら、ちょっとくらい通信が不便でも十分使えると思ってます。

気になるのは、どのプランが自分にとって最適なのか。です。
しばらくは、1日30MBプランで十分かと思ってます。

ちなみに、十分なデータは取ってませんが、速度制限は30mbを超えたら即座に200kbpsではないようです。
超えたばかりの時は、600kbps程でしたが、40mbを超えた頃に200kbpsとなってました。

2013年10月18日金曜日

GL04PにOCN モバイル ONEのSIMカードを挿入してみた

普段の通勤圏であれば、WiMaxで問題なかったけれどちょっと出かけたり、デパートやショッピングモール内に入ると電波が届かなくなるのに不満がつのったため、OCNのモバイルONEに乗り換えてみた。

利用した端末は以下
・GL04P (イーモバイル)

GL04Pの設定は以下のページを参考にしました。
※APNの設定部分だけ、モバイルONE申し込み完了時に表示されるAPNに読み替えれば問題なく接続出来ました。

http://tech.support.ntt.com/ocn/mobile/em_entry_lte/gl04p/setup_windows.html

まだ設定したばかりですが、WiMaxに比べると速度は落ちる印象があります。
#正確な速度測定はしていません。あくまで体感です。

端末は少し大きめで、スマートフォンと同じくらいの重さに感じます。
ただ、通信をしなければスリープしてくれるというので、カバンにしまったままにできるのではと期待しています。
WiMaxの時は端末が対応していなかったので、スリープモードからの解除は必ずボタンを押す必要がありました。
そのため、いつもポケットに入れてました。

GL04Pはポケットに入れっぱなしにするには大きすぎる気がします。

2013年9月23日月曜日

ペヤング辛口 食べてみた

夜食に困って近隣のドラックストアをふらふらしていたところ、ペヤングの辛口を発見
今まで、普通のペヤングしか食べたことがなかったので興味本位で購入。

http://www.peyoung.co.jp/item/product/8

実際に食べてみました。

感想としては、正直ここまで辛いとは思ってませんでした。
あまりの辛さに口を水でゆすぎましたが対処できず、インターネットで検索して牛乳を飲むと良いというので試したところ驚くほど辛さが引いていきました。

完全には辛さが引きませんでしたが、耐えられる程度にはなりました(汗)


2013年9月17日火曜日

iMac 2012 と ロジテックDVD( LDR-PMG8U3LSV)を接続してみた

iMacにDVDドライブが欲しかったので、安めのドライブとしてLogitec社のDVDドライブを購入しました。
接続してみたところ、正常に動作せずまともにDVD再生などできませんでした。


環境
OS : OS X 10.8.5
筐体:  iMac 27 inch ( 2012 )

接続対象
DVDドライブ: Logitec社 LDR-PMG8U3LSV


試したこと
まず、バスパワーで動作するとの事だったので、DVDドライブとiMacをUSBのみで接続しました。
Mac接続後は軽快に動作しているように見えましたが、「故障箇所をスキップします」のようなメッセージが頻繁に画面に表示され、しまいにはDVD Player(Mac標準のソフト)が強制終了しました。

なんどかDVDを変更し、試してみましたがうまくいかないため、Windowsへ接続(詳細は省略)
Windowsではなんの問題もなくバスパワー単体で動作するため、DVDドライブの初期不良の疑いを排除しました。
また、バスパワーだけで動作することから、iMacからの供給電力が不足しているのではないかと推測。

純正ではないですが、BUFFALO製の外部電源供給ACアダプタ AC-DC5-BKを接続した状態で再度挑戦。

しかしながら、状況は改善せず。

旧式のMacbookに上記アダプタを接続した状態では、動作しているように見えたので、iMacを疑い、Appleのサポートへ連絡。

いっとお決まりの手順であろう、以下の内容を実施させられるも、効果なし。
・SMCのリセット
・起動時にシフトキーを押した状態での設定リセット
・OS再インストール

結局Mac純正の USB SuperDriveを購入することに。
現在動作確認中ですが、あれだけ「故障」とか表示されてたDVDがなんの問題もなく動作している。

なんか悔しい。

2013年8月19日月曜日

ScheduledExecutorServiceが停止した。

なんの前触れもなく、ScheduledExecutorServiceが停止してしまった。
実行のため、invokeしていたThreadクラスに問題があったのかどうか調べたけど、そうでも無さそう。

そんなとき、ScheduledExecutorServiceが動かなくなるという現象について書かれた記事を見つけた。

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7139684

どうやらスレッドを起動するために利用している OSレベルの処理でシグナル受信に失敗し、起動するはずのスレッドが起動しないままになってしまっているようだ。
しかも、一度失敗すると二度と起動しないという。。。。。


みたところ、回避策は提示されていないので、この現象にはまったら、プロセスの再起動だろうか。
shutdown()と、submit()で、復旧できるといいんだけど。

2013年8月17日土曜日

new Date().getTime() と System.currentTimeMillis() どちらが早いのか を調べてみた

先ほどの投稿から、ちょっと気になったので調べてみた。
大したことではないですけど、時間を取得したり計測するのに、よく使うんじゃないかと思いますが、
どちらが高速なのか。が気になって調べてみました。

結果から言うと、System.currentTimeMillis()の方が倍高速です。
どちらも1000000回実行した時の合計時間です。

new Date().getTime()         188ms
System.currentTimeMillis()     91ms

インスタンス生成に時間がかかるのでしょうかね。
1000000回なので、どっちを使おうがあまり関係ない位だと思いますが、どちらかというと軽いのでSystem.currentTimeMills()を使ったほうが余計なことしないのでいいかなと。思いました。

計測環境を記載していないのは、実効速度を調べたかったのではなく、どちらが早いかを確認したかっただけなので載せてないです。マシンによって差があるというのであれば考えますが.....
OSはWindows Vistaです。

ソースは汚いですが、以下です。
import java.util.Arrays;
import java.util.Date;
import java.util.Iterator;
public class PerformanceSample {
/**
* @param args
*/
public static void main(String[] args) {
ExecuterIf process = null;
// NewDate
process = new NewDate();
PerformanceMesure.execute(process);
// currentTimeMillis
process = new SystemCurrent();
PerformanceMesure.execute(process);
}
}
class NewDate implements ExecuterIf{
@Override
public void exec(){
long time = new Date().getTime();
}
}
class SystemCurrent implements ExecuterIf{
@Override
public void exec(){
long time = System.currentTimeMillis();
}
}
interface ExecuterIf{
public void exec();
}
class PerformanceMesure{
public static void execute(ExecuterIf process){
long start = 0L;
long end = 0L;
long elapse = 0L;
start = System.currentTimeMillis();
for(int m = 0 ; m  < 1000000; m ++)
process.exec();
end = System.currentTimeMillis();
elapse = end - start;
System.out.println(elapse + "ms");
}
}

Exceptionを利用したループのハンドリング性能

Effective Java の Item57 にあるwhileループのやってはいけない例について調べてみました。
たぶん、こんな使い方する人はいないんだと思いますが、悪いことしかないってことを確かめたかったので。

調べたのは性能です。ソースを見るとわかりますが、エラーなのかループの終了なのか判断できないため、使う人はいないと思います。

以下の2つの性能を比較しました。
例1)
// Horrible abuse of exceptions. Don't ever do this!
try{
  int i = 0;
  while(true)
    range[i++].climb();
}catch{ArrayIndexOutOfBoundsException e{
}
例2)
int i = 0;
while(range. length > i)
  range[i++].climb();
配列のサイズは100、試行回数は1万回。累積時間(ms)を計測した結果です。

例1  230ms
例2  2ms

こんなに差があるとは思ってなかったですが、100倍違います。

EffectiveJavaでは、現在のJVMを利用した場合は遅い。とか書いてありましたが、昔は早かったのでしょうか。
そうだとすると、悪い書き方をしたソースがあるかもしれないですよね....
この例だけでは言えませんが、正当な作り方をしておくと、のちのち性能が上がるかも知れない。
ということでしょうか。
その場しのぎのコーディングはやめようと思います。