2017年 04月 17日

✖

photo

関連エントリー (画像)

2017年 04月 14日

Ruby Sequel で生 SQL をメインに使う

tech

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 が良い

tech

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
		});

関連エントリー

2017年 04月 13日

✖

photo

関連エントリー (画像)

Material Design Lite のテキストフィールドと Vue.js の相性があんまりよくない

tech

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();
			});
		}
	}
});

関連エントリー

2017年 04月 12日

✖

photo

関連エントリー (画像)

2017年 04月 11日

✖

photo






関連エントリー (画像)

2017年 04月 10日

✖

photo






関連エントリー (画像)

2017年 04月 05日

✖

photo




関連エントリー (画像)

Google Photos の ICC カラープロファイルの扱いの続き

tech

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 となり静的にキャッシュされる

が真相のようでした。動的にリサイズする場合はプロファイル変換までやるとオーバーヘッドがあるためプロファイルを埋め込むみたいな戦略なんでしょうかね？

関連エントリー