なかなか良さ気なマインドマップ用ツール
マインドマップ用のツールは数あれど、 もう何年もいままでずっと
を使ってた。
有料のツールだけど、とにかくシンプルで軽い！
Mac版もWin版もあるし。
紙に書くならもちろん別だけど、PCでちょっとしたメモ用途でマインドマッピングをする場合、自分的には画像貼ったりとか「重い機能」はまったく不要。
とにかくサクサク書けるやつがいい。
そういった意味では上の「マインドピース」は最高です。
そして最近「お？これ良い感じかも・・・。」と見つけたのが
画面はこんな感じです。
シンプルでデザインが綺麗！
Webベースのツールだけど軽い！そして、他のメンバとも共有もできる。
Macの「MindNode」のようなスマートレイアウトはないけど。
うーん、こいつはなかなか。('-'=
OmniFocus(Mac)の期限リマインダーの同期期間
MacのOmuniFocusの「期限リマインダー」をカレンダーとして表示したところ、
2週間先のリマインダーが表示されない。
同期時間短縮の為とかの理由で仕様となっているのだろうか・・・。
OmniSync使っても、Spootnik使っても同じ動きする。
そんな先のイベントやタスクをリマインダーになんか登録しないだろってことかな。
QiitaのAdvent Calendarがスタート
ああっ、ついに12月に入ってしまいました！早い・・・。
てことで、Qiitaの2013年のアドベント・カレンダーに続々と情報が出てきました。
できるだけいろいろな記事を読んで勉強しなきゃなぁ。
ちなみに私もちょこっと記事を書いて見ようと思ってます。('-'=
本日12月1日より，プログラマ有志による2013年の技術系Advent Calendarが各所ではじまる：インフォメーション｜gihyo.jp … 技術評論社
ソーシャルブクマ「Pinboard」で良さげなChrome拡張
プログラマなら気になりそうな、コード記述の話題
ソースコードの、
- インデントは「タブ」にするか「空白」にするか
- ここにスペースを「入れる」か「入れない」か
- カンマの位置は「前」か「後」か
といったことを、Githubから統計を取った結果のようです。
まぁ、書き方はどうあれ、
記述がプロジェクトやチームで統一されていることが大切なんじゃないかなと思う。
#Effective C# 4.0のもくじ
Chapter 1 イディオム
- アクセス可能なデータメンバの代わりに常にプロパティを使用すること
- constよりもreadonlyを使用する
- キャスト時にはisあるいはas演算子を使用すること
- #ifの代わりにConditional属性を使用する
- ToString()を常に実装すること
- さまざまな同値性メソッドの関係を把握する
- GetHashCode()の罠に注意する
- ループの代わりにクエリ構文を使用すること
- 独自のAPIでは変換演算子を定義しないこと
- メソッドのオーバーロードを最小限にするよう、オプション引数を使用する
- 機能を最小限かつシンプルにすること
Chapter 2 リソース管理
- 割り当て演算子よりもメンバ初期化子を使用すること
- staticメンバは適切に初期化する
- 初期化ロジックの重複を最小化する
- usingおよびtry...finallyを使用してリソースの後処理を行う
- 不必要なオブジェクトの生成を避けること
- Disposeパターンの標準的な実装
- 値型と参照型の違い
- 値型における0を正常な状態とすること
- 値型は不変かつアトミックにすること
Chapter 3 デザインの表現
- 型の可視性を制限すること
- 継承よりもインターフェイスの定義および実装を行うこと
- インターフェイスメソッドとかそうメソッドの違いを理解する
- デリゲートを使用してコールバックを実現する
- イベントパターンの実装により通知を行うこと
- クラス内オブジェクトの参照を返さないようにすること
- 型はできるだけシリアル化可能にすること
- 粒度の粗いインターネットサービスAPIを作成する
- ジェネリックの共変性と半変性をサポートする
Chapter 4 フレームワークの活用
- イベントハンドラよりもオーバーライドを優先すること
- IComparable
とIComparer を実装して順序関係をサポートする - ICloneableを使用しないこと
- 親クラスの変更に応じる場合のみnew修飾子を使用すること
- 基本クラスに定義されたメソッドをオーバーロードしないこと
- PLINQが並列アルゴリズムを実装する方法
- I/Oのコストが高い処理に対してPLINQを使用する方法
- 例外を考慮した並列アルゴリズムを構成すること
Chapter 5 動的プログラミング
- dynamicの利点と欠点を把握する
- ジェネリック型引数の実行時型を活用するためにdynamicを使用する
- 匿名型を引数にとれるようdynamicを使用する
- DynamicObjectあるいはIDynamicMetaObjectProviderを使用してデータ駆動のdynamic型を作成する
- Expression APIを活用する方法を把握する
- 式を利用して事前バインディングを遅延バインディングに切り替える
- 公開するAPIでは動的オブジェクトを最小限に抑えること
Chapter 6 その他
- ボックス化、ボックス化解除を最小限に抑える
- 完全にアプリケーション固有の例外クラスを作成する
- 例外を強く保証すること
- 安全なコードを採用すること
- CLS互換性のあるアセンブリを作成すること
- より小さく凝集したアセンブリを作成すること
More Effective C#のもくじ
Chapter 1 ジェネリック
- 1.xフレームワークAPIのクラスではなく、ジェネリッククラスを使え
- 制約は必要最小限にして十分なものを定義せよ
- 実行型チェックを使ってジェネリックアルゴリズムを特化せよ
- ジェネリックを使ってコンパイル時型インターフェイスを強制せよ
- ジェネリッククラスは、IDisposableを実装する型パラメータのサポートを忘れるな
- 型パラメータのメソッド制約の定義にはデリゲートを使え
- 規定クラスやインターフェイスのためにジェネリックな特別バージョンを書くな
- 型パラメータがインスタンスフィールドでない限り、ジェネリックメソッドを選べ
- out、ref引数よりもジェネリックタプルを使え
- ジェネリックなインターフェイスとともに古いインターフェイスも実装せよ
Chapter 2 C#におけるマルチスレッド
- スレッドを作らずにスレッドプールを使え
- スレッド間通信のためにBackgroundWorkerを利用せよ
- 同期のためにはまずlock()を使え
- ロックハンドルのためにはできる限り小さなスコープを使え
- ロックされたセクションからは未知のコードを呼び出すな
- WindowsフォームとWPFのスレッド間呼び出しを理解せよ
Chapter 3 C#の設計実践
- シーケンスのためには合成できるAPIを作れ
- アクション、述語、関数から反復処理を切り離せ
- シーケンスの要素は要求されたときに生成せよ
- 関数引数を使って結合を緩めよ
- メソッドグループは明快で完全なものを最小限の規模で作れ
- 演算子の多重定義よりもメソッドの定義を優先せよ
- イベントはオブジェクトを実行時に密結合することを理解せよ
- イベントはvirtual宣言するな
- 例外はメソッドの約束ごとが守れなかったときに使え
- プロパティはデータふらしくふるまうように作れ
- 継承と合成を区別せよ
Chapter 4 C# 3.0の新機能
- 拡張メソッドでインターフェイスの最小限の約束を補え
- 拡張メソッドでクローズジェネリック型を拡張せよ
- ローカル変数はできる限り暗黙の型付けに委ねよ
- 無名型を使って型のスコープを制限せよ
- 外部コンポーネントに対する合成可能APIを作れ
- 束縛変数の変更を避けよ
- 無名型を使ってローカル関数を定義せよ
- 拡張メソッドを多重定義してはならない
Chapter 5 LINQの操作
- クエリ式からメソッド呼び出しの変換がどのように行われるかを理解せよ
- 遅延評価クエリーを使うようにせよ
- メソッドよりもラムダ式を使うようにせよ
- 関数やアクションで例外を投げるな
- 遅延実行と先行実行を区別せよ
- 高価なリソースを抱え込まないようにせよ
- IEnumerableデータソースとIQueryableデータソースを区別せよ
- Single()とFirst()を使ってクエリのセマンティクスを指定せよ
- Func<>ではなくExpression<>を格納するようにせよ
Chapter 6 その他
- null許容値のスコープはできるだけ狭くせよ
- コンストラクタ、ミューテータ、イベントハンドラのために部分クラス、部分メソッドを使え
- 配列引数を使わず、Params配列を使え
- コンストラクタで仮想関数を呼び出すのを避けよ
- 大規模なオブジェクトでは弱参照を検討せよ
- ミュータブルでシリアライズできないデータは自動実装プロパティにせよ
