irc.juggler.jpの2ch@IRC脱退について

http://irc.juggler.jp/ の告知の詳細です。

2014年4月に Jim が irc.2ch.net をDNSから消しちゃった件について、2014年9月に Jim と色々交渉した結果、彼のネットワークポリシーだと irc.juggler.jp が再度 2ch@IRC とリレーできる可能性はほとんどないという結論に至りました。よって irc.juggler.jp は 2ch@IRC から脱退して、独立したIRCサーバとなります。ユーザの皆様にはご不便をおかけします。

2ch@IRCの現状

  • irc.2ch.net : 2ch@IRCの新1鯖。Jimが9月6日に建てた。彼のネットワークポリシーにより、外部とのリレーはほぼ不可能
  • irc.2ch.sc : 2ch@IRCの旧1鯖。3月ごろまでは irc.2ch.netの名前でアクセス可能だった
  • irc.nurs.or.jp : 2ch@IRCの旧2鯖。3月ごろまでは irc2.2ch.netの名前でアクセス可能だった
  • irc.juggler.jp : 2ch@IRCの旧3鯖だった。(脱退済)

上記4つがリレーせずに存在して、ユーザが分散しているのが現在の状態です。

時系列

今回の流れを時系列順に書くとこうなります

  • 4月ごろ：irc.2ch.netおよびirc2.2ch.netがDNSから消える。ただしサーバは稼働しており、旧1鯖はIPアドレス指定で、旧2鯖は IPアドレス指定および irc.nurs.or.jp の名前でアクセス可能。
  • (時期不明) 旧1鯖に irc.2ch.sc の名前でアクセスできるようになる。ただしWebサービスは停止した
  • 6月30日： irc.nurs.or.jp が メンテナンスに入る。この時点でサーバ間リレーは機能しなくなった。
  • 9月4日：irc.juggler.jp が 2ch.net の現管理者の Jim と交渉を開始。
  • 9月5日：irc.juggler.jp は 2ch@IRC から脱退を表明。
  • 9月6日：Jimは彼のirc.2ch.netを新しく建てた
  • 9月6日：irc.nurs.or.jp がメンテナンスから復旧

2ch@IRCの今後の展開

irc.2ch.net に Jim が Web IRC を設置するのは時間の問題でしょう。そうなると「板からリンクされてゼロインストールで使えるチャット」という2ch@IRCの本来の機能は復活することになります。

ただし長期的には、西村 vs Jimの 裁判によりDNSの所有権が移動して、irc.2ch.sc が irc.2ch.net として復活する可能性がかなりあります。

irc.juggler.jp の現状

irc.juggler.jp は irc.2ch.net にも irc.2ch.sc にも肩入れしないという選択をとりました。Jimが建てた irc.2ch.net とリレーできる可能性がない状態で 2ch@IRC を名乗り続けるのも、irc.2ch.sc とのリレーが長期間存在しない状態で 2ch@IRC を名乗り続けるのも、適切ではないと感じたからです。

2ch@IRCの既存ユーザの受け入れ先について

2ch@IRCの既存のユーザの大半は現時点では irc.juggler.jp に接続していますが、ユーザがどう動くのかは私にはわかりません。

irc.juggler.jp から外部サーバへの誘導告知を積極的に行える状態にはなっていないと思います。主に受け入れ側の態勢が整っていないという認識です。お家騒動が解決して、受け入れ準備ができた状態でならirc.juggler.jp はサービスを閉じても構わないと思います。もし irc.juggler.jp 独自のユーザ層ができていればまた話は別ですが。

個人的な感想

4月からの 2ch@IRC のDNSトラブルによるユーザ数の減少がどれだけ食い止められるか、というのが私の視点です。Jimが裁判に勝っても負けても、その後に 2ch@IRC のユーザがどの程度残るのかが重要でした。irc.2ch.netとそのWeb導線が生きているのなら、それを誰が運営しているかはどうでもよいと思います。
結果的に私自身と 2ch@IRC との関係がなくなるというオチになりましたが、別段それで誰が困るということもないでしょう。

