Tech カテゴリー「サイトの写真の表示方法の変更」以前の3件

サイトの写真の表示方法の変更

tech | 00:24 |

サイトのCSS・JSのちょっとした変更。1ヶ月前ぐらいから写真まわりにちょいちょい変更をいれてる。

写真の高さを 100vh に制限するようにした
ある程度以上のスクリーンサイズのときは16MPをロードするが、時間がかかるため、あらかじめ同等の大きさの灰色の画像を表示するようにした
ロード中にロード中とわかるようにアニメーションをつけた (Spinner)

アスペクト比を維持した画像のリサイズがむずかしい

このサイトの画像 (img 要素) は以下のようになっている

max-width max-height を指定
width: auto; height: auto を指定
十分に大きなサイズの画像を指定

これにより、max-width/max-height を超えない限り最大の大きさで、アスペクト比を保って表示することができる。しかし問題点がある。

問題点：ロード時にレイアウトが確定しない

img 要素にはロード先画像の width 及び height を属性値で指定してあるのだが、CSSで auto を指定しているため、実際に画像のサイズが得られるまで、レイアウトが確定しない。つまり画像ロードのタイミングで不定期にリフローが起こり、ページ全体の高さが変わる。

JS では実行タイミングがどうしても遅くなるので、できればCSSで対応したいが、うまい方法がない。

せっかくwidth/height 属性値でサイズを指定していて、アスペクト比がわかっていて、理論上は幅と高さを確定することができるはずなのに、これが現状ではできそうにない。

現行の対策

いい方法が思いつかなかったため、JSで動的に対処した。img 要素の width/height 属性をもとに canvas で画像を生成して、まずはこれを表示する。

これによって本来の画像を読みこむ前に、HTMLの情報だけでレイアウトを確定させることができるため、画像がロードされるたびにページの高さが変わるということはなくなる。

しかし JS でやっているため、高さが未確定の状態で1度レンダリングされてしまう。

Sierra にしたらリモートの日本語が化けるようになった

tech | 13:09 |

以下のような環境で日本語が化けるようになった。

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.

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

tech | 00:50 |

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コネクションがないとモデル定義できなかったりする。キモいけどテーブル情報を使ってアクセサを定義したりするっぽい。