進捗

本当はゆっくり一つ一つやっていけば問題なかったことでも、一度に行うと混乱して収集がつかなくなることもままあります。

「テキストボックスに表示していたのを自作マークダウン表示ルーチンに変更してテスト」
「自動スクロールに任せていたのを自作部分描画ルーチンに変更してテスト」
「問題のある動作を新バージョンに置き換えてテスト」

とやっていけばそんなに問題はなかったと思うのですが、そ全部を一度にやりつつ適当にイケてない設計を直したり、よくわからない処理をコメントアウトしたり、ミドルウェアのRedditSharpに依存しないように書きなおしたりした結果、まともに動かなくなりました。もちろんそれ自体は一時的なことのはずです。

特にRedditSharpにはいろいろな問題があり、置き換えたいと思っていたのですが、置き換えようと参照を切った瞬間にものすごい数のコンパイルエラーが発生し大改修が必要になりました。遅かれ早かれやらなければならなかったのですが、今やらなくても別に良かったはずなのですが、やってしまったので、RedditSharpがやっていたことを置き換えるためにしばらく時間が必要になりました。

RedditSharpの問題というのは、gzip圧縮を受け入れていなかったり、コメント取得時に全体のコメント数が取れなかったり、IDだけあればダウンロードできるデータを取得するのにオブジェクト全体を要求されたり、コメントが編集済みかどうかわからなかったりmoreが取れなかったりなど色々あるのですが、軽い気持ちで参照を切った瞬間にそのありがたみをヒシヒシと感じることになりました。

全く気合が足りていません。とにかくまともに生活するためにはソフトを作ってなんとかしてお金を得るしか今はありません。とにかく頑張らなければなりません。
　

頭を切り替える時の現象

一つのことをやっていると短期記憶が全部そのことで染まって、そのことをやっている分には効率がいいですが、さて別のことをしようとなるといろいろな不都合が起こります。長期間ひとつの作業をやって、それを終えてまた元の作業に戻るような場合には、一つのことをやっている間に忘れてしまったことを一つ一つ思い出しては短期記憶を上書きしていき、元の作業用に染め直さなければなりません。そして今がどういう状況で何をしたらいいのかを理解しなおす必要があります。

プログラミングでは、よほど小さなソフトでない限り一度に把握できるのはソフトウェアの一部だけで、深く理解しなければコードをいじることは出来ません。書いた直後はよく覚えていても、しばらく放っておけば忘れてしまいます。忘れたらまたコードを読んで理解して記憶し直すしかありません。

自分が書いたものなので理解するのはたやすいはずですが、なぜこんなにも辛かったり眠かったりするのか。一旦記憶が切れてしまうと、記憶を全部上書きしなおして本調子に戻るまでにずいぶん時間がかかってしまいます。その間中、頭が痺れるような感じになったり、ハイになったり眠くなったりします。この現象が一体何なのか、知りたいのですが検索しても出てきません。他の人からも聞いたことがありません。

部分描画とスクロールバーの問題

テーブルタグも引用タグもその他全部のタグもとりあえずの実装は出来ました。本格的なデバッグは出来ていないので完成というのはまだ無理ですがマークダウンの実装は一区切りつきました。

この後はマークダウン表示ルーチンをアプリに組み込まなければいけないのですが、ずっとマークダウンのことばかりやっていたのでアプリの実装の詳細をかなり忘れてしまいました。組み込みにもまだ大きな問題が残っています。

いろいろ思い出さなければいけないので、なぜこんなにもマークダウンをズルズルとやる羽目になったのかちょっと書き出してみようかと思います。

もともと不具合がありました。これはWindowsの16bit時代からの名残か何かで、全体の高さが32767ピクセルを超えるとスクロールバーがそれ以上スクロールしなくなるというものです。300コメントを超えた当たりでこれが実際に起きるようになり、これへの対応に追われ続けて、まだ対応が終わっていないという状況です。

