_ [食] 中華そば いまむら その後の店舗の変遷

ふと話題が出たので今村嘉宏氏の店舗の変遷を洗ってみた結果 (誰得)

いまむら17年間のラーメン店生活に終止符を打ち、新たな世界に旅立たれるということです。

[「いまむらワールド」を体験できた貴重な１年に感謝　中華ソバ　いまむら＠鋸南町保田　千葉ラーメンより引用]

とのことなので、その後は飲食店経営から引退されたのだろうか。

自分が初めて知った関内店時代の当初の味は好きでした。あれをもう食べることができないのは残念ですね。

参考: 南荘輪舞＠千葉県富津市保田★17【元東京いまむら・百舌鳥・臓印】 [無断転載禁止]©2ch.net

_ [Web制作] JavaScript 無効で閲覧できない静的コンテンツサイトは今でも有害か

「「デジタル庁創設に向けた準備サイト」がスクリプト無効で閲覧できない」にはてブや Twitter で賛否両論が起きていて、自分としても判断に悩むところ。

まず当人が批判している根拠「Flash は消えた、JS も将来はわからない」については、筋が悪い。Internet Archive では現在正常に表示できており、現時点で問題があるとは言い難いことから遠い将来のことを無理矢理持ち出したのだろうが、JS が無くなっている頃は HTML や Web も無くなってるだろう。

一昔前なら SEO 的に最悪と言えたのだけど、昨今のクローラーは JS も理解してくれるので、それも言い難くなっている。

ブコメでアクセシビリティ云々言ってる人もいるけど、JS 使えないブラウザとは具体的にどれのことを想定されてるんだろうか。

一方で「このサイトは JavaScript の技術に全面的に依存しないといけないような性質なのでしょうか」もその通りで、そもそもこんなサイト CSR にする意味がない。

総じて、「無意味な JS 乱用には違いないけど、第三者に変更を求める根拠とするだけの具体的な害があるかというとそれも言い難い」というのが現時点の印象。(JS 非対応のクローラーを使っている自分のような人間もいるので、そういう人間にとっては迷惑だけど、一般的な問題ではなく根拠に乏しい。)

なお、無意味な JS 乱用かつ有害な例として、昨年末にリニューアルされた横浜市 行政文書目録検索がある。これは本当に無意味に SPA 化しており、検索結果に固有の URL がなくブラウザの履歴も働かず、明らかに UX を損ねている。これは理解度の低い技術者が無意味に JS を使った結果起きた悪い例である。

一方今回のデジタル庁サイトはそのような問題はぱっと見発見できず、アクセシビリティや UX は損ねないよう配慮して作られているように見える。であれば実装手段の選択肢を狭めることは果たして妥当だろうか。

それとも自分がまだ気付いていない実害が何かあるだろうか?

_ [セキュリティ] 「地方公共団体における情報セキュリティポリシーに関するガイドライン」(改定案)等のパブコメ結果

12/09に意見募集が開始され12/22に〆切となった、「地方公共団体における情報セキュリティポリシーに関するガイドライン」（改定案）等のパブコメに、個人として28件の意見をお送りしていたが、その結果が28日に公表された。

総務省としては「何が何でも年内には公表」という絶対目標があったのだろう。自分以外にも88件の意見が投稿されていたようで、計116件も寄せられた意見について、たった4営業日で見解をとりまとめ、ごく一部ではあるがガイドラインに反映したことは敬服する。作業に当たっていた関係者に土日はあったのだろうか。

なお、「意見募集結果について」は PDF で公表されているが、フォントが游ゴシックとなっており読みづらいこと、再編集性がなく使い勝手が悪いことから、自力で Excel に逆変換をかけた。そのファイルをこちらに置いておく。(最初から Excel のまま出してくれればいいのに)

別添4 パブリックコメントで提出された主な意見及びその意見に対する総務省の考え方 (表部分 Excel ブック化)

これによると、全100種の意見の取扱いは次のような区分となっていた → 承認 6 / 見送り 66 / 却下 21 / 回答 7

なおそのうち自分の意見28件は次の取扱いとなっていた → 承認 2 / 見送り 21 / 却下 5

「スケジュール押してるようだし総スルーするんじゃないの」と思っていた割には承認されたかもしれない。ただしその2件は本質的でない些末な内容であって、一方で正当性のある内容が「(時間がないので) 見送り」ではなく「却下」となっていて、「えー?」と思うところもある。

