Introducing Now Headline X 7.0.
タイトルが「Now Headline X開発日記」なのに、その関係の話を一切していないという
とんでもない矛盾を抱えたまま運営している当ブログですが、ついにその話をするときが来たようです。
Now Headline X バージョン7.0リリース！です。
前々から２ちゃんねるの開発スレッド上では噂を流していましたが
・お気に入り番組検出キーワードで正規表現が使えるようになった
・お気に入り番組検出キーワードを番組の特定の要素（DJ名）などに絞って検出できるようになった
（今までは番組名やジャンル、DJ名などすべての要素に対して照合を行っていたものが
これらのうち１つに絞って検出できるようになった）
・番組表の表示設定で、ある列の列幅をいじったときに、その列の右側に位置する列も
右にずれてくれるようになった。
（今までは、ある列の幅を広げると、そのすぐ右の列の幅が縮まるというウザ仕様だった）
→環境設定の全般タブ「番組表列全体で100%になるようにする」のチェックオフで設定可能
・番組表ウインドウの下部に「録音番組数」「お気に入り番組数」が表示されるようになった
・番組表ウインドウの下部に選択中の番組にDJ名が設定されている場合、表示されるようになった
・他のツールからのお気に入りインポートで「LadioManager」「Dolphin」「RAZIE」からのお気に入り読み込みサポート。
・Now Headline X同士で遠隔再生要求送信できる機能で、録音要求の送信機能も追加。
録音状況ウインドウから他のMacで動くNow Headline Xの録音を止めたりとかもできる
（環境設定のネットワークタブでNow Headline X同士のなんとかのチェックが必要）
などが大きな機能追加/改善ポイントになっています。
他にもバグフィックスや細かい機能追加など１０点以上ありますのでぜひお試しください。
すべての明細については
http://nowheadline.brave-hero.net/VUP_whatsnew/
をご覧ください。
ダウンロードはこちらから。
http://hp.vector.co.jp/authors/VA023856/Now_Headline_X/
ふぅ、久しぶりにそれっぽいこと書いたなあ。
2013年2月27日のTwitter通信障害時のtracerouteログ
昨年のイー・モバイル通信障害に続くtracerouteシリーズ第二弾。
Twitterがつかえなくなったが、今回はTwitterがおかしかったのではなく日米間のどこかで経路障害がおこったようで
つながるプロバイダとつながらないプロバイダがあったのでいろいろ比較してみた。
単なる記録として残しているだけなので、見てもぜんぜん役に立たないです。
状況
フレッツ光ネクスト、@niftyでつながらなかったときのtracerouteログ
192.168.24.1は自宅のルータ。
＊.ntt.netというところを何個か通過した後引っかかっている。
最後通れたところはレスポンス速度からして国内とおもわれる。
この一個先が米国のルータかどうかは不明だが復帰後の状況を見るに一個先は米国ルータだったとおもわれる。
$ traceroute www.twitter.com
traceroute: Warning: www.twitter.com has multiple addresses; using 199.59.150.7
traceroute to twitter.com (199.59.150.7), 64 hops max, 52 byte packets
1 192.168.24.1 (192.168.24.1) 2.271 ms 1.862 ms 0.804 ms
2 133.160.150.52 (133.160.150.52) 7.293 ms 7.610 ms 5.634 ms
3 133.160.150.49 (133.160.150.49) 6.422 ms 5.869 ms 6.652 ms
4 133.160.163.105 (133.160.163.105) 5.599 ms 5.712 ms 5.712 ms
5 133.160.127.230 (133.160.127.230) 11.611 ms 11.063 ms 11.441 ms
6 xe-7-2.a14.tokyjp01.jp.ra.gin.ntt.net (61.213.160.137) 12.103 ms 12.917 ms 12.203 ms
7 ae-8.r24.tokyjp01.jp.bb.gin.ntt.net (61.213.160.241) 11.989 ms
ae-8.r25.tokyjp01.jp.bb.gin.ntt.net (203.105.72.149) 11.469 ms
ae-8.r24.tokyjp01.jp.bb.gin.ntt.net (61.213.160.241) 49.453 ms
8 ae-2.r00.tokyjp03.jp.bb.gin.ntt.net (129.250.2.5) 14.426 ms
ae-3.r00.tokyjp03.jp.bb.gin.ntt.net (129.250.4.233) 15.004 ms
ae-2.r00.tokyjp03.jp.bb.gin.ntt.net (129.250.2.5) 12.624 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
auの3G回線、つながらなかったときのtracerouteログ
フレッツ光ネクスト/@niftyはNTTのルータっぽいところで止まっていたが、こちらはさすがauとあってKDDIの回線を通っている模様。
3Gだからというのもあるが全体的にレスポンス速度が遅めでどこまでが日本かわかりにくい
Traceroute to www.twitter.com (199.59.150.7), 64 hops max.
1 *
2 172.23.134.114 (172.23.134.114) time=143 ms
3 172.23.204.34 (172.23.204.34) time=470 ms
4 172.23.204.141 (172.23.204.141) time=113 ms
5 tm4bbac01.bb.kddi.ne.jp (111.86.159.177) time=100 ms
6 otejbb205.int-gw.kddi.ne.jp (111.87.242.145) time=95 ms
7 pajbb001.int-gw.kddi.ne.jp (203.181.100.2) time=478 ms
8 ix-pa4.int-gw.kddi.ne.jp (111.87.3.50) time=257 ms
9 199.16.159.189 (199.16.159.189) time=467 ms
10 *
11 *
12 *
13 *
14 *
15 *
終始ちゃんとつながっていたi-revoアクセスからtraceroute
IIJはオッケーだったようだ。192.168.8.1は自宅のルータ。
$ traceroute www.twitter.com
traceroute: Warning: www.twitter.com has multiple addresses; using 199.59.150.39
traceroute to twitter.com (199.59.150.39), 64 hops max, 52 byte packets
1 192.168.8.1 (192.168.8.1) 9.172 ms 4.433 ms 1.222 ms
2 aichi06-n01.flets.2iij.net (203.180.195.114) 60.094 ms 64.468 ms 64.513 ms
3 ngy003lip30.iij.net (203.180.195.113) 65.316 ms 62.826 ms 65.106 ms
4 ngy003ipgw10.iij.net (210.138.115.77) 64.436 ms 64.263 ms 62.160 ms
5 ngy003bb11.iij.net (58.138.108.65) 62.608 ms 65.028 ms 66.140 ms
6 osk004bf00.iij.net (58.138.81.245) 65.805 ms 72.341 ms 69.777 ms
7 lax002bf00.iij.net (206.132.169.117) 173.410 ms
lax002bb10.iij.net (216.98.96.65) 176.882 ms
lax002bf00.iij.net (206.132.169.117) 175.765 ms
8 sjc002bb10.iij.net (206.132.169.90) 182.823 ms 184.494 ms 189.108 ms
9 eqix1.cr1.sjc2.twttr.com (206.223.116.94) 178.899 ms 187.248 ms
eqix2.cr2.sjc2.twttr.com (206.223.116.101) 192.116 ms
10 ae53.smf1-er1.twttr.com (199.16.159.37) 186.884 ms 194.229 ms
ae53.smf1-er2.twttr.com (199.16.159.41) 188.891 ms
11 r-199-59-150-39.twttr.com (199.59.150.39) 190.033 ms 189.822 ms 198.246 ms
ちなみに@niftyでwww.twitter.comを引いたときに出てきたIP宛に直接打ったがこれもオッケー
$ traceroute 199.59.150.7
traceroute to 199.59.150.7 (199.59.150.7), 64 hops max, 52 byte packets
1 192.168.8.1 (192.168.8.1) 7.214 ms 1.733 ms 1.204 ms
2 aichi06-n01.flets.2iij.net (203.180.195.114) 57.078 ms 55.501 ms 55.521 ms
3 ngy003lip30.iij.net (203.180.195.113) 64.365 ms 59.428 ms 58.841 ms
4 ngy003ipgw10.iij.net (210.138.115.77) 56.065 ms 58.557 ms 60.879 ms
5 ngy003bb10.iij.net (58.138.108.57) 68.704 ms 70.633 ms 67.726 ms
6 osk005bf00.iij.net (58.138.81.253) 72.251 ms
osk004bf01.iij.net (58.138.82.109) 58.281 ms 61.410 ms
7 lax002bf00.iij.net (216.98.96.53) 188.466 ms 187.637 ms
lax002bf01.iij.net (216.98.96.190) 178.083 ms
8 sjc002bb10.iij.net (206.132.169.94) 200.600 ms
sjc002bb10.iij.net (206.132.169.98) 193.531 ms
sjc002bb10.iij.net (206.132.169.94) 184.409 ms
9 * eqix2.cr2.sjc2.twttr.com (206.223.116.101) 209.286 ms 193.979 ms
10 ae53.smf1-er1.twttr.com (199.16.159.37) 195.958 ms
ae53.smf1-er2.twttr.com (199.16.159.41) 207.311 ms 190.489 ms
11 r-199-59-150-7.twttr.com (199.59.150.7) 191.693 ms 207.789 ms 195.741 ms
同一時間帯につながっていたとおもうSoftbank LTE回線のtracerouteログ
ソフトバンクはODNが出てきよる、当然と言えば当然なんだろうがiPhoneはパンダワールド一色だとおもっていたので
ここでODNの名前を見るのはちょっと意外だった
だが、これをやっていたときはもしかしたら既に復活していたかもしれない点には注意したい
Traceroute to www.twitter.com (199.59.148.10), 64 hops max.
1 192.168.100.1 (192.168.100.1) time=57 ms
2 192.168.100.2 (192.168.100.2) time=30 ms
3 192.168.100.36 (192.168.100.36) time=33 ms
4 192.168.100.33 (192.168.100.33) time=33 ms
5 192.168.100.33 (192.168.100.33) time=36 ms
6 192.168.100.44 (192.168.100.44) time=29 ms
7 *
8 pw126211148098.5.panda-world.ne.jp (126.211.148.98) time=83 ms
9 pw126211148110.5.panda-world.ne.jp (126.211.148.110) time=45 ms
10 *
11 pw126211148209.5.panda-world.ne.jp (126.211.148.209) time=78 ms
12 pw126211148122.5.panda-world.ne.jp (126.211.148.122) time=31 ms
13 pw126211147130.5.panda-world.ne.jp (126.211.147.130) time=32 ms
14 pw126211144161.5.panda-world.ne.jp (126.211.144.161) time=40 ms
15 pw126211144041.5.panda-world.ne.jp (126.211.144.41) time=56 ms
16 101.110.0.233 (101.110.0.233) time=31 ms
17 10.0.194.213 (10.0.194.213) time=37 ms
18 10.0.191.1 (10.0.191.1) time=41 ms
19 10.9.193.154 (10.9.193.154) time=43 ms
20 93.143090232.odn.ne.jp (143.90.232.93) time=36 ms
21 stoac-01te0-1-0-3.nw.odn.ad.jp (143.90.47.5) time=45 ms
22 pax-gw1-te3-1.gw.odn.ad.jp (210.142.161.38) time=168 ms
23 twitter.gw.odn.ad.jp (210.142.160.154) time=173 ms
24 ae52.smf1-er2.twttr.com (199.16.159.55) time=176 ms
25 r-199-59-148-10.twttr.com (199.59.148.10) time=196 msTraceroute at destination ***
というようなことをやっていて、NTT Docomo (Xi)はどうか、なんてことを思い始めた頃
22時まわらないぐらいの時間にいきなり全回線復活した。
なので、上のSoftbankは経路復活後かもしれない。
フレッツ光ネクスト、@niftyで経路復活後のtracerouteログ
８番目までの経路は多分同じで、先ほど出てこなかった９番目のルータが出てきている。
８番目のルータが13msとかでレスポンスしてきているのに対して
９番目のルータは186msなのでおそらく米国側のルータなんじゃないかと思う。
$ traceroute www.twitter.com
traceroute: Warning: www.twitter.com has multiple addresses; using 199.59.150.7
traceroute to twitter.com (199.59.150.7), 64 hops max, 52 byte packets
1 192.168.24.1 (192.168.24.1) 1.122 ms 1.645 ms 0.686 ms
2 133.160.150.52 (133.160.150.52) 5.937 ms 6.596 ms 8.055 ms
3 133.160.150.49 (133.160.150.49) 6.450 ms 10.172 ms 5.936 ms
4 133.160.163.105 (133.160.163.105) 5.423 ms 5.467 ms 5.750 ms
5 133.160.127.230 (133.160.127.230) 11.571 ms 10.844 ms 11.062 ms
6 xe-7-2.a14.tokyjp01.jp.ra.gin.ntt.net (61.213.160.137) 12.361 ms 12.895 ms 12.478 ms
7 ae-8.r24.tokyjp01.jp.bb.gin.ntt.net (61.213.160.241) 12.733 ms
ae-8.r25.tokyjp01.jp.bb.gin.ntt.net (203.105.72.149) 11.361 ms
ae-8.r24.tokyjp01.jp.bb.gin.ntt.net (61.213.160.241) 11.808 ms
8 ae-2.r00.tokyjp03.jp.bb.gin.ntt.net (129.250.2.5) 11.988 ms
ae-3.r00.tokyjp03.jp.bb.gin.ntt.net (129.250.4.233) 13.908 ms
ae-2.r00.tokyjp03.jp.bb.gin.ntt.net (129.250.2.5) 13.062 ms
9 xe-0-2-0-10.r00.tokyjp03.jp.ce.gin.ntt.net (61.213.145.166) 186.727 ms 186.270 ms 187.108 ms
10 xe-1-0-0.sin1-cr1.twttr.com (199.16.159.12) 193.822 ms 192.624 ms 305.592 ms
11 xe-0-3-0.sjc2-cr2.twttr.com (199.16.159.23) 187.074 ms 186.725 ms 187.041 ms
12 ae53.smf1-er2.twttr.com (199.16.159.41) 194.140 ms 191.865 ms 197.857 ms
13 r-199-59-150-7.twttr.com (199.59.150.7) 193.291 ms 194.834 ms 192.021 ms
auの3G回線で経路復活後のtracerouteログ
KDDI系というかモロKDDIのauはどうなったか。
６番目のotejbb205.int-gw.kddi.ne.jpまでは同じだが、
７番目が障害発生時pajbb001.int-gw.kddi.ne.jp (203.181.100.2)となっていたのが
ix-ote207.int-gw.kddi.ne.jp (106.187.6.74)に変更されている。
多分oteというのは東京大手町のIXのことを指しているんだろう（と推測）
さらにそっから先８〜１１はDNS名はひけないので深く追っていないが
１２からはNTTのルータが出てきている。
そしてこの１２に出てきているNTTのルータは@niftyで障害回復後通っている
xe-0-2-0-10.r00.tokyjp03.jp.ce.gin.ntt.net (61.213.145.166)である。
じゃあ、この１２番目のルータがトラブったことで@niftyとauがだめになったのか、という話だが
少なくともauに関しては途中の経路がかわっているので、もしかすると自社設備がおかしくなったので
NTTのほうに間借りしているのかもしれない。
いつもやってみてるわけじゃないからワカランけど、KDDIの回線でNTTが出てくるモンなのか？
Traceroute to www.twitter.com (199.59.150.7), 64 hops max.
1 *
2 172.23.134.114 (172.23.134.114) time=75 ms
3 172.23.204.34 (172.23.204.34) time=75 ms
4 172.23.204.141 (172.23.204.141) time=82 ms
5 tm4bbac01.bb.kddi.ne.jp (111.86.159.177) time=91 ms
6 otejbb205.int-gw.kddi.ne.jp (111.87.242.145) time=113 ms
7 ix-ote207.int-gw.kddi.ne.jp (106.187.6.74) time=114 ms
8 210.163.230.217 (210.163.230.217) time=87 ms
9 122.28.104.173 (122.28.104.173) time=84 ms
10 60.37.27.153 (60.37.27.153) time=96 ms
11 210.163.230.238 (210.163.230.238) time=473 ms
12 ae-7.r24.tokyjp01.jp.bb.gin.ntt.net (61.213.162.165) time=124 ms
13 ae-2.r00.tokyjp03.jp.bb.gin.ntt.net (129.250.2.5) time=111 ms
14 xe-0-2-0-10.r00.tokyjp03.jp.ce.gin.ntt.net (61.213.145.166) time=124 ms
15 xe-1-0-0.sin1-cr1.twttr.com (199.16.159.12) time=184 ms
16 xe-0-3-0.sjc2-cr2.twttr.com (199.16.159.23) time=474 ms
17 ae53.smf1-er2.twttr.com (199.16.159.41) time=473 ms
18 r-199-59-150-7.twttr.com (199.59.150.7) time=471 msTraceroute at destination ***
もう数日したら、KDDIに戻ってるとかあるのかしらん？
Mac OS XのMailで選択したメッセージのタイトルと受信日時の一覧抽出
Mac OS Xの「メール」アプリケーションで、選択したメッセージすべての「タイトル（Subject）」と「受信日時」をコンマ区切りでデータ化してクリップボードにコピーしてくれるAutomatorワークフロー
あくまでも「メール」というメールソフトだけで使えるやつなのでさんだーばーどとかは知らん
がハードディスクを整理していたら出てきたのでここに晒す
もしかしたら前にも書いてるかもしれないけど
１，選択したメールメッセージを取得を追加（選択項目を取得：メッセージ）
２，AppleScriptを実行
on run {input, parameters}
tell application "Mail"
set temp to ""
repeat with eachMessage in input
set theSubject to subject of eachMessage
set {year:y, month:m, day:d, time string:t} to (date sent of eachMessage)
-- set theDate to ((y * 10000 + m * 100 + d) as string) & " " & (t as string)
set theDate to ((y) as string) & "/" & ((m) * 1 as string) & "/" & ((d) as string) & " " & (t as string)
set temp to temp & theSubject & "," & theDate & (ASCII character 13)
end repeat
set the clipboard to temp
end tell
end run
こういう感じにして
メールを選択して
Automatorの実行ボタンをポチっとする。
上記の３通選択して実行した例だとこういうのがクリップボードにコピーされる
[Fruitmail](10ポイント)ライフスタイルに関するアンケート,2013/2/13 23:48:09
[goo Research]インターネットの利用等に関するアンケート☆本調査まで回答で最大210ポイント☆,2013/2/14 10:46:06
[ECナビ 総合] あなたにハートとポイントをお届けします♪,2013/2/14 4:00:47
Excelとかで加工すればA列にSubject、B列に受信時刻などという感じにできるはず
ホントなんのために作ったのかは不明、たぶんメールの受信時刻を簡単にコピーできなかったのでイライラして作ったんだとおもうけど。
ポイントサイトももう３年ぐらいやってないなー
Active Directoryユーザとコンピュータで無効ユーザだけ抽出する
Windows Server 2003 R2の「Active Directoryユーザとコンピュータ」の中で、アカウントのプロパティとして「アカウントは無効」にチェックが入っているユーザーだけ見たいと思うことが時々あるじゃん。
それでその一覧をエクスポートしたい。
2008だったらPowerShellとかでチョイチョイっとやればなんとかなるのかもしれないけど、それは置いといて
あの画面の中でフィルタをかけたいと思うことがあるじゃないですか。ない？そうですか。
単純に、Active DirectoryユーザとコンピュータのMMCコンソール内にフィルタというのがあるけど、
フィルタ条件を書く画面の「カスタムの検索条件」には上記「アカウントは無効」のオンオフで絞込みができるようなものは入っていない。
で、その絞り込み方には２種類あることが判明した。
ひとつ目のやり方：保存されたクエリ
あとでめんどくさいやり方も紹介するが、もしこちらのやり方でやりたいことができるなら
こっちのほうがかんたん
１．「保存されたクエリ」のところで右クリック→「新規作成」→「クエリ」を選ぶ
２．「名前」をなんかいれる
３．「クエリの定義(E)...」を押す
４．「ユーザー」タブで「無効になっているアカウント」にチェックを入れて「OK」を押す
５．特定のグループの下にいるユーザーだけを対象にしたい場合は
「クエリルート」の「参照」を押してグループとかOUを選んでOK
６．OKを押す
７．保存されたクエリのところを展開して、今作ったやつを押すとずらりと出てくる
８．このままユーザーを選択してプロパティの変更もできるし
ツールバーにしかないコマンド「一番をエクスポート」を押せば、表示中のユーザ一覧を
この絞り込み条件を保ったままタブ区切り形式のエクスポートなどができる。
ふたつ目のやり方：フィルタ（LDAPクエリ）
こっちはちょっとめんどくさいけど、やりたいことに一番近いやり方。
１．フィルタボタンを押す
２．「カスタムフィルタの作成」にチェックを入れる
３．「カスタマイズ」ボタンを押す
４．「詳細設定」タブを開く
５．LDAPクエリに以下を入力、OKを押す
(&(&(objectCategory=person)(objectClass=user))(userAccountControl:1.2.840.113556.1.4.803:=2))
※改行されているようにみえるが実際には１行なのでご注意を
６．無効ユーザーが入っているであろうグループを選択する（たとえば「Users」、あるいはOUなど）
無効ユーザーだけが出る。なお、下で赤で囲っているように「フィルタアクティブ」という表示が出る。
先ほどの手順と違って、フィルタがかかっているだけなのでグループごとに見ることができる。
これをメリットと思うかデメリットと思うかはやろうとしていること次第と思うが。
７．保存クエリと同様、ユーザーのプロパティを見ていじったり一覧のエクスポートが可能。
意外と知られていない「一覧のエクスポート」
８．満足したら、再びフィルタボタンを押して「カスタムフィルタの作成」を「すべての種類のオブジェクトを表示」に戻してOKを押す。
ちなみに、これをしても先ほどのLDAPクエリ文字列は消えずに保持されるので
「カスタムフィルタの作成」に戻すだけで無効ユーザーの一覧を表示させることができるが
クエリが残ったままになるのがイヤだという特殊な需要をお持ちのかたは、
カスタムフィルタの作成のままカスタマイズボタン→詳細設定→クエリ文字列をすべてDelete
→OK→「すべての種類のオブジェクトを表示」に戻す→OKと操作することで
本操作を実行する前の状態に完全に復元できる。
ちなみに以下のクエリを使うことで、逆に「アカウントは無効にチェックが入っていないユーザー」の一覧も出せる。
(&(&(objectCategory=person)(objectClass=user))(!userAccountControl:1.2.840.113556.1.4.803:=2))
※改行されているようにみえるが実際には１行なのでご注意を
違いは、エクスクラメーションマークの有無だけである。（条件が逆転しているだけ）
どちらのやり方がいいのか
使い勝手をそのままに、というか、グループごとに無効ユーザだけ見たい場合はフィルタのやり方のほうがいい。
アカウントが無効じゃないユーザー（つまり有効なユーザ）の一覧を出したいときもフィルタのほうがいい。
それ以外は保存クエリのほうがいい。
保存クエリのやり方が有利なのは
- グループは関係なしにドメイン全体で無効なユーザ一覧の抽出がしたい
- コンピュータアカウントの無効になっているやつも抽出したい（多分やろうと思えばLDAPクエリでもできそう）
- クエリを保存しておくことで後からすぐによびだせる
フィルタのやり方が有利なのは
- 「アカウントは無効」にチェックが入っていないリストも出せる（保存クエリのほうではできなさそう）
- グループごとに無効アカウントの一覧が出せる
- 保存クエリのやり方でも、クエリルートを変更することでグループの絞り込みは可能だが、いろんなグループをパッパッと切り替えながら見たい場合は絞りこまれてはいるが、画面の見た目は変わっていないフィルタのほうがやりやすい。
Safariが起動不能に。Lion用Safari 5.1.7再インストールで治った
予備機で使っていたMacBookでいつの間にかSafariが起動できなくなってた。
OSはMac OS X 10.7.5、Safari 5.1.7。
起動すると数回アイコンがはねた後に
「Safariが予期しない理由で終了しました」うんたらかんたら
とかいうメッセージが表示されて落ちる。
再度開くボタンを押しても同様に閉じてしまう
インターネッツでちょっと調べてみたところ
- 別のユーザーで再現するかどうか確認しろ。再現しなければユーザフォルダ内の設定ファイルか何かの問題
- ディスクユーティリティでアクセス権の修復をするとなおる
- SafariStandという拡張機能を入れている場合、バージョンの相性で起動できなくなるパターンがある
- （特にSafariをバージョンアップしたとき）
- インターネットプラグインに質の悪いものがあると落ちる
- 統合アップデートをインストールし直すと治る場合がある
- だめならOSごと再インストール？
というのがヒットしたので、順番にトライ。
- 別のユーザーに切り替え。普段使っていない別のユーザーと、ゲストユーザ両方で問題が再現。
- ディスクユーティリティのアクセス権の修復をしたところなにやらたくさん修復されたが問題修正ならず
- SafariStandは使ってないし、/Library/Application Support/にSIMBLフォルダなし
- /Library/Internet Plug-insを一時的にリネームしてみたが起動せず
- 統合アップデートはなぜかダウンロードにすごい時間がかかる
- 再インストールするぐらいならひと暴れしてから・・・
結果的にどうしたらなおったかというと、以下のフォーラムに投稿されていた
how do I downgrade safari 6 to 5.1.7 in Lion?
https://discussions.apple.com/thread/4187152?start=0&tstart=0
OSX LionでSafari 6を5.1.7にダウングレードするには？みたいなトピックの手順をそのままやった。
Safari 6環境ではなかったが、5.1.7でもアンインストール手順は共通のもようだ。たぶん。
sudo rm -rf /Applications/Safari.app
sudo rm -rf /System/Library/StagedFrameworks/Safari
sudo rm -rf /System/Library/PrivateFrameworks/Safari.framework
をターミナルから打って現存のSafariをブッ飛ばす。
なぜか１行打ってからしばらく動かなくなったりして、Enterポチポチ押したら先に進むなど、挙動不審な症状が出たが無理やり続行。
それから、以下の場所からSafari 5.1.7をダウンロードしてきて（これが一番知りたかった）
http://appldnld.apple.com/Safari5/041-5467.20120509.F6PPX/Safari5.1.7LionManual.dmg
もういっかいインストールしなおす。
sudo rm -rfがうまくいっていないと、すでに新しいバージョンがインストールされているとかって表示されて
インストールが出来ないので、その場合はもういっかいやる。
ちなみに私はrootユーザーを有効にして*1そこのシェルから打ってしまったのでなんでもやり放題だったが
一般ユーザーでsudoした場合にどうかは知らん。
インフルエンザに感染してイナビルを服用して治った
概略だけ説明すればタイトル通りであります。以下は闘病記。
2013年1月25日：一日中咳をしていた人と一日を過ごした
結局この人がインフルエンザの保菌者であったかどうかは定かではないが、その人はマスクをしていなくて
これはやばいかも？と思っていたが結局そのままam10:00〜pm5:00頃までずっと一緒にお仕事。
あともうひとつ、後から気がついて致命的だと思ったのが、この日の晩御飯は手を洗わずに食べてしまった。
2013年1月26日：初期症状が現る
インフルエンザウイルスの潜伏期間などを考えると、ここで症状が出るのはちょっと早いのか？
朝から少し喉に違和感を感じた。熱は特に出ていなかったと思う（が測ったわけではない）
私は風邪をひくと必ず喉から症状が出るので、いつものパターンで風邪をひいてしまったのだと思った。
この喉に違和感以外の症状はこのときは出ていなかった。
昼食は空腹感がなかったのでロッテリアでハンバーガーひとつとシェーキ。
この日は午後から外出の予定があって、私なりに暖かい服装でお出かけ。
ちょっとした会合に出席。途中、外では雪が降っていたがこれがすべて終わった午後９時には止んでいた。
これが終わって、帰りに例の私が書いた風邪をお金の力で解決する方法に従いルルアタックEXを購入。
自転車で帰宅。
ところが。
漕ぎ始めた時にはぜんぜんだったんだけど、途中からひどい倦怠感、なんか熱も出てるような気がするし
これは風邪をこじらせたかもと帰宅早々寝床につく。
2013年1月27日：インフルエンザと診断
夜中の３時ころに目が覚めて熱を測ったところ、38.3C。これはアカンやつや、と自覚。
それから朝９時ぐらいには目が覚めたけど、１０時まで全く動けず。
なんとか動き出して再度熱を測ると38.9C。インフルエンザや、きっと。
あいにく休日だったが、市役所のホームページから休日診療のページを引っ張りだして今日担当の内科に電話。
午前の診療は１２時までということだったので、なんとか飛び込みで診察を受ける。
といっても、今日はここが休日診療指定されているだけあって人がものすごくて３０分以上順番待ち。
年末に見たスギちゃんの病院の待合室でもう何時間も待ってるけど、オレ受付してもらってないンすよ、ワイルドだろぉ？とかいうネタが頭の中をぐるぐるぐるぐる。
実は数年前にも一度インフルエンザをやっているんだけど
鼻の奥に綿棒を入れてクリクリして検査するのは今だ健在だった。
結果は、インフルエンザ。A型。おわった
処方箋を出してもらうために薬局まで行く。
薬局でもものすごい人がごった返していたがソファがこれでもかというほど置いてあったのでそこに座って死んでいた。
出してもらった薬は、「カロナール」という解熱剤と、「イナビル」という薬。
えっタミフルじゃないの、イナビル？なんかぜんぜん知らないやつだし効かないやつじゃないのしまった・・・と一瞬でいろいろ考えた。
しかも口から吸入するタイプの薬で、おおまかに以下の様な説明だったのだが全然理解できず
- ２個あるが１日（１回）で両方とも使用する
- 食事の前後などは関係ないので帰っておちついたらすぐやっても大丈夫
- 飲み合わせなどは気にしなくてもイイ
- 使用前にとんとん机に叩いて薬を落とす
- １個目の１をプッシュして吸って、２をプッシュして吸って、もう一度繰り返す
- ２個目の１をプッシュして吸って、２をプッシュして吸って、もう一度繰り返す
薬局のおじさんに説明してもらうこと５分。
どうも２つもあるのに一回で両方とも使っちゃうというところがにわかに信じられなくて何度も聞いたがマジらしい。
つまるところイナビルは一発勝負の薬ということになるわけだが・・・
家に帰って、なんとか咳き込むことなく両方吸引を完了。
解熱剤も飲んで寝床につく。
夜、起きたら熱が39.1C。解熱剤が効いていないではないか。うぅ・・・
イナビルも効き目がどうなんだかと疑問を持ち始める
2013年1月28日：熱が下がる
朝起きて体温を測ってみると36.8C。ほぼ平熱に下がっているではないか。
しかし倦怠感とかはそのまま、筋肉痛のような関節痛のようなも加わり、腰も痛むときた。
夜にはこれらが８０％ぐらいなおったような感じになってきたが、今度はお腹になにか違和感が・・・
昼間寝たせいも十分あるが、この謎のお腹の違和感で夜眠れず、気づいたら新聞配達のバイクが来てしまうしまつ。
2013年1月29日：消化器系がダメになる
喉もよくなって、今までの症状はすべてなくなった。熱も36.2Cとか（平熱以下？）
が今度は
- 微妙な吐き気
- お腹の違和感
- 胃が痛いような気も
という微妙３兄弟が出現。
イナビルは神薬だと思う反面、これはイナビルの副作用ではないのかと疑問。
しかし午後６時から６時半ぐらいまでの間にスーっと消えていった。びっくりするぐらい。
2013年1月30日：よくなった
体温は36.5C。なぜか今までほとんどしていなかった咳が出始めるが、医者に治癒証明をもらう。大丈夫か？
医者いわく、解熱後２日たてば大丈夫らしい。ホントか？
カラオケに搭載されているハードディスク
カラオケの機種って、大きくわけると「ナントカDAM」と「HyperJoyナントカ」の２種類があると思う。
この間久しぶりにカラオケにいったら*1、受付で「LiveDAM」「Crosso」「JOYSOUND f1」がありますとか言われてワケワカメ！
えっ、CROSSOとかいうのとJOYSOUND f1はどっちが新しいやつなんだろう、できれば新しいやつがいいよな、と
CROSSOを選んだらなんとf1のほうが新しいということが判明！
今はどんなカラオケがあるの！時系列はどうなの！
ということで調べていたら、カラオケの機械にはハードディスクが搭載されているというのを発見！
意外とカラオケもPCっぽいじゃん！ってことでスペックの進化もまとめてみることにしたよ！
ちなみにカラオケの本体のことを「コマンダ」って呼ぶらしいよ！
HyperJoy系
ハイパージョイって読むから女医とか言われていたりもする。そして私が好きなのはコッチ系である。*2
| 機種名 | 発売年 | ハードディスクの容量 | 消費電力 | 特記事項 | ソース |
|---|---|---|---|---|---|
| HyperJoyV2 (JS-70) | 2003年7月 | 160GB×1 | 54W | 製品情報 | |
| HyperJoyV2 Concept-i (JS-70II) | 2005年9月 | 300GB×1（と160GB×1？） | 54W | 製品情報、HyperJoyV2(JS-70) - 東京音響株式会社 | |
| HyperJoyWAVE (JS-W1) | 2006年11月 | 320GB×1 | 43W | HyperJoyWAVE製品情報 | |
| JEWEL (XJ-J1) | 2008年10月 | 320GB×1 | 43W | ナイト市場向け | JEWEL製品情報、JEWEL(XJ-J1) - 東京音響株式会社 |
| CROSSO (JS-WX) | 2009年10月 | 1TB×1 | 49W | CROSSO製品情報 | |
| JOYSOUND f1 (JS-F1) | 2012年6月 | 3TB×1 | 53W | JOYSOUND f1製品情報 | |
| JOYSOUND fR (JS-FR) | 2012年10月 | 3TB×1 | 53W | ナイト市場向け | JOYSOUND fR製品情報 |
下が一番新しい。一部、ナイト市場向けとなっているのは普通のカラオケボックスに導入されるものではなくて、キャバクラとかに導入されるものだそうで。
システム仕様は同じで、外観が違うモノのようである。
なお、基本的にハードディスクは１台でRAIDなどは組まれていないが
OSなど基本的なプログラムはフラッシュメモリに入っていて、楽曲データのみハードディスクに入っている関係で
ハードディスク故障時は、LANを経由して他の部屋のコマンダーから楽曲データを読み込んで営業を継続できるらしい。（ソース）
他にも、HyperJoyWAVE以降ではUSBメモリに約10,000曲入れてそちらから読み出すこともできるらしい。
この10,000曲は、JEWELのスペックページに書かれている「演奏会数上位10,000曲、お店で演奏された直近の約1,000曲」とおもわれる。
DAM系
基本的にHyperJoy系と違って同容量HDDを２台搭載していることが特徴である。
NEW cyber DAMのページには「2台で構成される内蔵ハードディスクのどちらかが破損しても、即座に緊急動作に移り」と書いてあるため、おそらくRAID1構成になっていると思われる。
それ以降、BB cyber DAM f-stageまではNEW cyber DAMと同じく「それぞれ20GBをシステムで使用」という記述があるので
RAID1とおもわれるが、Premire DAMではHDD2台とは書かれているが、詳しいことが書いていないので
RAID1であるという確証がない。
おまけにLIVE DAMの最新機種では２台中１台のみ3TBを採用しており、これではRAID1にしたら2TBになってしまうので全く意味がない。ということはRAID構成じゃないのか？とも疑いたくなるが、HyperJoyのようにUSBメモリなどでバックアップできるとも書いてないし、多分冗長化されているのだろう。
ちなみにWikipediaではLive DAMに至るまでRAID1と記載されているがソースは不明。
UGA系
| 機種名 | 発売年 | ハードディスクの容量 | 消費電力 | 特記事項 | ソース |
|---|---|---|---|---|---|
| UGA (UGA-01) | 2004年5月 | 400GB×1、120GB×1 | 45W | RAID1だとすれば実効容量120GBだが・・・ | 製品情報 |
| UGA+ (UGA-10) | 2005年11月 | 400GB×3 RAID1 | 98W | たぶんRAID1 | 製品情報 |
| UGA→ (UGA-N10) | 2008年9月 | ２台搭載しているらしいが不明 | 98W | UPS内蔵 | 製品情報 |
UGA NEXTなんか特にわけわかめ。よくわからん。
リモコンはずっと赤外線リモコン。Bluetoothのバージョンもあるようだが・・・
UPSを搭載してみたり、けっこう先をいってた部分もあったようだが
今ではJOYSOUNDに吸収されてもう新しいのが出ることはないんだろうなぁ。
