スポンサーサイト 

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ガンバの冒険 

ガンバの冒険が映画とセットになって新たにDVDBOXで発売されます。つーか、映画いりません。 TVシリーズはまちがいなく傑作です。出崎アニメのよさがいっぱいの作品です。「しっぽを立てろ!」。 この言葉が見る前と見た後でどれほど受け取り方が変わるのか、是非実感してほしいものです。

気に入った方は「宝島」もいかがでしょう。


ガンバの冒険 DVDBOX
斎藤惇夫 野沢雅子 水城蘭子
B000EMSLKU
宝島 DVD BOX(2)
清水マリ 若山弦蔵 家弓家正
B00005QWIE
スポンサーサイト

サイバー経済学 

サイバー経済学
小島 寛之
4087201104

もともtベイズというキーワードに惹かれて買ったのですが、ベイズ以外の部分の方がとても興味深かった新書です。


金融工学とは何か、先物取引、オプション、デリバティブ、 リスクヘッジなどがそれぞれどのような関係にあるのかをわかりやすく説明してくれています。


個人的に気持ちがよかったのは、 テレビに出てくるような証券アナリスト達が言葉を濁さざるをえない投資と投機の違いをちゃんと定義しているところです。 その定義自体が実経済において適切な定義であるかどうかは別にして客観的に定義できることを示していることはとても重要だと思います。


低成長率経済においてのリスクヘッジはマクロで見るとゼロサムであり経済の成長へは直接影響を与えることがないというのも今まで気がつかない視点でした。 もちろんこれはスナップショット的な視点であり流動性から発生するエネルギーを考慮すればもっと複雑になるであろうことは予想できますが。


また、機会の平等についても経済学の面から注意すべき点があるという指摘もおもしろいものでした。 100倍の資産を持つ人と五分五分のリスクで勝負すれば破産する確率が100倍違うという例は適切ではないと思いますが、 一人が100の資産を持って市場に参加するのと100人が1の資産をもって市場に参加するのではスピードに違いがでてきます。 スピードの違いがもうけの大きさに影響することは自明ですよね。


全員が合理的な経済活動を行えば経済は成長するということが真であるためにはどのような前提が成立している場合なのかを再考する必要があるということに改めて気がつかされたのも有意義でした。


改めて他人の視点を借りることができる本を読むということがとても楽しいことだと実感しました。

 


コードを書くときのお話3 

どうせならということで私のコードの書き方でマイノリティなものをもう一つ。

関数を書くとき、

unsigned int func(void)
{
}

という形がメジャーらしい。grepかけたときに関数に型が付くので便利だとか。私の場合は以下の形です。

unsigned int
func(void)
{
}

grepかけたときに型までみたいときでも私はプロトタイプを書いているのでそちらでわかりますし、 関数の本体を探したいときは^funcのように正規表現を使えば問題なしです。

 


コードを書くときのお話2 

C言語でreturnの後に括弧を付けないのがどうやら主流のようです。Cプログラミングの秘訣でも

私にはなぜ括弧があった方がわかりやすいのか、全く理解できません。かえって分かりにくくなるだけだと思うのですが。

と書かれています。実は私は括弧を付ける人間です。マイノリティなのは承知しています。特に深い理由はないのですが、 あえて言えば予約語の後に式が続く場合には括弧を付けたいというところです。もちろんvoid型の場合には付けませんが。ん? となるとreturn ();なんて記述はコンパイラエラーになるんでしょうか。今度試してみます。


コードを書くときのお話1 

Cプログラミングの秘訣を読みました。 最終更新が1998-09-17ということで結構昔に書かれたものですね。今読んでもかなり参考になるのがすばらしいです。

 

その中に以下のような記述があります。

□必要なコメントをなぜ書けないのか
  …略…
