- ねこのこべや -
- ねこのこべや -
こんにちは、三猫です。
先週半ばくらいから、風邪っぽい感じだったのですが、 仕事の関係上休むわけにもいかず、 体をだましだまし使って昨日まで頑張ってきたのですが、 ついに今日はダウンしてしまいました。
さっきまで汗をいっぱいかきながら うんうん いって寝ていたのですが、 おかげで今久しぶりに頭がすっきりした感じがします。 うーん、やっぱり無理は良くないってことなんですが、 お仕事ってのは自分の仕事が遅れるだけじゃ住まないから、 なかなか「早期休養、早期解決」ができません。
そんなこんなで、いま布団の上に 愛しき愛機 Thinkpad s30 を置きながらこの雑文を書いているのですが、 思えば私のキーボード趣向も随分かわったものです。
猫のキーボードルームを開いた当時、ですから2002年ですね、 私の理想のキーボードは、X,s系 Thinkpad やNMB RT6600系のような ラバードームでクリック感のハッキリしたキーボードでした。
パチパチっとした感覚で打てるこれらキーボードは「打ち殴る」ような使い方をしたときに 非常に使いやすく、ミスタッチもしにくかったことから猫はこういったキーボードに魅かれていたのです。 が、最近はどうもそう単純にいかなくなってしまったようで。
去年、あたしのキーボード感を変えたのは、IBM Space Saver II Keyboardと、 Cherry MXリニアスイッチです。
Space Saver II Keyboardは、以前の猫なら斬って捨てる打鍵感で、 基本的に品質の低さを「NMB的クリック感」という秘伝のタレでどうにか食べられる味にしている あまり宜しくないものです。
ところが去年の頭、お仕事がどうにも修羅場になったとき、NMB RT6652TWJP を使っていた猫は 手が腱鞘炎気味になって難儀していて、代打としてこのSSK II を使ったのですが、 これがなかなか具合が良くって、ちょっと考え込んでしまったのです。
このノイジーでスライダ精度の悪さ剥き出しの打鍵感は、 とてもとても「良い」ものではないけれど、手に負担がかかっていないという事実と 慣れればそう打ちにくくもなく、というか「気持ちよい」と思ってしまう自分がいる。 う〜ん、これはどういうことなのかしら?
そのあと評価した Microsoft BasicKeyboardの評を見ればわかるとおり、 猫のキーボード評価は一転します。 例えるならば「たこ焼き」や「お好み焼き」も美味しいと言うようになってしまったのです。
最近は安物キーボードも落としどころが美味くなっていたというか、 ジャンクフードのような「おいしさ」を持つモノも増えています。 これは猫としては非常に悩みどころです。
これは「評価が甘い」というのとはちょっとちがくて、 たこ焼きとお寿司を同じテーブルにのっけてどちらが美味しいか、と問うのは無意味なのと 似ています。 まずいたこ焼き、美味しいたこ焼きの評価はできても、 寿司よりたこ焼きが美味い!と言い切るのは抵抗を感じてしまうのです。
そんなこんなで猫のページはだんだんと、屋台料理も美味しいとの判定になってきています。 でもでも、どれもこれも「美味しい」では何の参考にもなりゃしないったら・・・ねぇ(^^;
実は、猫のキーボードの好みが全体的に「あっさり」系にシフトしてきています。 強いクリック感をあまり指が好まなくなってきているという、 猫のキーボードルームにとってみれば大ピンチな事態になっています。
これは、いよいよお金に糸目をつけなくなってきたキーボード収集と、 あまりにツボを尽きすぎたDOS/Vmagazineのキーボードレビューラインナップのせいでしょう。
とくに後者はもう殆ど洗脳で、10時間ばかり缶詰で贅沢キーボードを取っ替え引っ替え打たされれば、 誰だってもう元のキーボード観には戻れません。 おそるべし、/Vmag.あやのさん、おそるべし、K.Tanaka//さんです。
それまでは、庶民の味系キーボードレビュワーだった猫の前に積み上げられたのは、 世界3大珍味ともいうべきキーボードたち。 ようするに、「贅沢の味」を知ってしまったのです。
キーボードを安く美味しく仕立てるには、やっぱりコテコテ系の味付けが宜しいようで、 安キーボードの「アッサリ系」はとても食べられたものではありません。
富士通高見沢コンポーネント(現富士通コンポーネント)の キーボードは、スライダに摺動グレード樹脂性パーツを使い、 底面が湾曲しているカーブド・スカルプチャ構造を取り、ストッパ構造を持たせ底付き時に ラバーカップを押しつぶさない、といった結構贅沢な作りをしているにもかかわらず、 その打鍵感はなかなか「美味しい」と評価されることはありません。
逆に言えばこの程度の「贅沢」をして、初めてスタートラインに立てるのかもしれません。 またはラバードーム & メンブレンシート という構造は おそらく「アッサリ」タッチを組み上げるに向いていないということなのでしょう。
ところが、素材に贅を尽くしたキーボードは、 薄味でとても美味な打鍵感を手に入れることが出来るのです。
こうなってくると逆に「秘伝のタレ」で 素材の至らなさを隠しているキーボードが気になってくるわけで、 ThinkPad s30のキーボードも 「一見美味しくおもえるのだけれどもねぇ・・」と思ってしまう私が居るのです。
クリック感だけでは、「う、ま、い、ぞ〜〜っ」と叫べなくなってしまっただけで、 決して薄味専門になったわけではないのですが、 庶民の味は味で「美味しい」といい、でも中間クラス、そこそこ贅沢をして あとは味付けで仕上げるようなのに、五月蠅くなっている私は、 なんだかレビューが支離滅裂です。
・・・ああ、もう、ダメかも。
新年始まってからここ数回は、 プログラムにかんするえらそうな話題ばかりですみません。
今の猫のお仕事は 実は COBOLer上がりの大規模開発チームに オブジェクト指向開発をさせること、だったりします。.NET様様ですね。
営業方針としてのウリが「XML Webサービスでビジネス層を提供」、 「UIはWebアプリでC/S並の使い勝手を実現」という仕様と、 現場の「構造化プログラミングって何?」「関数に分けると見にくくなるので関数かは共通ルーチンにとどめる」 「ループカウンタをグローバル変数で確保」といったすばらしきスキルが見事にかみ合っていないわけで、 ソフトウェアの進歩の歴史25年分あまりをどのように埋めようかと 日々奮闘しているわけでして。・・・ああ、逃げたい。
でも、保守しやすい業務システムを再構築する機会と前向きにとらえて 頑張っているのですが、 そのなかでどうしても「先生」役、 「教祖様」役(OOP教の教えを説いて差し上げましょう状態)になってしまうので、 なんだか「えらそう」が身にこびり付いてしまいました。うーんよくないにゃあ。
一度プロジェクトが転がりだして目の前に具体例が溢れ返れば 自然に出来るようになってくれると、猫は思っているのだけれど。
最近あちこちでキーボードサイトが立ち上がってます。
Keyboardersさんとか、 hamaさんちのキーボードコーナとか、 a little bit of keyboardsさんとか なんですが、(漏れがあったらごめんなさい)ここ2ヶ月でも これだけの立ち上がりを見せるのですから凄いものです。
キーボードサイト界の新入りだった猫のサイトもいつの間にか 古株さんと同じ括られ方をするときがあり、嬉しいようなくすぐったいような畏れ多いような そんな気分に身もだえしています。
しかし、ポコポコ立ち上がるサイトのレベルのなんと高いことよ! あたしはもう、追い越されないように頑張る気力すらうせてしまったというか。 サイト暦では後輩でもマニア暦では先輩なので、 満を持してのサイトさんたちに、猫ごときのへっぽこサイトが太刀打ちできるはずもありません。
それはそれで、正直ちょびっと悔しいのですが、 猫には猫の道があるさと、日々まったりとサイト運営しています。 今年は初心にもどって安くて良いキーボードの発掘に邁進したいと思っています。 (ホントのところはお財布の命令なんですけど)
そんなキーボードを尻目にトラックボールサイトを立ち上げたのですが、うーんなかなか進まない。 で、こちらが詰まっていると キーボードルームで紹介したいキーボードのドキュメント作成にリソースが回ってこない。
つまり、いま三猫さんちはコンテンツ待ち状態で渋滞中なのです。へみへみ、たいへんだわ。
さて、今猫が注目しているサイトにKeyboardersさんがあります。 このMicrosoftのソフトウェアのようなダイレクトなネーミングセンスがすばらしいです。
ここの掲示板は豪華な常連陣と超絶アクセスで貴重な情報源と化しています。
鍵盤界の台風の目といえば 101Keyboardさんやのぐ獣さんのKeyboard Maniaさん とこの、伝統と信頼の開拓者チームと、 個人サイトを凌駕した情報量を誇るQwerters Clinicさんだと思うのです。 これらのサイトさんは鍵盤愛好者がとりあえず最初にアクセスするターミナルとして重要なサイトさんだと(猫的には)思っています。
ところが最近Keyboardersさん(の、特に掲示板)は異様なほどの人の集まりが見られるようになりました。 1stアクセスページとして急速に勢力を伸ばすKeyboardersさんは このまま行くと第三勢力になるかしら、とひそかに(こんなところに書いたら密かも減ったくれもないですが) 期待しています。
ああ、なんだか勝手なことを書いてるわ。
最近サイトを立ち上げてよかったわ、と思うのは これら新規サイトさんの立ち上がりをかなり早期に発見できること。
有難いことに猫のサイトにリンクを張ってくださるので、 リファラーで突き止めて青田買いで見てしまっています。 Qwerters Clinicさんで紹介されるより早く見れるのは、まるで発売前の雑誌を読むような そんな優越感に浸れたり(笑)
もひとつ嬉しいことは みみラボ!さん と 101Keyboardさんにリンクを張っていただいたこと。
みみラボ!さんはもう ねみみにみず で(だって厳選リンクに入れるとは思わないじゃない) とてもビックリ。魅惑の鍵盤の「カタログ性」は猫の憧れです。 ここみたいな眺めて幸せになれるサイトをいつか作りたいなと思っています。
101Keyboardさんは、いつかここのリンクに名を連ねるのが夢だったので、
念願かなったりといったところ。昔、某有名声優が「徹子の部屋」に出るのが夢と言ってましたが
猫にとっての101Keyboardさんはその「徹子の部屋」のような位置づけなんです。
サイトを開いてからずいぶんたっていますので、実は「門前払い」というか
まだまだ載せるレベルになってないよ、ということなのかしら?と
思っていただけに、これまた突然でビックリです。
うーん、これはサイト運営のささやかなご褒美ってところかしらん。 というわけで、まったりまったりな、猫日誌でした。うにゃん。
補足：会議の突然の中止に、やることがなくなりました。
前略、宮坂電人様。
突然の書簡、失礼致します。 Cマガジン2月号を読んでどうしても一言言いたいと思い、 お送りする次第です。
宮坂様の書かれました 特集 「議論沸騰中 プログラミングの○×△」ですが、 私にとってこの記事は非常に納得の行かないものでした。 なぜなら、この特集は喧嘩の水掛け論について語っているだけで、 技術的知的好奇心に答えるものでは無かったからです。
まず、最も納得のいかないのは、 宮坂さまがテンプレートとして書かれたとおり、 それぞれの「意見」や、「反論」は、ワザと履き違えたもの ばかりを掲載している点です。
次に納得のいかないのが わざわざ履き違えているものを取り上げ、 あとから「履き違え」の考察をのべ問題自身の見解としていますが、 そもそもこの見解が公平とも、第三者的とも言えない、 宮坂様の個人見解である点です。 (中途半端に公平を装っていますが、いずれの文も どちらを宮下様が正しいとおもっているかがひと目でわかってしまう とても嫌らしいものです。)このような説明のしかたは、宮坂様が持論の説得力を 増強しようと心理誘導したとうけとられてもしかたがない ものだと私は思います。
議論が起こるところには面白いテーマが転がっているものです。 そのテーマの本質を見極めず 「メーリングリストの正しい質疑応答のしかた」とか、 「喧嘩はいけないよ」とかいう雑文を、 「プログラミングの○×△」というタイトルを被せて 発表することに何の意味があるのでしょうか。
もっとCマガジンにふさわしい、知的で面白い記事が書けるはずの テーマなのに、宮坂様の私的見解と、議論がこじれることへの 考察のみというのは余りに悲しいではないでしょうか。
そして、なにより悲しいのは宮坂様自身が「負け」や「失敗」を 認めたくない人になってしまっている点です。
結局の所、本特集の問題は、書き手である宮坂さまが 読者の存在を忘れてしまった点にあると思います。
おそらく取材の最中にメーリングリストまたは掲示板 それに類するものでの 議論に嫌気が差してしまってのことだと思いますが、 プロのライターとして守るべき節度があったのではと私は考えます。
今後、このようなことが無いように、一読者としてお願いいたします。
かしこ
いきなりものものしい出だしの今日の猫日誌です。
これでは件の特集を読んだ方で無いとなにがなんだかですので簡単に説明しますと、 Cマガジン2月号に掲載された「プログラミングの○×△」という特集、 「よくプログラミングである議論」をテーマにそれぞれについて纏めていくという 面白そうなものだったのですが、手にとって見るとひどいもので、 なぜだか読んでいると、賞味期限切れの揚げパンを食べたかのように 胃の中がムカムカする文章で、なんだかやるせない気分になってしまう 特集記事だったのです。
解りやすくいうならば、本特集は「朝まで生TV」と同質の不快さ、 つまり公平であるはずのナビゲータがその立場を持論への誘導に使っている 浅ましさがあります。
持論に導くためには「議題の局解」や「反対意見の意図的編算」 もいとわない姿勢は、もうひどいもので、よく編集部が掲載を許可したものだわ、と 半ば呆れ関心してしまいます。
これだけでしたら「ああ、この宮坂さんってのはレベルの低い技術ライタさんなのね」 と心の中にしまっておいて、「今後彼の名のつく本は買わないようにしよっと・・・」 ってそっと思っているくらいでした(:-p
しかし、以下のような文言を見たとき、どうにも収まりが付かなくなりました。
皮肉っぽいいい方ですが、沢山の人が集まっている掲示板で議論をふっかける人は 実社会では孤独な人であったり、うるさそうな人と敬遠されていることが多々あります。
まさか「反対意見者への人格攻撃」へも及ぶとは。
宮坂さんの議論の進め方自身問題ですが、それ以前に 鬱憤を晴らす目的で書いてません?
ふーん、ようするに、掲示板でムカっとする目にあって その鬱憤晴らしのために、記事を書いたというわけですか。
あなたはストレス発散になってよかったですね。 でも純粋に技術的にこの特集を楽しみにしていた読者さんの をそんなつまらないことで裏切ったんですか。
この方、ライター失格です。
まぁ、猫の毒トークはココまでにしておいて、 このライターさんは、どうやら怒りにまかせて 本文を書いたらしく、この記事、なんのやくにもたたない ものと成りはてています。
そこで猫が、一つ一つの議題に対して、 ちょちょっと雑文を書くという、 猛烈な嫌みをしてみようかと思います。
くふふふふ。
と、いうわけであまりにネチコラした文章になってしまったで、 別ファイル化しました。精神衛生上よろしくないものを作ってしまったのですが、 興味があればどうぞ。
たぶん、宮坂氏は単に頭に血が上った状態で記事を書いてしまったというだけなのでしょう。
雑誌ライタが掲示板で貫き通せなかった持論を、巨視的立場を装って発表すること自身に 猫は憤りを覚えたのです。 これが日○プログラミングだったら放置プレイだったのですが、 Cマガジンだったことも宮坂氏にとって不幸でした。
猫がこんなマイナな日誌で揚げ足取りの雑文を書くまでも無く、 宮坂氏のところには講義のメールが殺到しているのではないかと猫は想像しています。 (ハイレベルな読者が多いCマガジンでは相手にもされなかったかも)
もう一つ気になるのが、前橋和弥氏への 個人攻撃であるような気がしてならない点です。 前橋氏は、持論中で「Javaはポインタバリバリ」「メッセージはファンクションコール」などと 言っています。
もちろん前橋氏は「ポインタとは」を説明し、また教育上の効果を狙って場をわきまえた上で 「関数呼び出し」と言うなど、配慮の行き届いた論理展開をされています。
確信はもてないので、単なる推測以上のものではありません。
どちらにしても本特集を読む限り、宮坂氏は冷静な議論を行えるスキルを持っているとは 到底思えません。 (むしろ論理展開を持論という結果に強引に持っていこうとする節が強い、かなりの困ったチャンで あるように取れます。)
宮坂氏というのは「俺様経験に基づいた結論」を「布教」するために論議の輪に参加しているフシがあり、 その為議論の目的が「持論を勝たせること」となり、論旨の歪曲や、極論の持ち出しを平気て行ってしまえる 思考形態をお持ちの様子。
ようは、この方が技術的な議論の輪に加わると、論議がケンカになってしまうと 言うことでしょう。つまり、荒らしは彼自身だったのではと思います。
最後に、
この特集だけで宮坂氏の人格までもは推し量れないとは思います。 それでも想像してしまうわけで。
猫が感じた宮坂氏というのは、まず確固たる考え方をもっている方。 確固たる考え方を持っているというのは良いことです。 ですが、頑固もので勝ち負けを気になさる為自分の意見を曲げることを苦痛に感じる方でしょうねと。 またスキルがあると自負しているため、人を見下す姿勢をとる癖がついていたり、 謙虚にモノを聞ける耳が若干退化してしまっているのかしら、とも思います。
そして自分が正しいと過度に確信を抱いていることに (正しい自分は公平に物事をあつかうハズだからと思っているため)気付かない 困った性格だったりして・・なぁんて想像するのです。
まぁホントのところは解らないのですが、(今回は単に頭に血が上っていただけで普段は分別のある方なのかもしれない) 読者はそう思い兼ねないよという警鐘ということで。
だって本当の宮坂氏がどんな人間なんだかは猫には知る術がないにも関わらず、 それでも猫は今後金輪際宮下氏の文章は読むまいと心に深く刻み付けたのですから。
たぶん、こんなにネチコラいわなくても良かったのでしょう、一言こういいさえすれば。
「とてもつまらなかったです。」
最近KeyboardersさんのBBSが 面白くって仕方がありません。
鍵盤サイトやトラックボールサイトの管理者がぞろぞろと集まっている様子は 既に異様で、発言に参加しない方(いわゆるROMですね)が見ると、 雑誌の座談会のような様相を呈しているのではないでしょうか。
ただ、ちょっと悪いわ、と思うのは大量の発言をチェックし、こまめにレスをつけてくれる 管理人のpapa_さんに負担をかけちゃってるかしら、ということ。 本家サイトの更新がパタッととまってしまっているのを見ると、 なんだかとても申し訳なくなってきます。
とか、いいつつも、発言しっぱなしですけどね(笑)
またも、プログラミングネタで申し訳ないのですが、最近構造化プログラミングについて 考えることが多くなっています。
構造化プログラミングというと、「ああ、あれね、"順接"、"分岐"、"反復"っていう構造をつかえば、 goto文を使わないで済むってヤツでしょ?」 ・・なぁんて答えが返ってくることが多いのです。 が、それは「ブレーキってあれね、踏むとブレーキドラムをパッドではさむやつ。」 なぁんて答えが返ってくるのと同じじゃないかしら、と思うのです。 要は間違ってはいないけど、それは実現手段で本質ではありません。
と、いうことを言いたーい、というわけで、構造化プログラミングとは何なのかを、 ちょっとだけ語ってみようかと思います。 但し、あくまで「猫はこう理解している」というだけなので、注意が必要です。 (えらそうに言っておいてなんですが、実はダイクストラさんの原本は読んだことがないのです。(^^;) )
良く言われるのが、goto文を 3大制御構造で置き換えるプログラム手法、という言われ方。 でも、構造化プログラミングって、ホントはこんなことです。
トップダウン法な開発手法は大規模システムにおいてボトムアップ式開発よりも優れる
そのため、プログラムも段階的に詳細化する構造で作成すると良い
という風なお話です。 段階的に詳細化してるので、例えば「システム初期化」という処理が、 「ハードウェアのチェック」「EEPROMから、設定データを読み出す」「通信タスクとUIタスクのスレッドを起動する」 という処理で成り立っていたとしても、 全体を見通すときは「システム初期化」で済むわけですので、 システムが大きくなればなるほど、この考え方はパワーを持つわけです。
では、具体的にどういう風に実装できるのか、というと
ということになります。 「だけど、ホントに goto文を使用しないでプログラムを作れるの?」という 疑問に対しては
プログラムは3大制御構造(「順接」「分岐」「反復」)だけで記述することが可能である。
と、答えられるわけです。
この定義によって、プログラムは、 「アレをして、次にコレして、そのまた次に・・」というソース中に処理がズラズラっと平面に並ぶ書き方から、 「メイン関数があって、そこから呼ばれる関数があって、さらにそこから・・」という、 階層構造を持つもの、という意識に変わりました。
このパラダイム・シフトこそ、構造化プログラミング なわけです。
構造化プログラミングのインパクトは、「プログラムに階層構造をもたせる!」という本質よりも 「gotoを捨てる！」のほうが大きかったようです。 なので、「構造化プログラミング = 三大構造を駆使してプログラムを作ること」と 誤解される向きが多いです。
この場合「関数呼び出し」「return」「break」「continue」「thorw」などを 制限付きgoto文と捕らえて「構造化プログラミング」に従っても コードの可読性や保守性が上がるとは限らない。(むしろ一部は従わないほうが良い)といわれることが ありますが、それは枝と幹の優先度を履き違えてしまっていると猫には思えるのです。
なぜなら、これらの制限付きgoto文の「制限」は、goto文に「構造化」の制約を設けたゆえの制限です。 また、「goto文も上手に使えば( 具体的には多重ループから抜けるようなエラー処理とか ) よい」 というのは、上手に構造化された使いかたとも言えます。
これらの「goto文を使ったほうが良いケース」というのは、「goto文は絶対つかわない」という原則の不足分です。 でも制限付きgoto文は、構造化プログラミングの精神から言えば、既にgoto文ではない、 と捕らえるべきよね、と猫は思うのです。
C言語で考えると分かりやすいのですが、C言語は「{}」でパッケージングを記述することができこれを ブロックと呼びます。 このブロックに「if」ですとか「while」なんかをつけると、制御構造に、 「void Hoge( ) 」なんていう「{}」の外からみた名前と型をつけると、それは関数になります。
もともと「サブルーチン」という概念は構造化プログラミング以前にあったのですが、 それは共通処理のくくりだしという以上の意味はありません。
関数は処理に名前を与えることで、処理自体をトップレベルからみた概念に抽象化します。 だから、ある程度の規模以上、ある程度の意味以上を持つ処理の塊ををどんどん関数にしていく のが構造化プログラミング流というヤツでして、 その関数が1回しか呼ばれていなかろうと、そんなことは関係ない! ・・・ということなんです。
余談ですが 意外と知られていないことにC言語では無名のブロックを作ることが出来ます。
void main( )
{
/* 変数の宣言 ----------------------------------*/
int mains_number;
char mains_string[10 +1]; /* 10文字 + NUL文字 の意 */
/* 変数の初期化 --------------------------------*/
mains_number = 10;
strcpy( &mains_string[0] ,"HOGEHOGE" );
{
/* 変数宣言 --------------------------------*/
int noname_block_number;
char noname_block_string[10 +1];
/* 変数の初期化 ----------------------------*/
noname_block_nubmer = 20;
strcpy( &noname_block_number[0] ,"PIYOPIYO" );
/* 変数の中身を出力 ------------------------*/
/* main の変数 */
printf( "num=[%d],string=[%s]" , mains_number ,mains_string );
/* noname_block の変数 */
printf( "num=[%d],string=[%s]" , noname_block_number ,noname_block_string );
}
/* 変数の中身を出力 ----------------------------*/
/* main の変数 */
printf( "num=[%d],string=[%s]" , mains_number ,mains_string );
/* noname_block の変数 */
printf( "num=[%d],string=[%s]" , noname_block_number ,noname_block_string );
↑この文でコンパイルエラー↑
/* 関数の終了 ----------------------------------*/
return;
}
ブロックは、宣言するとソコに変数のスコープが区切られるようになり、 ブロックの内側で宣言した変数はブロックの外側からは見ることが出来ません。 この特徴こそが、「構造を分離する」という大きな力になっています。
だから、無名ブロックも一見パッケージングの役に立ちそうなのですが 上位ブロックの変数がそのまま使えてしまうため、イマイチ セパレート効果が薄く ネストの深いカッコも読みにくくなるだけですので、 現在の一般的な結論は「こういうソースは書かないほうが良い」です。
というわけで、Cのような言語でパッケージングを記述するときには、
関数化するしか無いのですが、関数パッケージング効果は逆に強すぎて、
ゆるいパッケージングの記述や小さいパッケージに適用すると、逆に分かりにくくなってしまいます。
(本当に有用な「構造」がうずもれてしまうからです)
こういうケースに利用するのが、前回のセンター解説で紹介した
このコメント書式はもちろん言語的制約はまったくないのですが、 猫はとっても愛用しています。 猫がプログラムを作る場合、まず、このコメントから先に記述します。 で、そのなかのコメントを実現する詳細なコードを書いていくわけです。
コメントのネスト書式が深くなった場合や、 一つの論理パッケージが長く大きくなった場合は、 関数化する規模のパッケージであると判断して関数にします。
猫のように、ナンバリングするのはヤリすぎかもしれませんが、 職業プログラマさんのソースには、ある処理のブロックをセパレートするような コメントを見ることが多いとおもいます。(が、書籍のソースとかは書いてない多いですね。)
そんなこんなで、構造化プログラミングとは、決して「if」や「while」のことじゃない と思っています。 現実として、gotoを使っていなくても構造化されていないプログラムは山ほどあります。
それを分かっていない方たちが、「プログラマ」を名乗られていることが、 猫にはとっても不満なんです。
と、以上が猫の脳内的構造化プログラミングです。 うーん、検証してない持論を展開できるのが「日誌」の強みだとおもうのですが、 いつかちゃんと原書をよまなくちゃ。
「号外です、号外で〜す。」と 新聞を配っているお兄さんが居たので、 思わず受け取ってしまったのですが、 それは号外に似せて作られたキャバクラの広告でした。
キャバクラの広告だと思ったときあたしゃ思わず笑ったよ。 腹が立つというより可笑しいじゃないか。 だってそうだろう?
・・と、キシリアさまモードに突入したのは言うまでもありません。
最近本業とトラックボールルームに すっかりリソースをとられてしまい、ぜんぜん日誌をかけてませんでした。 うーん・・。赤くて角が生えたくらいのスピードで仕事をこなしているつもりなんですけどね〜。
さて、大学センター試験の情報処理(試験問題)があるので、 ちょっと気分転換に解いてみました。 現役プログラマとしては頭の体操なのですが、 特定の技術をささないように気をつけながら構成された仮想言語なんかが楽しめます。
と、言うわけで今回はプログラマさん限定、センター試験解説と洒落込もうかと思います。
まず、[第一問]で使われているロボット制御言語ですが、 一見Lispっぽいカッコだらけの文法、素敵です。
とりあえず言語仕様。
ロボットを制御する言語です。
ロボットは2次元座標中にいて、この言語でそのなかをどう移動するかを 支持できます。
命令一覧
| 命令 | 副作用 |
|---|---|
| 前進( l ) | 進行方向に距離 l だけ進む |
| 方向( θ ) | 半時計周りに θ度だけ旋回 |
| 繰り返し( n, α ) | 命令列α を n回繰り返す |
命令は 「{}」内に「,」区切りで列挙することにより、 収斂できる。このとき、左から順に実行されるそうな。
で、以下のように記述されます。
{ 前進(5) ,方向(30) ,前進(10) }
ちなみに、この命令だと
前へ5進んで、30度左旋回、その後 前へ10進む
のように動きます。
この言語、第一印象はLispなのですが、 「{}」で複文をくくり出し、「func()」という形式はC語的です。 しかし、
{ 繰り返し(4 ,{ 前進(10) ,方向(45)} ) }
となると、構造が一気にリストっぽくなります。 ん〜、面白いシンタックスです。
ただ、ちょっといただけないなぁと思ったのが最後の問い
{繰り返し(4,{繰り返し(3,{前進(5),方向(120)}),前進(10),方向(90)})}
で、ロボットが歩く軌跡はどうなるか、という問題。
この問題って、結局カッコ対応がややこしいというのが難しいだけで、 コレをスラスラ読める人間がプログラマとして最適かというと、 そうじゃないですよね。
入試につき物の「理解度チェック」じゃなくって「ミスの誘発」を狙った問題です。
これについては、カッコ対応はばらして書けば直ぐわかります。
{
繰り返し(4 ,
{
繰り返し(3,
{
前進(5),
方向(120)
}),
前進(10),
方向(90)
})
}
というわけで、長さ10の正方形の各頂点に、 長さ5の正三角形がくっついてる構造になります。
* * *
うーん、いろいろバラし方を試してみたのですが、 結局C系言語のブロック構文的な改行・インデントが一番見やすいようです。 どうやらLispっぽいシンタックスだけで実は見掛け倒し、 Lispの概念を受験生に問う問題ではない様子。これでは読みにくいだけの単なる手続き言語です。 ここまでやったら再帰で書きんしゃい、と思ってしまいます。
ただ、時間の概念に支配される手続き言語が、 支配されない(数学的な)「関数」と等価にふるまう・・っていうのをなぁんとなく示唆させる感じで、 もう少しキチっと煮詰められれば良いかもしれませんね。
第2問は、手続き言語風(というかCっぽいかんじ)の言語を使って、 一つのプログラムを作る問題。
【仕様】
□1□2□3□4□5□6□7□8□9
の□に、「+」、「-」、「何も入れない」を設定し、 計算式を作る
例)
□1 +2□3 -4□5 +6 +7□8 -9 → 1 +23 -45 +6 +78 -9
※「1」の左には 「+」は来ないものとする。
以上のルールにおいて、 計算結果が100になる式をリストアップするプログラムを生成する。
【設計】
数字の前に付く符号を次のように表現する。
| 符号 | 表現値 |
|---|---|
| - | -1 |
| なし | 0 |
| + | 1 |
これを配列 Kigou[] で表現する。
【問題】
上記仕様を満たすソースを穴埋めせよ。 ただし、計算式生成アルゴリズムの出力結果は以下のとおり。
[1] [2] [3] [4] [5] [6] [7] [8] [9]
1番目: -1 -1 -1 -1 -1 -1 -1 -1 -1
2番目: -1 -1 -1 -1 -1 -1 -1 -1 0
3番目: -1 -1 -1 -1 -1 -1 -1 -1 1
4番目: -1 -1 -1 -1 -1 -1 -1 0 -1
5番目: -1 -1 -1 -1 -1 -1 -1 0 0
6番目: -1 -1 -1 -1 -1 -1 -1 0 1
7番目: -1 -1 -1 -1 -1 -1 -1 1 -1
・
・
・
・
最後 : 0 1 1 1 1 1 1 1 1
この問題は、最初に
最初の記号配置を決定する 繰り返し、 | | 記号配置に従って式の値を計算する | | もし計算結果が100ならば式を印刷する | | 次の記号配置を作り出す | を,全ての記号配置が調べ終わるまで実行
というトップ階層の手続き構造を示し、 その後、「計算式生成→計算実行」アルゴリズムと 「符号配列生成」アルゴリズムと段階的に詳細化させていく手法で解答させるものです。
計算式を生成したり、計算するアルゴリズムはとりあえず置いておいて、 「符号配列生成」はようする3進数のカウントアップロジックですね。 数の表現に、「'0' ,'1' ,'2'」ではなく「'-1' ,'0' ,'1'」を使っているだけです。
で、出題された問題をそれっぽく展開すると、
// (1) 最初の記号配置を決定する ------------------------------------------------ Kigo[1]〜kigo[9]を-1でに初期化する 繰り返し | | // (2) 記号配置に従って式の値を計算する ------------------------------------- | | //(2-1) バッファ変数の初期化 ----------------------- | kotae ← 0 // 答え格納変数 | n ← 0 // 式に含まれる数(ナンババッファ) | fugo ← 1 // 符号格納変数(初期値：+) | | //(2-2) 構文解析しながら計算 ----------------------- | i を 1 から 9 まで 1 づつ増やしながら、 | | | | もしKigo[i] = 0 ならば | | | | | | n ← 【キ】 // 符号が付かないので数字並びと判断し、数値を合成 | | | | | を実行し、そうでなければ | | | kotae ← 【ク】 // 生成した数値を加算(符号をつけるのを忘ない) | | | | | | hugo ← Kigo[i] // 次に生成する記号をセット | | | n ← 【ケ】 // 新しい数値をとりあえず1の位に。 | | | | | を実行する | | | | kotae ← 【コ】 // 最後の数を加算(符号をつけるのを忘れない) | | | を繰り返す | | | // (3) もし計算結果が100ならば式を印刷する ----------------------------------- | | もし kotae = 100 ならば | | | | 印刷 | | | を実行する | | | // (4) 次の記号配置を作り出す ----------------------------------------------- | | //---------------------------------- | // 配列全体を、9桁の3進数と見て、 | // カウントアップ処理を行うだけ | //---------------------------------- | | //(4-1) カウントアップ ----------------------------- | i ←9 // 計算対象を 1の位 に | Kigo[i] ←Kigo[i] +1 // カウントアップ | | //(4-2) 桁の繰り上げ処理 --------------------------- | Kigo[i] > 1 の間, | | | | Kigo[i] ←【ウ】 // 現在桁を最小値に 初期化、 | | | | i ←【エ】 // 操作対象の桁を一つ上に | | Kigo[i] ←【オ】 // 繰り上がったので、一つ加算 | | | を繰り返す | を, 【カ】になるまで実行する
結局、例題のメソッドはコメントに書いたようなロジックです。 この問題のキモは、手続き型ソースの読解力というころかしらん。
最初に 大きな構造単位での 手続き構造を示し、後に掘り下げるというのは好感がもてます。 プログラムでもある概念の塊が小さな処理の並びに展開されるときに、 大本の概念を失念してしまうことが多いです。
それを防ぐのが上の展開ソースのようにコメントでの構造化です。
コメントで、分離、階層付け、分離ブロックの手続き順次の明確化を行い、 それぞれのブロックを抽象概念として扱うことで、 コーディングや保守がとても楽になり、 また、ソースの枝葉を読まなくても処理の本質が一目で分かるようになるため、 とても有益です。
また、このようなコメンテーションを行った場合、
となったときは、関数による抽象化の対象になります。
これは構造化プログラミングの段階的詳細化法の実装上のテクニックです。
* * *
ちなみに、
というロジックは、とても合理的で、「学問」としてはは良いのですが、 「仕事」の場合はソースを一見してその意味を理解できないので不具合の温床になるため、 (極度のパフォーマンスを要求される場合を除いて)NGなロジックです。
Excelの使い方問題はプログラマさん的にはつまんないのでパスします。
詰まんない割りに、手こずる辺り、普段いかににExcel使ってないか、ということですね。 えぅえぅ。 (というか、ある程度以上複雑な処理はマクロじゃなくってVBA書いちゃうんですよ・・。)
第4問はアルゴリズム検証や机上デバッグのときに良くやりました。 が、こんなのテスト会場でやらされたら発狂しちゃうよぉ・・
特に解説することは無いのですが、このアルゴリズムは欠陥アルゴリズムで、 その欠陥を気づかせるのが目的の問題の様子。
最近は開発環境もRADが当たり前になり、 デバッガでお手軽デバッグするプログラマが増えているのですが、 猫は机上デバッグってマスタしておいたほうが良いと思うのですよ。
猫はファーム屋さん(・・もう3年やってないから「元」をつけたほうがよいかしら(TT) )ですので、 デバッガの無いシステムとか、ソースの実行環境がチームで一つしかない、 なぁんて開発を経験したことがあるのですが、 (決して、決して、昔のシステム開発はねぇ・・と語れる年齢ではありません!) 何ていったらいいか、「超重力環境で特訓すると、普通の重力環境でも強くなる」現象というか、 デバッガに使われるのではなく、デバッガを使役できるようになるので、 ぜひ、机上でのデバッグをマスタしてほしいな、とは思っているのですが・・。
えっと、わずかに 64 点でした。
で、間違えの内訳は、マークミス 4 点、 ケアレス(?)ミス 21 点、計算ミスが11点でした。
まぁ仕事の合間に時間ブツ切りで解いてましたし、 Excel問題はしょっちゅう仕事の割り込みが入ったのと(アレ?) 生来のミスの多さで、マークミスやケアレスミスに、 最後の机上デバッグは、 終電タイムオーバでバババッと解いたら計算間違っちゃいました、 という、「やっぱしなぁ」な失点だったのですが、
【猫の脳内】 kotae += fugo * n;
を試験の仮想言語に落とし込むときに
【仮想言語での回答】 kotae = fugo x n (ホントは 「kotae = kotae + fugo x n」)
としてしまったのと (コレが2箇所が同じ回答で 4 X 4 = 8点なのが痛い)、 「一つ上の桁のインデックスへ移動させる」という仕様が分かっていながら、
i = i + 1
と書いてしまったりと「これが仕事だったら、バグですよ」という実に情けない 失点をしてしまいました。
こういうミスを洗い出すために当然、机上デバッグをかけるべきだったのに、 やっていなかった、私の未熟。
う〜ん、本気で落ち込みました。 こりは情けない。
うみゅう・・・、えっと、あはは、受験生さんって大変ですね。 ・・って笑い事じゃないですね。
猛省して勉強しなおします。 m(_ _)m
で、このセンター試験問題なのですが微妙です。
技術的に古い(手続き or 関数型モドキ 言語)というのはまぁ良いとして、 これを「受験」でやらされたしまうなら、猫も嫌いになってしまうかも。
今回出題されたのは、
と、それなりだけど、数学で入試?といわれるととても疑問におもってしまいます。
特にLispちっくな言語を使う問題は、 せっかく手続き型とはパラダイムの違う言語を模したのだから 再帰による繰り返しの実装などを見せてくれるべきなのに、 手続き型ちっくなアルゴリズムなため、ただの「ネストしすぎたカッコを上手く読めますか?」 という問題に成り下がってるのが残念なところ。
机上デバッグはそれなりに良い問題だと思うのですが、 いかんせん、テスト会場で、この制限時間で・・では、デスマーチ中の修羅場のような状況・・。 能力を測るというよりは精神力を測る次元に突入してしまいます。
雑学は、・・・・これが大学受験の合否にかかわるかとおもうと、悲しくなってきますし、 Excelの使い方は、正直「数学」じゃないでしょう、コレは・・。
問題としては面白いです。
Excel問題なんかは 社会に出るときこれを勉強していると 役に立つでしょうし、入社試験で出せば 自称「Excelが使えます」なんだけど「表計算ってなんですか?」な人を弾くのに最適かもしれません。
またその他のプログラム的問題も十分な時間を与えた上でなら、 ソフトハウス系の入社試験にいいかもしれません。
ですが、大学で学ぶにふさわしい学力があるか・・を測る問題じゃないと猫は思うのです。 う〜ん、だってさ。 これらって、情報化社会のなかで、社会に出るのに必要な知識ってだけでしょう?
今回のテスト、要するに理解はできていたけどミスが多い というありがちな結果でした。 ホントのプログラムでは、「ミスのないように実装する」ではなく、 「実装にミスがあっても必ず発見できるように作業する」が基本です。
そういった開発手法が身に染み付いているので、 うっかり八兵衛な猫でも仕事で「仕上げた」プログラムにバグが入り込むことは 滅多にありません。(当たり前です)
が、そのせいでスッカリ忘れていた 自分の「ミス魔」属性を再認識できたのは良かったと思います。 う〜ん、学生のときはさんざ苦しめられたのですが、喉もと過ぎればなんとやら、 すっかり忘れていました。
気軽な気分転換のつもりがずいぶん重いコトになってしまいましたが、 こういうのをやって見るのもいいもんだ、なぁんて思ったりして。へみへみ。
なんだか大変遅くなりましたが、皆様、あけましておめでとうございます。
猫日誌の更新がここひと月弱滞っていたのは別にネタが無かったわけではなくて、 ひとつは年末はとても忙しくって、書いている暇がなかったこと、 年始は三猫OnLine自体のメンテナンス作業に追われてしまい、 当初もくろんでいた猫日誌のフォーマット変更をしようしようと、 引っ張っているうちに一月も半分過ぎようかという時期になってしまった、 という理由です。
というわけで、猫言との統合とか、コラムスタイルに変更するとか、 いろいろ考えてはいたものの、結局今年も昨年どおりのだらだらと、 思ったことを書き流す場としてスタートさせていただきます。
今年もご贔屓のほど、お願いいたします。
誰の言葉かは忘れたけれど(吉岡 平の小説だったような気がする) 「オタクというのは好きな事柄について嬉しそうに批判を語る生き物だ」 というのがありました。
確かに、「××が駄目なんだよ。」「○○はわかってねぇなあ」 というような台詞を目を輝かせて履くのがオタクというやつでして、 それだけ愛しているから、よく知っているから、という バロメータを外界に表示する瞬間が至福の時であるのは、 (猫にも身に覚えがあるので)痛いほどわかります。
ところが、年始の新年会でかつてのオタク仲間と久しぶりに語らったのですが、 最近自分が批判を口にするときって、 そういう「愛情の裏返し」というより、 「愛しさ余って憎さ100倍」というか、なんだかその話題が出ただけでも不愉快に感じる 瞬間になってしまっているんだなぁと、しみじみ痛感してしまいました。
いえ、具体的にはB社に食い物にされている某ガンダム、 MSが出てくればガンダムか!?と監督を小一時間ほど問い詰めたいガンダムシードSEEDなんですけどね。
と、いうわけでコミケにガンダムサークルを出店しないようになって
2年経ちますが、その理由はガンダムで楽しめなくなった自分にあるのかなぁ、と
思ってしまうわけです。
富野ガンダムなら胸を張って好きと言えるのだけれど。
一言毒を吐くならば、 ガンダムの本質は、お子様向けロボットアニメとして圧倒的な演出力をもって カタルシスを消化しながらも、 鬼才 富野由悠季 の描き出す リアリティのある人物描写、 そしてフィクションの世界観をあたかもそれがあるかのように感じさせる 抜群の世界観演出であるといえましょう。
前者のロボットがカッコいい、ということだけ追い求め、 記号化された人物、記号化された世界観やテーマしか持たないものを 有難がるのはどうかと思うのです。
富野監督以外の第三者ガンダムは、そこまでの高みに立てているものは 数少ないのですが、 少なくともそういった「ガンダムの名前の重み」を精一杯受け止めて、 できる限り答えようと努力しているので、 私はそれらを愛することができるのですが、 SEEDは記号化した富野リアリティを持ち込んでいるだけの 中身空っぽのマガイモノでしかありません。
SEEDで唯一猫が「よかった」と思えることは、 大河原邦夫のデザインが再評価されたということでしょうか。
さて、ツインタワーに飛行機がつっこんでから、 なんだが現実が小説じみてきた気がします。
そうなると、 以前は虚構的、滑稽にみえていた物語のなかの「世界観」も 非常にリアルだったのね、と再認識させられます。 「事実は小説より奇なり」とは、事実の方がおかしいというより、 人というものが縋って生きる「常識」というものが、 いかに不安定な存在だ、ということなのでしょう。
猫の愛する富野作品のなかでも、 正直「お話だからねぇ」と感じていた世界観、 現実にはありえないと思っていた世界観があります。 例えば、F91のコスモ貴族主義や、Vガンダムの地球クリーン作戦、 ブレンパワードの「未知の遺跡を勝手に51番目の州にするアメリカ」です。
ブレンパワードの中のアメリカかなり凄いかかれ方をしていて、 国連の一機関であるノヴィス・ノアに、 核ミサイル発射の濡れ衣を着せて、自身の攻撃を正当化したり、 先にも言った強大な力を持つ古代遺跡(の、ようなもの)を 勝手に占拠してしまったりと、 なかなかなアメリカっぷりを披露してくれます。
アメリカの非道っぷりは至極納得がいったのですが、 そこまでやりながらも当のアメリカ(の人)自身が「自分が正しいことをしている」と 思い込んでいること、 そこに猫は「アメリカ人だってそこまでバカじゃないよね」っと思っていました。 例えば「原爆は落として良かった」とのたまう一部のおバカさんがいても、 国全体がそういう思想で染まってしまうとは思わなかったのです。
ですが・・、ごめんなさい富野さん。アメリカ人ってそこまでバカでした。
と、いうわけで、
「自分は常識に惑わされない」と思っていること自身ひどくあいまいだなぁと思うようになりました。
人の頭って実は非力で、時間(因果律)と、常識(条件分岐の限定)に頼らないと世界を認識できないのかもしれません。
そういったものに思考が縛られることから逃れられないのなら、
せめて「自分は常に固定概念の虜だ」と自認するように勤めたいものです。
(ああ、ようやく新年の抱負らしくまとまったわっ!)
P.S.
ブレンパワードはお勧めです。
富野さんのアニメ創作スタイルが「自分で全部作りたいけど・・」から「監督するからみんな任せた」
に移行した一作目の作品です。
ですが、一作目故に「自作」の要素もたっぷりあって豊富な富野節が楽しめる最後のトミノものかも、といった作品です。
ちなみに猫は「ジョナサンの刃」という話がとっても好きです。
| SEO | [PR] おまとめローン 花 冷え性対策 坂本龍馬 | 動画掲示板 レンタルサーバー SEO | |