irc.juggler.jp の今後については、 2ch@IRC の末端という立場ではなくなった故に可能になることもいくつかありますが、どちらかというといつまでもIRCだとモバイルとの相性が悪くてどうしようもないので、そこをなんとかしたいです。

Android アプリの間違った作り方 の続き


ずっと前に「Android アプリの間違った作り方」という記事を書いたけど、
見なおしてみると色々アレだったので、今ならこうするというのを書いておく

Activity の初期化と終了処理

Activityはバックグラウンド状態になったり画面を回転させたりすると一時的に破棄/復元される事がある。プロセスごと一時的に破棄される場合もあるので、例えばstatic変数に状態を保存しても復元の際にそれが維持されているとは限らない。初期化処理と終了処理を書く際に破棄と復元を考慮するには以下のような工夫が必要になる。

onCreate(), onNewIntent(), onSaveInstanceState(), onRestoreInstanceState()

あるActivityが作成された時に、それが最初に作られたのか、一時的に破棄された後に復元されたのかはonCreateの引数がnullかどうかで切り分けられる。この引数に渡されるBundleは onSaveInstanceState() で設定したものと同じ内容になる。

void onCreate(Bundle state){
	initUI(); // ActivityのUIを初期化する
	if( state != null ){
		// このActivityは復元されたものなので、
		// state を使って状態を復元する
		restoreState( state );
	}else{
		// このActivityは新規に作成されたものなので、
		// インテントを使って状態を初期化する
		initState( getIntent() );
	}
}

void onNewIntent(){
	// あるActivityが新しいIntentを受け取った時に呼ばれる
	// インテントを使って状態を初期化する
	initState( getIntent() );
}

void onSaveInstanceState(Bundle state){
	super.onSaveInstanceState(state)
	// TODO: state に画面の現在の状態を保存する
}
void onRestoreInstanceState(Bundle state){
	// state を使って状態を復元する
	restoreState( state );
}

void initUI(){
	// UIの初期化を行う
}
void initState(Intent intent){
	// TODO: intent の情報を使って状態を初期化する
}
void restoreState(Bundle state){
	// TODO: state の情報を使って状態を復元する
	restoreState( state );
}
isFinishing()

Activityの 終了処理をonPause,onStop,onDestoroy に書く際、一時的な破棄とfinish()による破棄を区別するには isFinishing() を使う。あるActivityが一時的に破棄される際は isFinishing()はfalseを示す。

アプリケーションレベルの状態の管理

もしあなたのアプリAで「アプリ単位の状態管理」を実現したいなら、まずはAndroidはアプリ単位の起動状態なんて管理していないことを知っておいて欲しい。特に何も指定しない場合、アプリAに含まれるActivityは別のアプリBの画面スタックの末尾に積まれることもあるし単独の画面スタックに積まれることもある。公式ドキュメントのタスクアフィニティについての記述を参照。
http://developer.android.com/guide/components/tasks-and-back-stack.html#Affinities
それでもアプリケーションレベルの状態を管理したいなら、以下の手法が使えるかもしれない。

アプリケーション単位の初期化を行うタイミング
  • 外部から起動されるActivityの種類を1個だけにする
  • そのActivityに android:launchMode="singleTask" を指定する

この状態でそのActivityのonCreate()が呼ばれて、それが復元ではない(Bundle引数がnull)場合、その時点でアプリ単位の状態を初期化していい。

アプリケーション単位の状態の保存と復元

これだけだとプロセスごと破棄された場合に状態が失われてしまうので、
アプリ単位の状態をフラッシュメモリに保存する仕掛けを入れる。
画面スタックの底にあるアクティビティとそこから呼び出される子アクティビティの全てに以下のような記述を行う。

(manifestに登録したアプリケーションクラス)
class App1 extends Application{
    static MyAppState app_state;

    void saveAppState(){
        is( app_state != null ){
            // TODO: アプリ単位の状態をフラッシュメモリに保存する
        }
    }
    
    void prepareAppState(Activity activity,Bundle activity_state){
        if( activity_state == null &&  activity is (画面スタックの底にあるアクティビティ) ) ){
            // 初回起動なので、状態を初期化する
            // もし直前までの状態が残っていればその後処理を行ってもよい
            app_state = new MyAppState();
        }else if( app_state == null ){
            // TODO: フラッシュメモリから状態を読み込む
        }
    }
}