スクロールの範囲を広げるだけならスクロールルーチンを自作するだけなので別に難しいことはないのですが、問題は「300コメントを30000ピクセルに渡ってズラッと表示した後に、スクロールバーでスクロールする」というのが非常に動作が遅いというところにあります。それは私が「コメントに対してテキストボックスを作成し、300コメントなら300個のテキストボックスを縦に並べてズラッと表示する」という恐ろしいほどの手抜き実装をしているのが原因です。つまりこれは不具合というよりも、私の手抜きに対して必然的に生じた当然の帰結というべきものです。不具合というのは手抜きでもバグでもオブラートに包んで表せる便利な言葉ですが、それを隠れ蓑にするべきではありませんでした。まったく申し訳ないです。

300個のテキストボックスを並べるのは動作が非常に遅いです。それはテキストボックスというものが300個並べられることを想定して作られていないというようなことが原因だろうと思います。これを解決するためには部分描画が有効です。つまり必要な部分、たとえば132番目のコメントから描画を初めて、140番目のコメントで画面が全て埋まったらそこで描画をやめる、といったように画面に表示される部分だけ描画処理を行えば、全体がどんなに大きくても描画量を一定にすることが出来ます。この場合なら描画用アイテムは132から140までの9個で済みます。

そこからスクロールするのも簡単です。上に10ピクセルスクロールしたとしたら、131番目のコメントの下から10ピクセル分から描画を開始すればいいわけです。スマホのようなインターフェースであれば指でスクロールするだけなのでそれで問題ないのですが、この時問題になるのはスクロールバーです。

スクロールバーはスクロールできる全体の範囲を知っていることを前提にしたUIです。「これを描画した結果全体が何ピクセルになるか」を知っていないと正しく動かすことが出来ません。描画した結果何ピクセルになるかを知るためには描画に等しい負荷がかかることも多く、このスクロールバーの存在が原因で、大半のテキストエディタは1MBといったような、現代のCPUであれば二次キャッシュに乗ってしまうような小さな容量のテキストファイルを表示しただけでまともに動かなくなりますし、そうでないエディタは文字幅が一定のフォントを用い改行ケタ数を指定することでどうにか動かそうとします(それでもまともに動かないことも多いです)。

しかしスクロールバーはPC用アプリに必須のものなので削除することは出来ません。問題は「いかに効率よく描画後のサイズを知るか」というところにあります。そのためには「描画せずに描画後のサイズを知る」処理が必要になり、なかなか面倒です。しかしHTMLのテーブルタグを綺麗に配置しようとすれば、描画後の大きさをあらかじめ知ることが必須になりますので、どうせマークダウンのためにテーブルタグを実装するなら最初からマークダウンの処理を書いてしまえば良い、ということで作り始めたというのがあらましになります。

そして七難八苦があり、描画後の大きさを効率よく知ることが出来るルーチンが書けたように思います。ただ、まだ動かしていないのでわかりません。私がやったのは、動かす前に速く走るコードを書こうとする「事前最適化」と呼ばれるもので、プログラミングの世界では最も愚かな人間がやることとされています。「このコードは速く走るのか」ということを考えながら書くと普通に書くのの何倍も時間がかかりますし、普通に書いて実際にコードが遅くなるのか、その遅くなる原因はなにか、というところまで突き止めてからでないと、ほとんどの最適化の努力は空回りに終わります。現代のハードウェアでは、プログラマが思ったとおりにコードが実行されることは稀で、速く走るコードを書いたつもりで普通に書くより遅くなっているというのは非常によくあることです。

ただこの処理がボトルネックになるだろうというのは私なりの確信があります。「オバマ大統領だけどなにか質問ある？」といったサブミの2万ぐらいのコメントをストレスなく表示するためには、描画後の大きさをものすごい速さで計算することが必須になるでしょう。

そしてこれを「部分描画ルーチン」に組み込まなければなりません。部分描画ルーチンもマークダウンの実装を始めるより前の大昔に軽いテストしかしておらず、正しく動くかは分かりません。実際かなりややこしい処理になります。これがうまく動けば、とりあえずのブログ限定公開にこぎつけることが出来ると思います。

