「『はてなブログ遅い問題』問題」について思ったコト
読了まで：約6分
概要: 主に自分の開発への思想の話をします
大体のところとしては、
- [[はてなブログが遅いのはだいたい JavaScript のせい - もふぬこ戦記 http://emija.hatenablog.com/entry/2014/03/11/231940]]
- [[はてなブログの Javascript コメント抽出してたら、なんだかプログラマあるあるネタになってた - Minecraft とタートルと僕 http://hevohevo.hatenablog.com/entry/2014/03/12/192656]]
- [[些末なコードレビュー - naoya のはてなダイアリー http://d.hatena.ne.jp/naoya/20140313/1394664578]]
という辺りの記事を見て思ったコトを少し書きます。とは言っても、はてな Dis とかそういう話ではなく、僕の開発へのスタンスでの話です。あと多分上記リンク先と本質はズレてます。たぶん。
1. そもそもプログラミングとか DevOps とか言う文脈においては、『人間の作業は信用できない』という前提で、開発等を進めるべき
だと僕は思ってます。
まあこれは一応、その作業をした人が信用ならんとかそういう話ではなく、そもそもの話、僕の哲学じゃないけど、僕は基本的にプログラミング等に関しては、
- 人は皆、スキル(技術力)や勘(センス)がバラバラである
- また、ヒトというものは、常に SPoF 唯一無二である
- よって、 _ 属人性_ というモノを持った時点で、その作業は SPoF 化する
という考え方を持っていて、だからこそ、
- テストはきちんと書くべし
- テストは自動で回すべし (継続 CI)
- あとデプロイ等も自動化すべし
と考えています。あともう一つ、僕の根本的な考え方として、
密結合な何か を作ると、 _ 引き継いだ人が死ぬ_ (ような思いをする)
とも考えていて、これがまあ僕の Catalyst や Ruby on Rails の食わず嫌いに繋がってるのだろう、とは思ってます。
で、あと、この辺りの塩梅は難しいコトだとは思うのですが、プログラミングした何を、
-
_ 属人性_ と密結合させた場合: → 引き継いだ人が死ぬ (ような思いをする)
-
_ ライブラリや UI_ と密結合させた場合: → メンテや改良する際に死ぬ (ような思いをする)
-
上記二つが組み合わさってた場合: → _ 綺麗だ……地獄が見える……_ (と言いながら、死ぬような思いをする)
と思っていて、今回のはてなブログの Javascript が、なんかカオスってたのは、その辺りの何かに引っかかったんだろうなぁ、と僕は勝手に思ってます。
で、次。
2. [自転車置場の議論 http://0xcc.net/blog/archives/000135.html を避ける為には、その辺りの瑣末な事柄のチェック等は、全部自動化して機械に任せるべきだ]
とも思います。
まあこれはツールがないとちょっと厳しいなぁと思うんですが、例えはインデントのスタイルが云々、とかは、
で、統一すりゃ良い話だろ、って今だと言えますし、あと、コードの整形についても、例えば Golang であれば、
$ go fmt
すりゃ済む話なので、その辺りの、本当に瑣末なコーディングに関する問題は、
全部機械的に処理してしまえば良いんじゃない？
と思います。
が、いかんせんこの辺り、いい感じのツールやユーティリティが無いと、
- 自動化を行うためのツールから作り始めないといけない！
という感じになって、激しく Yak Sheving になる気がしているので、その辺り微妙ですけどね。ツールが無い場合は。
まあ基本的には、コードのタブ幅だとか、あるいはコーディングスタイルとかは、自動処理できるところは自動処理して、残りのクラス設計だとか、あるいはコンポーネントをどこまで結合させるべきか、みたいな話は、開発者が面倒みるしかないんじゃないかなーと思ってます。
で、最後。
3. Javascript が遅い？ なら、[JSX http://jsx.github.io/ (DeNA 製の方)を使おう！]
と、この、
- 『はてなブログ遅い問題』問題
を知ったとき、一番最初に思いました。
っていうか、なんでそっちに話を持って行くねん！ って感じではありますが、 JSX 、早いです。あと、クラス機構とかがデフォで実装されてますし、また、そもそも JSX 自体、
スマートフォン等のシビアな環境で、素早く動作する Javascript を吐き出す
という目的で作られた、という経緯があるので、モバイル開発も含め、Javascript の実行速度命！ っていう場合には、ぜひとも使うべきだと僕は思います！！！！！！
という半分ネタっぽいのはここまでにしておいて、真面目に思うところを書くと、そもそも、
- ページが動的生成である＝サーバサイドでどうしてもレンダリング時間が必要となる
- 広告とかたくさん貼付けてる＝外部のリソースをたくさん読み込む必要がある
- あと、結局のところ、Web ページの重さは、最後はユーザーの回線とマシン環境に左右される
と思っていて、まあなんだろう、一概に、
Web ページが重い
っていう話が有ったとしても、それが、
- リソースの読み込みが遅いのか
- UI のレンダリングが遅いのか
- 最後ユーザーの実行環境がそもそもクソではないのか
という辺りの区別が付かないと、まあ対応しようがないよね、と僕は思います。
まあその辺りについての改善の手法として、
- ロード時間とか UI のレンダリングタイムとかを Fluentd へぶち込んだり
- あるいは、Web ページの依存するリソースを data URI 化したり
- もしくは画像のスプライト化とかして HTTP Request を減らす
という方法があるんだろうなぁと最近思ったりしました。
4. という訳で本日なんとなく思ったコトは以上です。
あと、ぶっちゃけた話、僕の Tumblr 上のブログもそうはページのロードが軽くないのですが、これそもそもなんでかって言うと、
- ソーシャル系のボタン
- Javascript を用いる広告
- Disqus とか Zenback とかその辺り
- 背景画像
辺りが主な原因で、Tumblr 自体が重いというよりは、余計なモンゴテゴテとつけてるからだ、と思っていて、だからこそ、最近ちょっと Tumblr のテンプレを見直してるんですが、まあ、はてなブログのレンダリングが重い件については、
- ソーシャルボタン外せ
- ヘッダと広告は金はらって取っ払え
- あと画像系はできるだけ使うな
で FA なのではないかと思います。っていうかアレだ。その辺りについては、まあ大体は、
- はてなブログ Pro を契約し
- 自分でできる範囲でレンダリングが遅くなる要素を取っ払い
- 超シンプルなブログに仕上げる
という事をすれば良いだけやん？ と思います。
ま、という事で本日の雑文は以上ですね。
あと、最後に一つ言っておくと、僕のブログも一緒なんですが、広告をベタっとページのトップ等に貼付けてる時点で、そのページは Slowly になるのは当然の話なので、その辺り、はてな側の問題ではないのではないか？とか思いました。
まあ広告なしで重い！ とかならはてな側の問題だけど、広告ありで重い！ っていうのは、広告が足引っ張ってるんじゃねーの？ とか僕は思います。っていうか俺のページもソレで重いし。
という事で、本日は以上です。結構長くなりましたが。
#FIXME
