✖
Sierra にしたらリモートの日本語が化けるようになった
以下のような環境で日本語が化けるようになった。
- macOS Sierra
- リモートで screen を使っている
- ssh host -t screen -r で復帰している
問題ないケース
- Sierra にする前は問題なかった
- ssh host して手動で screen -r
解決方法
どうやら ssh -t したとき、特定の環境変数がリモートに渡されなくなったみたいだった。以下のように ~/.ssh/config に追記した
SendEnv LANG
Sierra での man ssh から抜粋。複数書く場合はスペース区切りか SendEnv 自体を複数書けば良い。
Specifies what variables from the local environ(7) should be sent to the server. The server must also support it, and the server must be configured to accept these environment variables. Note that the TERM environment variable is always sent whenever a pseudo-terminal is requested as it is required by the protocol. Refer to AcceptEnv in sshd_config(5) for how to configure the server. Variables are specified by name, which may contain wildcard characters. Multiple environment variables may be separated by whitespace or spread across multiple SendEnv directives. The default is not to send any environment variables.
✖
ゼルダやってた
最初のほう。
あんまりスクリーンショット撮ってなかった。
祠さん……
ライネルさん……
まじゲーム下手なので最初はヒノックスすら怯えてて、ライネルとか全く勝てなかったけど、片手剣のライネルなら安定して倒せるようになっておもしろくなった。よくできてるなあと思った。
ゲーム内のカメラを使わないと自録りができないんだけど、そうするとフルスクリーンで撮影できないのがもったいない。
カメラ向けると喋ってるNPCも目線くれるのおもしろい。
macOS Sierrra にしたら ssh 時に毎回秘密鍵のパスフレーズを聞かれるようになった
Sierra になる前はキーチェーンに勝手に登録されてうまいことやってくれてた気がするけど、うまいことやってくれなくなった。
機能が削除されたわけではなくてデフォルトで無効化されたらしい。
Host * AddKeysToAgent yes UseKeychain yes
を ~/.ssh/config に追記した
SmooseMouse が Sierra で使えなかった
https://steelseries.com/downloads?utm_source=smoothmouse.com&utm_medium=recommendation
から ExactMouse tool というのをダウンロードして起動すると加速をきれる。
✖
✖
Ruby Sequel で生 SQL をメインに使う
Sequel はドキュメント見ると SQL そのまま書くやりかたもとクエリビルダを介すやりかたも許されていると感じるので (別に他のライブラリでも可能だろうが)、導入負荷が低くてよさそうです。結構機能はもりだくさんありますが必要なければ使わないのも許されてる感じもよさそうです。
Sequel でのクエリ発行のしかたは sequel/querying.rdoc at master · jeremyevans/sequel · GitHub を読むとだいたい網羅できるが、特に自分に重要なところだけ別途メモしておく。
モデルを使っても使わなくても SQL クエリはそのまま発行できる。複雑な JOIN も安心。
モデルを使わない場合
SQL を発行して Hash として取得できる。
dastaset = DB["SELECT * FROM foo"] dataset.all # 全インスタンス化
モデルを使う場合
任意の SQL を発行しつつあるモデルとしてインスタンス化したい場合
class Foo < Sequel::Model(:foo)
end
dataset = Foo.with_sql("SELECT * FROM foo")
dataset.all # 全インスタンス化 Sequel::Model(:foo) の :foo はテーブル名を渡す。何も渡さないとクラス名を複数形にしたものを探そうとする。が明示したほうが良いと思います。
どういうときにモデルを使うか
使いたいときに使う。単にクエリ投げたいだけならモデルはいらないし、特に JOIN がからむなら余計なことせず Hash で返ってくるのは気楽で良い。
機能的な面からいえば、DBからひいてきたインスタンスにメソッドを生やしたいというときはモデルを使ったほうが楽。既存の行を update したいときもモデルがあったほうが楽。
Sequel のモデルも若干マジカルで、DBコネクションがないとモデル定義できなかったりする。キモいけどテーブル情報を使ってアクセサを定義したりするっぽい。
JavaScript で MQTT するなら MQTT.js が良い
https://github.com/mqttjs/MQTT.js
- ブラウザ (MQTT over WebSocket) でも node.js でもほぼ同じ使いかたができる
- 自動でリコネクトしてくれる
- API がモダン
Eclipse Paho の JS 版を一時期使っていたが、完全に乗り換えました。
MQTT over WebSocket の場合
ドキュメントの通りだけど以下のようにする。TLS なら wss にするだけ。
const client = mqtt.connect("ws://" + location.hostname + ":" + (location.port || 80) + "/mqtt", {
username: USER,
password: PASS,
reconnectPeriod: 500
});
✖
Material Design Lite のテキストフィールドと Vue.js の相性があんまりよくない
Material Design Lite のテキストフィールドの input 要素を Vue.js で扱うとき、普通に v-model で two way binding すると、ラベル位置が更新されなくて文字が重なってしまったりする。つまりこれは Vue.js側の更新処理がMDL側に適切に伝わっていないために起こる。
MDLのソースを軽く読んだ解決として、mdl-js-textfield クラスがついている親要素に v-mdl 属性を追加し、以下のようにカスタムディレクティブを定義すると解決する。あんまり美しくないがしかたない。
静的な要素だけなら upgradeElementは必須ではないが、動的になると必須になるためついでにやっている。
Vue.directive('mdl', {
bind: function (el) {
componentHandler.upgradeElement(el);
},
update: function (el, binding, vnode) {
const textfield = el.MaterialTextfield;
if (textfield) {
Vue.nextTick(function () {
textfield.checkDisabled();
textfield.checkValidity();
textfield.checkDirty();
textfield.checkFocus();
});
}
}
});
✖
✖
✖
✖
Google Photos の ICC カラープロファイルの扱いの続き
Google Photos の ICC カラープロファイルの扱い | tech - 氾濫原 の続きです。前回のまとめとしては
- Google Photos は基本的に sRGB に変換
- s0 (オリジナル同等サイズ) のみ元々のカラープロファイルが保持される
- 500px 未満の場合はカラープロファイルが削除される
でした。
ただしある程度時間が経つまではオリジナルのプロファイルの画像が配信されることがあることがわかりました。
検証の試行錯誤
今日追試してみたところ、前回わかったルールよりもうすこし複雑なようだぞという挙動にみえ、ついでにいうと法則性がわかりませんでした。
あらたなファイルをアップロードして検証
今日あらたにアップロードしたファイルで検証してみました。以下のようにして s0 の部分をかえています。
curl https://lh3.googleusercontent.com/-4gapCD_T4ag/WOT-_iAPFkI/AAAAAAAAu-I/KXcMpxSoEcMurTrZ3umFh8nfOfOV88knQCE0/s0/IMG_7343-16MP-2.jpg | exiftool -
- s320 - なし
- s480 - なし
- s499 - なし
- s500 - sRGB IEC61966-2-1 black scaled
- s1024 - sRGB IEC61966-2-1 black scaled
- s1280 - sRGB IEC61966-2-1 black scaled
- s1919 - sRGB IEC61966-2-1 black scaled
- s1920 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
- s1921 - sRGB IEC61966-2-1 black scaled
- s2047 - sRGB IEC61966-2-1 black scaled
- s2048 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
- s2049 - sRGB IEC61966-2-1 black scaled
- s0 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
前回のファイルを再度検証
一方、前回検証したときに使ったファイルを再度検証してみましたが、こちらは前回と変わりませんでした。
curl https://lh3.googleusercontent.com/-BDMfJtqE7Mw/WIlEQ29H7II/AAAAAAAAnw0/2ZUwqimJUcQUbiLomaBrvwcrAebJFSjWQCE0/s0/IMG_9415-16MP-AdobeRGB.jpg | exiftool - curl https://lh3.googleusercontent.com/-pEtCDwM8HhQ/WIlEQ5CSwLI/AAAAAAAAnw8/rAyZIkuFVzEk3x68vRLPAkkevHUxEicJQCE0/s2048/IMG_9415-16MP-ProPhotoRGB.jpg | exiftool -
- s320 - なし
- s480 - なし
- s499 - なし
- s500 - sRGB IEC61966-2-1 black scaled
- s1024 - sRGB IEC61966-2-1 black scaled
- s1280 - sRGB IEC61966-2-1 black scaled
- s1919 - sRGB IEC61966-2-1 black scaled
- s1920 - sRGB IEC61966-2-1 black scaled
- s1921 - sRGB IEC61966-2-1 black scaled
- s2047 - sRGB IEC61966-2-1 black scaled
- s2048 - sRGB IEC61966-2-1 black scaled
- s2049 - sRGB IEC61966-2-1 black scaled
- s0 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
よくわからないので、前回と同じファイルをアップロードしなおしてみましたが変わらず。
同じ内容ですこし違うファイルを再アップロード
しかし s0 をダウンロードしたものを再度アップロードすると今度は以下のような結果に…
curl https://lh3.googleusercontent.com/-ykbJTkOQRME/WOUC9VszXHI/AAAAAAAAu-g/E5q6Ds_DJu06zrYiOK8J2FKNbmMjlU34ACE0/s2049/IMG_9415-16MP-AdobeRGB.jpg | exiftool -
- s320 - なし
- s480 - なし
- s499 - なし
- s500 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
- s1024 - sRGB IEC61966-2-1 black scaled
- s1280 - sRGB IEC61966-2-1 black scaled
- s1919 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
- s1920 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
- s1921 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
- s2047 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
- s2048 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
- s2049 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
- s0 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
なぜか s500 でオリジナルが適用されていたり、だいたいオリジナルが適用されるかと思いきや s1024 や s1280 では sRGB になったりと意味不明です。
落ち着く
あきらかに挙動に疑問があるので、一旦冷静になります。さすがに Google といえどファイル内容を見てプロファイルを埋め込むかどうかを判定しているわけではないだろうし、なぜこんなことに……
と少し時間が経過してから再度検証してみたところ、結局 s0 以外は全て sRGB になりました。つまり
- 動的にリサイズする場合はプロファイルが保持される (s0 はリサイズしないのでそのまま)
- リサイズ結果は sRGB となり静的にキャッシュされる
が真相のようでした。動的にリサイズする場合はプロファイル変換までやるとオーバーヘッドがあるためプロファイルを埋め込むみたいな戦略なんでしょうかね？