「『はてなブログ遅い問題』問題」について思ったコト

概要: 主に自分の開発への思想の話をします

大体のところとしては、

1. [[はてなブログが遅いのはだいたい JavaScript のせい - もふぬこ戦記 http://emija.hatenablog.com/entry/2014/03/11/231940]]
2. [[はてなブログの Javascript コメント抽出してたら、なんだかプログラマあるあるネタになってた - Minecraft とタートルと僕 http://hevohevo.hatenablog.com/entry/2014/03/12/192656]]
3. [[些末なコードレビュー - naoya のはてなダイアリー http://d.hatena.ne.jp/naoya/20140313/1394664578]]

という辺りの記事を見て思ったコトを少し書きます。とは言っても、はてな Dis とかそういう話ではなく、僕の開発へのスタンスでの話です。あと多分上記リンク先と本質はズレてます。たぶん。

1. そもそもプログラミングとか DevOps とか言う文脈においては、『人間の作業は信用できない』という前提で、開発等を進めるべき

だと僕は思ってます。

まあこれは一応、その作業をした人が信用ならんとかそういう話ではなく、そもそもの話、僕の哲学じゃないけど、僕は基本的にプログラミング等に関しては、

1. 人は皆、スキル(技術力)や勘(センス)がバラバラである
2. また、ヒトというものは、常に SPoF 唯一無二である
3. よって、 _ 属人性_ というモノを持った時点で、その作業は SPoF 化する

という考え方を持っていて、だからこそ、

1. テストはきちんと書くべし
2. テストは自動で回すべし (継続 CI)
3. あとデプロイ等も自動化すべし

と考えています。あともう一つ、僕の根本的な考え方として、

密結合な何か を作ると、 _ 引き継いだ人が死ぬ_ (ような思いをする)

とも考えていて、これがまあ僕の Catalyst や Ruby on Rails の食わず嫌いに繋がってるのだろう、とは思ってます。

で、あと、この辺りの塩梅は難しいコトだとは思うのですが、プログラミングした何を、

1. _ 属人性_ と密結合させた場合: → 引き継いだ人が死ぬ (ような思いをする)

2. _ ライブラリや UI_ と密結合させた場合: → メンテや改良する際に死ぬ (ような思いをする)

3. 上記二つが組み合わさってた場合: → _ 綺麗だ……地獄が見える……_ (と言いながら、死ぬような思いをする)

と思っていて、今回のはてなブログの 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 の実行速度命！　っていう場合には、ぜひとも使うべきだと僕は思います！！！！！！

という半分ネタっぽいのはここまでにしておいて、真面目に思うところを書くと、そもそも、

1. ページが動的生成である＝サーバサイドでどうしてもレンダリング時間が必要となる
2. 広告とかたくさん貼付けてる＝外部のリソースをたくさん読み込む必要がある
3. あと、結局のところ、Web ページの重さは、最後はユーザーの回線とマシン環境に左右される

と思っていて、まあなんだろう、一概に、

Web ページが重い

っていう話が有ったとしても、それが、

1. リソースの読み込みが遅いのか
2. UI のレンダリングが遅いのか
3. 最後ユーザーの実行環境がそもそもクソではないのか

という辺りの区別が付かないと、まあ対応しようがないよね、と僕は思います。

まあその辺りについての改善の手法として、

1. ロード時間とか UI のレンダリングタイムとかを Fluentd へぶち込んだり
2. あるいは、Web ページの依存するリソースを data URI 化したり
3. もしくは画像のスプライト化とかして HTTP Request を減らす

という方法があるんだろうなぁと最近思ったりしました。

4. という訳で本日なんとなく思ったコトは以上です。

あと、ぶっちゃけた話、僕の Tumblr 上のブログもそうはページのロードが軽くないのですが、これそもそもなんでかって言うと、

1. ソーシャル系のボタン
2. Javascript を用いる広告
3. Disqus とか Zenback とかその辺り
4. 背景画像

辺りが主な原因で、Tumblr 自体が重いというよりは、余計なモンゴテゴテとつけてるからだ、と思っていて、だからこそ、最近ちょっと Tumblr のテンプレを見直してるんですが、まあ、はてなブログのレンダリングが重い件については、

1. ソーシャルボタン外せ
2. ヘッダと広告は金はらって取っ払え
3. あと画像系はできるだけ使うな

で FA なのではないかと思います。っていうかアレだ。その辺りについては、まあ大体は、

1. はてなブログ Pro を契約し
2. 自分でできる範囲でレンダリングが遅くなる要素を取っ払い
3. 超シンプルなブログに仕上げる

という事をすれば良いだけやん？　と思います。

ま、という事で本日の雑文は以上ですね。

あと、最後に一つ言っておくと、僕のブログも一緒なんですが、広告をベタっとページのトップ等に貼付けてる時点で、そのページは Slowly になるのは当然の話なので、その辺り、はてな側の問題ではないのではないか？とか思いました。

まあ広告なしで重い！　とかならはてな側の問題だけど、広告ありで重い！　っていうのは、広告が足引っ張ってるんじゃねーの？　とか僕は思います。っていうか俺のページもソレで重いし。

という事で、本日は以上です。結構長くなりましたが。

#FIXME