ToDo List

Ideas of Software

• FutureSearchEngine。2009/01/31。検索しないと始まらない現状から、勝手に提案する検索へ。ブログの感覚で日常の思ったことを書いていくと→検索エンジンがこれを基に自動で検索を続けて→あるとき、本人は気付いていなかった問題点に対して、解決する検索結果を提案。例で→肩こり／ノートPC／短い目の焦点距離→傾けたノートPCデスク←「傾き」をつける点が気付けなかったこと。
• HowToUseSearchEngine。検索エンジンを使った検索方法。調べたい事柄を、どうキーワードにして、検索上でヒットさせ、解説ページを得るかに対する1つの方法→直接、目的のページをヒットさせようとするのではなくて⇔現象を表すメジャーな単語をまず探して→それを使ってもう一度検索する。ビデオが滑らかに再生されない現象を、Googleで検索して、解決するページを見つける例。

Ideas of Programming

• RecurrenceCoding。2008/09/05。コードの構築方法の1つとして、漸化的に動作を作って、それぞれを連結してコードを作成する方法。いつもある部分だけに集中しながら開発できる。
• CallOrderAutoBuildUp。2010/04/14。コードから実行順序を分離→別ノートp30-31参照。
  2010/06/28。すべて部分だけで考えて、部分の直前と直後を作ることに集中し、これをすべての部分で繰り返して、最終的に結果がほしい部分も同じように完成させる。これを実行すると、部分だけを考えたものが、前後関係からすべてがつながって、全体を考慮して設計していなくても全体としてうまく動作するようになる、というコードの書き方。ある部分で直前の条件が満たされていない場合、イベント待機のように実行が待機され、満たされると自動的に実行される。このため全体のコードの流れを管理することなく実行できる。全体が条件を満たすようにうまく動作する。このモデルは並列化になじみやすい。並列化可能な部分を自動で見つけ出して並列実行できる。
• ★★★ThreeLayerAppApplying。2009/09/05。簡単なログファイル追加／編集ソフトを作るとき、そのUI(View)とファイル操作(Controller)の部分に3層アプリを適用したらコードが書きやすくなった。例 : ログを1つ追加する場合、UIからAdd操作→ControllerのAddを呼ぶ(Add操作はControllerに責任を委譲、ここでUI表示更新はしない)→ControllerがイベントOnAddを発生→UIがイベントを受けてログが追加された場合のUI処理を実行。これによってどこからAdd操作があってもUI表示は正しく反映される + UI表示更新コードはOnAddハンドラにある1箇所のみ。UI更新コードを気にする必要がなくなったので、コードが書きやすくなった。
  UIとロジックのコラボ方法が3通りある→UIのみ／中間型／3層アプリ型→3種それぞれ説明して利点を書く構成。
• ★★UnchangableIsReadable。2009/10/01。関数、クラスにしてインターフェースをがっちり決定→変更しにくい=読みやすい=コード作成中もそのコードを参照しやすい→他のコードの内容に気を配らなくて済む→楽、書きやすい⇔ベース部分の変更が大変、想定外の変更が大変。
  & ★★ClassMakesItGoodAndBad。2009/10/01。関数、クラスに分ける→関数、クラスが果たす役割／責任がはっきりしているならその効果は絶大⇔逆にあいまいor考えていなかったら...返ってもっとダメなコードになる(関数、クラスの機能を逆にいちいち覚えなくてはならない／作った関数を探さなくてはいけない／関数、クラスなので変更しにくい→だからべた書きの方がいいんだということになってしまう)
• TypesOfLearning。2009/02/13。学ぶスタイルの提案。「学ぶ／知る」の種類4つ→Perfect経験あり／HelloWorld経験のみ／紹介記事を読んだのみ／知らない。これからは新しい言語、ツール、機能が沢山出てくる傾向から、いろいろな言語、ツール、機能のHelloWorld経験(開始経験)を多く溜めて、利用できるチャンスが来たときにすぐに利用を開始できるように準備しているとよい? ⇔Perfect経験をいろいろな言語、ツール、機能で経験するのは無理。数に対して追いついていけない。⇔紹介記事を読んだ程度では、実際にその動作を確認したことがないので、開始方法の勉強から始めなくてはならず、利用したいときにすぐに利用できない。⇔知らない場合は、その言語、ツール、機能を利用できるチャンスが来ても、気付けない。知らないよりは、紹介記事を読んでいる方が、チャンスに気付けるので価値あり。

