SVX日記

　 昔の職場の先輩方と数年ぶりに呑み会。あんまり楽しくて、気がつくと日が変わっていた。あわてて電車に乗る。

　 というわけで、今日の工作は休み。

　 なお、今日のヤフーニュースにこんなワイヤレスマウスが取り上げられていたが、イマサラ何でこんなニュースなのだろう。デザインもワザとらしくて美しくない。だいたいGPL無視しかけた前科のあるエレコムというのが気に食わん。ザックリ。

　 昨日は仕事を終えてから、名古屋近郊の実家に泊まってノンビリとビールを呑みつつも、今日は午前中から東京に戻るのである。というのも、一応、明日は情報処理試験の試験日なんだよね。今回は、受けるに事欠いて、調子に乗って「アプリケーションエンジニア」なんて試験区分の受験申請をしてしまっている。この区分は「高度」と呼ばれる区分の入り口みたいな位置付けで、技術者というよりは、ちょっと管理者側に踏み込んだ人を対象とした試験である。準備はあまり……というか、一切勉強していないで、今日は早めに帰って少しは勉強するのである。

　 ま、試験の細かい話は明日に回すとして、新幹線の帰りである。行きはタイミングが悪くて、弁当は食べられないわ、ビールは呑めないわ、弁当は食べられないわ、ビールは呑めないわ、ビールは呑めないわ、呑めないわ、呑めないわッ!!　……というワケで、帰りはシッカリとリベンジしてしまうのである。

　 で、どーみても「わて、初めて名古屋には寄ったんじゃけん、これがウワサの『みそかつとえびふりゃー』だっぺか？　ほな食べとかなあきまへんわ!!」という感じの人を対象とした弁当を買ってしまう。生粋の名古屋人であるから、こーゆーイロモノ弁当を食うのにちょっと躊躇してしまったが、ま、いーか。それなりにウマかったし。

　 一方で、ちょっと名古屋通なアイテムも紹介してしまおう。名古屋のどらやき「千なり」である。昨日に引き続き名古屋びいきではあるが、この千なりはウマい。日本全国のドコのどら焼きよりもウマい。なにせ、基本的には甘いものの苦手なオイラが、お土産用の8個入りの箱で購入し、新幹線の中ですぐさま開けて、食ってしまうほどにウマい。で、特にポイントとなるのが「紅あん」である。紅いあんの入ったどら焼きなのである。その筋の人なら3倍の速度で食ってしまうアイテムである。昔の千なりは「黒いつぶあん」と「白いこしあん」の2種類の商品構成であったが、いつのまにか「紅あん」と「抹茶あん」というラインナップが拡充され「白あん」はディスコンになってしまっているらしい。それにしても、千なりの醍醐味は「紅あん」にあると、オイラは思っている。写真は「つぶあん」である。「紅あん」のスゴさは、買ってのお楽しみというコトにしておこう。スゴいぜ!!

　 千なりを食しつつ、インターネットから探してきたアプリケーションエンジニアの午前の過去問題に目を通しつつ、ほえほえと居眠りしつつ……ハッ!!　っと、気がつくと東京である!!　アカン……30問くらいしか目を通していない……というか、解答と解説がないと勉強にならん。基本的に午前問題なんちゅーのは、過去の問題が解答の順番もそのままに出題されるのが多いので、問題をパッと見ただけで「ウ」!!　なんて答え方もありなのだが、それではさすがに頭に入らない。

　 ちゅーワケで、秋葉である。明日に試験を控えつつ、前日の夕方に問題集を購入しているオイラである。あー、なーんてナメ切った受験態度なんでしょう、オイラ!!　ついでにLinuxのカーネルについて書かれた本も私費で購入してしまう。あー、なーんて熱心な仕事バカなんでしょう、オイラ!!

　 と、ココで突然であるが、出版業界にひとつ苦言を申しておこう。即刻、このビロビロする「カバー」をヤメなさい!!　オイラは読む前にハギ取ってしまうが、スグに捨ててしまうワケにもいかず、とっても困っているのである。愚かにもハギ取るコトを知らない世間の一般人は、なんとなく不便を感じながらも、それに気付くコトなく、ちょくちょくカバーのズレを直したり、ツルっと抜けて本を落としたり、日々、余計な手間をかけるコトを余儀なくされているのである。そんな作業は人生の無駄づかいなんだよ!!