2)必要なコメントであることがわからない。
実はこれが問題なのです。言い換えれば、そこにコメントしておく必要であるという判断ができないのです。または必要と思わなかった、 従ってコメントにしなかった、ということです。その時は頭に入っているが、後でわからなくなるかもしれないことがあれば、 コメントに書くのが望ましいことです。しかし、これは将来忘れるかもしれないということは、それを覚えている間は、 なかなか気付かないことがあります。

私の場合はソースコードだけではわかりようがない制約事項、 つまり開発環境やハードウェアの都合によってそう処理せざるを得なくなった部分にはコメントをつけるようにしてます。

他にもこのようなことが書かれています。

・関数を定義する場合には、それが何をする関数で、 どのような場合にどんな値を戻すのかを書く。
・変数に対するコメントは、その値がどのような場合に、どういう意味を持っているのかを書く。

これって実は実装の話ではなく設計の話ですね。C言語であろうとインターフェース設計が重要なことには変わりありません。

・繰り返し処理(for, whileなど)に対しては、 どのような条件で繰り返すか、または繰り返しを終了するのかを書く。
・条件判断(if, switchなど)に対しては、どのような条件の時に処理が実行されるかを書く。

通常の制御文にコメントが付けられていないのはよく見られます。 通常であるがゆえにコメントを読まなくても内容が理解できてしまうこともその原因でしょう。 このような場合にコメントを付けることの理由は修正時にあると考えられます。 安易な修正を繰り返すとソースコードは当然のように腐っていきます。 記述されているコメントが明確であれば安易な修正を行うことがコメントの内容から乖離していくことになります。 よいコードを書きたいと考えているプログラマーが忙しさに流されてしまうことを止めてくれる効果が期待できると思います。


Kyam's Schedule Sheet 

img_20060316T005139390.jpg


私が愛用しているスケジューラソフト、Kyam's Schedule Sheetです。多機能でヘビーなスケジュール管理ソフトではありませんがマニュアルやヘルプを読まずに使い始めることができた私にとって貴重なUIを持ったソフトです。マニュアルを読んでいないので間違いなく機能を使い切れていません(汗)。HPを読んでみたらiPodとも連携できるとか。全く知りませんでした。レジストリも汚しませんし、軽いスケジューラをお探しの方は一度試してみてはいかがでしょうか。

実例型開発プロセス解説の難しさ 

ソフトウェア開発の仕事をしていると、やっぱりもっとうまく開発を進めたいと考えるようになります。 私もいろんなサイトや本などを読ませていただいて勉強させていただきました。 その中に仮想的にプロジェクトを用意することで実例を提示している形で開発プロセスを解説しているものがあります。

 

この形式の解説は具体的なイメージが沸きやすく、現実にすばらしい解説がされているものも多くあります。 いまどきの開発プロセスで純粋なウォーターフールであるものはまずありえず、なんらかの形でイテレーションが組み込まれています。 イテレーションが発生するということはつまり手戻りが起きているということです。 この手戻りを如何にうまく対処できるかが解説しようとしているプロセスや手法の特徴とさえ言えるでしょう。

 

手戻りに対してうまく対処できますというタイプの場合、「このような仕様変更、追加が発生しました。この場合、 このように対処することで解決できます」という実例があげられます。仕様変更、追加に対してアジャイル型であれ統一プロセス型であれ、 重要なキーワードに抽象化があります。どのように抽象化すればよいのかを理解するために実例をあげているわけですが、 読者がそれを実際の業務に持ち込む際にはうまく抽象化するためにあげられた実例自体をうまく抽象化、つまり理解できている必要があります。 このことは抽象化を理解してもらうための実例はより抽象化が容易であるものでなければならないということです。 これはかなり難しいことだと思います。


Windows XP Boots on Macbook 

Windows XP Boots on Macbook

やってもうた!

ネタとアートの境界線 

Desiree Palmenというページがあるのですが、これがネタなのかアートなのか微妙なところをいってます。 今後の進展具合がやってる人たちの意識でどっちにでも転びそうなもの見てるのは結構好きだったりします。

