■

朝起きたら日記書くことにしてる．

一日の終わりに書くと，日ごとにテンションがちがうから，並べて見たときに気持ち悪い．

朝書くと，変な夢見て死にたいとかでない限りは，だいたい同じ感情で書けるから，クオリティが安定する．

また，一日経つと，些細なことは忘れて，昨日考えたことのうち，覚えていることだけを書けるので，あんまり書かなくて済む．

朝に日記書くの，だいたい良いけど，朝からパソコン開きたくない，画面がまぶしくてつらい，というので困ってる．

火曜日に焼肉で，昨日も焼肉だった．

最近死にそうな感じの人がいて，大丈夫ですか，病院行ってはどうですか，って言ったら，もう通ってるそうで，安心した．

適当に頼んでたらけっこう高かった．横のテーブルはそんなことなくて，倍ぐらいしてた．何が悪かったのかわからない．

ソフトウェア使い回し，既存のものを使って新しいものを作る，だいたい同じだからできる，とか言うけど，やってみると全然うまくいかない．

階層構造になっていて，上だけ差し替える，というのは簡単だけど，下から変わると，下から上まで順に，全部の行を見ないといけない．

下が変わると，テストが通らなくなって，新しい仕様にあわせて少しずつテストも修正する必要がある．

インターフェイスが定義されていて，これだけ呼べれば良い，というのが分かっていればもうちょっとましだけど，メソッド作るときは気軽に増やしてしまうから，なかなかそうなっていないことが多い．

最初はインターフェイスを決めてやっていても，仕様が増えて，あとから書き足して，その分は前の設計意図が反映されていないとか．

たとえば，リストクラスとかだと，どう呼んでもちゃんと動かないと困るけど，特定のドメインの処理を行う場合は，実際にアプリケーションから呼ばれる範囲内で動けばそれでよいので，安易に変更したり機能追加したりしがちだと思う．

クラスの責任をちゃんと決めて，そこから出ると，すごい違和感がある，ような設計が必要だと思う．便利なメソッド置場を作れないようにしたい．

仕事で書いてるやつ，コンテキストごとに自動的に対応するクラスのインスタンスができる + そのクラスが自由に継承されてて，複数のコンテキストから呼ばれるメソッドはどんどん親クラスに移動，という技が使われてて，すごく読みにくい．便利だから何も考えずに書けるけど，ソースコードが人間が理解できる範囲を越えた感じになる．ページの構成変えたいと思っただけで，全部が依存しあっていて，すごく大変．

かといって，新しいフレームワークを考えて，半年後とかに，実はこれではうまくいかなかったとか言って崩壊するのも嫌だから，難しいと思う．

世間のウェブアプリケーションのソースコードがどれぐらいぐちゃぐちゃなのかというのと，世間の人がどれくらい忍耐力が強くて，どれくらいぐちゃぐちゃでも自然にメンテナンスできるのか，というのが気になる．

今日の重ね着，昼はシャツで夜はカーディガンとか出ていて，朝すごく寒かったし，バグってるのかと思ったけど，天気APIから本当にそういう情報が来ていて，API利用する側では，信じて出すしかないから，対策できなかった．

タイムライン見てても，これはおかしいと言ってる人がいて，申し訳なかった．

複数の天気のAPIを使うと精度上げられるかと思ったけど，ウェザーニュースでも，暖かめに出ていて，全国的に予報が外れた日のようだった．

けど，よく考えると，複数のソースの天気から総合的に判断するくらいで天気の精度が上がるということはなくて，逆に，こっちで変にデータを加工することで，精度が下がる，というほうがもっともらしい．

重ね着，ホーム画面に登録して使うことを推奨しているけど，そうすると，バージョンアップできなくなる，ということに，リリースしてから気付いた．

天気APIはマッシュアップアワード用に無料で使わせてもらってるので，マッシュアップおわったら動かなくなる．

JSだけ差し替えできると思ってたけど，そうでもないとすると，すごく困る．

XHRでお知らせを取得して表示する機能を入れておけばよかった．実験して，うまくいきそうなら，いまからでも組込みたい．