2006-10-10

http://d.hatena.ne.jp/openpne/20061001/1159726262
http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/
ちょっとだけご無沙汰だったわね。あたしは元気だったわ。あんた達はどうだったかしら？

最近多い「小ネタ」シリーズ。本日の御題は「オブジェクト指向」よ？
いい加減この辺に耳や頭を傷めてる殿方も沢山いらっしゃるんじゃなくってかしら？
たまたま見つけた二つの素敵な文章をちょっと紹介してみるわね。準備はよろしくってかしら？

まずは、先日 http://d.hatena.ne.jp/Lucrezia/20060913#p1 で紹介差し上げた、素晴らしい理念*1をお持ちでいらっしゃるOpenPNEの開発ご担当者様のPageからご紹介いたしますわ。

http://d.hatena.ne.jp/openpne/20061001/1159726262 より
classを使うか否か
classを使うか否かも議論に出たんですが、
「また今度にしよう」と2.6ではとりあえず見送り。

まぁすごい英断だわぁ。昨今、ヘタしたら「オブジェクト指向知らなきゃプログラマじゃないよね」くらい言われかねないこの業界でこれだけ正面きって真っ向から向き合って反論なさるんですから、きっと素敵なご高説があるに違いなくってよ？
さぁこれを読んでるあんた達、しっかりと素晴らしいメッセージを読み取るのよ？

http://d.hatena.ne.jp/openpne/20061001/1159726262 より
xoopsとかeccubeとかのソース見てみたんだけど、
class使うのめんどくないすか？
なんかオブジェクト作って、どうこうとか。
下記に各アプリのメール送る処理を抜粋してみたんだけど、
関数一発で呼べた方が簡単じゃないすかね〜
どすかね？

大切だわねぇ。プログラマにとって「面倒ごとを避ける」ってのは、とてもとても重要な事だわ？
昔から「怠惰はプログラマの美徳の一つ」って言われているくらいですしね。
それにしても…サンプルコードがまたなんとも言えず素晴らしいわ。とにかく見て頂戴？

■openpne
$params = array(
"c_member" => db_common_c_member4c_member_id($c_member_id_invite),
"sid" => $session,
"invite_message"=> $message,
);
return fetch_send_mail($pc_address, 'm_pc_syoutai_mail', $params);

まぁ素敵とても簡単に記述できるのね？
確かに「関数一発で簡単にcall」出来てらっしゃるみたいですし。とても素晴らしいことだと思いますの。
もちろん、コレをご覧の、極々一部の、統計的には無視してもかまわない程度の微細な割合の方々が「ほかのXoopsとかのサンプルと設定してる情報量違うから比較にならねぇじゃん」とか「ハッシュ配列に設定してるんだからかわんねぇじゃん」とかっていう呟きをなさらないとも限りませんわ？
或いは、心配性も度を通り過ぎて病的なくらいにまでいっちゃった方々が「メソッドなら名前間違えてもわかるけどハッシュ配列で名前間違えたらバグ探し大変なんだぞ」とか叫んでらっしゃる声が聞こえなくもありませんの*2。
でも、この「ハッシュ配列に設定したらなんとなく色々変更もしやすくて便利だよ」的手法は、Perlのころからの素敵な手法だわ？これは素晴らしい手法だからちゃんと覚えておかなきゃダメよ？*3

或いは、もうちょっと別の、頭ん中が机上の空論でうまってるような方なら、こんなことをおっしゃるかもしれないわ？
「継承とかmultiple instanceとかpolymorphismとかの利点全部把握した上で言ってるのか？」
あらあらダメよいきなりそんなに相手のこと決め付けちゃ。
もちろん、あたしだってデータの隠匿性とかデザインパターンまで絡めたあたりの便利さ加減とか気にならなくもないわ？
でも、きっとそれらすべてを「熟知して研究し尽くした結果」として、きっと彼らは「classを使わない」って結論になったにきまっているわ？
まちがっても、そこらへんの凡百っていうかボンクラな連中にありがちな「生兵法でかじってみて美味しくないから使えないって勘違いしてる低脳な愚者集団」ではないはずだわ？*4