(Activity派生クラス全て)
void onPause(){
    super.onPause();
    ((App1)getApplication()).saveAppState();
}
void onCreate(Bundle state){
    super.onCreate();
    ((App1)getApplication()).prepareAppState(activity, state);
}

この方法には問題もあって、外部から呼び出せるアクティビティが１個に限られてしまうし、
それが呼び出されるたびにアクティビティの画面スタックのルート以外の部分が全て一旦クリアされてしまう。

アプリ単位の揮発性の状態を管理する、もっとイイ手法があれば誰か教えてください。

PENTAX K-3用のカメラプレート(Lブラケット)

デジカメ

カメラを縦位置で三脚に固定する際、アルカスイス型雲台の信者はカメラにL字型のプレートを取り付けるのですが

RRSもKirkもK-3用のLブラケットを出す予定はないそうですorz

We have no plans to create custom plates for the K-3 camera at this time.
Unfortunately it seems that camera will not be able to use our BK7-L plate,
which fits the K-7, K-5, K-5 II/IIs models.

If you would like a generic plate to fit to that camera,
I’d need to know the distance between the center of the tripod socket and the straight back
edge of the camera. Please let me know if you have further questions.

Really Right Stuff, LLC

Q: do you have plan to sell the L-braket for Pentax K-3 ?

A: Sorry we do not. Thank you,

Kirk Enterprise Solutions

(2013/11/1) K-3本体が来てみたらKIRK BL-K7 が普通にぴったり装着できました。底面の突起もちゃんと避けてます。なので以下の記述はほぼ無駄になったかも… ちなみにRRSのBK7-Lは前側のストッパーが干渉して装着できないはずです。



仕方ないので汎用のLブラケットを探してみます。

SUNWAYFOTO DPL-03 ユニバーサル（汎用） L型クイックリリースプレート アルカスイスタイプ DPL-03 【正規日本代理店】

SUNWAYFOTO DPL-03 ユニバーサル（汎用） L型クイックリリースプレート アルカスイスタイプ DPL-03 【正規日本代理店】

Desmond L型クイックリリースプレート DAL-1

Desmond L型クイックリリースプレート DAL-1

SUNWAYFOTO DPL-03

製品画像 http://i.imgur.com/ZzUViHc.jpg
http://i.imgur.com/ZzUViHc.jpg

  • 左側は KIRK BL-K7 です。K-5/K-7用のカスタムLプレート。90g。ネジ穴がクランプの中央にくるようになっています。カメラ本体底面四隅にある足(突起)を避けるよう、周辺部は少し凹んでいます。手前側にはストッパーがないのでK-3でも干渉しない可能性はゼロではありませんが、ネジ穴の位置を調整する機構はないのでカメラ本体の三脚穴の位置によってはフィットしないような気がします。
  • 右側は SUNWAYFOTO DPL-03 です。カメラ本体の三脚穴の位置にあまり依存しない構造。ストッパーを外したり左右逆に装着したりできます。HDMIやUSBの端子と干渉するおそれがありますが、K-3ならFLU CARDがあるのであまり気にする必要はないでしょう。画像手前の部分が長めなので、装着位置によっては電池ボックスを開けられなくなります。

JTec の汎用Lブラケット

製品画像を見る限りコンパクトそうで良いのですが、重量が全部58gというのは記載ミスでしょう。

感想

電池ボックスを塞いでしまうのは思ったより難儀です。重量よりも全長の短さを重視した方がいいかもしれません。K-5で測った場合は横幅95mm以内であれば電池ボックスを塞ぐことはないようです。挙げた中でこの条件を満たすのはhejnarの92mm,JTecの74mm,76mmが相当します。


使用感などの報告はK-3本体が届いてから…

PENTAX K-5, K-3 のACアダプタ

デジカメ

