2010-09-08

大本営参謀の情報戦記

枝葉末節にとらわれないで、本質を見ることだ。文字や形の奥のほうには本当の哲理のようなものがある。表層の文字や形を覚えないで、その奥にある真相の本質を見ることだ。世の中には似たようなものがあるが、みんなどこかが違うのだ。形だけを見ていると、これがみんな同じに見えてしまう。
それだけ覚えていたら大丈夫、ものを考える力が出来る。

今この場面で相手に勝つには何をするのが一番大事かを考えるのが戦術だ。

5つの敗因
・国力判断の誤り
・制空権の喪失
・組織の不統一
・作戦第一、情報軽視
・精神主義の誇張

「兎の耳」こそ最高の”戦力”である。

大本営参謀の情報戦記―情報なき国家の悲劇

作者: 堀栄三
出版社/メーカー: 文藝春秋
発売日: 1989/09
メディア: 単行本
クリック: 3回
この商品を含むブログ (3件) を見る

2010-09-06

クリエイティブ・シンキング

クリエイティブシンキングでアイディアを考え出す。

クリエイティブシンキング実践

・ブレインストーミング
・マインドマップ
・ウィッシュフルシンキング
・ランダム・エントリー
・メタフォリカルシンキング
・６色ハット思考法
・SCAMPER
　　Substitute （換える）
　　Combine　　（結びつける）
　　Adapt　　　（適応させる）
　　Modify　　（修正する）
　　Put to other purposes （他の目的の使用）
　　Eliminate　（除く）
　　Rearrange　（並べ替える、逆にする）
・アトリビュート・リスティング
・アサンプション・スマッシング
・フォース・ル−ル
・サーチ・アンド・リアプライ
・５Ｗ１Ｈ
・ＰＭＩ
・トヨタ式５Ｗ１Ｈ
・フィッシュボーン・ダイアグラム
・バーティカルマーケティング
・ラテラルマーケティング
・水平移動
・連結

通勤大学MBA〈14〉クリエイティブシンキング (通勤大学文庫)

作者: グローバルタスクフォース
出版社/メーカー: 総合法令出版
発売日: 2005/12/22
メディア: 新書
購入: 1人クリック: 40回
この商品を含むブログ (3件) を見る

2010-09-05

未来のつくりかた

元Audiの和田智さんの本。
文化とそれに基づいたデザイン、そしてコミュニケーションが大事。デザインは過去から未来に向かっての橋渡しをするコンセプトをもって行うべき。今の利益至上主義は崩壊してきている。

・過去を全否定しない
・すべてがコミュニケーション
・人から逃げない
・本質を見極める
・Nein Sagen：いいえと言おう！（ナイン・ザーゲン）小学1年の授業：ドイツ

未来のつくりかたアウディで学んだこと

作者: 和田智
出版社/メーカー: 小学館
発売日: 2010/07/21
メディア: 単行本
クリック: 33回
この商品を含むブログ (11件) を見る

2009-10-25

言語の進化

#話が取りとめがなくなっているのであとでまとめる

Rubyは楽しくより簡潔に書いていく感じ。、
Javaはきっちりかっちりオブジェクトしてく感じ。
Cはさまざまな処理をガリガリ書いていく感じ。

印象とは別に時代とともにプログラミング言語は進化していく。

ただ、Javaを触ってきた身からすると最近のきっちりかっちり系の言語の舵の切り方に疑問を覚える。

自分はきっちりかっちり系の言語には下記の考えがあって、

できるだけ実行時エラーを減らしてコンパイルエラーで捕捉しよう。
単一的な書き方を強制することによってコードレベルの均一化を図ろう。

そのことによって、下記の効果を求めていると考えていた。

テストを出来るだけ簡略化する
自動生成による作成効率化を行う

Javaがバージョンアップしていくにつれて、その思想はないのではないかという思いに駆られるようになってきた。
Javaはいろいろなコードの書き方ができるようになってきたし、
まだ、導入の議論の最中ではあるもののクロージャが追加されようとしていたり・・・