きっとこれからも、非オブジェクト指向的なプログラミングで、素晴らしく有意義で価値のあるソフトウェアを組み上げて行かれるのね。それはとても有意義で素敵なことですわね。
あたくしとしては…なんていうのかしら…騙される大勢の方々に心からお悔やみを差し上げますわ。

そうして、そんな風にオブジェクト指向が隆盛な中で*5。これもまた素晴らしい名文*6が登場いたしましたの。

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/ より
初心者がJavaを“超高速”で学ぶためのコツ

素晴らしいわぁ。大抵「時間を踏み潰して作ったもの」に大抵ろくなものはないんですけれども。
でもきっとIT Pro様の記事ですもの。きっと一味も二味も違ってよ？ *7

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/ より
皆さんの中には，「いまどきJavaくらいできなきゃねぇ〜」と言われてからもう何年も過ぎちゃった…なんて人も多いのではないでしょうか。いつ何時「新しいプロジェクトはJavaでいくから」なんて上司に言われたりしないか，内心ドキドキしてる方もいらっしゃるでしょう。私が受け持つJavaの授業でも，受講生の方からそういった悩みをよく聞きます。

あらあら。筆者様は講師の方なのね。素晴らしいわ教える事を生業にしていらっしゃるだなんて*8。

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/ より
なぜJavaの学習がなかなか進まないのでしょうか。残念ながら「Javaのスキルが上がらない」という方の多くは，「データとアルゴリズム」「Javaの文法」「オブジェクト指向」の三つをきちんと学べていないようです。

そうねぇ。よく言われる話なんですけれども。「プログラミング」そのもののお勉強とかってのは、言語の勉強よりもはるかに圧倒的に大切なものなのよね？*9

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/ より
特にやっかいなのが「オブジェクト指向」です。Javaの文法はオブジェクト指向と密接に結びついているため，「卵が先かニワトリが先か」――「オブジェクト指向を学ぶのが先か」「Javaの文法を学ぶのが先か」――という問題に直面するのです。

あらあら。それは大きな勘違いだわねぇ先生様も大変だわねぇ。
まず「考え方としてのオブジェクト指向」を理解して。文法なんてのは二の次三の次でよろしいでしょうに。そんな区別もつかない人を相手にすると本当に大変そうだわぁって思いますの*10。

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/ より
この問題を嫌う講師の中には，「先にC言語などの勉強をはじめた方が効率がよい」という方もいます。しかし，この意見には少し異論があります。なぜなら， C言語のエキスパートがきれいなJavaプログラムを書くとは，必ずしも言い切れないからです。つまり，C言語の先入観が，逆にJava言語の習得に足かせとなることがあるのです。

これはかなり難しい問題だわねぇ。
現実問題として「C言語をしっかりとなさってる殿方の多くがオブジェクト指向で躓く」事実は、これは存在いたしますの。
結局のところ「オブジェクト指向ってのが裏側でどんな風に動いているかが分からないから組めない」っていうのが一番初めの躓きね。あたしを含む何人かはこれを「C言語でクラスを実装する」ことで克服したわ？*11
次に躓くのは「やっぱり無駄が多いと感じてしまう」。…これはちょっと難しいのよねぇ実際オブジェクト指向プログラムってある程度「無駄の多い」ものですし。
ただ、その無駄の変わりに得られるものに気づけばいいんですけれども…ってのがあるわね*12。
っていうあたりを鑑みてのご発言なら、それは素晴らしい慧眼だと思いますの。ええ本当よ？

次のPageに行ってみるわね？

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=2 より
◆ STEP1
クラスとインスタンスの違いをイメージとコードで理解しよう

あらまた大事なところ来たわねぇ。そうねぇこの辺の理解って重要よ？

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=2 より
Javaを超高速に学習するには，「オブジェクト指向におけるクラスとは何か」を考えずに，まずはメモリー上のプログラム領域として「クラス」と「インスタンス」を理解するようにしてください。