マインドマップの使いどころ 

POLAR BEAR BLOG図解の弊害という記事を読みました。 ふむふむ、なるほどと読ませていただきました。私も仕事でマインドマップを使うことがあります。FreeMindを利用することが多いですね。 私自身はマインドマップを使うことにそれほど違和感を感じていなかったので何が違うのだろうと少し考えてみました。

 

何かを行おうとするとき、その実現可能性や意味を人に伝えるときに用いられるのが構想です。 構想を得る際に行うのが分析(いわゆる構想を練るというやつ)です。分析を行うには情報が必要となり、 情報はネタやデータを分類することで生まれます。私の場合、集めたネタを放り込む場所としてマインドマップを使っていることが多くあります。 ネタ同士の関係などはその時点ではあまり考えていません。大まかな分類に対して単に放り込んでいるだけです。 とりあえず関係ありそうなものを集めようとしています。発散させつつ大まかに分類しているわけです。ネタは分類されると情報になります。

 

ネタが情報になると次は分析です。このフェーズで自分なりの視点や発想が盛り込まれ、構想がアウトプットされます。 私が図解を行うのはアウトプットされた構想を理解してもらうときですね。 構想ですからそれ自体の理解のされかたにぶれがないようにしなければなりません。。 理解のされかたにぶれのない構想に対して合意がなされることが実現する際に生じる誤解を減らすことになると考えています。 このぶれを減らすためには図解だけでなく言葉も必要だと思います。UMLだけですべてが語れるとは思っていません。

 

実際にはネタの分類と分析の間でイテレーションが発生するのが普通だと思います。 このときにネタをあっちへもっていったりこっちへもっていったり、コメントをつけたりするのにFreeMindを使わせてもらっています。 アウトラインエディタよりいい加減さを許容してもらえますから。

 

参考
それは「情報」ではない。―無情報爆発時代を生き抜くためのコミュニケーション・デザインそれは「情報」ではない。―無情報爆発時代を生き抜くためのコミュニケーション・デザイン
リチャード・S. ワーマン Richard Saul Wurman 金井 哲夫

by G-Tools

RSSフィードをFeedburnerに変更しました 

物は試しということでRSSフィードをFeedburnerに変えてみました。
このあたりは全くの素人なのでうまく出来てるといいけど。

忍空、復活! 

ちょっとコンビニにお茶を買いにいったらなんと、

 

忍空~SECOND STAGE~干支忍編~

 

うぉぉ、風助、なつかしい!

ウルトラジャンプで連載してたなんて全然しらなかったよ。

 

 

TiddlyWikiでリンクをクリックしたときの挙動 

仕事場でも自宅でもtiddlywikiを使ってるんだけど、 メインメニュー内のリンクをクリックしたときの挙動が違っているの理由がわかった。

 

options→Advance OptionsにあるClicking on links to tiddlers that are already open causes them to closeがチェックされているとすでにtiddlerが表示されている場合、 tiddlerへのリンクをクリックした時にそこへジャンプする。チェックされていないと表示されていたtiddlerがcloseする。 チェックされていないほうが私の好みだ。、

プレファクタリング 

プレファクタリング―リファクタリング軽減のための新設計
ケン パーク Ken Pugh 木下 哲也
4873112729

この本はCDレンタルの管理システムを題材としてシステムを開発していく流れを著者の考えに基づいておこなっていくという形になっています。 サブタイトルの中に新設計という言葉が使われていますがとてもベーシックな王道とも言える開発手法だというのが私の感想です。

 

そのままではありませんがRobert C. MartinのOOPの法則も意識されていますし、 デザインパターンの使用も盛り込まれています。本のタイトル(特にサブタイトル)がややキャッチーな気がしないでもありませんが、 基本となる開発の流れの中に如何にいまどきのテクニックを活用するかという点において無理矢理な感じが少ないのが好感が持てました。

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。