自分はJavaはカチカチに堅い言語を貫き通すべきだと考えている。
がっちりとした構造を規定してJavaによってかっちりつくっていく。
Javaの技術が一定量あれば、皆が読むことができ保守していくことが出来る。
そんな真面目で融通の利かなさがJavaの売りだと思う。

初心者がわかりやすく、堅いがゆえに構造のノウハウを継承しやすい。
上級者は新たな構造を規定して創作していく。
その構造は分解可能で中級者なら理解していける。
スーパープログラマがいなくても、そこそこのプログラマが分担分担でやっていける言語がJavaの目指すところだと思っている。

2009-10-24

オブジェクトの天使と悪魔

オブジェクト指向プログラミングをするときの感覚はどのようなものか。

一言で言うと、ボクは新世界の神になる！（ｷﾘｯ

オブジェクト達がうごめいている世界を作って、
オブジェクトのコミュニケーションによって
創造主（プログラマ）の望むものを造りあげる。

まず、創造主は世界を作るための箱庭（VM)を用意する。
何らかの役割を持った種を作り上げるための元となる偶像（クラス）達を作り上げ、偶像と偶像の間の関係を定義する。
偶像の中には創世で最初に天命を授かるものの印として、天使のレリーフ（main）をもつものがいる。

世界の定義が終わったら、創造主はある1つの天使のレリーフに天使（ActiveThread)を使いに行かせて世界が始まりを告げる。

命（インスタンス）は天使が偶像に祈りをささげる（New)で創られ、
命は与えられた役割に沿って仕事を成して行く。
役割を終えた命はそっと天使の目の届かないところへ行き（ActiveThreadからの参照がなくなる）、悪魔（GC）がその命を昇天させる時までじっとしている。

箱庭から外の世界へ交信する（ファイル、DB、ソケットなど）者達も創造されることがある。これらは外の世界へ祈りをささげることによって、自分の世界の情報を伝えたり、外の世界の情報を受け取ったりすることが出来る。
祈りの交信は神聖なものであるため交信が終わるまでは光を放ち、悪魔を寄せ付けない。（C#でいうアンマネージド）
そのため、交信を終える（Close）をしないといつまでも悪魔が昇天させることが出来ずに箱庭世界を圧迫することになる。

天使は仲間の天使を呼んで分担して世界を動かしていくことが出来る（マルチスレッド）

・・・と、ここまで考えた。
あとは偶像の関連（継承とかインターフェースとか）って言うのは、偶像やその命とかのつくりの話になってしまうので割愛。

こうやって突き詰めていくと、やっぱりプログラムの思考は創造主を超えないんじゃないかっていう気がする。人が処理できないような膨大なデータを解析した結果を元に判断をしなければ・・・

2009-10-23

Cライブラリ

友人がどうもCライブラリを使っていろいろやっているようなので、
ちょっと調べてみたくなった。

Cのライブラリの関数1つ1つはとても短く書かれていてとても参考になる。
基本的に文字列操作は'\0'（ヌル文字）とポインタの戦いになるんだよねぇ・・・
うまく活用しないとバグる。

あと、真偽を返すものに関しては、偽が0で真はそれ以外の値(!)って言うのを
覚えておかないと思わぬところではまるんだったっけ・・・
（どっかでそう習ったような気がする）

調べてみると、ちゃんとレポートしてる人がいてとても助かった。

標準Cライブラリの実装
http://libc.blog47.fc2.com/

2009-10-10

getReaderとgetParamater系って一回のリクエストで同時に使えないの？について調べてみた

下記の質問を見つけたので、ちょっと調べてみた。

getReaderとgetParamater系って一回のリクエストで同時に使えないの？
http://bwind.blog19.fc2.com/blog-entry-15.html

