- ねこのこべや -
- ねこのこべや -
速いもので1月もあっという間に終わってしまいました。 こうやって歳を取っていくのね、と思うとゾッとする気がしないでもないです。
速く感じるのは 今月はお仕事が忙しくってなかなか私生活に時間を割けなかったせいもあるのですが、 そのせいか、最近は人恋しさが爆裂状態で、なんだかさみしい、さみしい言ってます。
寂しいといえば、この前アップロードしました、 サンワサプライ フォースのレビュー、実はちょっとした仕掛けを 仕組んでありまして、 だれか掲示板で見つけて報告してくれるかしら♪ とウキウキノリノリだったのですが、 ・・・・誰からも報告がありませんでした。うう、、寂しい。
このまま放置は猫があまりにも寂しすぎるので、 すみませんが、どなたか「各部の詳細」の写真の上にマウスを置きながら 読んでみてください。(ああ、ネタが受けなかったお笑い芸人の気持ちがわかる・・・。)
いきなりつかみと全然違うことを書いてしまうのですが、 C#ってJavaのクローンじゃなかったのね、と思います。
えっと、話が飛びすぎですね。飛ばした所を少し戻って、順々に説明すると、 JavaとかC#とかはプログラム言語です。 もうちょっと詳しくいうと 「ヘビーウェイトなクラスベース・オブジェクト指向言語」という同じ仲間に 分類される言語です。
プログラム言語もいろんな落としどころがあって、その中の一つがオブジェクト指向言語なのですが、 そのオブジェクト指向言語のなかでも、PythonやRuby、javascriptは 変数に型を持たない「ライトウェイトなオブジェクト指向言語」ですし、 このうちJavascriptは「クラス」を持たない 「プロトタイプベース・オブジェクト指向言語」です。 一口にオブジェクト指向言語といってもいろいろな設計思想で作られていて、 それぞれに個性的です。
その中でもJavaは「比較的軽い」こと、 変数に型を持ち不正操作をコンパイル時に見つけられること、 それでいてガーベージコレクタを持ちメモリ管理を完全に隠蔽していることなど、 お仕事運用をターゲットとしたとても上手な落としどころで 多くの支持を獲得し、今や押しも押されぬ人気言語となりました。
一方のC#はMicrosoftが自称「C++の後継」という位置づけで作ったプログラム言語で、 その名前「C#」も「C++ ++」の「++」を二段にならべると「#」に見えるところから来ています。 しかしこのC#、中身は驚くぐらいににJavaに似ていると大評判(?)なのです。
もちろんまったく一緒というわけではなくて、 C#は後出しジャンケンの強みでより「改良されたJava」であることや、 実用重視のMicrosoftと、比較的ピュアさにこだわるJavaのアプローチの差も多少あります。 でも、後出しジャンケン部分はJava側も追随拡張を施してますし、 違いはあるといっても、 うーん、この違いはもう「方言」といってもいいかしら。 C#びいきの猫でも正直これじゃあパクリと言われてもしょうがないかな、と思います。(^^;
さて、まとめましょう。C# はJavaの代替え言語をねらった、Javaで受け入れられた堅実な手法で 仕様を形作っています。 言語自体は若くても、PythonやRubyなどの「より目新しい」改善は行っていません。
でも、猫はこれを悪いことだとおもってません。 もちろん同様のニッチェを狙って良く似ている言語に仕上げてきた、と言うのは本当のところです。 でも、それだけJavaの設計が巧みだったと言うことですし、 イルカとサメが似るように、同じニッチェに最適化すれば姿形もどんどん似てきます。 たんに堅実にJavaを模倣するだけでなく、そこに細かい心遣いを加えてある点にも好感が持てます。 そして同じゴールに向かってC#とJavaは競い合ってどんどん良くなって そしてどんどん似てきていくのかしらね、と思っていました。
でも、C# 2.0や Cω(C#ベースの実験言語)の新機能は、 C# 1.0のJavaライクな堅実な実装は、単なるスタートの足場固めだったのだと まざまざと見せつけてくれました。 う、ぅうむ、こりは、この実装の目指す先は明らかに「Javaのゴール」では無いわっ!
C# 2.0で追加された、無名関数や yield returnの実装は、興味深いものですが、 このアイデアははるかLispにさかのぼり、 そしてPythonなどのライトウェイトなOOPLも備えています。 アイデア自体は決して新しいモノではありません。 これらは、おそらくJavaが「まだ実装していない」ものではなく 「実装しないと決めた」ものでしょう。
またCωの SQL文やXMLをプログラム中で「文字列リテラル」ではなくて、 構文として記述できる対応などは、とてもMicrosoftのお鍋的文化を感じさせる面白いアイデアですし、 スレッドを意識させない並列実行の仕組み(メソッドの呼出方で、 実行完了まで呼出元が止まるか、呼出元と並列に実行されるかを決める) は、現在の「高級」のさらに上、「超高級」といってよい仕様です。
Javaのゴールはほぼ現在のJavaの姿であり、このバランスを崩さないで 進化しようとしている風に猫は思えます。いわば、「ここに素敵な家を建てようっ!」です。 でもC#のスローガンはきっと「Javaからはじめようっ!」 現在のJavaの姿をスタート地点に、もっと違う姿のゴールを見据えて ガンガン走っている様に感じます。
どちらが良いかという話ではありません。 「なんでもつけちゃえ!」が言語に深刻な影響を及ぼすことは C++で実証済みですし、現在のJavaのような言語は、 そういう姿を求める層が確実にいます。 ただ、少なくとも「C#はJavaのパクリだ」という論評は当てはまらなくなってきたと思うのです。
「想像は模倣から始まる」と言います。 確かにC#はJavaをクローニングして作りました。だけど双子は育て先が変わればまったく別人に育ちます。 上手にJavaの双子を作り終えた今、 C#はようやく模倣を終え、想像に踏み出そうとしている・・なぁんて言うと 格好つけすぎでしょうか?
注：猫はJavaにあんまり詳しくないので、的はずれだったらごめんなさい。
改めまして、あけましておめでとうございます。 なんだかとっても忙しくて、 それ以上に、どんな文章を書いてもトゲトゲしくなってしまって、 結局年賀状、年賀メールとも誰にも返事を出していません。 ・・ごめんなさい。
実は猫日誌も書けども書けども気に入らない文章が続いていて、 掲載を見送っていたのがいくつかあります。 そんな中の一つ、11月の猫日誌の「センス・オブ・プログラミング! を弄ぶ」 をようやくアップロードすることが出来ました。 (良い文章になったから、じゃなくて、あきらめたからなのですが・・・)
そんなわけで、アップデート報告と心残りの解消をかねて、 もう一度 センス・オブ・プログラミング!を弄んでみることにします。
センス・オブ・プログラミング!は、読んでいると 些細なことに突っ込みたくなる本です。 それはプログラマの矜持に訴え、こだわりのコアに触れる 内容だからでしょうか、 猫もプログラマの端くれとして、至福の重箱の隅つつきを楽しませて頂きました。
さんざんつつきまくっておきながら、なんだかちょっとつつき足りない気がします。 せっかくだからもう一回つっついてみようかしら(笑)
猫はコメント大好きっこなので、ここには反論を唱えたいところでした。
コメントは必要悪だ、という論は一大勢力を誇るモノですが、 それは「ポインタ必要悪論」と同じコトだと思います。つまり、強力すぎるものは 悪になりやすいという次元でしかない、と猫的には考えています。
「処理」を人間に読める形で記述するのが「プログラムソース」の役割の一つですが、 この役割に於いてコメントは強力すぎます。 特に、誤ったコメントの破壊力の強さ、コメント修正のコストの高さ、そしてなによりコンパイラやlintが 誤ったコメントを警告してくれないという、「機械が正しさを証明してくれない」という 難点が、コメントを悪とたらしめるのでしょう。
しかし、便利だけれど強力すぎるものを上手く脆弱化して使いやすくする試みは プログラムの世界ではよくされることです。goto文然り、ポインタ然り、とくれば、 コメントも実はそうで、 近年のコメントは決してコンパイラやインタプリタなどの処理系が無視する物では 無くなってきています。
具体的には javadocや pydocのような埋め込みドキュメント としてのコメントが一般的になってきていて、 コメントといえども文法を持つようになってきてきます。
javadocは、
/**
* 猫ニュース1件分となるクラス。
*/
class NekoNewsNode{
・
・
の様にjavadocの書式(「/**]」で始まるコメント)でプログラムの構造の前に コメントを入れるとそこからドキュメントが作れたりする仕組みです。 便利ですよね?
javadocは有名だけれど比較的原始的で、 これをもうちょうっと推し進めて、 オブジェクトまでがコメントを持ち回るようになっているものも登場しています。
この例がpythonのpydocで、 pythonではオブジェクトに隠しメンバ__doc__が用意されていて、 pydoc書式でコメントを記述するとpythonインタプリタはここにコメント文字列を格納してくれます。 つまり、pythonオブジェクトは、実行時もコメントを持ち回っているわけです。
この仕組みがあるお陰で、pydocは単なるドキュメント作成ツール用埋め込みコメントの枠を越え ユーザI/Fの一部としても機能させることが出来ます。 python製Webアプリケーションサーバ「ZOPE」では、 ページ表示にこのコメントが利用されてるなど、 決して「実行時には無視される」存在ではありませんし、そのコメントは 開発者だけではなく、アプリケーションユーザも利用します。
コメントはその登場以来進歩していないようなイメージを受けますが、 実はこのように大きく進化し続けているわけです。 (リソース食いだから、ガベージコレクタと同じく、 コンピュータの性能アップでようやく実現できた、という見方の方が正しいかしら)
ただ、気をつけたいのはここでも間違ったコメントはそのままスルーすることには変わりない ということです。 結局、コメント必要悪論とは、プログラマのプログラムに対する姿勢の差かな、と思います。 「ソースは限られた人間(プログラマ)にしか読めなくて良い」と思っているか 「ソースは作れない人はいる。でも万人が読めるようにするべき」と思っているか、の 違いかなぁと思います。
センス・オブ・プログラミング!を読んでいて一番思ったのは、 「ひょっとして前橋さんって 構造化プログラミング を読んでいない?」ということです。
センス・オブ・プログラミング!の全体は非常に構造化プログラミング的なことが書かれているのですが、 「構造化プログラミング」という言葉に対しては、どうも「三大制御構造で書かれたプログラム」と 誤解を受けそうな表現なのよね、と感じます。
「実は(わかりやすさのために)ワザと?」とか考えたりもするのですが、
しかし――実のところ、いまの時代、構造化プログラミングをことさら意識する必要はないでしょう。 いまどきのまともなプログラミング言語を使えば、特に意識しなくても自然に構造化プログラミングになるからです。
の下りは、それは間違いであると言わずには居られません。
ダイクストラさんは、構造化プログラミングの冒頭で、 構造化プログラミングの目的を、以下のような順を追って 解りやすく説明しています。
■良いプログラムとは →・正しく動く
・正しく動くことを容易に証明しうる
であり、一方大規模プログラムでは
・人は規模が大きくなるとそれだけで理解できなくなる ・大きな規模のプログラムは実行結果を見て正しく動くと証明できない (全てのパターンを網羅するのは不可能だから)
と言う問題があります。そして、
実行で正しさを確認できない → プログラムの中を見て確認するしかない。 ∴ならば良いプログラムとは → 人が解りやすい構造をもつプログラムである。
そのための具体的な方法として、 構造化プログラミングでは段階的詳細化を掲げています。
つまり、構造化プログラミングとは、 人間が容易に論証できる様に、 人に解りやすい段階的に詳細化するよ構造をもつ プログラムを書きましょう 、、ということです。
じゃあ、例の三大制御構造云々とは、なんなの、というと、 段階的詳細化をされた(つまり自由度を奪われた)プログラム手法が 旧来のプログラムと同等の物が記述可能であることを証明した 構造化定理という 「手段」を目的とはき違えて流布してしまったものだったりします。 (それだけ「gotoいらず」、のインパクトが強かったのでしょう)
――と、いうわけで、猫は構造化プログラミングにも思い入れが強いため、 「順次(順接・連接・concatenation)」「選択(分岐・selection)」「反復(繰り返し・repetition)」だけでプログラムを書いても それだけで構造化プログラミングになるなんて大間違い! というのは主張しておかなくっちゃ・・と思いました。
でも、センス・オブ・プログラミング! は「構造化プログラミング」という用語の使い方こそ 「???」なのですが、本全体としては構造カプログラミングの本質をよく説明しているため、 ま、細かいコトかしら、とは思います。
これは、猫も外観しか理解してないのに偉そうなことを言っています。 猫の知識もDBエンジニアと意思疎通を図るための知識、と言ったレベルでしかありません。
ただ、
しかし、構造体とポインタによるデータ構造になれた人は、こう思うのではないでしょうか。
「部コード」なんかじゃなくて、「部」へのポインタを持つべきなのでは?
正論です。しかしリレーショナルデータベースでは、それを直接表現することが出来ません。
のくだりには、全国1億8000万のDBエンジニアの皆様が、 「そのポインタを苦労して追い出したんじゃねーかよぉ・・」 と突っ込みを入れる姿が思わずまぶたの裏に浮かびまして、(^^;) 猫もつなない知識で突っ込ませていただきました。
さすがに知識不足でミイラ取りがミイラになった感もしないではないですが(^^;)、 本文中でもオススメした リレーショナル・データベースの世界さんへの 誘導を出来るだけでも世の中に有意義かしらね、と思ってたりもします。
センス・オブ・プログラミング!ですが、 はっきり言ってリレーショナルデータベースの項だけは、「とんでも本」に足をつっこんでると 思います。特にサブタイトルで「抽象的に考えること・データ構造を理解すること」と 唄っている以上、文調が ロケーションというより抽象的でない概念の方に誘導するものであるのは、 悪だわぁ、と思います。
まず一つはフローチャートについて。
確かにフローチャートは強力すぎるので、 設計の道具としては適切ではありません。(これはずっと昔からの常識です。) しかし、それにしたって 前橋さんのフローチャート批判はちょっと偏ってるんじゃ、、と思います。
例えば「設計の段階でフローチャートを使うとgoto文使いまくりのスパゲティプログラムになってしまう」、というのは それはフローチャートのせいじゃないんじゃ、、と思います。 そのスパゲティはフローチャートの時点でスパゲティ化してるはずなので、 逆に絵を描く際に線を書くのがとても大変になり、 結果まずいプログラムを視覚化してくれる・・・というのが猫の考えかたかしら。 こんがらがったフローチャートをみて、それが設計として大丈夫と判断するならば、 ダメなのは設計者さんの頭の中身の方じゃないかしら。
また、「フローチャートの位置づけ」で、
脳内にあるなんだか
もやもやしたもの
↓
設計書
↓
ソースコード
↓
コンパイラ
↓←──────フローチャートはこのあたりに位置する
機械語コード
は、いくら何でも違うでしょう、と思います。
確かにコーディングの図形版であるフローチャートは プログラム言語と同等に何でも書けちゃう強力さがあるため、 とても抽象的なものも、高級言語より低級なものも書けてしまうのは確かなのです。 でも、 普通の書き方をしていて、ターゲットとなる言語よりも低レベルになるとは、 猫にはとても思えないのです。
「箇条書き設計」を出来るということは、フローチャートでも設計は可能です。(あくまで可能・不可能論ですが) また、誰もフローチャートだけで設計するなんて言ってないのに、 欄外の注釈までフローチャートを否定するための論理を展開する姿に、 前橋さんってフローチャートに対して トラウマがあるんじゃないかなぁ、、なんて思います。
これは年代の差で、 猫が若輩だから、構造化されたフローチャートしか見ていないせいなのかもしれません。 前橋さんがどれだけ恐ろしいフローチャートの設計を見てきたかを想像するだけで、 猫は逆毛だってしまいます。
ちなみに猫はフローチャート、そこそこ使います。 ただ、設計の道具ではなくて説明の道具、 自分の考えをまとめる為ではなくて、処理の詳細を視覚的に相手に説明するためです。 機器の制御などの場合、制御によって人を怪我させてしまう可能性があり、 クライアント共々指で追って処理の流れを確認できるフローチャートは有意義、 と実は思っていたりします。
ただ、これもUMLが読めるクライアントが増えてきた為、 アクティビティ図に取って代わられて来ているのが猫の現状です。
もう一つは処理の流れを目で追えるため、 猫は、新人研修ではいきなりコーディングさせずにフローチャートを書かせています。 (ああ、「え〜〜っ」という声が聞こえる・・(笑))
もちろん「ぜ〜ったい、設計につかっちゃダメ〜っ！」、と必ず但し書き付きで、 しかも手書き限定(考えてから書かないと書き直しになるというペナルティをつけるのです)ですが、 そもそも制御構造に不慣れな入門者に、 多重ネストのスパゲティ度を見た目で理解させるのにいいかなぁ、と思ってます。
これは猫の(というか制御系の)特殊事情ですが、 プログラムに不具合があったからと言って、時と場合によってはassert()で死なれてもらっちゃあ 困るのよね、と思います。
例えばモータ制御中になにがしかの不具合ルートを通った場合、 そこでアサーションされてしまい、プログラムが落ちてしまうと そのモータは永遠に回りっぱなしです。 それによって装置が暴走し壊してしまいかねない場合であれば、 アサーションにより処理が止まってしまうのは困ります。
もちろん「バグ」を検出する仕組みをプログラムに入れることに 反対してるわけじゃありません。 どちらかといえば、ですが、アサーションという言い方よりも 事前条件・事後条件、、なとどいった考え方を教えて欲しかったということもあります。 まあ、これは完全に「重箱の隅」ですね(^^;
ハンガリアン記法は、変数名に型情報を埋め込む命名規約です。 センス・オブ・プログラミング!では、好き嫌い論でサッと流されてしまっていますが、 ハンガリアン記法が生まれた背景にはC言語が、 特殊な言語である、ということがあります。
面白いことに、C言語は変数に型があって値に型がありません。 Cでの値はあくまでビットパターン以上の物では無くって 変数に入れたとき、その変数の型により、そういう型として扱うようになります。
だから、ハンガリアン記法の 「変数名に型の情報を持ち回る」という手法はCの世界ではそれなりに有効です。 変数が名前と一緒に型の情報を持ち回ることで、 プリフィクスの示す型とデータの受け渡しの不一致を水際で発見しやすいのが ハンガリアン記法の最大のメリットでしょう。
もちろんそんな記法よりも名前付けで区別できるようにするほうが良い、 という意見もあり、ハンガリアン記法の有効性にハテナが付くのを否定しません。 またJavaやC#のようなオブジェクト指向言語では、 オブジェクト(値)が型の情報を持っているし、 どこまでをプリフィクスをすべし「型」とするかも難しいので、ハンガリアン記法は運用にマッチしません。 (というか、殆ど意味がないことです。)
・・・・ということを、ついでで良いから書いておいて欲しかったです。
インデントは・・宗教問題です。 というか、なれたインデントスタイルをプログラマは図形として認識しているため、 高速にソースを読むことが出来ますが、 なれていないと、図形的に読めなくなるため、とたんに読みにくく感じます。
中括弧「{」にまつわるC系言語のスタイルは自由度がありすぎて、 それは言語としての欠陥と言って良いかと思います。 「C」は生い立ちを考えるとそれで良かったかもしれません。Cと互換を持たなくて良いJavaやC#ですら そういうのを引き継いでいるのはどうかなぁとおもいます。
Javaの場合、K&R第二版のサンプルコードのようなスタイルが標準となっています。 前橋さんは「つまらないこだわりを持つな」といいつつも、 JavaにGNUスタイル等を持ち込のは迷惑だ、と言っています。 一般化した様な微妙な言い回しですけれど、なんだか、うん、こだわりを感じます。(笑)
真面目な話、Javaの世界で共通のスタイルを守らせたいのなら、文法で縛ればいいのです。(CurlやPythonのようにです) 逆に自由度を与えるということは、選択の余地をプログラマに与えていると言うことなので、好きに選べばいいのです。 大切なのは、チームで同じスタイルを守ること。それだけだと思うのだけれど。
猫の個人的見解としては、よく言われることと一緒、 チームで開発するときは、特に事情がなければ、開発環境や標準ライブラリの使ってる規約に従います。 でも、チームがあるスタイルになれきってる場合は生産性と天秤にかけます。 そして、個人で書く場合には、自分のスタイルにこだわります。
あけました。
| 三猫 |
あけましておめでとうございます。三猫OnLineももうすぐ丸3年です。 最初からおつきあいされてた方も、最近おつきあいをはじめた方も、 ご愛顧ありがとうございます。今年もよろしくですよ〜♪ |
| たま |
あけましておめでとうございます。(にっこり) |
| 三猫 |
げげ、たまちゃん、、どうしてここに。 |
| たま |
うふふふ、ど〜こかに、年末2ヶ月ばっかり、ろくな更新しない子がいるって 聞いたからね〜。 |
| 三猫 |
いあ、でも、それは・・・。本業が忙しくなったからで、 本心では、あたしも更新したくてしたくてしょうがなっかったのですよ。 ええ、不可抗力ですにゃ。 |
| たま |
・・・コミケ、 |
| 三猫 |
(びくぅ) |
| たま |
・・・には、いってたのよねぇ・・・。 |
| 三猫 |
(えぅえぅ) |
| たま |
説明なさい。 |
| 三猫 |
こ、コミケはあたしの命ですっ! 命を最優先にして何が悪いんですにゃっ!! コミケいけなかったら死にますよ、あ、た、し、はーーーーっ! きーーーーーっ!!! |
| たま |
逆ギレかい・・。 |
| 三猫 |
えっと、とにかく忙しい年末だったんです。 もう、10月からいっぱいいっぱいだったんですが、 特に年末は酷くって、 コミケ直前に 出張を命じられた時は、 もう、コミケ皆勤も25回目にしてついに崩れるかと思いました。 |
| たま |
ま、それが社会人のつらさよね。 |
| 三猫 |
いあ、あたし思うんです。仕事とコミケを両立するって 頑張ればできるって。 「体調悪いので午前中だけ医者にいく」とか言って コミケに行ってコミケ会場から出社 したりですとか、 丁度出張に出る日がコミケ最終日だったから、 会場から羽田に飛んだですとか、 いろいろチャレンジしたんですよ〜。 |
| たま |
そういや、一度昼間コミケ・夜仕事とかやって 倒れたことあったけ、三猫ちゃん。 |
| 三猫 |
はいな♪ でも倒れたのはちゃんと三日目完了後ですよ〜(^O^)/ |
| たま |
そこ・・・ニッコリわらうところじゃないから。 それに両立できてないし。 で、今回は出張で連れ去られちゃったそうだけど、 どうしてコミケ参加できたの? |
| 三猫 |
なんで、出張になったかというと、猫のプログラムの動く装置が、 ソコにしかなかったからなんですよ。 |
| たま |
ふむふむ? |
| 三猫 |
で、その装置が壊れちまえばやることは無くなるわけでして。 必然と出張打ち切りになるわけです。 年末だから年明けなければ修理できませんしね〜。うふふ。。 |
| たま |
!? 三猫ちゃん、あんた、まさか・・。 |
| 三猫 |
いやですよ〜。まさかそんなコトするわけないじゃないですか。 ほら、アレ、 きっと日頃の行いがよいから、神様がご褒美にぶっ壊してくれたにちがいないです。 |
| たま |
・・・・やな神様だ。 |
| たま |
で、どうだった。コミケット。 |
| 三猫 |
そりゃあもぅ、そりゃ〜もぅ愉しかったです。 惜しむらくは1日目のカタログチェックがろくに出来なかったことです。(TT) ・・・会場で朝並んでる間にやろうと思ったのですが、 雨がザパザパで(TT) |
| たま |
三猫ちゃんは、同人誌買いまくりっ子だからねぇ。 で、なんかいいのあった? |
| 三猫 |
うーん、飛び抜けて「これはっ!」というのは無かったのですよ。 やっぱり2日開催だから、ほら、いつもより1日たりないでしょう? サークルに厚みがない感じでした。 |
| たま |
ふーん。じゃ、コミケのお話、これで終りね。(ニヤ) |
| 三猫 |
いあいあ、今回は本とは別にとっておきがあるのですよ〜。 |
| たま |
脇目もふらず本を買いあさる三猫ちゃんに、「本とは別」があるとは思えないなぁ。 |
| 三猫 |
(ぐっ・・)一つは PSPがムービーサークルさんのプレイヤとして結構広まりを見せていたことです。 ほら、いままでそういうサークルさんってノートパソコンとかで頑張ってらしたけど、 場所は取るし電池は持たないしだったでしょ。 安いし、そこそこ電池は持つし、手頃なサイズだし、画面綺麗だしで、 今後は標準として根付くかも、です。 |
| たま |
いやあ、オタクさんって新しもの好きだから、 単なるそれだけかもよ。 |
| 三猫 |
(ぐっ・・)、もう一つはニンテンドーDSです。 ほらほら、あれって「ピクトチャット」が付いてるでしょ。 |
| たま |
ついてるねぇ。宇多田さんがCMやってるやつ。でもあんなのありえないよね。絶対 |
| 三猫 |
そうなんです。いろんなレビューでも、「ピクトチャットをONにして待ってみたけど 誰も参加しない」ってなってました。(TT) 猫も「ああ、あれは使わない機能No.1かしら」なんて思ってました、が! |
| たま |
コミケで使ってる人がいた、と。 |
| 三猫 |
そうなんです〜♪サークルの売り子さんが コレ使ってるのが多くって、本を買う傍ら、 売り子さんが置いたDSをのぞき見るとピョコピョコけっこうな頻度で着信してるのですよ〜 |
| たま |
なるほどね〜。絵描き多し。場所動けない人多し。ハード普及率高し。三拍子そろってるわ。 |
| 三猫 |
そんな風景を何カ所もの島でみると、ああ、ドコでも使わないと思ったけれど、 こんなピッタリの場所があるのねってしみじみ。 |
| たま |
ふむふむ。 |
| 三猫 |
なんかもうとても愉しそうでうらやましくって。 いわばあれって、ブロックノートの進化版じゃないですか。 IT革命ってすばらしいな、というかニンテンドーは同人屋さんのためにこの機能を盛り込んだと、 突然解ってしまいました。 |
| たま |
解ってしまったって、いやいや、あんた、また凄い電波がにじみ出てるというか・・。 |
| 三猫 |
しっかり充電しましたからっ!! |
| たま |
・・・。 |
| 三猫 |
そのほかにもギター侍がなにげなく流行っていたりとか (「こんなに並んだけど、もう、売り切れましたから〜っ!残念っ!!」とか、 某同人誌で、酷い落ちのコマの下に「ネタが浮かばないのでむしゃくしゃしてやった。ページが埋まればなんでもよかった。今は後悔している。」とか が個人的には面白かったです。 |
| たま |
題無視してコミケの話、続けないでよ・・。 |
| 三猫 |
じゃ、じゃあ、仕事の話かな。 最近仕事とコミケの他はなぁんにもありませんでしたから。 |
| たま |
寂しい年末年始ね・・。 |
| 三猫 |
ほっといてください(TT) 猫は今は立派なファームウェア屋さんなのですが、 開発言語はCで、オブジェクト指向はまったく関係のないお仕事です。 |
| たま |
まーねぇ。組み込みLinuxとか、組み込みオブジェクト指向とか、 そういうのの担当に、なぜか成らなかったからねぇ・・。 |
| 三猫 |
あ〜、、。担当に成らなかった件は良いことなんです。 横にOOチームがいるのですが、誰もオブジェクト指向を知らない、 横紙破りは居る、と絶対トラブル事請け合いのチームですから。 |
| たま |
・・・(^^; そんなに酷いの? |
| 三猫 |
ええ。UMLとXMLは同じようなモノと言っているおじさんが 旗振ってますから。 |
| たま |
うあぁ・・・・。 |
| 三猫 |
それはおいといてね、オブジェクト指向にドップリ浸かってから、 こういう昔ながらの構造化プログラミングの世界でも、 オブジェクトチックな考え方するようになったなぁ、と。 例えば、シリアルポートのアクセサ関数群を定義するときにね、 良くある方法は 引数に「SIO番号」なんかを持たせて、 その番号をキーにアクセスするレジスタのベースアドレスを切り分けたりする処理は 定番なのだけれど、それが気持ち悪く感じるようになりました。 |
| たま |
ふみふみ |
| 三猫 |
気が付けば、ファイルをクラスに見立てて、 フィールドに相当する構造体を作ったりしてたり。 気が付けば「エセオブジェクト」を見つけようとしてしまうのですよ。 あと、もう一人Java畑の人がチームにいるのだけれど、 その人とのコミュニケーションにUMLをよく使いますね〜。 なるほど、Language言うだけあって、双方が知っていると かなりスムースにお話できます。 |
| たま |
いああ、一般の読者さん置いてけぼりだよ。 |
| 三猫 |
あ、あうあう。そうですね。 ん、と。複数のパラダイムを知っているというのは、 一つのパラダイムだけを深く深く極めるのとはまた別に、 広い視野が持てる・・ってのを、実体験したというか、 無駄になるモノなんてないのよね、というか。 ま〜、勉強って愉しいですってコトです。 |
| 三猫 |
ところで たまちゃん。 |
| たま |
なぁに? |
| 三猫 |
きょ、今日の落ちはないのですか・・? |
| たま |
あー、お仕置きタイム。・・・・してほしい? |
| 三猫 |
め、滅相もないっ! |
| たま |
ふふ、ま、今日はね。なぁんにも言わないしやらない。 聞き手役だからね。 |
| 三猫 |
(ほっ) |
| たま |
最近、あんたの話つまんないし。 なんか、Zガンダムでのシャア? というか、クロノクル=アシャー? 今回の対談だって、それこそ 「ネタが浮かばないのでむしゃくしゃしてやった。ページが埋まればなんでもよかった。今は後悔している。」 じゃない。 もうね、駄目な子はかまっても駄目なのよ。 |
| 三猫 |
えっ？、た、たまちゃん? |
| たま |
じゃあ、そう言うことで。 みなさま、今年もよろしくおねがいします。 三猫ちゃん、ばいばい〜♪ |
| 三猫 |
ちょ、ちょっとまって、たまちゃん。、、見捨てないで〜〜〜〜。 |
| SEO | [PR] おまとめローン 花 冷え性対策 坂本龍馬 | 動画掲示板 レンタルサーバー SEO | |