　 フツーに厚紙の表紙をつけなさい!!　で、その表紙をビニールコーティングしなさい!!　もひとつ言えば、本紙に妙に厚い紙を使うのもヤメなさい!!　裏写りしない程度の薄い紙を使いなさい!!　そーすれば場所を取らないし、なんと言っても机の上に「本を開いたまま置いておく」ことができるのである!!　オイラにとってはこんな試験対策本なんぞ、ノートに書き写すまでもなくパラパラと4時間ほどめくったらゴミ化する「読み物」だからいいが、人によっては机の上に本を開いてノートに書き写して勉強する人もいるかもしれないだろ!!　また、リファレンスマニュアルの類は、PCデスクの上で本を開くコトが多いのである。コタツの上で本を開くなら、カゴの中のミカンを重しにして本を開いておくコトもできるだろうが、PCデスクの上にはミカンが置いてないことが多いのである!!　少しはその本を読む状況を考えて装丁を考えなさい!!　出版業界は頭の悪いヤツの集まりなのか？　著者も少しは装丁にコダわって口を出せよ……ったく。

　 さて、いつもどおりコマかいコトにひととおりブチ切れたトコロで、いつもどおり秋葉をグルっと一周するのである。最近工作をしていないので、ナニを見ても食指が動かない。そんな中でフト見つけたのがこの腕時計だ。2個で100円。以前にコンなモノにちょっと心動かされていたので、改造してナンチャッテアイテムを密造しようと2個を購入。あとは某所で某アタッチメントを購入。使うことがあるかどうか未知数だが、あったらイイなと願いつつ購入。

　 つくばエクスプレスで家に向かいつつ、試験対策本に目を通す。こういう本の頭の方は、スゴくバカらしい常識問題が並んでいるので、イキナリやる気をなくさないように、1/3程度のところから読み始める。電車を降りるまでに1/4ほど読破して、家に着いてからビール呑んで、寝っ転がりつつ、最後まで通しで読む。最後まで読んだら、前半の1/3に目を通して午前問題の勉強は終了。午後Iはアレだ。ブッつけでガンバろう。アレは勉強して勉強できるものではない。午後IIはアレだ。ブッつけでガンバろう。アレも勉強して勉強できるものではない。さて、午後I,IIの勉強も終わったところでおやすみである。明日は明日の風が吹くのである。

　 何を思ったのか、どどーんと情報処理試験の「プロジェクトマネージャ」区分を受験してしまうのであった。昨年、アプリケーションエンジニアに落ちたにもかかわらず、なんでさらにレベルを上げてプロジェクトマネージャなのか？　そりゃあ……報奨金が「20万円も」もらえるからであるッ!!　アプリケーションなんか受かったって、同ランクの資格(ネットワーク等)を既に保持しているからという理由で、わが社の規定では15万円の半分、7.5万円しかもらえないのだ。こりゃ、どう考えたってプロマネるしか無い状況なのである(じゃ、なんで昨年受けなかったんだ？　という話もあるが……)。

　 基本的にオイラは「お金目当て」だったので、プロマネ区分の受験を決めて約半年、早々に参考書は購入したものの、そんなに気合を入れてなかった。しかし、数日前からガゼン気合が入ってきて、昨日などは近所の図書館で数時間勉強するという、世にも奇妙な行動を起こしてしまったほどである。いったいナゼか？　それは、オイラが神と崇める上司に「プロジェクトマネージャは持っておくべき」と言われたからだったりする。

　 ちょっと前から、オイラはLinuxのOSサポートで食っているのだが、その尊敬する上司に「ウチのサポートサービスは『プロジェクトマネージャ』を相手にすることが多いしねぇ」と言われてしまったのである。相手がプロマネなんだから、コッチもプロマネの資格程度は持っておく……「よく考えたら、よくわからない論理」ではあるが……イイのだッ!!　資格を持っていて損になるコトはないのだッ!!　そして、ある意味これはオイラに向けられた挑戦なのでもあるから、プロマネの資格くらいスポンと取ってみせたいのだッ!!　オイラはいつか「あの人に勝ちたい……」のであるッ!!

