cafegale(LeafCage備忘録)

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

note.muを登録するときには初めの、興味のあるジャンルを選択してフォローする機能を使わないようにしないように

興味のあるジャンルを選択すると、もっと少なくて気軽にタイムラインを眺められる分量のユーザーが登録されるんだろうなー、そこからフォローを絞り込んだらいいやーとか深く考えずにいたら、150を超えるユーザーを初期で登録されて、しかも削除するのにマイページ作成まで進まなくてはいけなくて、とても難儀した。

フォロー外すボタンを連続で押すと誤動作でそのユーザーページに飛んだりしてすんなりフォロー全部外すことができないんだよ!

 

私はただ、ほんの気になった記事一つをブックマーク代わりに登録しようとしただけなのに、予想外の事態になって、フォロー削除作業に時間を費やすことになった。

 

初期登録で150を超えるフォローをさせるような仕様にしないでください。多くても30です。それ以上は認知が追いつきません。note.mu運営さん。

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

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

 

q-az.net

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

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

しかし、ウィンドウの幅を取得するときにはECMAScriptwindow.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文字)にすべきだし、頭字語にしない。頭字語からほんの少しずらす。

例えば、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)

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

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