mp3: ベートーベン ピアノソナタ第26番
ベートーベン ピアノソナタ第26番「告別」
Beethoven Piano Sonata No26 "Les Aduieux"
Italian Grand2で演奏。ハーフペダルとソフトペダルが、あると無いとでは表現の幅が全く違う
JBossを狙ったwormにやられてしまいました。
JBossを狙ったwormにやられてしまいました。
侵入されたwormは、どうやらこれのよう。ここに解説があります。
ここに書くことは、私が個人的に調べたことで、必ずしも正しくない場合があります。
アクセスログを見て、HEAD /jmx-console/HtmlAdaptor... のような身に覚えのないリクエストがあり、サーバが200を返していたら、やられている可能性が高いです。サーバのカレントディレクトリ(通常はJBossのbinディレクトリ)に、pnscanとかfly.plのような見慣れないファイルがあるようなら、100%やられています。
jmx-consoleにきちんとユーザ、パスワードを設定していないことが原因で、これにより外部から管理用のWebアプリケーションをデプロイできてしまうようです。上記のページには、きちんとjmx-consoleにユーザ、パスワードを設定する方法が記載されていますが、一度でも侵入されてしまった場合、バックドアアプリケーションがデプロイされてしまっているので、jmx-consoleだけ手当してもwormがどんどん入ってきてしまいます。
基本的にはサーバを綺麗に入れ直すのが良いと思いますが、本稼働中だと、なかなかそうもいかないので、私は以下のようにしました。まずJBossを落とします。jmx-consoleとweb-consoleは使用していなかったので、deploy/jmx-console.war、deploy/management/console-mgr.sarをリネームしました。あと、deploy/managementの下に、idssvc.war、iesvc.war、zecmd.war、zlpwhWeJ.warというディレクトリがあるようであれば削除します。私の場合は特に見つかりませんでしたが、deploy直下に怪しいwarがあるようなら、それも削除(リネーム)します。あと、念のためdeploy/workも削除しておきました。binディレクトリに送りこまれたwormも削除します。これでJBossを立ち上げて、アクセスログを監視し、サーバが200を返しているリクエストに怪しいものが無いことを確認します。とりあえず、うちのサーバはこの対処をしてからは侵入されていないようです。
繰り返しますが、ここに書いた内容は間違っているかもしれませんので、ご注意ください。
Play frameworkでデッドロック その4
こりゃあかん、
framework/src/play/server/ServletWrapper.java
private void copyStream(HttpServletResponse servletResponse, InputStream is) throws IOException {
OutputStream os = servletResponse.getOutputStream();
byte[] buffer = new byte[8096];
int read = 0;
while ((read = is.read(buffer)) > 0) {
os.write(buffer, 0, read);
}
os.flush();
is.close();
}
というわけで修正。
private void copyStream(HttpServletResponse servletResponse, InputStream is) throws IOException {
try {
OutputStream os = servletResponse.getOutputStream();
byte[] buffer = new byte[8096];
int read = 0;
while ((read = is.read(buffer)) > 0) {
os.write(buffer, 0, read);
}
os.flush();
}
finally {
try {
is.close();
}
catch (IOException e) {
Logger.error("Cannot close input stream.", e);
}
}
}
このパッチ当てておけば、とりあえず、warで実行する限りは問題なくなった。
こちらもバグ報告しておいた。
Play frameworkでデッドロック その3
war exportしたら、どうかなということで、warにしてTomcat7で動かしてみた。デッドロックは起きなくなったんだけど、
Caused by: java.io.FileNotFoundException: data/no07.mp3 (ファイルを開きすぎです)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:138)
at play.vfs.VirtualFile.inputstream(VirtualFile.java:109)
... 23 more
ぐは。途中で接続切れた時にファイルクローズしていないっぽい。う〜む、Play Framework面白いけど、ちゃんと運用するには、色々ストレスかけてテストしてみないと危ないな〜。
Play frameworkでデッドロック その2
ふと思い立って試してみたら、割と簡単に再現プログラムが出来たんで、バグ報告してみた。
Play framework内でのチャネルのcloseを削除してみたけど、やはりデッドロックするみたいだ。Nettyの動きをもうちょっと、ちゃんと勉強しないと、これ以上は無理だな。
Play frameworkでデッドロック
久し振りに時間ができたので、ピアノ発表会のページを更新。ここはPlay frameworkを試しに使ってみているのだけど、どうもある程度の確率でデッドロックするようで、だんだんワーカスレッドがいなくなっていってハングしてしまうという現象が起きている。スレッドダンプはこんな感じ。
Java stack information for the threads listed above: =================================================== "New I/O server worker #1-4": at org.jboss.netty.handler.stream.ChunkedWriteHandler.discard(ChunkedWriteHandler.java:153) - waiting to lock <0x00000007d93a3438> (a org.jboss.netty.handler.stream.ChunkedWriteHandler) at org.jboss.netty.handler.stream.ChunkedWriteHandler.handleUpstream(ChunkedWriteHandler.java:143) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:754) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.channelClosed(SimpleChannelUpstreamHandler.java:208) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:98) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:754) at org.jboss.netty.handler.codec.replay.ReplayingDecoder.cleanup(ReplayingDecoder.java:554) at org.jboss.netty.handler.codec.replay.ReplayingDecoder.channelClosed(ReplayingDecoder.java:455) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:98) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:540) at org.jboss.netty.channel.Channels.fireChannelClosed(Channels.java:404) at org.jboss.netty.channel.socket.nio.NioWorker.close(NioWorker.java:593) at org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:119) at org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:76) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:742) at org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:60) at org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:568) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:747) at org.jboss.netty.handler.stream.ChunkedWriteHandler.handleDownstream(ChunkedWriteHandler.java:114) at org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:568) at org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:563) at org.jboss.netty.channel.Channels.close(Channels.java:720) at org.jboss.netty.channel.AbstractChannel.close(AbstractChannel.java:208) at play.server.PlayHandler.exceptionCaught(PlayHandler.java:600) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:122) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:754) at org.jboss.netty.handler.stream.ChunkedWriteHandler.handleUpstream(ChunkedWriteHandler.java:148) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:754) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.exceptionCaught(SimpleChannelUpstreamHandler.java:148) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:122) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:754) at org.jboss.netty.handler.codec.replay.ReplayingDecoder.exceptionCaught(ReplayingDecoder.java:461) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:122) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:540) at org.jboss.netty.channel.Channels.fireExceptionCaught(Channels.java:432) at org.jboss.netty.channel.socket.nio.NioWorker.write0(NioWorker.java:509) - locked <0x00000007d93a3790> (a java.lang.Object) at org.jboss.netty.channel.socket.nio.NioWorker.writeFromTaskLoop(NioWorker.java:392) at org.jboss.netty.channel.socket.nio.NioSocketChannel$WriteTask.run(NioSocketChannel.java:276) at org.jboss.netty.channel.socket.nio.NioWorker.processWriteTaskQueue(NioWorker.java:268) at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:199) at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:44) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) "play-thread-2": at org.jboss.netty.channel.socket.nio.NioWorker.cleanUpWriteBuffer(NioWorker.java:609) - waiting to lock <0x00000007d93a3790> (a java.lang.Object) at org.jboss.netty.channel.socket.nio.NioWorker.writeFromUserCode(NioWorker.java:369) at org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:137) at org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:76) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:742) at org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:68) at org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:568) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:747) at org.jboss.netty.channel.Channels.write(Channels.java:632) at org.jboss.netty.handler.stream.ChunkedWriteHandler.flush(ChunkedWriteHandler.java:244) - locked <0x00000007d93a3438> (a org.jboss.netty.handler.stream.ChunkedWriteHandler) at org.jboss.netty.handler.stream.ChunkedWriteHandler.handleDownstream(ChunkedWriteHandler.java:124) at org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:568) at org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:563) at org.jboss.netty.channel.Channels.write(Channels.java:611) at org.jboss.netty.channel.Channels.write(Channels.java:578) at org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:259) at play.server.PlayHandler.copyResponse(PlayHandler.java:397) at play.server.PlayHandler$NettyInvocation.onSuccess(PlayHandler.java:229) at play.Invoker$Invocation.run(Invoker.java:267) at play.server.PlayHandler$NettyInvocation.run(PlayHandler.java:200) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Found 1 deadlock.
どうもNettyまわりのようで、ソケットへの書き込みで例外が発生したタイミングが怪しそう。これといった再現タイミングが見つからないので、簡単には直りそうにない。
P.S. どうもNioWorker側で、closeかかるので、
future.setFailure(t);
fireExceptionCaught(channel, t);
if (t instanceof IOException) {
open = false;
close(channel, succeededFuture(channel));
}
Play側でcloseかける必要は無い気がするんだけど、どうだろう。
@Override
public void exceptionCaught(ChannelHandlerContext ctx, ExceptionEvent e) throws Exception {
try {
e.getChannel().close();
} catch (Exception ex) {
}
}
mp3: ベートーベン ピアノソナタ第13番
ベートーベン ピアノソナタ第13番
Beethoven Piano Sonata No 13
幻想的な主題と、中間部の猛烈な速さとの対比が見事。ベートーベンの自信作だが、あまり有名にはならなかった不遇の名作。
JavaOneの写真
JavaOneで撮った写真。一応EF50mmとEF135mmも持って行ったけど、結局TS-E17しか使わなかった。
BARTの始発駅、ミルブレー。
水曜日のAppreciation Session。
ロックコンサートを深夜までやるのがOracle流らしい。。
ゲームコーナ。とは言え景品のぬいぐるみとかもらっても、持って帰るの大変だしなぁ。
豚の丸焼き、うまい!
最終日。Nikko HotelとHilton Hotelの間に休憩コーナがある。ジオラマ遊び。
セッション終了。夕方はSFを回る。
建物がいちいちシャレている。
すごい坂。
坂は、まだまだ続く。
坂を上まで登りきると、遠方に海が見える。
古い教会。
大分日が暮れてきた。
ふと上を見上げると、こういう屋根が落ちて来ないかと不安になる。実際結構欠けているし...
イスラム風
最終日は恒例の蟹パーティ。
蟹デカ! ニンニク炒めになっており、手をベタベタにしながらスパゲッティと一緒にいただく。ちなみに対面で手際良く蟹をさばいているのは、Jenkinsの川口さん。
JavaOne 1日目
キーノート。出席者は増えているそうでなりより。来年は東京でJavaOneがあるそうだ(Apr 4-6)。
最初のパートは、スポンサーIntel様の宣伝タイム。「この枠でこの内容ってことは、やはり一番お金を出してくれたんだろうな」などと邪推している横で、来場者は律儀に要所要所で拍手していて、みんなおとなだなぁと感心。なんかスループットの比較グラフで、1.7.0_01が、1.6.0_06の2倍以上の結果を叩き出しているんだけど、ハードウェアが違うんで、なんというか何を比較しているんだかって感じ。Oracle Fusionでは、同時に20000ユーザをさばけるのだそう。
NoSQLのパフォーマンス。96ノードまで良くスケールする。って製品名が出てこないんですけど、これってCoherenceの話ってわけじゃないんだろうか。
JavaSEの話は、いつも通りのProject Coin, InvokeDynamic, Fork/Joinの話。JigsawとLambdaはJava8に入る予定。型推論とかswitchでの文字列使用、マルチcatch、try-with-resource、16進数リテラルとかは、そろそろ食傷気味。で、知らなかった話題を2つ。1つ目はsafe rethrow
void m() throws X1, X2 {
try { /* X1, X2をスローする可能性のあるコード */ }
catch (Throwable e) {
throw e; // コンパイルエラー
}
}
この場合、try節内で発生するチェック例外がX1とX2だけであっても、Throwableでキャッチしてrethrowするから、throws節にThrowableが無いとコンパイルエラーになる。それを、
catch (final Throwable e) {
とすることで、rethrowできるようになるそうだ(さくらばさんからの指摘によると、finalは必須では無いらしい)。これは地味だけどJavaの例外の扱いでのストレスが減る良い改善だね(って書いていたら、どこかで見たような気もする)。もう1つが、safe varargs
public static <T> void print(T... a) {
for (T t : a) {
System.out.println(t);
}
}
public static void main(String[] args){
print(new Pair<Integer,String>(1,"One"), new Pair<Integer,String>(2,"Two"));
//WARNING: Type safety : A generic array of Pair<Integer,String>
//is created for a varargs parameter
}
この例は、ここから拝借したものだけど、可変引数は内部的には配列で実装されているんで、型パラメータを伴った型のオブジェクトを渡そうとすると警告が出る。で呼び出し側に、@SafeVarargsを付けてやると警告を抑制できるようになるそうだ。
@SafeVarargs
// WARNING SUPPRESSED: Type safety: Potential heap pollution via varargs parameter a
public static <T> void print(T... a) {
JRubyでの最適化が進んだそうだ。
def foo bar end def bar baz end def baz end
こんな例では、foo呼び出し => JRubyのコンテキスト => bar呼び出し => JRubyのコンテキスト => baz呼び出しとなって、思い切った最適化ができなかったのが、Java7でInvokeDynamicが入ったことで、foo -> bar -> bazとなってインライン化などの最適化が可能になったのだそう。これによりベンチマークで2-3倍の結果が出ていた。
Lambdaでは、卒業年が2011の生徒の成績の最大を求めるコードが以下のように書けますよという話。
double max = students.filter(s -> s.gradYear == 2011) .map(s-> s.core) .reduce(0.0, Math#max);
Math#maxという書き方は、staticメソッドをlambda式に変換するものらしい。まぁこのあたりはScalaとかではおなじみのやり方で、Javaでもようやくこういう書き方ができるようになるようだ。あと、
double max = students.parallel() .filter(s -> s.gradYear == 2011) .map(s-> s.core) .reduce(0.0, Math#max);
とすることで、並列実行もできるようになるそうだ。で、これらはIterableにfilterとか新たなメソッドを追加しなきゃいけないんだけど、そうすると既存のIterableを実装したコードがみんなコンパイルエラーになってしまう(そういえば、JDBCのConnectionとかバリバリメソッド追加されて、単体テストのモックがことごとくコンパイルエラーになって頭に来たよね)。で、インターフェースにdefault実装が追加できるようになるらしい。
interface Iterable{ Iterable filter(Predicate predicate) default Iterables.filter;
この場合Iterables.filterはstaticメソッドで、第一引数にthisが、第二引数にpredicateが渡される。これはC#のextension methodからインスパイアされたものかな。
Jigsawは依存関係の解決をするための仕様。昔はJAMファイルとか言ってなかったっけ。これによりJDKのライブラリも分割して、headlessだけ、とかdesktopだけという括りにして小さくできるのだそう。そういえばOSGiとの関係はどうなるんだろうか。いずれにせよMavenのXML嫌いなんで、こっちが主流になって欲しい。
Java9の予定
- Self tuning
- Improve native integration
- Big data
- Reification 型システムの改善(Primitiveの改善)
- Tail calls/continuation
- Meta-object protocolresource management
- Heterogeneous compute modules
Self tuningって、HotSpotもself tuningじゃないのかな。あまり聞き取れなかったけど覚えている範囲で解説すると、Big dataは2GB以上のデータを扱えるようにする。Reificationは、intみたいな特別なprimitive型を無くす(多分Scalaみたいになる？)。という感じ。
JavaFXではCross platformを強調(多分Androidを意識していると思われる)。あとは2.0が出たよとか、デモとか。ただ正直ケータイの方はAndroidでキマりな感じだし、プロプライエタリなRIAは、flashもsilverlightも受け入れられない感じなわけで、そんな中でどういう戦略でJavaFXをはやらせようと考えているのか、そういう戦略的な話がキーノートでは聞きたかったところ（さくらばさんからの指摘によると、戦略的な話は昨年あったそうで、今後はデスクトップに注力するようです）。
JavaEE7の話。データソースをアノテーションで書けるようにするそうだ（nekopさんからの指摘によると、データソースの記載はJavaEE6からの機能だそうです）。
@DataSourceDefinition( name="java:app/jdbc/myDB", className="oracle.jdbc.pool.OracleDatasSource", isolationLevel=TRANSACTION_REPEATABLE_READ, initialPoolSize=5 )
みたいな。JMSとかJavaMailのセッションもアノテーションで書けるようにするらしい。Entity BeanのCMP/BMPと、JAX-RPC、Deplyment APIは消される(オプション実装になる)予定だそうだ。
このあとJavaMEの話があったらしいけど、時間切れなのと仕事でも趣味でもいじること無さそうなので退室。
JavaOne 0日目
日曜日の朝9時ころにサンフランシスコ空港に到着。10時前にはホテルに到着。安いホテルなので仕方が無いのだろうけど、中心街から遠いだけじゃなく、金庫が無いわ、冷蔵庫が無いわで結構不便。そしてインターネット接続は1日$10とられる。これで1日$190は痛い。
JavaOneへの出席は月曜日からなので今日はのんびりと市内観光することにする。ホテルの最寄り駅はCaltrainのBroadwayという駅で、ここは休日しか電車がとまらない。今回の滞在中だと今日しか乗る機会が無さそうなので行ってみた。
すごい。改札も柵も何も無くて、誰でもホームに入れるわ簡単に線路に降りられるわの状態。そこへいきなり2階建の巨大な電車が汽笛を鳴らしながら突っこんでくる。夜とか事故にならないんだろうか。
休日便は1時間に1本。のんびりとサンフランシスコ方面行きを待つ。で、反対ホームに電車がやってくる。みんな普通に線路をまたいで渡って電車に乗り込む。
ちゃんと切符買ったけど、こんな感じで改札とか無いんで、全然チェックされなかった。San Brunoという駅でBARTという地下鉄に乗り換えようとしたら、えらく駅が離れていて30分くらい歩くはめに。あとはBARTで中心街まで行ける。BARTの方はプリペイドの磁気カードタイプになっている。Suicaみたいな感じかな。ちゃんと自動改札式。Clipperというカードを買うと割引があるらしく空港で売っているらしいんだけど、結局見つけられなかった。Powell駅に到着して出口で景観に圧倒される。
Oracleのブースに行って事前登録を済ませバッジをもらう。
これで今日の仕事は終了。あとはAT&Tに行ってSIMを買っておくことにした。で、いつものくせでAT&Tの場所を調べておくのを忘れた。最近出先でもオンラインなのが当たり前なので、ついつい下調べせずに出掛けちゃうんだよね。仕方が無いのでApple storeに行ってGoogle Mapを拝借。で、着いたのはAT&Tの会社の方だった．．．警備員(？)の人に、お店の場所を教えてもらいようやく到着。ちなみに住所は、705 Market Street San Francisco CA 94103。上海で買ったNOKIAのE66があるので、これを見せてプリペイドのSIMを買う。$25で国際電話付きのにしておいた。まぁ使い切れそうにないけど。
今回は光ポータブルも持ってきたんで、データバックの100MBを付けて、ってお願いしたら、その電話じゃパケット通信できないよ？ と釘をさされる。もう1台パケット通信できるの持ってるからといって、お願いしたら、もう1つ別の0円SIMが出てきてあとは自分でインターネットでデータパック買ってねと言われる。
とりあえず中心街で予定していたことは全部終わったので、ぶらぶらと回る。
到着した時は、14℃と言われたので、結構寒いかと思ったらとても快適。
帰りは、さすがに1時間待ちは避けて空港回りにしてホテルのシャトルで帰ってきた。ホテル周りもちょっと散歩。3分ほど歩くと海(湖？)がある。
で、光ポータブルでのSIM認識にてこずる。Googleで「サンフランシスコ 光ポータブル」あたりで引っかかる情報ではどうもうまくいかない。タイプが異なるようで、これはDataConnect Passというタイプみたい。https://buyasession.att.com/に行って、Prepaid DataConnect Passというのを登録すれば良いらしい。IMEI番号を聞かれるけど、光ポータブルには見当たらないんで、全然関係無いけどNOKIAのE66の方のIMEI番号を入れてみた。住所とかもホテルの住所を入力。特に問題無く使えているので、IMEI番号が結局何に使われているのかは不明。光ポータブルでは、APNをbroadbandにして、PIN、ユーザ、パスワードは入力無しでつながった。とりあえずこれで会期中はオンラインになった。
ベッドに耳栓が用意してあって、いやな予感がしていたけど、あぁやっぱり飛行場に近いだけあって、結構な轟音．．．
P.S. DataConnect Passでは、期間制限が厳しいので注意！
そんなには使わないだろうと、1番上の100MBとか選ぶと、1日で切れます。1MBしか使わなくても、1日で無情にexpireします！ 良く説明を読んでから契約してください。
EVO WiMAX雑感
EVO WiMAXに乗り換えて1か月近くたった。Androidは、HT-03A、IS01に続く3台目、ようやくメジャバージョンが2になった。HT-03AからIS01のパフォーマンスアップが劇的だったので、それと比べるとおとなし目ではあるけどブラウザの動きなどでもたつくことも無くなったし、やはりメモリに余裕があるのでタスクの切り替えが高速になっているのが分かる。フラッシュにも対応しているので微妙に便利。
それより大きいのは無線LANが安定していることで、IS01まではスタンバイ(？)からの復帰とかで良くつながらなくなることがあって、3日に1回は再起動しているような感じだったが、EVOはこのあたりが非常に安定していて変な挙動があまりない。ここ1月くらい使ってみて変な挙動は、1度だけ勝手に再起動したことがあったくらい。Androidも大分安定してきたように感じる。
WiMAXはonにすると電池があっという間に無くなるは熱くなるはで、常にonにはできない感じ。しかも電波の入りも良くないので、大量のダウンロードがある時などにonにするくらい。テザリングは文句無しに便利なんだけど、これまでのemobile + 光ポータブルに比べると、確実にPCを使わない割合が増えた気がする。
画面の大きさが小さくなったのはあまり気にならなかった。IS01は横に長いだけで縦の大きさはあまり変わらないし。ただキーボードが無いのはやはり不便。とはいえ、あの大きさのキーボード付きでこれはといモデルが無いので仕方無いかな。
というわけで昨日は有楽町のビックカメラ5Fに行ってemobileを解約してきた。隣のブースも解約客だったみたいだけど「10月に契約した場合、10月だと契約解除料かかるんですよね〜 11月まで待たないと」とか言われていた。分かりにくいよね、あれ。
