cafegale(LeafCage備忘録)

LeafCage備忘録（はてなダイアリー）と統一しました。

なんでinnerWidth outerWidthじゃなくて clientWidth offsetWidth なの？

front-end

ブラウザ js の、DOM要素のサイズを取得するプロパティ／メソッドの話。

 

q-az.net

js標準であるECMAScriptでは、jQuery なら .innerWidth であらわされるものが .clientWidth に、.outerWidth であらわされるものが .offsetWidth になるんですと。

多少わかりにくい命名なのだが、これ単体なら命名の違い程度にしか思わない。

しかし、ウィンドウの幅を取得するときにはECMAScriptは window.innerWidth(ウィンドウ内側表示領域（垂直スクロールバー含む）)、window.outerWidth（ブラウザのウィンドウサイズ）を使うんですと。

統一しとけよって思う。

マウスイベントなどのときの `offsetX` や `clientX` の扱い方とかを見る限り、JavaScriptは "offset" や "client" という語をかなりいい加減に扱っているように思われる。（ここでは `client` をウィンドウからの距離、`offset` を発火したDOM要素からの距離として扱っている）

qiita.com

 

web-designer.cman.jp

 

ところで、DOM要素のサイズを取得するのに`getClientRects()`というのがあるが、直接`offsetWidth`で取得できるのに、このメソッドの存在意義はあるのだろうか？
(getClientRects()の返り値のDOMRectの`height`が`offsetHeight`、`width`が`offsetWidth`相当)

 

なんかうまくまとめてる記事見つけた。

babyron64.hatenablog.com

はてなダイアリーが終わってしまうのか

しょうがないから、はてダの記事をこっちにインポートしてブログを統一した。
別のブログを作成してそっちにインポートすることも考えたけれど、domainを考えるのが面倒だったし、今現在こっちのブログとはてダとの使い分けがあいまいになってきているし*1。

はてダの何も考えずに書き散らせる感じがよかったんだがなぁ。はてブロでは「見たまま編集モード」にしていても、「記事を書く」で一瞬Ajax的なロードがあるが、はてダはそういうもたつきはなかったし、はてな記法などを適度に交えて気軽に書き散らせる感じが好きだった。はてブロの「見たまま編集モード」は実際にはこちらが想像した通りのhtmlになってくれてないときがある（改行ごとに<p>タグにされてしまうところとか）（このあと気づいたけれど、<p>タグ入れずに改行するためには shiftキー押しながらEnter押さないといけないみたい。だる）
そして、はてダでは記事を保存せずに閉じたら勝手に下書きとして保存してくれていたが、はてブロではそういった気の利いたことはしてくれないようだ。
しかも下書きにしたら次編集するときには「ダッシュボード」画面からいくつか画面変位を経ないといけないじゃないか！

見たままモードで記事を書き終わった後の、更新されました画面も画面いっぱいに表示されて、閉じるボタンを押さないとブログを確認できないのもくそだるい。

そういえば、はてダ記事の、はてな記法や、微妙に入り混じったhtmlの部分はちゃんと考慮してインポートしてくれてるんだろうか？
おかしな形にインポートされている気がするが、確かめる気力がない。

あと、心残りはカテゴリーだ。はてダのカテゴリーは自分ルールで、他人には理解できないようなものを付けていたけれど、統一されてはてダ時代の訳の分からないカテゴリーが入り混じってしまってるのが、残念ポイントになってしまった。

 

メディアマーカーも終わってしまう。愛用していたサービスが終焉を迎えていくのは面倒なことだ。引っ越し先を考えないといけないし、なければ最悪自分で代替ツールを作らなければいけない。メディアマーカーの代わりを務められるだけのものがみつからなかったので、自分で何かツールを用意することになるだろう。本当、面倒なことだー。

*1:あと、はてなブログを2つ持つと上部ヘッダーからの編集メニューにサブメニューが表示され、どちらを編集するかを選ばなければいけない手間が増えるのが嫌だ

MacからRemote Desktop でWindowsにつなぐと一部のキーが使えなくて超不便

PrtSc や バックスラッシュ2つが動かない。
バックスラッシュは正確には標準ではない文字コードが出力される。このMacから送られるおかしなキーコードが厄介で、AutoHotkeyでキースワップでとらえることができない*1。
何とか解決策を探したけれどどうにもできなかったので、
PrtSc はAutoHotkeyをいじくって Winキーとs を同時押しでも機能するようにして対応

#s:: Send, {PrintScreen}

