✖
筋の悪さ
JS しか書いてないんだなって人は筋悪いものをありがたがっていたりする印象はある。しかし筋悪いものをありがたがるみたいなのはどこにでもいるので、JSがどうとかは直接は関係がないはずではあると思う。JSしか書いてない人とPHPしか書いてない人は似たようなもんで、単に広範囲の知識に興味がないだけな気がする。
それはともかく「これは筋悪そうだな」っていう感覚がどこからくるのかよくわかってないので、現時点で思いつく限り雑にメモしておく。
割の合わなさ
「これは何の問題を解決してるんだろう」と思ってドキュメント読んだりソース読んだりした結果、大したことを解決してなくて、その割に実装量が多いとか学習コストが高いと、筋悪いなあと思う。
フットプリントや学習コストに対して提供されるモノが「割に合わない」のは筋が悪く感じる。
将来性のなさ
「あ、これはただの流行だな」みたいな、5年後には消滅してるなというものは筋が悪い。
標準にそういう機能入るよ、みたいなのを全然違うインターフェイスで実装してたりするのとかがあてはまる。標準で議論されている機能なら、ポリフィルにするのが最も将来無駄にならない。
HTTP2 に向けてキャッシュフレンドリーなリソース構成にしていこうな、という昨今で、何でもかんでもパックや!みたいなのも、今はぎりぎりいいかもしれないけど、既に筋悪い感じがする。
プログラムの見方を変えないラッパー
たとえば Promise はコールバックのちょっとしたラッパーぐらいの機能しかないが、プログラムの見方を変えるという重要な役割を持っているので、意味がある。
しかし単にシンタックスシュガー的なものしか提供していないとかで、何もプログラムの見方が変わっていないのにラッパーがかぶさっているのは、ライブラリとしての意味がない。
「プログラムの理解を助ける」という役割はとても重要だけど、そういう視点で作られているライブラリかどうか、それが割に合うかは難しい。
しかし最悪なのは書き手にとってしかメリットがないというもの。特に実装を全て読まないと使えない系は要注意で、そういう書き手のオナニーで変なラッパーが挟まってるみたいなのは読み手がとても苦労する。これはメリットがないというよりも明確に将来にわたって害となる。
ただし実装を全て読まないといけないものが全てだめかというとそういうわけでもない。実装は読まないと危険だけど可読性はあがるので割に合うこともある。
フルスタック
フレームワークのレールから外れた瞬間アホみたいなマジカルコードを書くことになる。レールから脱線すると必ずハマる。そしてフレームワークの枠組み内で収まるようなアプリケーションはない 。
もし使う場合コピペで実装できる以外のことをしないことがポイントで、「ここはこう書きたいんだ！」という自我を捨ててコピペする機械として生きなければならない。
実際のフルスタックというのは検索して出てきたstackoverflowのコピペで全部やりますよという意味で、なんでもできるという意味ではない。
HTTP2 で何をサーバープッシュすべきか
意外と何をプッシュすべきか悩んだのでひとまず現時点での自分の結論をまとめました。
CSS は必ずプッシュ・JSは場合による
サイトの構成によりますが、ページの表示に必要なものは全てプッシュするべきのようです。
- CSS の全て
- ページの根幹に関わるJSの全て
サーバプッシュの目的
まずサーバプッシュの目的を改めて確認しておくと、これはクリティカルレンダリングパスを削減するためです。
クリティカルレンダリングパスについては クリティカル レンダリング パスのパフォーマンスを分析する | Web Fundamentals - Google Developers がわかりやすいです。
サーバープッシュなしの場合 HTML+CSS 構成のページはクリティカルレンダリングパスが必ず2以上になります。つまり最低でもRTTの2倍の時間がページ表示に加算されます。
これをサーバプッシュで行う場合、HTML+CSSを一度に送り返すので、クリティカルレンダリングパスは1になります。
イメージとしてはHTML内の外部CSSが全てインライン style 要素にしてある場合に似ています。ただしサーバプッシュの場合、適切なキャッシュを効かせることができるケースがあるので、インライン style 要素よりも効率的です。
JSをプッシュすべきか
これは場合によると思っています。JSがないとページの表示に致命的な不具合がある場合、サーバープッシュしないと意味がありません。
一方、JS がページのインターフェイスの向上のために使わていて、とりあえずの表示に関係がない場合、JS をプッシュした分、ファーストペイントが遅れます。
そういうわけでなので、JS をプッシュすべきかどうかは場合によるので簡単に決められない気がしています。
理想のサーバープッシュ
理想のサーバープッシュを考えるにあたって、ロードされるリソースの分類をしてみます。
クリティカルリソース (ブロッキングアセッツ)
ファーストペイントのために必要なリソース
- CSS
- ブロックする JS (async/defer のない script 要素)
- HTML
DOMContentLoaded リソース
DOMContentLoaded までに必要なリソース
- defer された script
onload リソース
onload までに必要なリソース
- 画像
- async された script
どうプッシュするか
最終的に必ずロードされるリソースなら、プッシュしてしまっていいはずです (初回ロードの場合)。
- クリティカルリソース
- DOMContentLoaded リソース
- onload リソース
の順に全てプッシュするのが理想そうです。ただ、現時点で任意の順番に優先順位を明確に決めて送信することはできないような気がしてます。
このエントリを参照するエントリ
プルリクエストを送るときは大抵気が重い。
たとえ明かなバグ修正、すなわちマージされる公算が大きくても、些細なことでケチがついたりする。これがさらに機能追加みたいな「マージしてもしなくても本流には関係ないね」みたいなのは、マージされる公算がさらに低くてさらに気が重い。
まずプルリクエストを送るケースってのは、別にプルリクエストを送りたくてやってるわけではなく、そのプルリクエストに含まれるコードが自分に必要だからやってるに過ぎない。つまり最悪自分のレポジトリに置いておけばいいのだが、本流に取り込まれていれば今後のバージョンアップで機能が壊れることが減る (ついでに他に困ってる人がいたら助かるかもしれないね)。そういう保守的なモチベーションで動いていることであって、元気良くプルリクを送っているわけではない。
そういうわけで、大抵の場合プルリクエストを投げた時点で「XX だ! とか言われてDISられそうだ」とか「コードスタイルがあってない!!とか言われてリジェクトされないか」とか「オレのところだとテストが通らん!とか言われないか」とか気が滅入る妄想に支配され、燃えつきており、あとはもう勝手にしてくれ (コミュニケーションはしたくないぞ) という気分になっている。
最近良くあるのが、プルリクエスト送る前にコミュニケーションしろ!みたいなルールを強いているプロジェクトで、こういうのはほんとどうしようもない。死ぬほど困っているとか、仕事でやるとかじゃないならプルリク送る気がしない。コミュニケーションしたくないからコード書いてプルリクしてんのに、コミュニケーションを強要してくるのはどういうことなのか。かつて github に感じた居心地の良さはここにはない。
みいつけた！
サボさんいい
「ワンワンパッコロ!キャラともワールド」でワンワンとサボさんが共演する夢の回があって、サボさんがダンソン(バンビーノ)をやっていた。この番組、全体的に子供には難しいネタが多い。改めて見るとお笑いって常識(お約束)を裏切る形のパターンがよくあって、そもそも常識のない子供はいつから笑えるようになるのだろうと思った。
しょぼい個人サイトのキャッシュ
殆どアクセスがないサイトは、ファーストアクセスでキャッシュを作るようなサーバサイドキャッシュの戦略が全く意味がないので、バッチで予めキャッシュを作っておくみたいなことが必要そうだなと思い、そういうスクリプトを書いて流せるようにしました。
特にサイトのHTML頻繁に変えたりしているとしょっちゅうキャッシュの意味がなくなります。要はこれ、blosxom における静的なページ生成とか、MT におけるリビルドみたいなもんです。
✖
意外と http/1.1 のホストがない
このサイトのトップをロードするとこんな感じで、Google 系 (Adsense や Google Photo) は quic/1+spdy/3、このサイトは h2 となっていて、 http/1.1 となっているほうが少ないことに気付きました (はてなスターのみ)。Firefox では quic/1+spdy/3 の部分が全て h2 になってました。
バイポーラトランジスタによるRFアンプの覚書
こんな感じでシミュレーションしつつ、感覚をつかもうとしています。
今ところ感じたこと
- を十分に流すこと (データシートに のグラフがあることが多い)
- を流そうとすると負荷抵抗は大きくできない (大きな増幅率をとれない)
- そもそも高周波になると増幅率がとれない (ミラー効果)
- ぐらいが限界周波数になるらしい？ このシミュレーションだと の20分の1ぐらいまでしか十分な増幅ができない
100MHz ぐらいまで増幅したい場合 は 1GHz〜2GHz が必要
負荷がコイルの場合は？
このシミュレーションの負荷は、伝送線路的トランスによる 4:1 (または9:1) のインピーダンス変換器になっている。出力側が50Ωになっているので、増幅器の負荷は200Ω (450Ω) になる。つまり増幅率があがる。
このシミュレーションの場合 450Ω 負荷だと頭うちになっていてあまり意味がないように見える。
なぜエミッタ接地なのか？
電圧増幅+エミッタフォロワみたいな形にしないのは、電圧増幅を伴なう場合エミッタフォロワの意味が薄いから？
を十分流す必要がある以上、負荷抵抗を大きくできない。逆にいうと出力インピーダンスは低くならざるを得ない。出力インピーダンスを直接50Ωとかにマッチングさせるなら、エミッタフォロワを使う意味はない。
ベース接地・エミッタフォロワ
いずれも電流増幅率が1だったり、電圧増幅率が1だったりするので電力増幅に向いてない。
カスコード接続
エミッタ接地の負荷にベース接地をつける形のもの。ミラー効果がなくなるので高い周波数まで増幅できるようになる。ただしトランジスタを2つ縦に繋げるので電源電圧をその分上げる必要がある。