まぁ素敵。さっそく引っ掛け問題ね？
そうねぇ…間違えているのはまず「「オブジェクト指向におけるクラスとは何か」を考えずに」の部分ね？
基本的な思想をはずした状態で物事を理解しようとしても、それは無駄が多いだけじゃなくて間違える可能性も随分と高くなってしまってよ？
ええもちろん初歩的でごくごく当たり前のことだとは思いますし、こんな簡単な引っ掛けに引っかかる人もそうはいないと思うんですけれども。
あとは…ここね。「メモリー上のプログラム領域として「クラス」と「インスタンス」を理解するように」。
インスタンスは当然メモリ上のものですけれども、クラスはただの設計図ですから、この表現は明らかにおかしいんですもの。
でも…これは確かに、クラスとインスタンスとの違いをちゃんと認識していないと引っかかってしまうかもしれなくってよ？まぁ随分と怖い引っ掛け問題じゃなくってかしら？こんなハイレベルな方がいらっしゃっただなんて…ちょっと惚れてしまいそうよ？ *13

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=2 より
「クラス」とは「変数（フィールド）」や「メソッド」をひとまとめにした，一つのプログラム単位でしかありません。そして，その部分だけ言えば，クラスとインスタンスに大きな違いはないのです。では，クラスとインスタンスはどこが違うのかといえば，それは「生成のされ方」または「性質」が違うということになります（図2）。
「クラス」といった場合，そもそも元になるものは，拡張子.classでできたクラス・ファイルです。そして，プログラムの中でクラスにアクセスすると，このクラス・ファイルが読み込まれて，メモリー上に配置されます。これに対して，インスタンスの方は，すでにメモリー上に配置されているクラスから生成され，クラスとは別の領域に作られます。このとき注意する点として，クラスは一度クラス・ファイルから読み込まれてメモリー上に配置されている限り，同じクラス・ファイルが別に読み込まれることはありませんが，インスタンスの方は，メモリー容量が許す限り，クラスから同じものを複数作り出せる点にあります。

あら。なるほどさっきの引っ掛けはここで二度も三度もしつこいくらいに出して「いい加減気づけよ変だって」って言ってくださっているのね？
ちょっと甘い感じがしないでもないんですけれども、でも優しい男ってのも悪くはないとおもうわ？
図の中にある「クラスはクラス・ファイルから生成される」って書き方も「言語仕様とオブジェクト指向を混ぜると危険だ」っていうことへの再三の警告なのね？

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=2 より
【超高速ポイント】
クラスとインスタンスは，共に変数とメソッドをまとめた単位でしかない。その違いは，クラスがクラス・ファイルの読み込み後に唯一つだけ生成されるのに対して，インスタンスはその生成されたクラスから複数生成できる点にある。

これは…わかったわ？これはあたし達の「ツッコミビリティ」を試しているのね？
さぁあたくしのために存在する道化たち、ちょっとやって御覧なさい？

道化１：「クラスがクラス・ファイルの読み込み後に唯一つだけ生成されるのに対して」
道化２：「それはクラスの読み込み云々じゃなくてGoFのSingletonパターンやんけ。だれが騙されるかい！！」

ちょっとストレートに過ぎるんですけれども。まぁよしとしてあげても「よろしくってよ？」

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=2 より
まず(a)のクラスAでは，変数（フィールド）やメソッドにstatic修飾子が付いています。つまりこれらは，クラス変数やクラス・メソッドで「クラス側」に作られます。

まぁ随分と細かい部分にまでひっかけを残してくださっているのね？
これは「static修飾子に関する知識」がないと難しそうね？*14

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=2 より
【超高速ポイント】
　クラスはメモリー上に一つだけ生成される。その利点を最大限に引き出すクラス変数，クラス・メソッドを作ること。