TomcatのServlet API ServletRequest#getParameter()内には下記の記載がある。

http://mergedoc.sourceforge.jp/tomcat-servletapi-5-ja/javax/servlet/ServletRequest.html
HTTP POST リクエストで送ったなど、パラメータのデータがリクエストのメッセージボディで送られた場合、
getInputStream() や getReader() メソッドを使って直接メッセージボディを読み込む操作は、
このメソッドの実行に影響を与えることがあります。

なぜ1度しか読めないか。
予想としてはHTTP POSTのリクエストで受け取ったメッセージボディを
作成者が作成したクラスに渡すときにサーバで受け取ったメッセージを
そのままストリームとして渡してしまうために、
再度違う方法では取得できないということなのだろう。

ざらっとだけど、
Tomcatのソースを確認すると（org.apache.coyote.tomcat4.CoyoteRequest）
getParameter系、getInputStream系、getReader系でそれぞれ
requestParametersParsed、usingInputStream、usingReaderのフラグを立てていて、
取得時にこれらのフラグを確認して処理を分けている。

厄介なのはgetParameter系の処理の場合、パースするメソッド（parseRequestParameters()）
にて、usingInputStream、usingReaderのフラグがたっていると
解析結果を格納するParametersに何も設定せずそのままスルーしてしまうところだろう。
（Exceptionくらい返してもいいと思うのだけど･･･）

とりあえず、Tomcatでは処理をそうしているということは理解した。

getReaderとgetParamater系を両方使えるサーブレットコンテナがないか探してみると
OPEN INTRA MARTというNTTデータイントラマート社提供のオープンソースに当たった。
http://oss.intra-mart.org/

このAPIの中のim-javaee-assist-impl 0.1.1 API（im-commons）の下記クラス
（org.intra_mart.common.aid.jsdk.javax.servlet.filter.impl.AbstractHttpServletRequestMessageBodyWrapper）
では、

AbstractHttpServletRequestMessageBodyWrapper#getMessageBody()で下記の記載がある。

http://oss.intra-mart.org/projects/im-commons/maveniframe/im-javaee-assist-impl/apidocs/org/intra_mart/common/aid/jsdk/javax/servlet/filter/impl/AbstractHttpServletRequestMessageBodyWrapper.html
このメソッドは、ServletRequest.getInputStream()
または ServletRequest.getReader() を実行した後でも、
メッセージボディを含む入力ストリームを返します。
また同様に、 ServletRequest.getParameter(String name) を実行した後でも、
メッセージボディを含む入力ストリームを返します。

ソースを確認すると、受け取ったメッセージボディはbyte配列として保持しておき、
getParameter系、getInputStream系、getReader系はそのbyte配列から生成したものを
返してくれる形になっているためにgetMessageBodyとgetParameter系の使用で
rswさんの問題は（代替案が出来たということで）解決かな。

どれでも使用できるようにbyte配列を持っているにもかかわらず
getReaderとgetInputStreamに関しては両方は使えないように実装されているのは
なんか規定された仕様があるようだなぁ・・・
詳細には調べていないけどJSRか何かで規定されてるんだろうな。

うんじゃぁ、TomcatでStreamをとりつつ、ParameterをMapとして取得したい場合どうするか。
getInputStreamで取得したものをbyte列として保持しておいて解析するしかないのだろうなと思う。
javax.servlet.http.HttpUtilsにパースするメソッドがあったけど、
このクラス自体が非推奨になってしまっているなぁ･･･
エンコーディングに気をつけたりする必要があるためなのだろうけど。

うーん・・・
TOMCAT_HOME/server/libにある
catalina.jarの（org.apache.catalina.util.RequestUtil#parseParameters）でいけそうかな？

結論としてはgetReaderとgetParameter系同時に使えない。
TomcatならStreamで取った値をパースしてParameterの代用とすればいいし、
OPEN INTRA MARTならgetMessageBodyをReaderの代用とすればいいということになる。