真のアルファブロガーになるには何をすればいいのか？(GIGAGINE)

ttp://gigazine.net/index.php?/news/comments/20070508_alphablogger/

アルファーブロガー（有名であり影響力のあるブロガー）になるためには・・・とりあえず書くことか。

このブログを初めてもう一年以上がたち、ＰＧに就職してからも一年がたった。
一年前の自分と比べると自分はなんて成長したんだろうと思うが、
諸先輩方から見ると、どっちもあまり変わらないってのが正直な感想だろう。

自分の「日記」としてはブログは及第点だと思うが
（更新頻度は低いが）
ブログとして見た時、知り合い以外に誰が見るのだろう？
付加価値を考えないといけない時期に来たのかもしれない。
”ブログとして人気があるブログ”　＝　”アルファブログ”ではないが、
書くからには見てもらいたいと思うのが心情ではないか？

だが、赤の他人の視点から私のブログを見て面白いとは思えない。

「売り」はなんだ？
私がプログラマーとして生きていることは珍しいことではない。
この職業自体は門戸も広いし、私のレベルが頭抜けて高いわけでもない。

売りがあるとすれば、私があほうだと言う事ぐらいか。
集中力がない、要領が悪い、整理が下手。
これらの欠点を補ってなんとか仕事をしていっている。
この視点で同じ境遇の人に対して何かしらの手助けになるものが書けないか？

ついでに私側からの要求を出すならば、
出来るだけポスティングの工数を下げたい。
つまり、凝ったことはしたくない。
理由は仕事に支障が出るから。

何案か出すところで今日はやめておこう。

現在幸運なことにApollo が出たばかりである。
先行きがどうなるのか分からぬ開発環境ではあるが、
Adobe人口が少なくない事を考えると
数年後の動きが楽しみな言語ではある。

デザインパターンなどについてのブログ・・・
いや・・・おもろないだろ。

プログラミングの内容などについてのブログ
これもおもろない。
実装過程のブログなら腐るほどある。
読み手を自分としたチラシの裏的なものであるならば問題ないが。

仕事の内容ならば今ならwikka に書けばいい。いや書くべきだ。
（wikiは集合知なので情報の精査は書き込んだ後に行われるが、ブログの情報の精査は書き込む前に行わなければいけない。よってブログは不確定情報を記述する場所としては適さない）

となると仕事に関しては、確定情報と日記的なものだけになるが・・・
はてさて・・・

以下まさしくチラシの裏

最近の思考まとめ

以下最近たまってる疑問点などのチラシの裏です。
適当に書いてるし、命題の答えが出てないことも多く。
えーっと命題の答え知ってる人いたらヒントを教えて！！

strutsはMVCデザインパターンではない？

MVCデザインパターンの定義は
Model / View / Controller が別れていること。

つまりMVCそれぞれの繋がりが疎結合であるということ。
この疎結合性が問題ではないか？
アプリケーションにおいてなんらかの仕様変更が生じた場合。
きちんと疎結合であれば、各機能単位で変更を吸収できるはず。
それが出来てないのだったら疎結合ではない。
・・・なのか？

Facadeデザインパターンはオブジェクト指向的ではない？

GoFの23パターンの一つであるFacadeがオブジェクト指向的ではないという話。

“オブジェクト指向の優秀な雛形であるデザインパターン"その基礎たるGoFのパターン
それが"オブジェクト指向的ではない”

うーん・・・意味が・・・
私の理解力が足りないのだろうか？
私の理解ではFacadeはマジックサーブレットのリファクタリング手法としてエントランス的なものを設ける。
各オブジェクトに役割を与える・・・
うーん・・・オブジェクト指向の構成要件を復習すると

  1. カプセル化
    オブジェクト内部のデータを隠蔽したり(データ隠蔽)、
    オブジェクトの振る舞いを隠蔽したり、
    オブジェクトの実際の型を隠蔽したりすることをいう。

  2. 継承
    あるオブジェクトが他のオブジェクトの特性を引き継ぐ場合、
    両者の間に「継承関係」があると言われる。

  3. ポリモーフィズム (多態性)
    あるオブジェクトへの操作が呼び出し側(sender)ではなく、
    受け手のオブジェクト(receiver)によって定まる特性。

カプセル化においては、隠蔽ということで考えるとエントランスを設け以下のレイヤーの動きを隠蔽してる・・・？
まて隠蔽するってことは、そこは見なくてもいいということでそのオブジェクト間は疎結合でないといけない？
うーん・・・でもそれは実装方法だよなぁ、書き方の問題になるよなぁ
なる・・よなぁ？

ＯＫ！隠蔽化はクリアしてるんだ！
継承とポリモーフィズムに対応してないからオブジェクト指向的ではないんだ。

後GoFデザインパターンに対する
私の認識違いを今日指摘された。

私の以前の認識 「オブジェクト指向設計における良いデザインパターンの集合」

指摘内容
「オブジェクト指向設計における良く出てくるデザインパターンの集合」

デザインパターンが優れているところは、

  1. コンテキスト（プログラムの内部状態や置かれた状況、与えられた条件）
  2. ネーミング
  3. クラス図

コンテキストによってデザインパターンを選ぶ条件が分かり。
ネーミングによってコミニケーション工数が下がり（名前を言えば理解してもらえるのだから）
クラス図によって、コーディング言語に縛られないスケルトンが用意されている。

”そこが”素晴らしいのであって、
オブジェクト指向的に優れているデザインパターンかどうかとはまた別。

なるほど
(q.e.d.)

品質とは？

可読性、スケーラブル、可溶性。。。

ガベコレを実装しているjavaの長所と短所

ガベージコレクション（動的メモリ開放機能）
javaプログラムが動的に確保したメモリの解放機能がjavaには標準実装している。
C言語などでは自分で領域を確保し、それを解放してやる必要がある。
便利なところには危険がある。
なんらかの理由でjavaのガベージコレクション機能が動作しない場合、こちらからの制御は出来ない。

だが実際困った例は聞いたことがない、今では解決された問題なのだろうか？
今度の帰社日に質問しみよう