　 という背景もあって、オイラは気合十分。早めに起きて、試験会場に「徒歩」で向かう。なんと、今回の試験会場は駅前留学……ではなく「隣駅の前」にある大学なのである。こりゃ、ラクだわい。

　 例によって午前はサクサクだが、一度、満点を取ってみたいので、無駄に力を入れ、制限時間一杯まで粘ってみた。そして昼休み。近所であることを最大限に活用し、試験会場の隣のオープンカフェでカミさん、イッペイと合流。たこ焼きで優雅なランチタイム(？)を過ごしてから、イッペイの応援を受けて、午後の試験に臨む。

　 午後はもうアレだ。脳みそがちぎれ鼻血も吹き出さんほどに集中して取り組む。実のトコロ、情報処理試験の上位資格は、理論よりも精神論みたいなもんだ。コツといえば、論文を書く時に使う筆記用具くらいかな。ちょっと柔らかめの芯を、グリップのよい太めの軸のシャープペンに装填して挑むといい。オイラは何も考えず、かれこれ20年くらい愛用している赤いシャープペンにFの芯を装填して挑んだトコロ、この組み合わせは書きにくい上に消しにくく、まったくもって最悪だった。

　 で、今回も試験が終わった直後、バチバチとデジカメで答案を撮ってしまうオイラなのであった。特に禁止されてないし、誰に迷惑が掛かるわけでもないので問題ないと思う……が、そんなコトしてるヤツはオイラの他に誰もいない!?　えぇー!?　みんなはせっかく苦労して書いた答案、特に論文を、記念に手元に置いておきたいとは思わないのぉ？　それよりなにより、帰ってからネットで答え合わせをする時に便利だよねぇ？　……まぁ、みんなが一斉にやりはじめたら、禁止事項になりかねない気もせんでもない……よいこのみんなは絶対にマネすんなよッ!!　じゃあなッ!!

　 ガキの小さな頃から、トヨタ産業技術記念館で開催している「週末ワークショップ」という工作教室を横目で見ていたのだが、ようやく小学校中学年くらいから参加可能なプログラムが増えてきて、今はかなりの頻度で通っているオイラとガキなのであった。

　 2時間のプログラムなので、正直たわいもないものもあるが、なかなかどうして、大人でも感心するような内容のものも少なくない。オイラは楽しみの範囲の中で学ぶことこそが至高だと思っているので、ここしばらくの間、目が離せないイベントなのである。

　 で、今回のプログラムは「マイコンをつかったシンプルゲームをつくろう」だ。

　 内容は、主にハンダ付け。かなりしっかりとレクチャしてくれた。各机に装備してあるのはハッコーのステーション型、糸ハンダはリール巻と本格的。普段、温調ハンダゴテと縦巻きのハンダを使っているオイラからすると、ちょっとうらやましいほど。

　 プログラミングに関する詳しいレクチャはないが、1秒間に3百万回(※)の足し算ができるとか、起動時にオープニングメッセージに任意の内容を書き込める、という辺りで多少フォローしていた(※厳密には4MHzだと百万回のような気もするが)。

　 ガキもちゃんと時間内に完成させ、ちょっとしたインベーダのようなゲームで遊んでいた。ハンダ付けも、割とキレイにできている。7x5のLEDながら、そこそこ遊べるゲームになっているのがたいへん素晴らしい。

　 ちなみに、使っているPICは16F88だった。帰路、ガキにダイナミック点灯について説明しつつ、家に帰ったらプログラムを覗いてやろうか、などと言っていたのだが、自作のPICライタは、16F88には対応してなかったのであった。うぅむ。

　 で、実践プログラミングの前の最後のテストとして、WebAssemblyの「制御構造」をテストしてみることにする。いわゆる、条件分岐(if)、繰り返し(loop)というヤツだ。