ペンタックスのデジタル一眼レフに装着するACアダプタは二種類あります。

  • K-AC50J (D-AC50とメガネケーブルのセット)(対応機種 645D/ K-5/ K-7/ K10D/ K20D )
  • K-AC123J (D-AC120とメガネケーブルのセット) (対応機種 K-5II / K-5IIs / K-3 )

実際に両方買ってみました。

製品画像 http://i.imgur.com/jh6QObC.jpg
http://i.imgur.com/jh6QObC.jpg

サイズと重量は K-AC50J よりも K-AC123J の方がややコンパクトですが、コネクタ形状と定格出力(DC 8.3V 2A 16.6W)は同じでした。
気になって問い合わせてみたら「結論からいうと互換性はある。明記していないのは認可が云々」という回答を頂きました。
どうも電気用品安全法絡みのモデルチェンジのようですね。

…ちくしょう！ 片方は無駄になっちゃったじゃないか！

Android Walkman NW-F807

今まで NW-X1050 を使ってたんですが、容量16GBだとロスレスの曲を入れるには厳しかったので10月20日発売の NW-F807 を調達してみました。

2chのNW-F800シリーズスレに書いたことや指摘された問題を以下に書いておきます。

プレイヤーアプリの選択

Google Playストアから色々な音楽プレイヤーアプリをインストールすることができます。

主なプレイヤーの特徴を表にしてみました。

自前デコーダ flac replaygain gapless 歌詞表示 Shift_JISタグ 無料継続利用 アプリ名
y y n 可能だが形式によっては音飛びする ◎ ◎ 標準 W.ミュージック
y y y y n ? 広告あり DeaDBeeF Player
y 可能(※1) 有料 有料 ? ◎ 制限つきで可能 Winamp
y y y y y ○ 試用期間15日 PowerAMP
y Pro 有料 Pro ? ? 制限つきで可能 MyTunes
y y y y LRC file ? 試用期間5日 Neutron Music Player
y y y y n ○ 試用期間14日 GoneMAD Music Player
y y n y y ? 試用期間30日 Astro Player Nova
y y n DSPプラグイン(CPU消費増加) y ? 試用期間7日 PlayerPro
y y n n n ? 広告あり Mixzing
n (Android 3.1+) n n LRCファイル(有料版のみ) 修復ソフト配布 可能 Meridian
n (Android 3.1+) n n ? ? 可能 Zimly
n (Android 3.1+) n n n ? 可能 KENWOOD Music Control
  • ※1: 有料オプションのはずですが、F800では無料版でも再生可能という報告がありました。Android 3.1以降ではシステムデコーダでFLACを再生できるため、制限が緩和されているのかもしれません。

実際にコレを全部買ってF807で試聴してみました。

W.ミュージックは音が悪いと断言していいと思いますｗ 作り物っぽい音で高音が劣化したように感じられます。アンプの傾向が過去のウォークマンと大きく異なるのを、プレイヤーがムリヤリ似せようとして失敗した感じです。FLAC形式以外の再生では曲の境目の前後で音飛びが発生するという報告がありました。

無料で一通りのことができるWinamp や完成度の高いPowerAMP が無難だと思いますが、音質的には GoneMAD Music Player が優れていました。PowerAMPよりクリア感があって、W.ミュージックより自然です。歌詞表示こそありませんが、gapless再生やreplaygain対応も可能。音飛びも他プレイヤーより少ないようです。

mp3のID3タグにShift_JISが使われていた場合、PowerAMPだと一部文字化けするものがあるようです。Winampだと読めたという報告がありました。

不要なアプリの無効化

Android 4.0以降ではプリインストールのアプリを無効化することでメモリやCPUの浪費を避けることができます。今回は音楽再生とWebブラウザ以外のアプリで止められるものは全部止めてみました。無効にしたアプリの一覧はこちら。

W.コントロールは無効化すると本体横のW.ボタンをスクリーンONボタンとして使えるようになります。W.ミュージックを使わないのならW.コントロールも不要です。なお残念ながらW.ミュージック自体は無効化できないようです。

mora や music unlimited は無効化しました。SCEはプレイ履歴や録画履歴の無断公開をやっている(現在進行形)、プライバシー侵害を平気で行う企業です。ソニー系列企業の情報サービスなんて使う気には全くなれません。