進捗

　HTMLの禁則処理が難しくかなり苦戦しています。が多分出来たんじゃないかと思います。

　マークダウンが出来上がるまでまだ少しかかりそうです。

マークダウン

　Redditのマークダウンはタグの直接入力が出来ませんし、綺麗なXHTMLデータがもらえるので解析に苦労することはありません。

　マークダウン自体に幾つか温情があり「Tableは入れ子にならない」「Tableの中にリストも引用も作れない」「リストの中にTableも引用も作れない」といった形になっています。入れ子になるのは引用とリストだけですがリストの入れ子はほとんど何も出来ません。問題は引用の入れ子で、引用の中にはTableも入れることが出来ます。といっても引用は入れ子になってもインデントが深くなるぐらいの効果しかないので別に複雑になりません。Tableが入れ子にできたら終わりでしたがギリギリ致命傷は免れたと思います。

　これはマークダウンを解析して専ブラをつくろうという人に対しては有用な情報かもしれません。といっても仕様を見ればわかるので無用かもわかりません。いちおう備忘録として残しておきます。

進捗

前回マークダウン対応とブラッシュアップを一週間でやるといっていました。そして一週間が過ぎ、現在マークダウン対応の半分ぐらいしか進んでいないという状況です。

おそらく1日16時間ぐらいやれば目標通りのスケジュールで出来たと思うのですが、そこまでは出来ないにしても1日8時間ぐらいやっていけばマークダウンぐらいは終わるだろうと思っていたのですが、思っていたよりかなり難しく、全然終わりませんでした。申し訳ないです。

気合も足りていません。しかし難易度が高いと気合ではカバーしきれない部分もあります。マークダウンといっても簡易HTMLブラウザの表示部分をちょこっと作るだけだと思ったのですが、禁則処理などよく理解できない部分が多く、まだマークダウンの底が見えたのかも自信がありません。

とりあえずあと4日ぐらいでマークダウンを完成させて、もういろいろ考えるのが面倒なのでその後公開しようと思います。

今後の予定

　自分の中で公開へのハードルが上がっていき、「マークダウンもツリー表示もできていない現状では公開は不可能」という確信が芽生えてきました。不具合を直してブラッシュアップして公開してしまう、という予定は自分の中では無理な感じになりました。

　「不具合を直すついでにマークダウンへの対応もしてしまいたい」という、関連する作業をまとめてやってしまいたい願望があり、またデバッグやブラッシュアップをそろそろやってしまわないと、自分で動かしていても快適に便利に動いているかどうかはブラッシュアップしてみるまでわからず、またデバッグは放っておくほどに入り組みながら記憶が薄れていき直すのが大変になっていくというのもあるので、不具合を直してブラッシュアップするのは公開と関係なくしなければならないように思います。

　不具合を直してブラッシュアップしてるのに公開しないというのはやるせないものがあります。近い時期に目標を立てていかないとやる気を継続するのが難しい部分もあるので、不具合を直し、ブラッシュアップして、マークダウンへの対応も行い、その上であまりおおごとにならないようにひっそりと公開しようと思います。これの目標を一週間後とします。

　そこからさらに一週間かけて、ツリー表示と、それに付随するいろいろなアイデアの実装を行って、正式なベータ版として公開したいと思います。結局最近考えていたいろいろな機能が、ツリー表示と連動させないとイマイチ意味不明の謎機能にしかならないので、私の考えているレディット専ブラを世に問えるのはツリー表示導入以降ということになりそうです。

　まとめると、1週間後に2ch専ブラ風のレディットブラウザを作り、2週間後にレディット専ブラの最初のまともなベータを作る、そういう予定で進もうと思います。

体調不良

体調不良のため2日間休んでしまいました。休むと取り戻すのに時間がかかります。

非常に悪い流れです。なんとかしないといけません。どうすればいいのかはよく分かりませんがとにかく頑張ります。