タイトルがすべてなんだけど、To Do はただ把握すればいいってわけではなくて、To Do を管理するってことは、
ちなみに黙殺できるようなものは最初から引き受けない。
1 をやったら To Do 管理だという誤解があるけど、それだと時間の管理にならないってこと。
わかっちゃいるので、あとはやるだけなのだ。
Gmail で、「開かずに件名だけ見て削除」というのが8割以上の場合は自動的にその送信元からのメールを Trash に回す。ということがやりたい。
あと、LDR みたいにメールの送信元にレート付したい。特に社用のメール。
岡本吏郎さんの「会社の数字がカラダでわかる! 〜会計するカラダのススメ〜」を読みました。
基本的には会計の本なのですが、それ以上に会計の話を通して、マネジメントということについての思想を伝えようとする。そんな本です。
管理するのでも、コントロールするというのとも少し違います。何もかもを自分が手を出すことはできない中で、正しい方向へ行っているのか否かというのを、どのように判断するのか。そのための知恵が詰まっています。
これはまさに知恵の本です。とにかく実際に必要なことは何か。会計ということが現実的に役に立つためには、一体何をする必要があって、何はする必要がないのか、それはなぜか。そんな「知恵」が書かれています。
一方で、会計についての「知識」はとても手薄です。必要ないから薄いのでしょう。試験に答えるための会計を知りたいからとか、知らないと恥ずかしいから、というような動機でこの本を読むのはオススメしません。(いや、ある意味、そういう人こそ本書を読んで考えた方がいいんですけどね。)
まー、それにしても、この岡本吏郎さんの書く内容を読むと、なぜかいつも羽生章洋さんの文が頭に浮かんで仕方ない。地に足の着いた主張。あくまで基礎を徹底した結果の他とは一味違う知見。どうにも受ける印象というか、色合いが似ているのです。
たとえば「DB の仕組みを正しく理解して適切な SQL を書かないから、パフォーマンスも出ないんだよ!」みたいな話と、「経理はまずは徹底した実査なんだよ。会社にとっての入出金の現実の姿が見えずに会計がわからんとか言ってちゃダメなんだよ!」みたいなのは、ジャンルが違うだけで姿勢は同じ。しかも会計をカラダで理解しろ!って。いつ「量は質に〜」て出てくるかとひやひやしながら読みました。
じゃ、最後に一節を引用。
粗利額と人件費の二つの管理。これが経営の基本だ。とどのつまり、経営の管理はこれだけ。これ以上でも、これ以下でもない。
経営とは、この二つの数字とそのバランスを見ていればよい。当然だが、粗利額は1円でも多く稼ぎ、人件費は抑える。
ただし、人件費の管理は絶対額ではない。割合で管理する。図の限界利益を分母として、人件費を分子とした割合で見る。これを労働分配率という。
この労働分配率を低くする。妥協せずに低くする。そういう経営ならば儲かる。これだけだ。これは決して人件費の絶対額を低くすることではない。給料は同業他社よりも支給する。しかし、労働分配率は低いというのが理想。そのためには分母の限界利益を多くすればよい。つまり、一人当たりの限界利益を多くすればよいことになる。
そして、そうこう思いながら、Bloglines でフィードを読んでたら、こんな話が。
夏のはぶにっき コストのはなし
うーん、おもしろい。
babie さんの ■[rails] link_to_remote の★のところを。(遅レスに遅レス)
Optionally, you can use the options[:position] parameter to influence how the target DOM element is updated.
また、引数の options[:position] では対象の DOM エレメントをどのように更新するかを指定することもできます。:before, :top, :bottom, :after のどれかを指定しましょう。
:condition: Perform remote request conditionally by this expression. Use this to describe browser-side conditions when request should not be initiated.
:condition: この表現を使うことで、リモートリクエストをより安定して (conditionally) 使うことができます。リモートリクエストが発行されない場合には、ブラウザサイドの状態を返すようになります。
:submit: Specifies the DOM element ID that’s used as the parent of the form elements. By default this is the current form, but it could just as well be the ID of a table row or any other DOM element.
:submit: (submit する)フォームエレメントの親となる DOM エレメントの ID を指定できます。デフォルトではカレントフォームですが、テーブルの行にすることも、別の DOM エレメントにすることもできます。
それから、Duck Typing は、こんなところでいかがでしょう?
まつもとさんの「計算機システム特別講義ＩＡ」より。
http://www.rubyist.net/%7Ematz/slides/tsukuba-seminar2/mgp00038.html
ポリモーフィズムは具体的な現象であり、Duck Typing は方針なのだと思います。Java だと Interface で外部インタフェースを定義するけど、 Ruby は型でしばることをせずメソッドだけで外部インタフェースをやりくりした方が動的型言語っていう特長が生きてうれしいよねっていう。
参考) ActionView::Helper::PrototypeHelper の link_to_remote
http://api.rubyonrails.org/classes/ActionView/Helpers/PrototypeHelper.html#M000412
Lessons from Hpricot のエントリを読んで抑え切れなくなって遊んでみる。
require 'pathname'
class Pathname
def /(path)
self + path
end
end
def method_missing(name, *args)
name.to_s
end
実行結果はこんなかんじ。
root = Pathname.new '/tmp' root/foo/bar # => #<Pathname:/tmp/foo/bar> (root/bar/foo).parent.children # => [#<Pathname:/tmp/foo/bar>, #<Pathname:/tmp/foo/baz>]
もう最高。
てことで書いてみた。
# random_index.rb
class RandomIndex
def initialize(size)
@indexes = Array.new(size) { |i| i }
end
def next
@indexes.delete_at(rand(@indexes.size))
end
end
# enumerable_shuffle_method.rb
module Enumerable
def shuffle(seed = nil)
srand(seed) if seed
require 'random_index'
entries = self.entries # for chache
indexes = RandomIndex.new(entries.size)
shuffled_entries = []
while index = indexes.next
shuffled_entries << entries[index]
end
shuffled_entries
end
end
class Array
def shuffle!
self.replace self.shuffle
end
end
というような話でいいんだろうか？
この実装だとパフォーマンスがわりと厳しいので、実際は要素の数が1万個くらいまでが実用できる限度だと思う。
追記：Enumerable#sort や Enumerable#collect と同様に結果は Array クラスで返す。
１０年来の業務プログラムなので、いろいろ経緯があって今の形なのは仕方がないと思うけど、よくない設計に何も言わないとそのまま次の１０年も過ぎ去りそうなので指摘してしまおう。
今後、コードをデータとして持つときは、次の二点を考慮して扱ってください。
たとえば、こんなシステムの話です。GUIからコードとその名称を入力値として受け取り、DBへ一時保存します。そして、あるタイミングでそのコードを他システムへ送信します。送信された先ではそのコードを使って集計・分析をします。
こんなときに、現在の実装は次のような形になっているのです。
「GUIで表示されるコード」＝「DBへ保存されるコード」=「他システムへ送信されるコード」
これでは柔軟性がありません。どこかのコードを修正する必要が出た場合、すべてのコードについて対応の有無を検討する必要が出てきます。
そこで、よりやわらかい設計にするためにこんなふうにしてみます。
一方で、元のデータ設計へ戻って考えてみてください。これらの仕様変更のどれか一つに対応するにしても、影響や開発量はけして馬鹿になるものではありません。
と、長々と書きましたが、次の本を読んだほうが話は早いのでぜひ読んでください。
ちなみに Identifier とコードの話だけであれば、これだけでも十分です。
仕事をしている中で、 Windows のネットワーク周りの知識と知恵が物理的にも論理的にも弱点になっているのに気付く。
んで、 Google に聞いてみて「 Windows2003 Server による社内ネットワークの構築」を発見。
まさにこれだよ！という気持ちと、あー、こんな基本的なこともわかっていなかったなんて・・・という気持ちとで複雑。。
あとは、基本でこの辺か。。