バックスラッシュはMac側のKarabiner elements でいったん別のキーにしてからさらにAutoHotkey でキーを差し替える的なやり方で解決した。

    {
      "description": "右上バックスラッシュをリモートデスクトップでright_guiに",
      "manipulators": [
        {
          "from": {
            "key_code": "international3",
            "modifiers": {"optional": ["any"]}
          },
          "to": [
            {
              "key_code": "right_gui"
            }
          ],
          "conditions": [
            {
              "type": "frontmost_application_if",
              "bundle_identifiers": [
                "^com\\.microsoft\\.rdc\\.osx",
                "^com\\.microsoft\\.rdc\\.macos"
              ]
            }
          ],
          "type": "basic"
        }
      ]
    },

RWin:: \
vkFF:: Send, {vkE2}
+vkFF:: Send, +{vkE2}

*1:実際には犯人はMacか、Remote Desktop for Macかわからない

短い変数名を付けるときは3文字以上（できれば3文字）にすべきだし、頭字語にしない。頭字語からほんの少しずらす。

notation

例えば、CheckManager を収める変数名を付けるなら `cm` でなく、例えば `cmg` にする。
頭字語は文脈からほんの少し離れるだけでぱっと見で意味が解らない。
「`cm`・・何の略だったっけな・・」と一瞬考えてしまう。それが目に見えない心理的なロスになる。

そして、短い変数名を付けるとき3文字が読むときにも書く時にも都合がいい。
3文字は書く時には補完を使わずに打てる許容量だ（4文字は補完を使うかどうかのギリギリの線だ）。
そして読むときには直感をつかさどる原始的な脳が瞬間的に把握できる文字量だ。

私は短い変数を気に入っている。短いということは一時的に作られ使われるという視覚的シンボルになる。
それでもほんの数行程度、本当に一度しか使われないのなら1文字2文字の変数もありだと思うけれど*1、それ以上長く使うとか、何度も使う（他の関数で同じようにして同じ名前の変数を作っているなど）ならやはり3文字がベストだと思う*2。
そして3文字に近くても頭字語になるならほんの少し文字を足し引きして、元の単語の目立つ音の文字を取り出して作って、なんとなく元の単語が想像できるように作るべきだと思う。

*1:逆にそういう短い期間でなら冗長な変数名でもいい。

*2:実際、変数の寿命よりも使用されている頻度の方がより重要である。使用されている頻度が高いのなら、変数名は短い方がいい。（頻度が高いと変数名が短くても概念として記録できる。）

Mac mini を中古で買ったので環境を整える途中経過

感じるのは、環境一つ整えるにしてもMacは大抵有料ソフトしかなく、しかも問題にならんだろうと高をくくっていたところが（Appleがおかしな制限をしてたりするせいで微妙にかゆいところに手が届かず）問題になったりして、やっぱMacって私のような自分の妙な操作性に拘る人間には向いてないんだなって事。
そしてwindowsは独自仕様を入れて囲い込みをしていて好きではなかったのだが、Macも相当おかしな仕様を入れていて、囲い込みの程度は50歩100歩だった。
それでも一昔前と比べてだいぶん自分好みのカスタマイズができるようになってたので、手放さずに済みそうだ。

ffmpegエンコード設定メモ

tsファイルをffmpegでx264 mp4でエンコードする設定を検案した際のメモ。
エンコードの適切な設定値を求めようとするとどうしても大量のドキュメントを読まなくてはいけないし、実際にいくつかの設定でファイルを生成して出来栄えを比較することも必要になってくる。つまり楽はできないってことだ。
Handbrakeからffmpegに乗り換えたわけはffmpegの方が汎用性がありそうだったから。

CRF＞CQP＞VBR

CBRやVBRやABRは基本的な知識だ(CBR(固定)とVBR(可変)とABR(平均)の違い【ビットレート】)が、ほかにCQP、CRFという方式があって訳わからなかったので調べた。

どうやらCQPもCRFもVBRの一種らしい。生成されるファイルのサイズを考慮するとCRFが最も優れている？

PSP向けにエンコードを始めた頃から、同じ容量で圧倒的に高画質になる2パスエンコードを盲目的に信仰し、高画質を狙うときは常に使っていましたが、実際は品質基準VBR（可変ビットレート）の方が画質が上回る場合があることにびっくり。

地デジのエンコード設定を試行錯誤。 - WebLog
  • FFmpeg, H.264 エンコーディングガイド
    • 手早く済ませたいときにはCRFを、出力サイズが決まっている場合は2-Pass ABR を勧めている(画質はCRFの方がいい)。
    • プリセット(-preset)は slow slower velyslow を使うことが推奨されている(デフォルト medium)

CRFの適切な値は？

20くらいらしい。私はffmpegのデフォルト値23を使うことにしたが。

profileはMainに

h.264の画質について(Main ProfileとHigh Profileのお話) - ぼくんちのTV 別館

内蔵AACは音質が良くないのか？