_ [Internet] ASAHI ネット PPPoE から楽天ひかり DS-Lite による快適 IPv4 接続に乗り換えた

自宅はフレッツ光 + ASAHI ネットを使い続けて17年になるけど、ここしばらく IPv4 通信がなかなか不安定になってきており、平日夜や休日午後といった混み合う時間帯だと 20 Mbps 以下…最悪 1 Mbps を割って「MVNO の方がマシ」レベルなこともある状態に。数年前から言われている PPPoE ボトルネック問題の影響をまさに被ってしまっている。

そんな折、楽天ひかりが1年無料キャンペーンを展開していたこと、また楽天ひかりが DS-Lite による IPv4 over IPv6 接続を提供していることから、楽天ひかりの IPv4 over IPv6 に乗り換えつつ、ついでにマンションの屋内配線を VDSL (100Mbps) から光 (1Gbps) に切り替えた。

平日23時頃の IPv4 下り帯域を見てみると…

と、DS-Lite なら混み合う時間帯でも 300 Mbps 近い状態に改善。

なお、楽天ひかりの DS-Lite ゲートウェイは、知名度の高いインターネットマルチフィードの transix ではなく、アルテリア・ネットワークスの xpass。NEC のルーターだと特定機種しかこれに対応できないという問題がある (参考: 楽天ひかりIPv6で、劇遅環境から脱出できた３００Mbps) のだけど、YAMAHA RTX810 では特に問題なく接続できた。(参考: DS-Lite による楽天ひかりの IPv4 over IPv6 を NVR500 で利用する - [ぴ]

自分がマンションを選ぶ際の絶対条件が「フレッツ光を契約可能なこと」なのだけど、それはこの「不満があれば ISP を乗り換えられる」点や「複数 ISP の併用ができる」点に圧倒的魅力を感じているから。

ASAHI ネットは長いこと愛用してきたけど、これにてお別れすることになります。ASAHI ネットは、IPv4 over IPv6 接続について未だに「IPv4接続をご利用いただけない光接続サービスに限り、本機能を提供いたします。」として対象ユーザーをごく一部に限定しているけど、いい加減全ユーザーに開放しないと、自分のように逃げる人が増えてくるんじゃないですかね。

_ [Internet] DS-Lite による楽天ひかりの IPv4 over IPv6 を NVR500 で利用する

YAMAHA NVR500 は DS-Lite 接続に対応しているとの情報はあるが、実例は transix のものばかりで楽天ひかりのクロスパス (dgw.xpass.jp) での実例情報がなかなか見当たらない。

そこで実機で試したところ、問題なく接続できたのでメモしておく。

IPoE による IPv6 接続設定が既に完了している状態で、以下のコマンド追加投入で無事成功。

tunnel select 1

tunnel encapsulation ipip

tunnel endpoint address 2001:f60:0:200::1:1

ip tunnel mtu 1460

ip tunnel tcp mss limit auto

tunnel enable 1

ip route default gateway tunnel 1

NVR500 で行けたので、NVR510 や RTX810 / RTX830 / RTX1200 / RTX1210 等でも同様にいけるだろう。

なお

tunnel endpoint address 2001:f60:0:200::1:1

の代わりに

tunnel endpoint name dgw.xpass.jp

を試してみたところ、コマンドは投入できたが通信できなかった。

速度測定結果

素晴らしい。(マンション VDSL タイプのため 100Mbps が上限)

参考

• DS-Lite(transix)でインターネット接続 : コマンド設定 - YAMAHA
• 楽天ひかりIPv6で、劇遅環境から脱出できた３００Mbps | パソコンサポート事例｜パソコン１１９

_ [セキュリティ][Webアプリケーション] IPA「安全なウェブサイトの作り方」HTML版

「安全なウェブサイトの作り方」HTML版にリンクジュースを注ぎ込むに倣い、IPA の「安全なウェブサイトの作り方」（改定第7版2015年、初版2006年）のHTML版にリンクしておく。

• 1.1 SQLインジェクション
• 1.2 OSコマンド・インジェクション
• 1.3 パス名パラメータの未チェック／ディレクトリ・トラバーサル
• 1.4 セッション管理の不備
• 1.5 クロスサイト・スクリプティング
• 1.6 CSRF（クロスサイト・リクエスト・フォージェリ）
• 1.7 HTTPヘッダ・インジェクション
• 1.8 メールヘッダ・インジェクション
• 1.9 クリックジャッキング
• 1.10 バッファオーバーフロー
• 1.11 アクセス制御や認可制御の欠落

_ [日記/blog] tDiary 5.0.14 うp

tDiary、4年半前に4.1.1にしてからずっと放置していたところだが、サーバーを Ubuntu 14.04 から 18.04 に移行したところ動かなくなったので、久しぶりにアップデート。

以下いつも通りのメモ。

• カテゴリリンクの間に余計な | が入るのを防ぐため、misc/plugin/category.rb 40行目、category_list 最後の end.join() から | を削除
• views/header.rhtml に SyntaxHighlighter 用 CSS、JS 挿入
• views/diary.rhtml に AdSense 用 JS 挿入

_ [システム運用][システム障害] Zenlogic システム障害・メンテナンスで接続できたサイト・できなかったサイト

確認日時は 2018/07/09 午前3時頃。

接続できた

以下は Zenlogic 導入事例に載っていた各サイトを確認したもの。(現在も Zenlogic を使っているとは限らない)

接続できなかった

以下は Twitter で Zenlogic 障害によりつながらないとの情報を見かけたもの。

ここまでの考察

同じ YAHOO-JP2-CIDR-BLK-JP の IP でも 210.～ のものは問題なく 154.34.～ のものが NG らしい。(ただしニフレルに限っては 210.～ だが NG)

6月19日より一部のお客様で発生している高負荷障害に関するお詫びとお知らせでも「「Zenlogicホスティング Powered by AWS」は本障害の対象外です」と書かれているが、ここでも接続不可のサイトに Amazon 所有の IP アドレスは出てこない。(もっとも正常サイトにも出てこないが)

「ふうせん宇宙撮影」と「俺の嫁が可愛い」は現在は Zenlogic を使っていない?

関連

• 障害発生中のZenlogicが金曜の夜に全サービスの60時間メンテナンスを通達して7分後に全停止！サーバ管理者の阿鼻叫喚の様子 - Togetter
• 6月19日より一部のお客様で発生している高負荷障害に関するお詫びとお知らせ ｜Zenlogicサポートサイト
• レンタルサーバーのZenlogicが緊急メンテナンスでサービス全停止、経緯をまとめる - orangeitems’s diary
• 契約してはいけない Zenlogic

_ [システム運用] 政令市・都道府県の CDN 導入状況を調べてみた (2018年版)

以前政令市・都道府県・省庁等の CDN 導入状況を調べてみたが、それ以降どう変化したか確認してみた。

CDN 導入有無はの判定、前回と同じトップページの URL の FQDN を名前解決し、他者ドメインに CNAME を振っておりかつその組織が CDS を提供している場合に導入ありと判定した。

政令市

3.5年前には福岡市1市だけだった CDN 利用都市が9市まで増えている。また WAF 利用都市が2市出現している。

都道府県

都道府県における CDN 利用都市は3.5年前の2府県から1県だけ増加している。WAF 利用都市が1県出現している。

都道府県が CDN 利用率がさっぱり上がっていないのはなぜだろうか?

_ [Windows][システム運用] Windows 標準機能で BASE64 エンコード・デコードする

今日の Windows には PowerShell という強力なスクリプト環境が用意されているおかげで、OS ビルトイン機能で BASE64 のエンコード・デコードが可能である。

そこで、ファイルをドロップすると BASE64 エンコード・デコードを行うバッチファイルを書いた。

b64encode.bat

powershell -command "$raw = '%1'; $b64 = \"$raw.b64.txt\"; [System.IO.File]::WriteAllText($b64, [Convert]::ToBase64String([System.IO.File]::ReadAllBytes($raw)))"

b64decode.bat

powershell -command "$b64 = '%1'; $raw = $b64 -replace '.b64.txt', ''; if ($raw -eq $b64) { $raw = \"$b64.bin\" }; [System.IO.File]::WriteAllBytes($raw, [Convert]::FromBase64String([System.IO.File]::ReadAllText($b64)))"

これにより、「ファイル送受信は禁止されているがテキストコピペは可」という VDI 環境において、小容量であれば任意のファイル送受信が可能ということになり、ちょっと便利なケースがある反面場合によっては情報漏洩の抜け穴となる恐れもある。

では VDI では PowerShell を動作禁止すべきなのかというと、VDI 側でだけ禁止しても端末側でも禁止しないと意味がない。端末側で PowerShell を禁止してもメールを作成してその下書きのソースを開くといった抜け道もある。

現実的なのはコピペ可能な容量を常識的な利用では困らない程度 (1KB 等) に制限することでしょうか。