やだわぁ先生様ったら。こんなところまで、微に入り細に入り地雷しかけなくてもいいんじゃなくってかしら？

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=2 より
図4●Integerクラスのクラス・メソッドとインスタンス・メソッド

ここもそうなんですけれども。きちんと生徒さんが「クラスメソッドじゃなくてstaticメソッドないし静的メソッドですよね？」って突っ込まないと、閻魔帳にでも書かれてしまうのかしら？
お気持ちが分からないでもないんですけれども、ちょっと地雷の数が多すぎやしませんかしら？
でもまぁここでへこたれるのもオカマがすたるってものよね？
次頑張ってみるわ？

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=3 より
◆ STEP2
配列を正しく学ぼう

あら。配列はそうねぇ基本の一つだわねぇ。

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=3 より
たいていのJavaの入門書は，配列に対して，どうも歯切れがよくありません。その理由として，配列がインスタンスであることや，Javaでは多次元配列のインスタンスが作れないことなどが主な原因ではないかと，私は思っています。そのため「Javaでは多次元配列のインスタンスを作れません」と言うと，いまだに驚く人がいます。

ここは…やっぱりcontainer関連のお話にまで持ち込まないといけないのね？
それとも…まさかjava.utilのcontainer関連のクラスとあちこちのframeworkのcontainer系のクラスとの差異とかにまで言及しなくてはいけないのかしら？
まぁ多次元配列関連のお話が「ここで簡単に片付く」って話は絡めるとして、なんですけれども*15。
あとは…ここかしらね。

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=3 より
Javaの配列を理解するポイントは，「配列は参照型＊6である」という言葉に集約されています。この言葉の意味がわかりにくければ，「配列は一種のクラスである」と考えると理解しやすいかもしれません。

の「配列は一種のクラスである」。一瞬読み流してしまいそうだわねぇ。突っ込むべきは「一種はいらない」よね？

次のPageにいくと…まぁ素敵。あちこちで困っていることを教えてくださるみたいよ？

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=4 より
初級編
オブジェクト指向と
Javaの関係を学ぶポイント

大切だわねぇ。このあたりのポイントはちゃんと押さえていきたいわ？*16

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=4 より
Java言語の攻略を進めていく過程で，必ず大きな壁となるのが「オブジェクト指向」です。巷にはオブジェクト指向の良書があふれているにもかかわらず，多くの初心者が「オブジェクト指向は難しい」と答えます。

まぁさっそくいつもの引っ掛け問題ね？
これは簡単だわ。答えは「巷にはオブジェクト指向の良書があふれている」よね？
これは皆さんとても苦労なさっておりますもの。簡単に気づくんじゃなくってかしら？

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=4 より
中には「オブジェクト指向は理解している」そう答える人もいますが「ではポリモーフィズムを利用してクラスを設計してますか？」と聞くと，急に自信無さそうにしてしまいます。

これも簡単だわねぇ。答えは「ポリモーフィズムを利用してクラスを設計」ね？
きちんと用語を踏まえていれば簡単に気づきそうなものなんですけれども。このあたりで「知ったふりをしているだけかどうか」が判断できる、なかなかに穿ったよい引っ掛けだと思いますわ？

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=4 より
確かにオブジェクト指向はすばらしい概念ですが，Javaのプログラムからオブジェクト指向を利用する場合，使い方を間違えると意味をなさないどころが，逆に使い物にならないプログラムを作ってしまう危険すらあります。

これも簡単だわねぇ答えは「Javaに限らないんじゃなくってかしら？」ね？

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=4 より
◆ STEP1
カプセル化を取り入れよう

