Windows 8 Pro 64bit版環境下での話なのですが。
@font-faceを使用してウェイト別に異なるフォントを割り当てる (太字に別フォントとか) - ymknの日記のようにして、太字の文字が引き延ばしのBoldではなく適切なウェイトの書体で描画されるようにしていたのだけど、Chrome 37からこれが効かなくなった。
ユーザスタイルに限った話ではなくて、Chrome本体のフォント設定でも、ウェイト名付きで表示されているフォント（M+とか）が効かなくなっている（リストから選んでも前の書体から変更されない）。
これって仕様変更なのかなあ。適当にChromeやChromiumのリリースノートを見てみたけど、それっぽい記載は無いし・・。
直ったぽい。従来通りウェイト名付きで表示されているフォントも効くようになった。
Chromeのバージョンは37.0.2062.102 unknown-m (64-bit)。日本語グリフの描画周りに問題があって修正されたようなので、それがらみなのかも。
最近すっかり完全放置状態の自サービス創作小説投稿コミュニティー - ぱろしょだが、サーバーホスティング元にてソフトウェアの一斉バージョンアップメンテナンスが行われるとのことで、影響確認テストを行った。
現新の環境はまとめるとこんな感じ。
| 環境 | PHP | Apache | MySQL |
|---|---|---|---|
| 現行 | 5.2.x | 1.3 | 5.1.22 |
| 検証環境*1 | 5.5.11 | 2.4.9 | 5.1.73 |
| 新環境 | 5.3.x | 2.4.9 | 5.1.73 |
検証環境のバージョンがやたら高いが、個別に用意するのが面倒なのと、PHP: PHP 5.4.x における変更点、PHP: PHP 5.5.x における変更点を見た感じ、5.3から5.5の間に戻された仕様はなさそうなのでまあいいかと判断。でもさすがにノーチェックは怖いので、無影響確認のつもりで全画面一通り打鍵した。
で、下記のような問題を発見。対処した。
最後のものはPHP 5.3とは関係なくphp.iniの設定の問題だが、個人的にはもとより<?phpで統一していたつもりだっただけに発見したときは驚いた。n年越しの潜在バグというやつだ。動作しているPHPファイルをそのまま食わせただけなのに構文エラーとなり、発見に苦労した。括弧の数があっているか追うために<?でソースを検索していたときに偶然見つけたのだ。いやはや。
これでとりあえずは安心と思っているが、バージョンアップから数日はチェックが必要かな。仕事が立て込んでいるので、何かあったら睡眠時間を削る羽目になる可能性が高い。ホント、ソフトウェアのバージョンアップ問題は頭が痛い。
*1:XAMPP 1.8.3
Windows Server 2003以降で使用できるポリシーベースのQoSによるネットワーク通信の優先制御や帯域制御は、対象の通信に使用するネットワークアダプタのプロパティで「QoSパケットスケジューラ」が有効でないと機能しない。
ポリシーは確かに適用されているのにQoSが効かず大変悩んだのだが、原因がこれだった。直接的な警告もエラーも出ないため突き止めるのに大変苦労した。
なお、ポリシーベースのQoSを使用するためにQoSパケットスケジューラが必要な旨は下記参考サイトにて言及があるが、Windows Server 2003向けの部分に記載されていたため読み飛ばしていたのだった。
参考：The Cable Guy: Windows での QoS のサポート
どなたかの参考になれば幸いです。
カフェ風（笑）なリビング空間を演出するために、iPod Touchを使ってTuneIn Radio(ほぼSKY.FMしか聞いてないけど)でネットラジオを流すなんてことをよくやるのだけど、出力に使っているのがただのMDコンポ(CD部故障)なので、iPod TouchからAUX INにステレオケーブル直刺しとかやってて、さらに充電用にUSBケーブル＋USB-ACアダプタなんかも必要でケーブルだらけであり、見た目的に美しくなかった。
で、嫁さんから買い換え許可が下りたこともあり、MDコンポをBluetoothスピーカーにリプレースした。いろいろ調べた結果買ったのはP9｜フィリップス Fidelio ワイヤレスポータブルスピーカーのホワイト。
フィリップス Fidelio P9 Bluetoothスピーカー ブラック P9BLK
これを選んだポイントは、↓な感じ。
iPod用のDockがあるものを選ぼうか迷ったのだけど、Appleが規格を変えると無駄になるし、デザイン的に微妙なので、汎用的に使えるBluetoothを選んだ。スマホとかもつなげられるしね。
で、こんな感じになりました。すっきりおしゃれ。
比較用の写真はないのでどれくらいすっきりしたのかはわかりづらいね。とり忘れたのだ。
その手前にある細長い白いのはApple Remote(初代)。iPodが挿さっているUniversal Dockとペアリング済み。離れたところから操作と言うより、普段はDockの目の前に置いて使ってる。Dockに挿したまま画面をタッチ操作するのが案外大変なので、Remoteのボタンをポチポチして再生/停止してる。便利。
あと、不満点とか。まあ、些細なポイントではある。
まあ、おすすめです。
これに気づかずハマリにはまったのでメモ。
[すべてのユーザー ID のコンピューター全体のトレース]にチェックを入れれば[ログ ファイルのパス]に指定したファイルに全てのユーザのトレースログが出力されると思い込んでいたのですが、どうやら常にユーザ別のパスに出力されるらしい。
どういうことかというと、ODBCを使ってDBアクセスを行うサービスservice_aをhoge_userというユーザで実行しているときに、メンテナンス用ユーザfuga_userでservice_aのODBCのトレースログを取得しようとして、fuga_userでODBC アドミニストレータを起動して上記画面の[すべてのユーザー ID のコンピューター全体のトレース]にチェックを入れ[トレースの開始]を押下しても、
[ログ ファイルのパス]に一切トレースが出力されない、という話。
どこにログが出ているのかというと、serivce_aを動かしているhoge_userの[ログ ファイルのパス]に指定された場所である。なんてこった。
[ログ ファイルのパス]は通常%TEMP%¥<数字>¥SQL.LOGとなっているので、そこを見に行けば良い。管理上場所を変更したい場合は、hoge_userでログインしてODBC アドミニストレータを起動し、[ログ ファイルのパス]を変更すれば良い。
やっかいなのはhoge_userがサービス実行専用に設計されていて、デスクトップログインを許可していない場合。ODBCアドミニストレータの設定の実体は下記レジストリキーにある。
ユーザ別な設定: HKEY_CURRENT_USER\Software\ODBC\
グローバルな設定: HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\
[ログ ファイルのパス]はユーザ個別の設定なので、HEKY_CURRENT_USERのほうにある。ただ、HEKY_CURRENT_USERは現在ログイン中のユーザのレジストリである。今回修正したいのはログインできないhoge_userのもの。HEKY_USERSからhoge_userのツリーを探す必要があるが、面倒なことにユーザ名ではなくSIDでツリーが分けられている。つまり、hoge_userのSIDを調べる必要がある。
下記サイトのようにして、HKEY_LOCAL_MACHINE以下のキーから各ユーザのSIDを推測し、目的の値を修正すれば良い。
普段の業務ではかすりもしないジャンルだけれど、いい加減無視し続けてもいられないモバイル開発。というわけでAndroid開発の勉強がてらアプリを作ってみることに。大変ローペースだけれども三日坊主はこえたっぽいので、非公開でつけていた開発日誌を公開にしてみる。
まずは動くものができるのを最優先に、コピペプログラミング上等でゆっくりやってます。
確認電話を受けた際に、今後の連絡は不要である旨を伝えたところ了解してもらえた。
(それ以降、宅配BOXで受け取るような郵便物がないので、本当に連絡しない運用になったのかは不明であるが)
宅配BOXに入れた旨記載した伝票が郵便受けに入っているので、電話までしてフォローするのは過剰と感じるが(実際、ヤマトとか佐川はやらないし)、郵便局の顧客層を考えると致したがない運用なのでしょう。
ともあれ、このような個人的に重要度が低いと思っている電話が仕事中にかかってくると大変鬱陶しいので、同じような悩みを抱えている方はぜひおためしください。
