投稿

2018の投稿を表示しています

ASUS TPM-L R2.0 のファームウェアを 5.63.3144 に更新しました

Windows 10 Version 1803 に更新したところ、Windows Defender セキュリティセンターにて、TPM チップのファームウェアの更新が必要という警告が出るようになったので、さっそく更新してみました。作業内容についてメモしておきます。 更新手順 1. 更新元バージョンを調べて USB ストレージを準備 2. ASUS のマニュアルの指示の通り、以下を実行 2.1. UEFI の設定で、Security Device Support と Launch CSM を Disable 2.2. USB ストレージから起動して、EFI シェルで更新手続きを実行 2.3. UEFI の設定を元に戻して再起動 3. Microsoft の指示の通り TPMのクリアを実行 補足 更新手順はマニュアルの通りで上手くいきましたが、更新元のバージョンに合わせたファイルをダウンロードして使用することが必要でした。 更新元のバージョンによっては、ASUS のダウンロードページで Show all を押すと出てくるもう一つの方を使う必要がある場合があります。 TPM チップのバージョンを確認するには、 Windows Defender セキュリティセンター > デバイスセキュリティ > セキュリティプロセッサ > セキュリティプロセッサの詳細 を見ると良いようです。 EFI シェルに入る方法は、配布されているファイルを、X:\EFI\Boot\BOOTX64.EFI というパスになるように USB ストレージに展開して、起動すれば良いようでした。 UEFI の設定変更や、TPM のクリアを行う際は、BitLocker の保護の中断を行ってから作業をすると回復キーを何度も入れなくて済むので便利です。 リンク セキュリティ プロセッサ (TPM) ファームウェアを更新する - Windows Help TPM-L R2.0 Driver & Tools | Motherboard Accessory | ASUS Global - 2018年5月現在、更新元バージョンの異なる2種類のファイルがダウンロード出来るようになっています。 TPM-L R2.0 Manual | Motherboa

[blogger] ブログの HTTPS 化が完了しました

Blogger のカスタムドメイン用 HTTPS 対応がリリースされたので、さっそく有効にしてみました。特に追加費用は発生せず、証明書は Let's Encrypt の DV (Domain Validation) 証明書が自動で設定されるようで、大変便利でした。 証明書が設定されたことで、GFE (Google Front End) の配信方式が、HTTP 1.1 から、HTTP 2, QUIC 39 に変更され、やけに最先端感があります (2018/04/01 時点)。また、HTTPS 有効化前からですが、当たり前のように IPv4, IPv6 のデュアルスタックになっています。 ブログ内の http:// な画像は親切なことに Blogger 側で用意してくれたプロキシで https:// な URL に変換されるので、mixed content 問題も回避してくれるようです。 Google App Engine のカスタムドメイン用 HTTPS 機能でも同じように Let's Encrypt + GFE で設定されたので、どうやら同じ仕組みを使っているようです。 特に問題はないと思うので、HTTP サイトの表示変更が予定されている、2018/07 の Chrome 68 リリースまでに、HTTPS リダイレクトまで有効化しておくと良いと思います。 Marking HTTP As Non-Secure - The Chromium Projects

So-net フレッツ回線を IPv6 + DS-Lite に変更して劇的に速度改善しました

イメージ
最近、毎晩8時~12時くらいの時間帯で、So-net フレッツ光マンションタイプのインターネット回線のダウンロード速度が非常に遅くなる (0.1~1Mbps程度) 現象に見舞われており、大変困っていました。 具体的には、YouTube の 1080p や、AbemaTV の最高画質はダウンロードが追い付かず、低ビットレートのモヤモヤした画面を見させられ、アプリの更新やデータダウンロードでもやたら時間がかかるという感じで、この回線に繋がる Wi-Fi よりも、ドコモ Xi の 4G+ の方がずっと速いという、いったい何にお金払っているんだろうかという状況でした。 切り分け用に NTT 東日本の用意してくれている フレッツ速度測定 では、十分に高速 (90Mbps 以上) な速度になっているので、おそらくボトルネックは So-net 用の PPPoE 部分にあるようで、先駆者のブログでの改善報告も参考にして、以下のページより IPv6 接続オプションを申し込みました。 「IPv6」ご利用のご案内 | 会員サポート | So-net 申し込み数時間後、手続きが完了したようで、ルーター広告 (RA) でグローバル IPv6 アドレスが降ってきて IPv6 で通信できるようになり、Google, Facebook, YouTube, Netflix など、IPv6 接続性のあるサイトの速度が改善しました。 この調子で IPv4 の速度も改善するため、So-net での IPv4 over IPv6 トンネリング (IPv6 ネットワーク上で IPv4 の通信を行う技術) のために必要な DS-Lite に対応した無線LANルーター WXR-1751DHP2 を導入してみました。セットアップ自体は PPPoE の設定すら必要なく、有線で繋いで電源を入れるだけで、あとは IPv6 と IPv4 (DS-Lite) の接続性が得られました。 速度測定結果は以下のように、混み合っていた時間帯でも安定してダウンロード 60Mbps 以上は出るようになって、非常に快適になりました。 プロバイダを So-net に変えてから、遅延がひどくてやらなくなっていた、FPS も試しにやってみたところ、ちゃんと敵の居場所が反映されるようになって、レイテンシーも安定し