ちょっと見、地雷のない文章が続いて、思わず引っかかりそうだったわ？
なかなかのテクニシャンよねぇ。ちょっとすごすぎてよ？答えは「図5●変数とメソッドをprivateにしてカプセル化する」に隠されていたの。
「コンストラクタに複数の引数をもたせてるのが大体おかしいのよね？」*17
これが正解ね。間違って「コンストラクタがprivateなのも」「データは必要に応じてアクセッサを用意すべきだわ？」って突っ込むと、その後の文章で突っ込み返されてしまうの。

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=4 より
と，このようにカプセル化とは，実に簡単なものですが，当然このままでは使い物になりません。コンストラクタをprivateで宣言していますらインスタンスが作れませんよね。

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=4 より
とりあえず，ここではコンストラクタだけ，publicにすることにしましょう。これで，他のパッケージのクラスからでもインスタンスを作れるようになります。ところが，まだ問題があります，このままでは，データの変更ができません。年齢は毎年増えていくので，フィールドageが外部から変更できないと不便です。しかしカプセル化の観点から見ると，もしpublicにして公開してしまうと，あり得ない値（例えばマイナス値など）が代入される可能性が出てきます。なんとかカプセル化を維持しつつ，外部に公開することはできないものでしょうか。
そこで，登場するのが「アクセサ・メソッド」です。

先生の、ちょっといたずらな笑顔が浮かんできてしまいそうよ？
続いて継承に移っていくわ？

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=4 より
◆ STEP2
継承のメリットとデメリットを理解しよう

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=4 より
このとき重要なのは，SubClassにアクセスした時点で，スーパークラスであるMySuperがメモリー上に自動的に読み込まれて生成されることです。この「スーパークラスを自動生成」という機能は，サブクラスのインスタンスを生成した場合も同じです。サブクラスをインスタンス化すると，スーパークラスは自動的にインスタンス化されます。

ここも沢山の落とし穴があるわね？このあたりは、クラスとインスタンスの違いっていう「極めて初歩的な理解」さえ出来ていれば勘違いは防げるはずよね？

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=4 より
【超高速ポイント】
　継承とはスーパークラスの自動的生成と，そのスーパークラスを暗黙にアクセスできるようにする機能のことである。

ここにもしっかりと「チェックポイント」があったわねぇ。すごい量だわ…。

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=4 より
そもそも継承は，「ソースコードを再利用する」という目的があるはずでした。しかし実際は，自動的にインスタンスが生成されるので便利であるとか，暗黙にアクセスできるという程度でしかないのです。なぜなら，コードを再利用したいだけなら，クラスの中で別のクラスをインスタンス化すればいいからです＊10。

あらこれはちょっと、始めての子にはハイブリッドすぎやしないかしら？
もちろん、慣れてる連中なら「基本はこっちだよねっていうか最近は継承を可能なかぎり忌避する方向性だよね」って突っ込めるんでしょうけれども。

…とはいえ…流石にこれだけの量があると息切れしてきてしまいそうよ？
ちょっとざっくりと省略しながら進んでいくわ？
次は「オーバロードとオーバライド」のお話。

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=5 より
【超高速ポイント】
　オーバーライドの特徴は，参照する変数がスーパークラス型であったとしても，サブクラス側のメソッドが呼ばれるところにある。

このあたりが分かりやすくも大きい地雷ポイントかしら？
次のポリモフィズムは

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=5 より
【超高速ポイント】
　ポリモーフィズムとは，同じメソッド名のメソッドを実行すると，違う処理が行われること。

ね。…あらやだ。ポイントが悉くチェックポイント化してるのね？
ある意味分かりやすいとは思うわぁ。

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=5 より
【超高速ポイント】
　インタフェースは，単一継承の問題を解決しつつポリモーフィズムを実現する，一種のスーパークラスである。

ここもそうですし。

さて…後半ざっくりと割愛しちゃったんですけれども。そうねぇ

http://itpro.nikkeibp.co.jp/article/COLUMN/20060927/249181/?ST=develop&P=6 より
いかがでしょうか。Javaを“超高速”に学習するヒントを見つけていただけたでしょうか。今回紹介したポイントは，どれも「知っていそうで，実は詳しく知らない」という内容に絞っています。今後，Javaの学習中に，どうしてもつまずいて先に進めないようなら，今回の「超高速ポイント」を見直してみてください。きっと，その先へ進むヒントが隠れていると思いますよ。