Learned

• ClassLibGoodStructure。200?/0?/??。クラスライブラリの構造→必然的に書かなくてはならない仕組み。
• TwoTypesOfCodes。2009/02/13。2つあるコードの特徴→シングルフローのコード／マルチイベントのコード。例: シングルフロー=通常のアルゴリズム実装／UIイベント実装／逐次的同期処理／ほとんどのコード⇔マルチイベント=複数回のイベントに対して処理／TimerのTick／制御ループのコード／jQueryの複数イベント処理／WebBrowserを使った非同期処理。
• NotCreativeToCreative。2009/02/17。物事、一見、クリエイティブでないものも、考え方を変えれば、何でもクリエイティブにできる。MatlabからCコードへ変換する作業の例では、目的の持ち方を変えるだけで、クリエイティブに。

Others

• MDDに関する懸念事項。

Remaining

• ■文章を書く→書く内容を出す、関係／構成を整理する、簡単な言葉で書く、の3つのタスクを一度にやろうとすると難しくて筆が進まない→タスクを分離して、日を置いて順番に行うと、効率が上がる
• ■説明文の書き方(説明の仕方)もスモールステップ型がよい
  スモールステップ型 : まず全体をコンパクトに説明(必ず一度説明を完結させる)→そのうち一部をピックアップして不足分を説明／修正→さらに細かいポイントを説明／修正 : 一般聴衆も飽きない⇔既に知識がある聴衆はコンパクトな説明時に不足分に気付いてイライラする
  ウォーターフォール型 : はじめの一部分を丁寧に説明→次の一部分を丁寧に説明...と詳しい解説書のように頭から順番に詳しく説明する : 一般聴衆は挫折する⇔既に知識がある聴衆は非常によく理解できる
• ■説明文の書き方 : 消しゴム具体例
  例として、今まで消しゴムを見たこともないアフリカ奥の原住民に対して、消しゴムについて説明する場面を考える。性質、限定条件(～できるようなもの、～するためのもの、～のときに使うもの)、利点(～のようなことが出来る、～のときに役に立つ)、他との依存関係(～の部分を変更したもの、～の反対に位置するもの)などから話し始めても何も伝わらない→一番初めは、「それは何なのか、どんなものか & シンプルな具体例」で説明する。具体例でしか理解を共有できない。
• ■名前が重要:
  名前が付けにくい=きれいに機能が分かれていない→構成の組みなおしを視野によい名前を考える。名前はそれを見てその機能がどれだけ分かりやすく表されているか、になる(使う側のための名前)⇔機能を抽象化したものではない、中で行う細かい動作を表すものではない(作る側になっている)、取りこぼしなく忠実に機能を表すものではない。
  中身で複数の処理をするので名前が付けにくい場合、複数のうちのメイン処理に絞って命名する、入力側の処理は引数を見れば分かるので名前には含めない、結果的にどんなことをしてくれるのかを名前にする、複数処理の一番最後の処理名(ただし、後処理でないもの)を名前にする→すると、入力から最終処理までの過程はイメージできる。外から見れば、そのクラス／関数は、どんな情報が必要で、それを与えれば何をしてくれるのかが最も知りたい。
  ソースコードにある全ての名前(ex あるメンバの名前)は、名前空間と参照構造による「.」でつながる名前の連鎖1つ1つ(上層から順に意味が限定されてくる)からと、その周りにある他の名前との対応関係からで、その名前の意味をイメージできる。これにより、1つ1つの名前(メンバ名、変数名...)は短くても意味が分かるようになる。名前を長くしないと識別できないような場合は、もっとクラス／関数に分割できる兆候。