[adtech] 行動ターゲティング広告を最大限強化するには

イメージ
インターネット広告について、もし広告ブロッカーなどは使わず、広告を受け入れるポリシーなのであれば、完全に最適化してもらうのも面白いと思います。行動ターゲティング広告という仕組みはご存知であっても、具体的に最適化を強化するには何をすれば良いかは、各社気持ち悪がられることを恐れてか、あまり明確な説明をしていないように思います。そこで、広告の最適化をより進め、広告の配信が楽しみになるアイディアをご紹介します。 まず、Google, Facebook, Twitter, Yahoo! JAPAN など、広告配信に直結したアカウントで、モバイルを含む普段使うすべてのブラウザにログインしましょう。クッキーを受け入れていれば、すでにブラウザごとに履歴が蓄積しているのですが、アカウント経由で全ての行動履歴が統合されることでより正確なプロフィールが仕上がります。 Safari のデフォルトの設定は広告最適化上よろしくないものがあるので、サードパーティークッキーは受け入れる、サイト越えトラッキングも防がない設定に変更すると良いです。 次に、所持しているモバイル端末全てに、各社のモバイルアプリをインストールし、ログインしましょう。これにより、デバイス単位で存在する IDFA (iOS), AdID (Android) の広告用識別子と、ユーザープロフィールが統合され、モバイルアプリ内の広告も最適化が完了します。追加で、位置情報も定期送信しておくと良いです。 これらのユーザーごとに広告配信を最適化する仕組みは、必ずしもリアルタイムではなく、日次~週次ほどのバッチ処理で随時更新されるような雰囲気です。すぐに面白い広告が出なくともしばらく放置してみると良いと思います。 以上の対応により、例えば、 Google 広告設定 を見てみると、以下のように収集された興味関心が一覧で表示されると思います。 現状の分析 現状どれくらい正確なユーザーの情報を得られているかについて、Google は Google Chrome により、SDK の埋め込みがなくても、全ての閲覧履歴を収集する仕組みを持っているので、格段に優位な状況にあると思います。 Facebook のモバイルアプリも、標準ブラウザでログイン済みかどうかを定期的に確認し、ログインさせる機能を有しているので、広告

[isucon] ISUCON7 本選17位でした

イメージ
2017年11月25日、LINE の新宿ミライナタワーの会場にて、 ISUCON7 本選にチーム 円山町(hidekiy, kotaroy, k_enoki) として参加してきました。成績は ISUCON6 本選と比べて若干の進歩はしたのですが、まだまだ上位層との壁を感じました。 当日やったことを書いておきます。 10:00~ SSH 鍵ログイン設定、Mackerel Agent 設定、Go 実装に変更、アプリの動作確認、Go の CPU プロファイル取得 (pprof) 12:00~ 分析の結果、初期状態のボトルネックは、DB と API のどちらの CPU, 各種 IO も使い切っていると言えないので、ロック競合か何かかと思ったが、煮え切らないまま深く考えなかった (これが致命的にまずかった) CPU プロファイル的には、多倍長整数演算が遅かったのと、コード上明らかにおかしな1000回ループ、テストコード付属という親切設計を見て、このループを最初に修理することにした。 16:00~ 初めて使う Go の多倍長整数演算ライブラリで、苦労の末1000回ループの除去に成功、それでも相変わらずボトルネックはDBのロックにあるように見え、これを何とか小細工しようとするが、特に有効な手を打てないまま時間切れとなった。 感想 速やかに、オンメモリー方式に作り替え、ロックを部屋別に分散させる決定をする必要があった。 Go の多倍長演算には結構苦しんだ。 糖を消費したせいか、ISUCON ケーキが美味しかった。 総括 素晴らしいイベントを企画、運営いただいた、LINE、KLab、さくらインターネット様には大変お世話になりました。ありがとうございます。