FC2ブログ

質問するという事

質問なんですが、外部ライブラリってDXライブラリを使うのが一番いいのですか??


これ、某C/C++の質疑応答での突然の質問。もちろん全文。

”外部ライブラリ”ってのが何をそう呼んでいるのか、”DXライブラリ”ってデラックス?とか。
で、この質問をしたのが工学院生。なんというか悲しすぎる。

本人のエリアを覗くと、どうやらゲームプログラミングを始めようとしているらしい。
”外部ライブラリ”って言葉をどこで聞きかじったのかは不明だが、たぶん、”DXライブラリ”と言っているのは、DirectXのことなのだろう。
DXライブラリじゃぁどうみたって、デラックスじゃねぇかと。
しかも処理系非依存の掲示板に”Windows”の一言も書いちゃない。

最近この手の、情報まったく出さずの質問がやけに多い。
相手から、『どうしたの?』、と声をかけてもらう為だけの、中身のない質問。というか声掛け。

技術系質疑応答掲示板であれば、最低でもOSやコンパイラ、そのバージョンに最低のソースをつけると的確な応答が帰ってくる。
なのに、それをあえて対話形式で、「どうしたの?」を待つ形式で書き込む。なぜだ。彼はこの一行で”質問した”と思っているのだろうか。

で、「何の話?」という問いかけに対して、
C言語でゲームを作るときの話です
よく言われるウインドウズAPIとかいうものの類です

と返した。
ここで初めて、ゲームと、ウインドウズというキーワードが出てきた。
ただし、彼の脳内の”ゲーム”という定義は、彼以外誰も知らない。
”ウインドウズ”もバージョンは決して言わない。
そして、次の応答の、待機体勢

彼にとって理想の対応を考えてみると、内容への応答は二の次で、とりあえず優しく頷いてくれる対応が欲しいのかもしれない。
見も知らぬ他人がどう思うかよりも、自分をどう見てくれるのかが重要なのかもしれない。
もっと言うと、彼にとっての世界は、自分自分の母親だけなのかもしれない。

この手の質問者はだいたいが自身の質問の仕方を直したりはしない。自分に落ち度は無いからだ。
だが、だいたいが2度と質問しない。自分を理解してくれない人間には用が無いからだ。

なんかあれこれいろいろ考えさせられる一行なんだが・・・

