月: 2014年12月

12 月の燃費、まとめ

大和 環Leave a comment

12 月は修羅場で会社との行き帰りなので給油回数が 3 回しかない。
なので燃費もガクンと落ちる。
12/4 の燃費がいいのは静岡から帰ってきた分が含まれているため。
23 区内の移動で燃費 8km/L は未だに到達できずと言う所か。
せめてアイドリング ストップがあればなぁ……。

Date 走行距離(km) 給油量(L) 単価(\) 燃費(km/L) メーカー 油種 給油地
12/04 579.5 59.50 155.0 9.739 ESSO ハイオク 東京都練馬区関町南
12/16 481.1 61.27 151.4 7.852 ENEOS ハイオク 東京都杉並区井草
12/26 454.5 58.27 145.0 7.800 ENEOS ハイオク 〃
まとめ 1515.1 179.04 150.5 8.462  － － －

ところで 12 月は本当に事故現場を目撃することが多かった。特にクリスマスの週は毎日、1 回以上の事故現場に出交した。やはり 12 月というのは師走という言葉の通り、皆、遽しくなるのだろうか？
自分も確かに 12/24 が抱えているプロジェクトのサービスインだったし、大晦日までイベント更新で仕事だったけど、移動そのものが遽しくなることはないので運転そのものが荒れたり、焦ったりするようなことはなかった。
ただ 20 年以上車を運転していて 12 月は事故が多いという印象は、あんまりないんだよねぇ。でも思い返せば、車の量は増える印象はあったかも。

では実際数字ではどうかというと、2012 年ではあるが、月別の事故件数は以下の通りだった（ソース：三井住友海上の PDF）。また死亡数は警察庁の PDF より同じく 2012 年のもの。

月 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
事故件数 48907 46131 51795 49409 50781 49684 54040 51734 49723 51716 53598 57393
死亡者数 345 336 333 345 332 313 331 373 366 378 431 490

というわけで、12 月はやはりどの月よりも交通事故は多いようだ。死者数も、一位。12 月は特に気をつけて運転しなくちゃいけないですな。

▼関連記事

12 月の燃費まとめ 9 月の燃費と台風 3 月の燃費と、Edge のピン止めサイトに苦労する 4 月の燃費と徴用工雑感

赤い看板シリーズ、南京亭

大和 環Leave a comment

道路を走っているとたまに（よく？）見かける赤い看板のお店。看板には中華とか定食とか餃子とかラーメンといった言葉が並ぶ、そんな店を見かけたことはないですか？ 良く目にするのは「満北亭」「南京亭」「珍来」などなど。というわけで、今日はそんなお店の一つ、南京亭 国立店に会社の帰り、寄ってみた。

まずびっくりしたのは食べログの点数が高いと言うこと（2015.05.01 時点で 3.47）。なんで？ どうして？ ここ、10 年以上前に来た時はえらい不味かったような……。

というわけで、味の差が解りやすい塩ラーメンと茄子味噌炒め定食を注文。前者は美味しく作るのが難しいメニュー、後者は誰が作っても美味しくなるメニューだ。

塩ラーメン、思ったよりもコクがある。業務用のスープ味丸出しだけど（ぁ
そして茄子味噌炒めは、うん、しょっぱい、ご飯が進む。
というわけでボク的に想像通りの店で、食べログ的に 3.00 な店だと思うんだけど……なんで 3.47 なんだろう？？ なんかとても美味しいメニューがあったりするのかなぁ？
食べログの口コミを見た感じでは、深夜でもラーメンだけじゃなくて定食も食べられることってのをよく見かけたけど……うう～ん？

まぁでもボクみたいな人間には 24 時間開いているのは有難いね。

1412290931 1412290934

▼関連記事

東京大移動 満北亭 10 年以上ぶりの『のぶちゃん』 哲ちゃん物語

iOS 版 Atok を入れてみた

大和 環Leave a comment

iOS が 8 になり、アプリだけでなくデバイス ドライバもサードパーティが提供できるようになった。というこの一文だけで、その意味が理解出来る人は少ないと思うので噛み砕いて説明し直すと、iOS は今までアプリしか Apple 以外の会社が提供することは出来なかった。
アプリ以外何があるんだよ、っていうとそれはデバイス ドライバと言われるモノで、特定のデバイスをコントロールするプログラムだ。デバイス ドライバのように常にメモリ上に常駐し、ハードウェアを制御するようなプログラムは、通常のアプリよりも高い権限が与えられる。
なぜ高い権限が必要かというと、デバイス ドライバは全てのアプリから利用できる必要があり、さらに必要に応じてアプリよりも優先度が高く実行されなければならないからだ。例えばキー入力や画面タップを扱うプログラムは、各アプリにキーや画面が押されたことを伝えなければならないし、アプリの動作に関係なく、人間は勝手にキーや画面をタップするので、アプリの動作をいったん止めてでも、その人間様の操作をとりに行かなければならない。なので、デバイス ドライバは通常のアプリよりも優先して動くように作られているのだ。
そのため、悪さをするソフトウェア（マルウェア）の自由度も広がってしまい、さらに通常のアプリからは排除できないなどの問題も出てくるため、Apple 以外では配布できないようになっていたのだ。
それをどのようにクリアしたのか、ボクは調べてないのだが（マテ）、iOS 8 からはサードパーティ（Apple とは関係ない存在）からもリリースできるようになった。

