アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
ソースよりデータ読め (スコア:3, すばらしい洞察)
データをどう構成するかはその重要度にくらべて低く見積もられすぎてる
ような気がします。
世の中のプログラムのかなりを占めているのが情報を再利用可能な形で
保存して、あとからそれを効率よく読み出すたぐいのもの。それらを
どう実現するのが効率よくメンテしやすいかを学ぶのはプログラミング
技術向上のかなりの早道ではないかと思うのです。
さまざまなファイルフォーマットに着目して、どうしてそのフォーマットが
採用されるに至ったかを考え、それをどう扱うのがロジックとして適切かを
いろいろ考えてみるのは楽しくもあり、勉強にもなります。
データ構造として人間が読んで理解できることが目的のものならたとえば
HTML。パーザやレンダラを読み合わせれば、機械が処理しやすいことと
人間が読みやすいことにどう折り合いをつけるかという妥協点の選択が
過去どのように行われてきたかを読み取れそうです。計算機言語のパーザ
なども表現能力と処理効率のせめぎあいを見てとれて楽しめますね。
読み書き両方の自由度と性能を考えるなら、おすすめなのはデータベース。
検索と更新の性能バランスをどうとるかで設計が大幅に違ってきますし、
ワーストケースを救済したいのか平均処理速度を上げたいのかでもまた
違ってくるわけです。そのバランスをとるために読み書きを行うコードの
どの部分に負担がかかっているのかをソースコードを見て調べると、自分が
その手の(もっと単純なものであっても)プログラムを書くときの道しるべに
なります。
広い意味では、というかここでの観点からは、たとえばファイルシステムや
日本語入力プログラムの辞書や学習ファイルなどもデータベースの一種です。
辞書ソフトの辞書データなどはリードオンリーのデータベースであり、作成の
コストを度外視して検索とスペース効率を上げることが設計目標となります。
その意味ではデータ圧縮も重要なファクターのひとつ。
このようなデータをソースコードなしに解析し、それを処理するコードを
自分で再構成してみるというのも、パズルのようなもので、プログラミングの
技量向上というかタフさを身につけるうえで非常に役立ちます。