相手してられん・・(ーー;
スポンサーサイト

インターフェースと抽象基底クラス

ちょっと突っ込んで聞かれると返答に詰まるのは仕様です。:-P

JavaやC#で使える、インターフェース
実際にこれが威力を発揮するのは、多態(Morphing)であるのは異論のないところ。
んだがこれがC++からの流れ者として理解するにはちょいとしんどい。

基底クラスではいかんのか?
多態として使用する事を考えた場合、インターフェースは基底クラスと等価といってよい。
いちいち全て実装を強制するインターフェースは使いやすいのか?
基底クラスで実装しておけば良いだけなのではないか?という疑問はしばしば的を射ている。
抽象基底クラスではいかんのか?
「インターフェースは実装者に実装すべきルールを強制するのだ」、という意見に対して、抽象基底クラスを用いる事でほぼ同様の効果を得られる。(実装せねば実体化できないのだから)
多重継承の代替品なのか?
そうとも言える。

まぁ、ぶっちゃけたところ、使いやすく使えればえぇねん。
多重継承(ダイヤモンド継承)の問題はオブジェクト指向プログラミング創生期から取り沙汰されており、多重継承を認めない言語仕様へということでJavaやC#は進んできた。
しかし、オブジェクト指向プログラミングで重要な、性質ってやつは複数組み合わせる事で力を発揮するわけで、ここを捨てるわけにはいかない。
それならいっそ、この性質部分を分けてみてはどないやねん。
ってことで、実装とはまったく分離させたオブジェクトのラッパが生まれた。

ってのがほんとかどうかは知らないが、このインターフェース、存在理由や抽象クラスでの置換えとか難しいこと考えずに使ってみると、なんととっても使いよい。

なによりもコードが見やすい。
抽象基底クラスでも、それなりな命名規則でルール付けすれば良いのだろうが、インターフェースの場合、
IHogeHogeって出てくるだけで、「あぁこれはインターフェース」とわかるし、IEnumraterだのIComparatorだの、一目で意味するところがわかるのが良い。

C#の場合でも、クラスの設計/実装とは別の次元で、業務的なロジックはインターフェースを介すると、ちゃちゃっと変更可能だったりする。
インターフェース自体の変更は、実際のクラスの変更を余儀なくされるのだが、プロパティの追加程度なら、インデクサでちょちょっと追加しとけとりあえず、みたいな。
とにかくお手軽なのよ。何がと聞かれてもやっぱり詰まるんだけれども。

インターフェースとは、の問いに真剣に答えるとしたら、非似多重継承となっちゃうんだが、実はこの上っ面だけで中身のない物体、リモート(CORBAやRMI)になるとまた重宝だったりもする。

まぁ何はともあれ、ちょいと使うと癖になる。それがインターフェース。ってことで、ちゃんちゃん。

Apache License, Version 2.0

オープンソースの中には、"Apache License"の記述のあるものが多くある。

Apache Loggin Serviceから提供されている、Log4シリーズも当然、Apache License, Version 2.0のプロジェクトである。(日本語訳はSourceForge : Apache License, Version 2.0

GNU GPLとの差異が時に取り沙汰されるが、思想的にそれほど差は無い。

最近は業務系プロジェクトでも Log4シリーズに代表されるようなオープンソースを利用するケースが増えてきているが、そのラインセンスについての意識は驚くほど低い。
今までも納品の際にオープンソース関連のライセンスについて触れられたことはないし、ソースの扱いを含めて、ライセンスの記述さへ無いものもある。

業務系開発の現場において、品質の向上が叫ばれる中で、製造側の負担は増し、単価はどんどん減らされる状況にあり、発注者の意図とは別に今後これらオープンソースに頼る部分がどんどん大きくなっていくだろうと思われる。また製造側としてもやむを得ずオープンソースを利用してしまう状況が発生するだろう。
そのような時に、それ(オープンソースを利用している事)をきちんと伝達できる仕組みを作っておかないと結構大変な事になる。
(現在、著作権については契約書に明記されるようになったが、他ライセンスについて記述のある契約書は目にしたことがない。)

本来、GPL(および相当ライセンス)が利用できないようなプロジェクト(業務系だと結構あると思うんだが)では、その旨を末端まで周知させるべきであるんだが、
なにもするな。だから単価は半額。でも全部やれ。
という状況では、”ありものの組み合わせ”へ流れる可能性は大きいし、実際そういうプロジェクト/開発者も目にしたりする。

オープンソース同等の機能を要求されるが
  • 開発は客先で
  • 素のWindows上のエディタのみで
  • 持ち込み厳禁/持ち出し厳禁
  • ネット接続不可
  • 工期は数週間
  • テストも個人持ち
  • 瑕疵も個人持ち
  • 納品後の損害賠償も個人へ
っちう環境だと、どうしても契約の穴探すようになっちゃうのもしょうがないことで。

んー、どう考えてもまともじゃないよな。

久々Newノート

珍しく3年半程も頑張っていた、GATEWAY 3538JPがとうとうダメになってしまった。

ここのところHDDが怪しくなったとともに、内蔵無線アダプタを有効にするとブルースクリーンが発生したりするようになり、だましだまし使っていたんだが、昨日はLCDのバックライトが切れてしまった。

このままでは仕事にならん、ってぇことでツクモに走って買ってきたのがこれ。
W466U-403CP2

GIGABYTE W466U-403/CP2
ツクモで89,800円。

もともとGIGABYTEW466Uで、
  • Core2Duo
  • 120GB HDD
  • 1GB DIMM
  • Windows XP Home SP2
の構成で九十九が販売しているもの。

業務の都合で今回もXPなわけなんだが、店舗入り口にいた店員をつかまえて、
Core2でWindows XPで10万円以下のノートくれ
と言ったら出してきたのがこれ。

画面は一応14.1インチワイド、最大解像度は1280x800とちょっとしょぼい。
Vistaだとちょっと不満が出るかも、なんだけれど今のところ予定もないし。

まー特別な事は何もないPCなのだが、Core2Duoで10万切るのは今のところこんなもん。

とりあえず気になるのは、キーボードの押した感じが、クシャンって感じなのが嫌い。
さて、何年持つかなー・・・

オープンソースカンファレンス 2008 Hokkaido

毎年毎年、行きたい行きたいと言っていながら、なかなか時間がとれないこの時期ですが、今年もやってまいりました、
オープンソースカンファレンス 2008 Hokkaido

固い話ばかりでもないので、皆様お誘いあわせの上、、行きてぇ(ーー;

歳の功より亀の甲

プログラマとして生きるようになってもうかれこれ、結構なもんで。
地位も名声も関係の無いこの業界は、やっぱり居心地が良いと感じる今日この頃でございます。

おりしも秋葉原でバカヤローが暴れた昨日今日ですが、
誰かに認めてもらいたいだとか、一発大逆転だとか、思ったことがない君はプログラマの素質十分。どうだい?片足突っ込んでみないかい?

虚勢を張る必要がない
できるものはできる。できないものはできない。それが技術屋の世界。
20年選手だろうが新卒だろうが、その状況で必要とされる技術が選ばれる。
興味がつきない
新しい技術は毎日沸いてくる。どれを捨て、どれを拾うかはその人次第。
それが即戦力になろうがなるまいが気にすることはない。学んだ技術は全て明日また沸いてくる新しい技術の糧となる。
しんどい作業は少ない
世間で言われるほどしんどい作業は無い。他業種と比べても、時間的には差が無い。
デスマデスマと騒いでも、殆どは当人の精神的なものである。
意外ともてない
虚勢を張らずに興味のある事をコツコツやれている、って事は、常にギリギリで勝負している相場師なんかと比べると派手さはないし、特別金回りがいい業種でもないので、女の子にちやほやされる場面てぇのはまず期待できない。
その代わり、しっかり自分を見てくれる人、ずっと見ていたい人が見えてくる。
だめな時はだめ
どんな著名な技術屋でも、だめな状況やだめな時期はある。それでもコツコツやれることがあるのがこの仕事。”マイペースとはなんぞや”なんて他の業種では考える事もできないだろう。
かの、επιστημη氏も、「明日できることは今日やるな」と仰っておられる。
どうでもいい組
勝ち組/負け組とうるさい世の中で、「んなことどうでもいい」と正面きって言える職業が技術屋。
財布の中身よりもヨドバシゴールドカードのポイントが気になるはず。・・・なのは俺だけか・・・


とまぁこんな業界だもの、気軽に入ってくればいいのに。

本音はね、若い人が増えてくれないとオジサンだんだんきつくなってきてるのよ。(^^;

人生ゲーム/運命ゲーム

涙がちょちょ切れるくらい懐かしいパッケージ。

びーのホームページへようこそ! ~ ボードゲーム研究所

この中の、人生ゲーム(タカラ:現タカラトミー)と、運命ゲーム(任天堂)。
画像を無断で借りちゃうけれども許されよ。
Game Of LIFE Unmei Game

ボード上に山あり橋ありの立体感に、すごろく=サイコロの当時の常識を破ったルーレットが斬新だった人生ゲーム。この箱の右下のなんだかわからん外人の親父がまたイイ。

それに対して、二番煎じでありながら、無機的なボードに人型のコマで職業選択を迫る運命ゲーム
中一コースを彷彿させるような、子供のポーズがまたイイ。

どちらもそれぞれ面白かったんだが、当時の子供の人気を分けたのが、それぞれのルーレットだったんじゃまいかと考察してみたり。
硬質ビニルのストッパー付きルーレットの人生ゲームに対し、運命ゲームは裏面の磁石の磁力によって回転速度を減速する。
見た目や操作のなめららかさは断然運命ゲームのマグネット方式なのだが、いかんせん、これ、止まるのが遅い
Unmei Game Rulet

子供を売り払ったり、約束手形があったり、一発逆転の大立者になれたり、一発転落の貧乏農場ありと、派手な展開の人生ゲームとは、また違う味わいのある運命ゲームではあったが、このノロノロとしたルーレットだけは我慢ならんかった。

20世紀少年で出てきたのは、少年マガジンと平凡パンチだったが、少年画報冒険王も登場させて欲しかったなぁ、と突然思った。

ちょっとノスタルジックな夜でござんす。

Dependency Injection

DI(ディー・アイ)と略される。
'依存性注入'などと言うらしい。
BINARY-IT用語辞典 : DI


抽象クラスの実態を、設定により実行時に決定する設計思想(デザインパタン)ということで、結構前からある手法らしい。

C++では'抽象クラス'あるいは'基底クラス'、JavaやC#では'インタフェース'によって、オブジェクト指向プログラミングの核である多態(Morphing)は支えられているわけなんだが、何れも、
抽象オブジェクトとして扱う事ができる
というだけで、その実体はコードのどこかではっきりさせておかねばならない。

ところがこのDIというやつ、実際はDIContainerとして実装されるのだが、その実体を'実行時に'決定できる。
これが何を意味するかというと、ロジック/モジュールを完全に分離する事が可能で、すなわち、開発部隊を完全に分離できるという事になる。

従来の抽象クラスイメージでも開発自体は分離可能だが、ソースを入れ替えコンパイルし直す作業が発生する。ところがDIContainerを使うと、呼ぶ側/呼ばれる側の依存が無いため、それぞれ独立して存在できるんである。

DIContainerの実装は今のところJavaの例しか知らないが、C++やC#でも既にあるのかもしれない。

ちょっとだけ危惧を感じるのは、Enterpriseなシステム開発には絶好といえるこういう思想が、業務系の事務屋から見ると、
リリース後でもモジュール入替えが容易という見方をされてしまうんじゃないかって部分。おまけに、例えば20人でサミダレ式に作業しているプロジェクトで、役割分担により品質向上が図れる状況でも、
DIで何人減らせんねん?
というスタンスで10人体制になるとしたら、結果は以前と何も変わらない。
ロジックの完全分離によってそれぞれの役割が明確になり、テストも容易で品質も上がるはずなのに、一人の役割が倍になるだけという事態が想像できてしまう。

なんだかとっても面白い手法なんだが、ここいらの現場はまだまだ先の方がいいな・・・
(ちうかJavaは本業ではないのでどっちにしてもまだ先なんだが)

人と物

元日本サッカー協会会長の長沼健氏が亡くなった。
メキシコ五輪の監督だった人であり、良くも悪くも日本サッカーの顔だった人物である。

とりあえず「長沼健」でGoogle先生に尋ねてみると、こんなのを教えてくれた。

http://homepage1.nifty.com/moritake/doutoku/itiryu.htm

ネタバレしてしまうけれども、
あいさつと、整理整頓ができなければ何事もうんぬん。

どっちもだめだめなわたしゃぁ一流にはなれないっちうことで、残念。

しかし、こんなんでも三流の中くらいならなんとか頑張ってなれないことも無いのだ。
目指せ!三流の上!
って感じで生きてもいいよね、母ちゃん。(^^;

困った困った

この業界、フリーランス(それぞれ呼び名はあると思うが)でやってるといろいろ困った事が起きる。
ここの所は契約社員の流れ。

発注者側が個人への発注を認めなくなってきた。
これは、”責任の所在を明確にする”という理屈のようだ。

クライアントが発注した仕事は、一次受注者から二次受注へと投げられ、最後は末端の会社の社員や個人が実際に作業する、というのが普通の流れ。
これはどの業種でもだいたい似たようなもので。簡単に図にするとこんな感じ。
hbar1.jpg


本来は、それぞれの受注者が、その利益の中に”リスク”分を含めていて当然なのだが、このリスクが注目されてからは、
実際にはリスクを負う覚悟の無い中間が利益はそのままにリスク分を加える事が行われた。
hbar2.jpg


そして今回は、
末端作業者は末端会社の社員でなければならないという妙な指導が入った。
社員扱いとなると福利厚生分を末端会社は負担せねばならないのだが、会社が負担するわけもなく、当然、個人への発注額から差し引く。
hbar3.jpg


こう見ると分かるように、間に入る者は利益が確保され続ける
かといって中間には(リスク管理費をはねているくせに)リスクを負う覚悟はゼロで、契約内容からも納品検査の項目は削られ、瑕疵は全て個人であろうと末端が被る事が明記されるようになってきた。
皺寄せは全て弱い所に集まるのも世の常ということだろう。まぁこれも他業種でも似たようなもので。

この状況で末端個人として考えるのは、
  • 上位の請負へ食い込む。あるいは自身が中間請負となり、下流へ流す側になる。
  • 複数業務を抱え、薄利多売として利益を確保する。
  • 請負としての業務形式をやめ、製造物を販売する形式へ遷移する。(この流れから外れる)
  • 廃業する

のいずれかといった感じ。
どれをとっても末端作業者は減っていく。
これは中間業者にとっても痛手であって、品質は下がり信頼は地に落ちる。これも当たり前。結局”吸い取れるうちに吸い取れ”という企業倫理が先行して、自分の畑にクラスター爆弾を撒いているようなもんで。

プログラマっていうのは技術屋であって、基本的に起業家ではないので、自分の仕事がやりやすい環境を求めてふらふらする傾向があるので、そこそこ生活ができてやりやすいポジションにいるだけで満足するのだが、生活が厳しくなるようならそうも言ってはいられず。

とりあえずこんな馬鹿げた流れの中にいるとまともな感覚が保てなくなってしまうので、なんとか売り物が作れればな~、とは思ってるんだけれども、そういった商売の才覚があるわけでもないしな。

んー、と、考えるよりまず何でも作れ、って事なのかな・・・

IT業界で今食えてるってのも、”たまたま”趣味が当たったって感じだし、地球の未来を預かる立場でもないので、なんとか食って行けて、何かやり続けていればどうにかなるんだろうな。

とりあえず、マイペースを再確認。

---
あ、大事なのを忘れてた。
・相応の報酬が得られるよう交渉する。
ってのがまず最初だな。まずはそれから。
プロフィール

f_yamaki

Author:f_yamaki

アクセスカウンタ
最近の記事
最近のコメント
最近のトラックバック
月別アーカイブ
カテゴリー
ブロとも申請フォーム

この人とブロともになる

ブログ内検索
RSSフィード
リンク