付属イアホンの音割れ

付属イアホンと標準プレイヤーで低音を強調した設定にすると付属イアホンが音割れする問題が報告されています。

FLAC データの転送

この製品、FLAC 対応が売りなのに付属ソフトウェアのx-アプリではFLACデータを転送できません。

PCにUSB接続するとUSBストレージとして認識されるので、普通にエクスプローラでDnDしてファイルを転送することができます。

操作性

再生/停止や曲送りを行う物理キーがないため、ポケットの中で手探りで操作することが困難です。

NW-X1050 との音質比較

  • W.ミュージック => 使わない
  • W.コントロール => 使わない
  • 付属イアホン => 使わない
  • x-アプリ => 使わない

という偏った感じになってしまいましたが、この条件で NW-X1050 との音質比較を行なってみました。曲データのファイルフォーマットは NW-X1050 ではATRACロスレス、 NW-F807 ではFLACロスレスです。イアホンはどちらも e-Q7 を使いました。NW-F807 ではプレイヤーアプリに GoneMAD Music Player を使いました。 曲はジャンルの違うものを複数使用しました。

ソースの旨味やアラをストレートに表現するのはFの方です。Xは逆に音の整え方が上手く、ソースが多少荒れてても聴きやすい感じになります。
Fは音のつながりが自然で空間に余白がある感じになります。Xは逆に音にメリハリがあって、このイアホンだと特にキラキラした感じに聞こえます。

Fはイアホンを耳につけた直後は少し物足りない感じです。Xはイアホンを耳につけた直後は少しやかましい感じです。どちらもそのまま聞いてると数分でしっくりきます。

Fの方が低音はちょっとだけ厚いです。これが強調なのか、アンプに余力があるのかは私には分かりませんでした。Xの方がホワイトノイズがちょっとだけ多いです。FとXのどちらが聞き疲れしにくいかはこの二点とソースの相性で決まると思います。

Android端末としての評価

画面が小さいのはいいんですが、タッチパネルの出来がAndroidの中でも悪い方に入るため文字入力などで操作ミスが目立ちました。ソニー製品なのにPOBox Touchを内蔵していないのも微妙です。CPU/GPUのスペックはAndroidの最新からするとかなり古めで、RAMも512MBとゲーム用途にはやや物足りません。DAPではなくAndroid端末が欲しい方は、中古屋でAndroidスマートフォンを購入したほうが幸せだと思います。

まとめ

標準のままで使った場合、単に転送が不便で音が悪くて操作性の悪いDAPです。付属イアホンや付属ソフト、標準プレイヤーアプリが残念な出来であり、その回避にかなり時間を使うので、普通の人には全くオススメできないと思います。

しかし本体ハードそのものは音楽プレイヤーとして高水準だと思います。一通りの手間をかけると、最終的には音のいいFLAC再生機が出来上がります。自由度の高いDAPが欲しい人なら検討の価値はあるでしょう。

Windows Phone の WebException のハンドリング

Windows Phone の WebRequest で リクエストを送った際にネットワークやサーバ由来のエラーがあると WebException 例外が発生するんですが、この例外のStatusプロパティやResponseプロパティにはクセがあって以下のような現象が発生します。

  • 存在するサーバの、存在しないリソースをリクエストすると、例外のStatusはWebExceptionStatus.UnknownErrorだったり WebExceptionStatus.ProtocolError だったりする。例外のResponse にはサーバからの404レスポンスが正しく格納されている。
  • 接続できないサーバの、存在しないリソースをリクエストすると、例外のStatusはWebExceptionStatus.UnknownErrorになる。例外のResponse には適当にでっち上げられた404レスポンスが格納されている。

サーバに接続できてもいないのに適当にレスポンスをでっち上げるという実装ポリシーも関心しませんが、そのレスポンスのステータスが404だというのも関心しません。接続できないという現象は別に永続的なものではないはずです。

実際、このレスポンスをそのまま信用すると、呼び出し側としては接続のリトライを早急に諦めるか、サーバが404を返しているにも関わらずリトライを続けることになってしまいます。

続きを読む