素晴らしい出来だと思いますわ。いかにも正しそうに見えてあちこちにたっぷりと、それはもう潤沢に隠されている問題点をどこまで突っ込めるかで自分のスキルも見えてきますし。
今まで突っ込めなかったところが突っ込めれば、それで成長の度合いも図れてしまうんですもの。
流石は、日経BPスクールで記事を書いていらっしゃったり、工学研究社とかってところでも教えてらっしゃったり*18する先生様だけのことはありましてよ？
しかも、何冊か書籍もお書きになられ、雑誌にも執筆なっている上に、プログラム言語のセミナーやSE向けの新人研修、通信教育やeラーニングをしている有限会社メディアプラネット ( http://www.media-pra.net/ )の社長様でもあらせられるみたいなんですもの。
あのなんともいえない絶妙な、量と質とを見事なまでに兼ね備えた地雷は、やっぱり「役者が一枚上手」って感じだったんですもの。なんだかすごく得心が行ってしまったわ？

そうねぇ…これだけ素晴らしいものをおつくりになる方にあたくし如きが…とは思うんですけれども。
せめても一言あるとしたらこれくらいかしら？
「基礎の基礎から一通り全部やりなおしてらっしゃい？」
ネクタイの締め方どころかボタンのつけ方一つすら知らないような愚鈍な輩がファッションについて語っても、虚しさが恥を伴って絡みつくだけよ？
今の自分を知る。そうして、今にふさわしい装いとその先を見つめ、歩むことが出来る。それが出来る男だけが魅力的な殿方になり、それが出来る女だけが…あたしの邪魔を出来るのよ？

*1:崇高な理念って大抵厄介ごとしかうまないのよねぇ

*2:それはそうとして…なんでメール送るのにsession idとか必要なのかしら？本気で意味不明だわ？

*3:実際現場でよくあるのよねぇ「ハッシュのキー値をtypoして」ってバグ見つけるのに壮絶に苦労することとか。一回火傷でもすりゃ少しは…忘れちゃうのかしらねぇ馬鹿だと。

*4:まぁマトモにclass設計できてりゃglobalとかってあほみたいなもの使う必要はないですものねぇ。結局、globalって「データの流れが追いきれない」から使ってるだけですし。それを考えると、先日の「session使わずhiddenで情報を回す」なんて狂気の沙汰も理解はできるわねぇ。

*5:どんな風に隆盛なのかしらね(邪笑

*6:迷文？謎文？いっそ冥文かしらね？

*7:実際一味も二味もちがうのよねぇ。…困ったことに。

*8:大抵実務経験に乏しくてロクな教育しないのよねぇ…困ったことに。

*9:で、あんたいつになったらそのネタ書くのかしら？そのうち催促に伺って差し上げても「よろしくってよ？」

*10:生徒さんが、ね。

*11:そういや、あんたこの話も書くって言ってたわよねぇ？とっとと書きなさい？沢山のファンの皆様が心待ちに期待していてよ？

*12:具体的には保守性よ。あんだけダイナミックな変更に耐えられるっていうのは、始めに分かったときはちょっとしたカルチャーショックだったわ？

*13:こんな文章を平気で載せられるその図太さは本気でちょっとした賞賛ものよね？

*14:…いい加減疲れてきたわねぇ。詳細は後は自分で調べてみて頂戴？たいして難しい話じゃなくってよ？

*15:配列の配列、ってシンプルな手段でもいけるんですけれどもねぇ。

*16:正確にツボ突けば簡単に「眠って」いただけますしねぇ。あたしの流儀ではないにしても。

*17:順番間違えたりとかって事を考慮できないのかしら？業務系での厄介なバグでこういった「単純な」ところに起因する可能性って低くないのよ？

*18:ソフトウェア技術教育シリーズですって。

Lucrezia Borgia の Room Cantarella

■

対象が見えないんじゃ主題も主体も失われてしまってよ？

そういえば語源は「非道」だったわねぇ