ffmpegで使える音声codec：AACについて - 脳内メモ＋＋
libfdk_aac や libfaac はライセンスの関係で組み込まれていない。欲しけりゃコンパイルしろ

字幕

ffmpeg -i INPUT -f srt -i SUB.srt -map 0:0 -map 0:1 -map 1:0 -metadata:s:a:0 language=jpn -c:a copy -c:v copy -c:s mov_text OUTPUT
Ubuntu Linuxでtsファイルをffmpegでmp4に変換する際にmov_text字幕ファイルをsrt形式で埋め込む方法（シェルスクリプトで自動化対応） | web net FORCE
FFmpeg使って複数の音声と字幕から一つの動画を作成する - Qiita
mp4 - Use ffmpeg to add text subtitles - Stack Overflow
FFMPEG An Intermediate Guide/subtitle options - Wikibooks, open books for an open world

PS: VLCはバージョン3以上でないと字幕のサイズが設定にかかわらず最小になってしまうバグがある。

-movflags faststart

HTML5のvideoタグで利用するmp4の動画を作る時のTips - Qiita

解説ページ

どのナッツをメインに食べるべきか、脂肪酸に注目して検討してみる

(追記)読むのがダルい人のために結論：（良い）マカダミアナッツ＞ヘーゼルナッツ＞カシューナッツ＞アーモンド＞＞ピスタチオ＞＞＞その他（悪い）

===
ララバー(エナジーバー)の材料に、また普段の間食に、どのナッツをメインにするかを検討した。
ナッツはオイルが多数含まれているのでどれでも食べすぎ注意なのだが、それでも食べるとすればどれを選ぶべきなのか。
複数のサイトをめぐってみたが、脂肪酸の比率を分かりやすくまとめたサイトがなかったのでここにまとめてみた。

評価方針

脂肪酸で酸化しにくいものを高く評価する。したがって飽和脂肪酸と一価不飽和脂肪酸を高く評価する。
多価不飽和脂肪酸は低いに越したことがいいが、含まれているのならオメガ3の比率が高いものの方がいい。
オメガ6は可能な限り低いほうがいい。

備考

オレイン酸‥一価不飽和脂肪酸のひとつ。オリーブオイルなどに含まれる。
リノール酸‥オメガ6。現代人は摂りすぎと言われる。
αリノレン酸‥オメガ3。EPAやDHAに代謝されて体にいいと言われるが‥

脂肪酸表

100gあたり(カロリーSlism - 栄養成分/カロリー計算より※)
(※カボチャの種のみ SELF Nutrition Data | Food Facts, Information & Calorie Calculator より)

名前 飽和脂肪酸 一価不飽和 オメガ6(悪) オメガ3 脂肪酸総量 100gあたり参考価格
アーモンド 4.13g(7.9%) 35.16g(67.6%) 12.67g(24.37%) 0.01g(0.01%) 51.97g 252.6円
カシューナッツ 9.97g(21.7%) 27.74g(60.5%) 8g(17.4%) 0.08g(0.17%) 45.79g 314.8円
ヘーゼルナッツ(ハシバミ) 6.21g(9.3%) 54.74g(82.6%) 5.24g(7.9%) 0.07g(0.1%) 66.26g 329.4円
マカダミア(マカデミア)ナッツ 12.46g(17%) 59.23g(80.9%) 1.47g(2%) 0.09g(0.12%) 73.25g 558.4円
くるみ 6.83g(10.1%) 10.26g(15.2%) 41.32g(61.29%) 8.96g(13.3%) 67.41g 315円
ペカン(ピーカン)ナッツ 7.4g(10.6%) 37.33g(54.3%) 23.07g(33.5%) 0.99g(1.4%) 68.79g 494.1円
ピスタチオ 6.15g(11.5%) 30.92g(57.8%) 16.22g(30.3%) 0.2g(0.37%) 53.49g 303.5円
ヒマワリの種 5.68g(12.1%) 12.87g(27.5%) 28.22g(60.2%) 0.09g(0.2%) 46.86g 152.4円
カボチャの種 8.0g(19%) 13.1g(31.1%) 19.02g(45.18%) 0.166g(0.39%) 42.1g 213.3円
ピーナッツ 8.33g(18.6%) 22.76g(50.8%) 13.65g(30.4%) 0.08g(0.18%) 44.83g

おまけ