;; https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/Control_flow
(module
    (func $log (import "console" "log") (param i32))
 
    (func (export "ifTest") (param $val i32)
        local.get   $val
        if  (result i32)
            i32.const   456                     ;; not 0: True
        else
            i32.const   123                     ;; 0: False
        end
        call        $log
    )
 
    (func (export "loopTest") (param $times i32) (result i32)
        (local $i i32)
        (local $sum i32)
 
        i32.const   0                           ;; 初期値
        local.tee   $i
        local.set   $sum
        loop        $loop1
            local.get   $i                      ;; 処理1
            call        $log
 
            local.get   $sum                    ;; 処理2 $sum += $i
            local.get   $i
            i32.add
            local.set   $sum
 
            local.get   $i                      ;; $i += 1
            i32.const   1
            i32.add
            local.tee   $i
            local.get   $times
            i32.lt_s                            ;; $i < $times
            br_if       $loop1
        end
 
        local.get   $sum
    )
 
    (func (export "whileTest") (param $times i32)
        (local $i i32)
 
        local.get   $times                      ;; 初期値
        local.set   $i
        block       $loop1
            loop        $loop2
                local.get   $i                  ;; $i == 0
                i32.const   0
                i32.eq
                br_if       $loop1              ;; break
 
                local.get   $i                  ;; 処理1
                call $log
 
                local.get   $i                  ;; $i -= 1
                i32.const   1
                i32.sub
                local.set   $i
                br          $loop2              ;; continue
            end
        end
    )
)

<!-- https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/Control_flow -->
<HTML>
    <HEAD>
        <TITLE>WebAssembly Control Flow Test</TITLE>
    </HEAD>
    <BODY>
        <SCRIPT>
            async function main() {
                const importObjects = {
                    console:    { log: (arg) => console.log(arg) },
                };
                const obj = await WebAssembly.instantiateStreaming(fetch('controlflow.wasm'), importObjects);
 
                obj.instance.exports.ifTest(0);
                obj.instance.exports.ifTest(1);
                obj.instance.exports.ifTest(2);
 
                let sum = obj.instance.exports.loopTest(11);
                console.log('total:', sum);
 
                obj.instance.exports.whileTest(5);
            }
            main();
        </SCRIPT>
    </BODY>
</HTML>

123
456
456
0
1
2
3
4
5
6
7
8
9
10
total: 55
5
4
3
2
1

　 まずは条件分岐(if)。WebAssemblyのifはスタックの先頭の値がゼロか非ゼロかで処理を分岐するものだ。JavaScriptから0を渡すとelseの123が返り、非ゼロを渡すと456が返っている。ちょっとクセがあるのは、アセンブラにはスタックのズレを検出する機能があり、if構造を抜けた際にスタックが高くなって(ズレて)いると、それが検出されてエラーになってしまうところだ。そういう場合「スタックに返り値を積んだんのですよ」と明示する必要がある。ifの後の「(result i32)」がそれだ。思い返せば、Z80の頃にプログラムを暴走させてしまう一番の原因はPUSHとPOPのズレだったよなぁ。

　 次は繰り返し(loop)。カウンタは0から加算され、指定した回数だけ実行される。中身に処理がないのもアレなんでカウンタの累計を計算して返すようにしてみた。11回のループで0〜10が加算され結果の55が返っている。

　 最後はwhileっぽい繰り返し。条件は最初に評価され、一度も実行されないことがありうるループ構造で、最も使用頻度が高いループ構造じゃないかな。WebAssemblyの場合、2重ループのようにしないと実現できないようだ。カウンタは指定した値から減算され、指定した回数だけ実行される。しかし、インデントをかますとアセンブラらしく見えないな。ないほうがいいのかな。

　 というわけで、先月末くらいからダラダラと進めていたら半月もかかってしまったが、別に急ぐ必要もないのだし、やめてしまうより、やらないより、ダラダラと進めることには十分な価値があるのだ、ということにしておこう。さて、引き続き、最初に思いついた「WebAssemblyのひとつだけの使い道」のプログラミングに入るかな。イヒヒ。