で、案の定 Atok という日本語を入力／変換するドライバの iOS 版が今日リリースされたので、さっそく入れてみた。
今まで iOS にも Atok はあったのだが、それはメモ帳として提供され、そのメモ帳でのみ Atok が使えるというものだった。常にメモリに常駐し、ユーザからの入力をすべて乗っ取って（プログラムでは、フックという）動作するようには今まで書けなかったからだ。

でね、解ったことは、スマフォで文章を入力する場合、圧倒的に単文節変換＋予測変換なのよ。例えば、「今日は東京はいい天気です。そちら、青森の天気はいかがですか？」って入力しようとすると、パソコンの場合、最後の「いかがですか？」を入力したところで初めて変換ボタンを押す（ボクの場合は自動変換を用いているので、変換ボタンさえも押さないが）。
ところがスマフォだと、「今日は」「東京は」「いい天気です。」「そちら、」「青森の」「天気は」「いかがですか？」と文節毎に変換していき、その途中で予測変換で合致したモノがあれば、それを採用していく。
となると、文章全体から予想される同音異義語の変換（例えば「貴社の記者が汽車で帰社した」みたいな文章）というのは余り効果を発揮しない。結局、文節毎に変換するので、どちらかというと「過去に何を入力したか」の方が大事になってくる。
なので「頭がいい」と評判の Atok である意味が、あんまりないのだ。
もちろん既に変換し終わった文章からも推測してくれてはいるようだが、スマフォでは圧倒的に過去に変換したものと予測変換（但しこれも過去に変換したものに大きく影響される）を頼りにしているので、Atok じゃなくても特に問題ないのだ。

つまり正直な感想、Atok にする意味って……ないような気がする。

まぁ、スマフォでも連文節変換すれば Atok でもいいような気がするんだけど、ボクは今のところスマフォで連文節変換をする気にはなれない。なぜなら変換途中のままずらずらと長い文字列を表示できるほどスマフォの画面って広くないし、入力間違いや変換間違いを見付けたとき、そこまで戻ってそこを修正して、また文末まで戻るとかそういう操作がやりづらい UI なのだ。

あと Atok にはもう一つ難点があって、やはりまだデバッグ不足なのか、時々お亡くなり（フリーズ状態）になる。そうすると文字入力が一切出来なくなってしまうのだ。こうなってしまった場合、現在のアプリをいったん終了してから起動しなおすと文字入力できるようになる。
それともう一つ、Siri が使えなくなってしまうのも問題だ。標準の文字入力から Atok に切り替えると Siri の呼び出しボタンがない。
ボクは両手が塞がっているときなどに Skype や SMS に応答するとき、Siri を使って文字入力している。Atok にしておくと Siri が呼び出せないのだ。

そんなわけで、iOS 版 Atok、今のところ……うーん、イマイチという感じだ。

IMG_2302 IMG_2303

▼関連記事

雑談、アレコレ（主に iPhone の話） text-size-adjust とかるかん iPhone で小説を書く キャッシュレスの還元は本当にお得なのか？

マルデナポリ

大和 環Leave a comment

晩御飯にマルデナポリに行ってきた（食べログ）。
いつもパスタとピザしか頼まないので、今回はリゾットを頼んでみた。メニューの名前は忘れてしまった……チーズ系の何か（ぁ

