✖
✖
↑ の写真 webp で Google Photos にアップロードしたんだけど、Chrome で見ても jpeg でしか配信されない。うーん…… いまいち webp 配信の条件がわからない。
Google Photos 上のサムネとかは webp になってるけど、大きめの画像は jpeg 固定なんだろうか
Lightroom で webp の一発書きだし
webp のインストール
homebrew で入れる。
$ brew install libtiff $ brew install --HEAD webp
-
- HEAD つけないとコンパイル済みの TIFF 非対応バイナリがインストールされるので注意
Export Actions にシェルスクリプトを置く
~/Library/Application Support/Adobe/Lightroom/Export Actions
にスクリプトを置くと、書き出しダイアログで選べるようになる。書き出したあとスクリプトの引数に現像済みファイル名が渡されるので、これを処理するようにすればよい。
以下のようなファイルを webp.rb という名前で Export Actions フォルダに保存して実行属性をつけておく。
#!/usr/bin/env ruby
require 'logger'
logger = Logger.new('/tmp/webplog')
logger.info ARGV.inspect
begin
ARGV.each do |f|
dir = File.dirname(f)
out = File.join(dir, File.basename(f, ".tif") + '.webp')
logger.info "%s => %s" % [f, out]
IO.popen([
'/usr/local/bin/cwebp',
'-metadata', 'all',
'-preset', 'photo',
'-q', '90',
'-o', out,
'--',
f
], :err=>[:child, :out]) do |io|
while l = io.gets
logger.info l.chomp
end
end
end
rescue Exception => e
logger.fatal e.inspect
end
Lightroom の書き出し設定
ファイル設定
- TIFF
- 8 bit/チャンネル
として
「後処理」で「webp」を選ぶ
で書きだし。
問題点
EXIF が消える。cwebp が TIFF の EXIF デコードに非対応のため
h2o の proxy.reverse.url で localhost を指定していたら確率的に connection failure
リバースプロキシとして使っている h2o で
proxy.reverse.url: http://localhost:5001/
みたいに書いていたら確率的に connection failure がでて悩んだ。結局
proxy.reverse.url: http://127.0.0.1:5001/
で解決
なぜこうなったか
/etc/hosts に ::1 localhost のエントリ(IPv6)があり、h2o は解決したアドレスのうちからランダムに1つ選択するため。プロキシ先のバックエンドサーバは IPv6 を bind しておらず、::1 が選択された場合に接続に失敗していた。
メモ
- h2o がホストを選択するところ (rand している)
- nginx でも同様の設定をしていたが、nginx はランダムにしないみたい
このエントリを参照するエントリ
h2o で listen するポートを増やしたときは master プロセスの再起動が必要
start_server が listen してないポートは以下のようなエラーになる。
cp socket:(null):80 is not being bound to the server
h2o は SIGHUP で graceful restart が可能だが、listen するポートが変わった場合は実際にlistenしている親プロセス (start_server プロセス) の再起動が必要になる。
このエントリを参照するエントリ
nginx をアンインストール
これまで HTTPS (443) だけ h2o で処理していたが、nginx に使ってるぶんのメモリ量がMOTTAINAIのでh2oだけでやるようにした。さようなら nginx。
複雑なことをしているホストは全くなかったので普通に書きかえていっただけ
このエントリを参照するエントリ
さくらのVPSのウェブサーバでIPv6の接続をうける
最初からアドレスついてたので意外とやることない。
ifconfig すると既に v6 のアドレスがついている。Scope:Global になっているやつがグローバルIPアドレス (正確にはグローバルユニキャストアドレス)
inet6 addr: 2001:e42:102:1807:160:16:210:51/64 Scope:Global
これを該当ドメインの AAAA レコードでひけるようにする。
nginx
nginx -V の結果に --with-ipv6 があることを確認する。
server { listen 80; listen [::]:80; ... }
という感じにして ipv6 側もlistenするようにする。
h2o
listen: 80 と書いてる場合、デフォルトで v6 も listen するようになっているのでやることはない。
DNS サーバの IPv6 対応
ここでの「DNS サーバの IPv6 対応」はDNS サーバへの通信が IPv6 でできるかという話になるが、value-domain の NS1.VALUE-DOMAIN.COM とか、さくらインターネットの ns1.dns.ne.jp は対応していないっぽい?
IPv4 で解決できるなら別に問題ないんだけど、IPv6 オンリーの環境 (あるの?) からだと名前がひけないことになる。
確認
備考
自分に IPv6 アクセス環境がないので、とりあえず1つのドメインだけ対応させた。現状ではとくに IPv6 の対応したからといってメリットがないのが微妙。。。
このエントリを参照するエントリ
✖
人と人とは利害が一致する部分と一致しない部分があり、ある言葉を受けとるときにバイアスを補正して受けとる必要がある。自分にとって無意味なことでいちいち気が乱されるようなことを避けるために、相手のポジションと自分のポジションによって生じるバイアスは補正して理解しないといけない。インターネットは大変いろんな立場の人がいるため、いちいち全部の話を真面目に聞いてるとアホになる。
利害の一致(問題なく議論が成立する)
向いてる方向性が一緒なら議論可能なので、素直に意見をもってよい。
利害が不一致(前提が共有化されていないため議論不可。交渉が必要)
このとき必要なのは議論ではなくて交渉なので、議論をもとめられても適当にやっておけば良く、話真剣に受け止める必要はない。
なお経営者対従業員的な文脈だと、経営系の人はこういうことを言うと渋い顔をするので、あくまで「経営者視点を持ってます(キリッ」ってことにして真面目に聞いているフリをしておくこと。
アナログ値
お互いの利害を直交のベクトルとして合成したときの大きさによって、どれぐらい真剣に聞くかを決めたらいい気がする。二項対立というよりは、どのぐらい話を真剣に聞くべきかというアナログ値を感じたほうがよい。
サイトの負荷のシミュレーション
どのぐらいまで生きていられるのか気になったので試してみる。wrk を使う (ab だとうまく高負荷にできなかった) wrk は brew で入る。
ベンチの際いくつか注意する
- Transfer/sec が十分に低いこと
- 帯域を使いきってると負荷をかけきれない
- Non-2xx or 3xx responses がではじめたら限界
- 発生しなかったときは表示されない
$ wrk -c 170 -d 10s -t 16 https://... Running 10s test @ https://... 16 threads and 170 connections Thread Stats Avg Stdev Max +/- Stdev Latency 164.27ms 64.53ms 852.22ms 80.26% Req/Sec 61.56 22.99 170.00 72.60% 9278 requests in 10.10s, 44.31MB read Non-2xx or 3xx responses: 22 Requests/sec: 918.52 Transfer/sec: 4.39MB
日記システムは、これぐらいでCPUは使いきってちょいちょいエラーが発生する感じだった。
ヤフー砲が瞬間最大で100req/sec、継続的に30req/secぐらいらしいので、現実的にはこの日記が負荷で死ぬことはまずなさそう。他のサービスも同居してて相互に影響してる(バックエンドプロセスのワーカーを共有してる)けど。
このエントリを参照するエントリ
Mackerel つかいはじめた
サーバ移行のタイミングでつかいはじめた。監視をちゃんとするようにしようという感じ。loadavg5 と filesystem でひとまず監視。メトリクスの保存とグラフ化はフリープランだと1日だけなのであまり重視してない。
しかし、さくらのVPSはホスト不具合で落ちるってことは滅多にないので、やりたいことはサーバ自体の死活というよりウェブサーバの監視になる。このへんはプラグインでごにょごにょやってみている。パフォーマンス(応答時間のパーセンタイル値とか)とエラー数あたりでアラートが出せればいいかなという感じ。
チップコンデンサ(MLCC)の容量回復
高誘電体 MLCC は容量が時間経過で減少していくが、約125度(キュリー温度)まで加熱すると容量が回復する特性がある、らしい。
エージングで容量が減っていくというのはいいとして、一定より温度をあげると回復するというのを知らなかったのでびっくりした。
PS3/PS4 の修理方法でとにかくホットブローするみたいなのがあるけど、はんだクラックだけではなくて容量回復するという意味合いもあるのだろうか。
ref
✖
welq 問題でいろいろ思うところがあるけど、最終的にこれは「国会議員バカばっかり問題」と一緒ということなのだなと思って、解決にはほど遠いので気が重くなった。
「国会議員バカばっかり」って思うんだけど、あれは有権者が求めて選ばれた存在なわけで、こう思うということは有権者バカばっかりと思うに等しい。
検索エンジンの結果って、人々が求めるもののランクを上げた結果なので、その結果がバカなのって、結局人間がバカってことなんだよなあと思う。検索エンジンは人知を超えて賢くあるべきか?そして教育的であるべきか?はたしてそんな人工知能はバカな人間に受け入れられるのか (ビジネスになるのか)。
PV が稼げるのはなんでか
- 検索エンジンにヒットしやすいということ
検索エンジンにヒットしやすいのはなんでか
- すくなくともグーグルのアルゴリズムは「人にとって役に立つ」と判断しているということ
グーグルはなぜそういう判断をするのか
- 人々がそれを求めるため
人々はなぜそれを求めるのか
- 人はあんがい頭を使ってないから
地道にやることはネトゲから学んだ
ネトゲって最初からエンドコンテンツなので、スキル上げとかが途方もない。とはいえゲームなのでやってればいつか終わるぐらいのバランスにはなっている。結果僕らは学ぶことができる、時間をかければあらゆるタスクは必ず終わる。さらにネトゲに飽きて失った時間に気付いたときにもう一つ学ぶことができる。人生は有限であること。