プログラミングの魔物スマートフォン用の表示で見るプログラミングの魔物エラー、バグ、仕様変更と戦うブログこの広告は、90日以上更新していないブログに表示しています。雑記どこかで区切りを見つけないといつまでも本読みを再開できそうにない。一段落したら再開しよう。Parserはその名の通りHTMLのパーサー。スクレイピングするために使用している。比較検討したわけではないのでひょっとしたらもっと優れたものがあるかも知れないけど、今のところ満足している。Startを読むと大体分かる。jQuery風の要素指定が可能。文字列からオブジェクトを作れるので文字コード変換等の対応はそれで。APIヘルプhttp://simplehtmldom.sourceforge.net/manual_api.htm書き換えや保存も可能な様子。外部HTMLを取得した後、書き換えて保存するといった用途に使えるかもしれない。雑記なんだかんだで3月中に終わらせようと思っていた作業が結構な時間を食っている。難しいのは作業に対するモチベーションを上げることだったりする。一日ごとに目標を決めて進めているが、最近はそのハードルを低くしすぎているため遅々として進まない。いえ、ハードルを上げすぎて完全にモチベーションが死んでしまっても元も子もない。怠惰な自分を飼い慣らす方法を手探りで探していこう。未知の技術を使う場面においては、目標とする内容がそもそも実現可能かどうかを検討する必要があり、目標の設定が困難である。なるとたとえば「この作業にどの程度従事したか」というのを目標にしたりするわけだ。・・・なにやらいつ終わるのかわからない危険な香りがして来た。コードで遊びながら頑張ろう。必要のないものを作っている時が一番楽しいとか言うあるある。リファクタリングの本を読み始めてから、気の利いたソースの書き方ができるようになった気がする。後々の自分が苦労しないための組み方というかなんというか。他人のソースをリファクタリングしながら読むのはとても良い。http://dlvr.it/3GPR5vhttps://twitter.com/codezine/status/326168173760110593ワーオ。これバージョン上げるのためらってしまう。1.x系は継続してサポートするということならそこまで深刻でもないか。Update4/1ってなんかやだな。IE8はまだまだ現役の人が多い様子。それにしてもChromeすごいな。最近はFirefoxも起動が早くなってきたけど、昔はモッサリしてたからそれで人を逃したのかな?あとFirefoxのプラグイン、バージョンアップすると使えなくなったりするし。Chromeは共有が便利だからそれもあるかな。メソッドの名前を変更するメソッドにつけるコメントを考え、それをメソッド名にする良い名前を思いついたら何度でも変更する同じ事がシグニチャにも言える。問い合わせ用と更新用の2つのメソッドをそれぞれ作成する値を返す関数は観測可能な副作用がなければ価値がある。引数の値に対応する別々のメソッドを作成する「メソッドのパラメーター化」の裏返し条件に依存する振る舞いを減らす。代わりにオブジェクトそのものを渡すオブジェクトから得られる情報量を増やすことができる副作用としてオブジェクトへの依存関係ができるメソッドによる引数の置き換えあるオブジェクトがメソッドを呼び出し、その戻り値を別のメソッドの引数として渡している。条件ロジックは分かりにくくなる宿命にあり、それを単純化するリファクタリングが多数存在する。特殊ケースすべてに対してガード節を使う条件は次の2つの形式に分類される。条件記述の各アクション部をサブクラスのオーバライドメソッドに移動する。その仮定を、表明を使って明示する前提条件があるならassertする偽になったらプログラマのエラー。作業と交互に読みすすめるので、今までよりペースは落ちると思う。フィールドに対するget,setを作ってそれだけでアクセスフィールドのアクセス方法は2種類。同じインスタンスが多数存在するクラスがある。そのデータをドメインオブジェクトにコピーして、それらを同期させるためのオブザーバを設ける振る舞いを階層ごとに分離するのは容易だが、データはそうは行かない。不要になった関連の一方を削除する双方向はコストが掛かり、ゾンビも生まれやすくなる。定数を作り、それにふさわしい名前をつけて、そのリテラルを置き換えるマジックナンバーはプログラムの理解を遅らせる。定数にして可読性を高めるこのリファクタリングを行う前に代替案を探す。その数字を新しいクラスで置き換えるシンボリック名は可読性を高められるが別名でしかない数字をクラスに置き換えると静的な型チェックができるこれを行う前に他のタイプコードの置き換えについて検討するタイプコードが純粋なデータである時だけタイプコードをクラスで置き換えるすべてのswitchはいずれ「ポリモーフィズムによる条件記述の置き換え」により取り除かれる。出来ないケースはオブジェクトが生成された後にタイプコードが変わる場合、またはタイプコードを持つクラスがすでに別の処理でサブクラス化されている場合。「ポリモーフィズムによる条件記述の置き換え」の土台。きっかけは条件文により処理が分岐する場合。条件文がなければ「クラスによるタイプコードの置き換え」が有効このリファクタリングを使うもう一つの理由は、あるタイプコードを持つオブジェクトにだけ関連する特性が存在する場合。このリファクタリングが終われば「メソッドの引き下げ」や「フィールドの引き下げ」を行なって、サブクラスをより特化できるサブタイプによる振る舞いの差異をクラス自身で持つことが可能になる。Lua今月は別の作業に集中するので、本読みは4月頃再開予定。3月中に終わらなければ伸びる可能性もあるけど、とりあえず3月中を目処に作業中。あと暇な時にでも次に作成するプログラムの資料用に構文解析のアルゴリズムなどを調べて載せるかも知れない。効率よく解析できればもっと複雑なDSLを組めるようになる。MetaluaというLuaにマクロを追加するものがあるが、それは出力がバイトコードなのでクロスプラットフォームを意識した場合にエンディアン等が鬼門になる。MetaluaがLuaファイルを吐いてくれるなら内部DSLも記述しやすくなるが、その辺は面倒くさそうなのであまり詳しく調べていない。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。