美味しいけど、かなり味は濃い。と言ってもしょっぱい方面ではなくて、チーズ方面に。かなりねっとりとした食感。美味しいがたくさんは食べられなさそう(^^; このリゾット、家で作れたらいいのになぁ。
そしてピザはカルツォーネ。ラ・ファリネッラのところと較べると、生地の味が少し強いかもしれない。ラ・ファリネッラのはここまで生地の主張は強くなかったと思う。
さらに今回はグリル料理も頼んでみた。豚のソテー。香草が効いていて、あまりしょっぱくなく、ご飯が欲しいということもないちょうどいい味付けだった。

さー、まだまだ仕事。食べ終わった後は、また会社に戻っていったのだった。

1412270908 1412270910 1412270913
1412270915 1412270917 1412270921
1412270922 1412270926

▼関連記事

マルデナポリ マルデナポリ マルデナポリ マルデナポリのゴボウ

カレーの王様のタンカレー

大和 環Leave a comment

今日のお昼は、浅草橋のカレー屋の中では比較的気に入っているカレーの王様。CoCo 壱よりボクは好きである。前も書いたと思うけど、ここのカレーで一番好きなのが、牛タンカレーである。750 円。
中にゴロゴロと牛タンが入っているのだ。
これの辛口を頼むのが、ボクの定番である。

で、オニオンフライとらっきょうは有料なんだけど、いつも無料券をくれるので、結局この二つは無料でつけてもらっている。

夜警の写真はとあるビルから見下ろした浅草橋駅。このアングルから見られることってあんまりないなぁと思って、撮ってしまった。今日は会社の忘年会があり、その会場がこうして浅草橋を見下ろせる場所だったのである。

忘年会も終わり、今日で仕事納めなんだけど、ボクが関わっているプロジェクトはこのあと大晦日イベント、新年イベント、お年玉イベントとイベントが目白押しで正月休みはなさそうだ。

1412260901 1412260903 1412260904

▼関連記事

バーガーキングと新企画 また名前が変わっていたアティティ 串竹と道路標識と luv wave のパッチ 会社の引っ越しと大悟

きまぐれキッチン石橋と関町のびっくりドンキー

大和 環Leave a comment

お昼に、キッチン石橋に行ってきた（過去の記事）。
ここはポアル館（食べログ）と並ぶ大食いの店……ではあるんだけど、ポアル館ほどインパクトはない。というか、ポアル館との違いは、ポアル館は何も言わなくても量が多いんだけど、キッチン石橋はこちらから能動的に行動しないと、量が多くならない。たけど、大食いの要素てんこ盛りのお店なのだ。

今日はチキンカツ定食を頼んだ。
このカツのデカさ。
ただ最初出てきたとき、揚げすぎなのではと思ったのだが、これはソースが沁みているからのようだ。
カツは箸で切れるくらい柔らかい。
ご飯が何杯でも食べられてしまう。

そして夜は会社の帰りにびっくりドンキーに寄った。
カレールーが本当に少なくなっているのか、もう一度確かめたかったからだ。
結果的に、今日食べたカリーバーグディッシュは特にカレールーが少ないと感じる事はなかった。たまたまだったのかなぁ？

最後の写真はくらまえ橋郵便局にある蔵前橋～浅草橋の史跡の看板。
Timepiece Ensemble を作る時にあらかた調べたはずだったんだけど、ボクのが知らないものもあったので写真に収めた。今度、昼休みとかに散歩がてら見てこよう。惜しむらくは、史跡の説明は残っているが、名前が消えてしまっていることだ（笑）。これでは検索できないじゃないか（爆）。

1412250896 1412250899 1412250890
1412250892 1412250892l 1412250892r

▼関連記事

やっぱり腹が減った… 最後のびっくりドンキー？ ろく月の冷やしラーメンとびっくりドンキー かつお拳とびっくりドンキー

オープン リゾルバ事件

大和 環1 Comment

勤め先の会社は三つの開発室があるんだけど、それらのネットワークを管理している。で、そのうちの一つの開発室で利用しているプロバイダから、どうも大量の不正パケットが流れた形跡があると連絡をよこしてきた。
ログをみたら、一目超然、DNS amp 攻撃だった。

ぎゃーす！ そういえば、DNS の設定ってどうなってたんだっけ？＜ヲイ
って色々調べたら、amatsukami.jp サーバもオープン リゾルバになっていた……orz

皆さんがウェブサイトを閲覧するとき、そのサイトを運営しているサーバに正しくアクセスするためには DNS という仕組みが不可欠である。インターネット上のサーバはすべて一意の重複することのない番号（IP アドレス）が割り振られていて、この IP アドレスはグローバル IP アドレスと言って、インターネット内で重複しないように割り振られている。例えば今あなたが見ている TAMA Networks を提供しているサーバのグローバル IP アドレスは 210.136.205.247 であり、これは世界に一つしかない IP アドレスである。この番号を他の誰かが使うことはない。
でもこの 210.136.205.247 という数字を使ってデータをやりとるするのは非常に非効率だ。この数字は将来的に変わるかもしれないし、この IP アドレスで提供されるサービスは一つに限ったことではない（FTP、メールなど）。
そこで、この数字と抽象的な名前（○○.co.jp とかのことで、これをドメイン名という）を関連づけることによって、柔軟なアクセスを提供するのが DNS という仕組みだ。たとえば、TAMA Networks のブックマークをブラウザで呼び出すと、ブラウザは amatsukami.jp にアクセスしようとする。ブラウザはまず DNS を提供しているサーバに「amatsukami.jp は何番でっしゃろ？」と問い合わせに行くのだ。すると、DNS サーバが「210.136.205.247 でんがな」と答えてくるので、ブラウザはその DNS から答えられた番号の振られているコンピュータ（サーバ）にアクセスしに行くのである。
これはなにも amatsukami.jp に限ったことではなく、世の様々なサーバ（sony.co.jp とか honda.co.jp とか）すべてがこの方法でアクセスしたいサーバを求めており、これを名前解決と言い、このような DNS サーバを「フルサービス・リゾルバ」という。

ではどのフルサービス リゾルバ DNS にアクセスしに行くのかというと、それは各プロバイダが提供している。他にも Google なんかが自由に使える DNS サーバを用意してくれたりしているし、自分で設定することも出来る。
また会社では会社で建てたフルサービス リゾルバ DNS サーバがその役を担い、ウチの会社もそうなっている。

さて、では DNS サーバというのは全世界中の IP アドレスと名前の情報を持っているのかというと、そう言うワケではない。DNS サーバは例えば「amatsukami.jp は何番よ？」と問い合わされたら過去に同じ問い合わせがないかをまず調べる（キャッシュ）。なければ、.jp を管理している DNS サーバに問い合わせに行く。すると .jp を管理している DNS サーバは「amatsukami.jp なら 210.136.205.247 っていうサーバが詳しいことを知ってるぜ」と返してくるので、210.136.205.247 に問い合わせに行くと、210.136.205.247  の DNS サーバ（つまりボクのサーバ）が amatsukami.jp に関する様々な名前と数字の対応を返すのである。このようにフルサービス リゾルバは、次々とより上の DNS サーバに問い合わせていくようになっていて、これを再帰呼び出しと言う。
amatsukami.jp に関する様々な名前というのは、例えば ftp.amatsukami.jp や www.amatsukami.jp など、amatsukami.jp がつく様々な名前である。ここで初めて、amatsukami.jp も 210.136.205.247 だとって返ってくるので、これを問い合わせしに来た機械に渡すのである。
この時、この「問い合わせをしに来た機械を詐称」することができる。
つまり本来は、A というコンピュータが「amatsukami.jp は何番よ？」って聞いてきたら、その結果を A に返すはずなのだが、ここを B というコンピュータに返せとすることが出来てしまうのである。
こうすることによって DNS サーバは B に答えを送ってしまうどころか、本来定義されていない情報を問い合わせる（この問い合わせ内容が、普通の DNS 問い合わせより遙かに情報量が多いように細工されている）ことによって、DNS サーバはコンピュータ B の回線をパンクさせてしまうのだ（実際には何万台という乗っ取られたパソコンをつかって、DNS サーバにこのような攻撃を行う）。
そのためフルサービス リゾルバは、インターネットの誰からでも受けてはいけないように設定しなければならない。そもそもこの名前解決の問い合わせは各プロバイダが提供しているのであって、わざわざ他人のサーバに問い合わせる必要などない。従ってウチも社内でのみ、このサービスは提供すべきなのである。

ではなぜそれがインターネット全体にも提供していたのか？
それは上の説明にも出てきた「amatsukami.jp なら 210.136.205.247 っていうサーバが詳しいことを知ってるぜ」という部分である。ボクのサーバは全インターネットに向けて、amatsukami.jp に関してのみ責任を持って名前解決をしなければならない（こういう DNS サーバをコンテンツ サーバという）。
amatsukami.jp のついたものに関しては、ボクのサーバだけが真実を知っているのである（実際には真実を知っているサーバを定義することが出来るが）。
そして Microsoft の DNS サーバは、フルサービス リゾルバとコンテンツ サーバを分離出来ない。もし分離したかったら、フルサービス リゾルバ用の DNS と、コンテンツ サーバ用の DNS をそれぞれ別に立てないといけないんですな（ちなみに UNIX の世界で使われている BIND という DNS のプログラムは、この二つの機能を分離出来る）。

まぁ、Windows でも BIND 使うべきなのかもしれないけどね……。

で、とりあえず会社の方はコンテンツ サーバとしての役割を他の外向けサーバに移し、ルータ側で DNS の外部ポートを閉じた。
一方の amatsukami.jp は LAN 内の Active Directory を提供しているマシンにフルサービス リゾルバを設定し、SMTP（メール）のゲートウェイをしているサーバに新たに DNS をインストールし、そちらでコンテンツ サーバとして設定した。これで amatsukami.jp サーバがオープン リゾルバではなくなった。

あー、説明が長かった……orz
ちゃんと正しく説明できているかなぁ……。

▼関連記事

たまきんは、正月に何をしていたか？ YouTube に BAN されたｗｗｗ 同人誌の状況とか spam とかパケット使用量とか AWS の固定 IP とか Instagram とか日乃屋カレーとか