名前 飽和脂肪酸 一価不飽和 オメガ6(悪) オメガ3 脂肪酸総量 100gあたり参考価格 備考
チアシード 3.2g(10.39%) 2.1g(6.8%) 5.785g(18.78%) 17.552g(56.99%) 30.8g 149円 unroasted
フラックスシード(亜麻仁) 3.7g(8.77%) 7.5g(17.77%) 5.911g(14%) 22.813g(54.06%) 42.2g 280.5円 unroasted?
えごま 3.34g(8.6%) 6.61g(17.04%) 5.12g(13.19%) 23.7g(61.09%) 38.79g
キヌア 0.7g(11.48%) 1.6g(26.2%) 2.977g(48.8%) 0.307g(5.03%) 6.1g unroasted?
松の実 5.8g(8.3%) 20.26g(29.1%) 31.36g(45.1%) 0.18g(0.25%) 69.51g 643.9円 およそ9.94gの多価不飽和はピノレン酸だと思われる
評価

マカダミアナッツ＞ヘーゼルナッツ＞カシューナッツ＞アーモンド＞＞ピスタチオ＞＞＞その他
ふたを開けてみればオメガ3はくるみ以外にはほとんど含まれず、無視していい要素だといえる。

  • オメガ3を摂るならくるみと言われているが、それ以上にオメガ6の比率が多い。くるみではオメガ3とオメガ6の比率を改善できない。あえて摂る意味は少ない。
    • というかオメガ6がダントツに多いからむしろ避けるべきではないのか？ヒマワリも多いけれど、くるみは脂肪酸総量自体が多いし。
    • オメガ6とオメガ3のパレオ的理想比率は1:1だが、くるみではどう頑張っても達成不可能。
    • ナッツからオメガ3を摂るなら圧倒的にチアシード。
    • そもそもオメガ3を積極摂取すべきという言説を私は疑っている。酸化しやすいし、むしろ有害という説もある。オメガ3を摂るよりもオメガ6を減らすことを考えるべきという意見に賛成。
    • オメガ3を摂りたいのならナッツで摂るのは諦めてサバ水煮缶を食べるべきだ。
  • ヘーゼルナッツ、マカダミアナッツは優秀。徹底してオメガ6を減らしたければマカダミアなのだけど、コストを考えるとヘーゼルナッツも混ぜたい。
  • カシューナッツもまずまず。甘みが強いから脂肪が多く含まれてる先入観があったがこの中では最も脂肪が少なかった。オメガ6も意外と少ない。コストも安い。
    • ただし甘みがあるからつい食べ過ぎてしまうという問題がある。小分けにしておくとか、砕いて何かに混ぜるといった工夫で摂取量を制限したい。
    • 飽和脂肪酸が多いが私は飽和脂肪酸を気にしないのでOK。


というわけで、カシューナッツ、ヘーゼルナッツ、マカダミアナッツをメインに摂取することにした。
意外とカシューナッツとヘーゼルナッツは優れていたんだな。さすが3大ナッツだ。
アーモンドはほどほどに、ピスタチオはカビ毒が怖いからさらにほどほどに、ヒマワリの種は数値だけを見ればあえて摂る意味がないけれど好きなのとコスパがいいので何かに混ぜる程度に使用する所存。ピーカンナッツはあまり好きじゃないので買わない。ピーナッツは好きじゃない上に毒性が強いので摂らない。
くるみは今まで健康に良いと信じて積極摂取していたけれど、こうやってまとめてみるとデメリットばかり目立つ結果となったのでもうこれからは控えていこうと思う。

参考

その後、各ナッツの評価

鳴り物入りで希望がもたれていたヘーゼルナッツだが、ローストした味が油っぽいのと、食欲を促進させて食べ過ぎてしまうという問題点が浮上した。
現時点での仮説は、アーモンドとカシューナッツと何かほかのナッツを組み合わせることでちょうどいいおつまみになるのではないか、とのこと。
なおヘーゼルナッツはデーツと混ぜることでブリスボールとして活用することも考えたが、デーツ自体が甘すぎてかえって食欲を増進させてしまうためこの計画も半ばとん挫気味。ドライフルーツとして現時点で甘みが少なく評価できるのはイチジクであるが、ことによってはブリスボール化せず、単品でイチジクとナッツをつまむという構成も考える。

  • マカダミアナッツ
    • コスパ悪いことを除けば優秀。おつまみにも素材にも最適。
  • ヘーゼルナッツ
    • 単独で食べるには癖のある味でしかも食欲が抑えられない（またほしくなる）ので不適。お菓子などの素材に混ぜるのがよいだろう。
  • カシューナッツ
    • この甘みから、食欲を抑えるおつまみの役目としては不適切である疑いがある。まだ結論を下していない。なお、素材として混ぜるのには向いている。
  • アーモンド
    • 独特の香ばしさとコスパの良さからおつまみ候補に浮上。単独では食欲を抑えるのに力不足の感があるが、カシューナッツと同時に食べると案外役割を果たせるのではと希望がもたれる。なお、堅いため、砕くと歯茎に刺さり、素材として使うには不適。ヘーゼルナッツと対極でおつまみ専門。