コンピュータ13ページ目の日記です

目次

前のページ
2013-01-09 続・Windows8
2013-01-10 続々・Windows8
2013-01-15 マインスイーパー
2013-01-20 ピクミン
2013-01-22 Tweetの取得
2013-01-31 いろいろ書きたいなぁ
2013-02-10 10年ぶりの更新
2013-02-20 goto不要論を本当に理解する
2013-05-04 記事の更新
2013-05-16 デザイン変えた
2013-05-23 システムちょっと改変
2013-05-25 キーボード
2013-05-31 LUMIX Phone 不具合
2013-06-04 コードゴルフの起源
2013-06-09 WEB上でのドット絵の拡大
2013-06-10 Chrome でもドット絵拡大!
2013-06-20 古いコンピューターを長持ちさせる
2013-06-21 「暗号の歴史」と、アメリカの盗聴問題
2013-06-26 TX-0の命令
2013-06-27 TX-0完了
次のページ
続・Windows8  2013-01-09 11:55:36  コンピュータ

▲目次へ ⇒この記事のURL

さて、トラブルがやってまいりましたよ。


先日書いたように、何の問題もなく Win7 → Win8 に移行できて、素晴らしいと思っていたのですが、多少のトラブルが…。


どうも、Windows Update に失敗するようです。


Win7 以前なら Fixit をダウンロードして、問題を検査・修復、という流れです。


Fixit って、存在を知らない人も多いようなのですが、Microsoft が配布しているツール群。

自分の症状を検索して、思い当たる節があったら、該当する「FixIt」をダウンロードして実行すると、問題点を自動的に検出して修復してくれます。



ところが、Win8 はここでも素晴らしい。

Windows Update に失敗してから、手動で「update」を起動してみたところ、自動的に問題点の検出・修復を行う流れになりました。

この時は気づかなかったのですが、自動的に起こったエラーのコードから該当する Fixit プログラムをダウンロードし、実行する、という流れになっているようです。手間いらず!


でも、僕の今回おこったトラブルでは、この修復に失敗しました。

「Windows Update コンポーネントを修復する必要があります。 未解決」という通知が…

ここで「解決済み」と表示されていれば自動修復された、ということで終わりなのですが、「未解決」なのです。


しかたなく、解決方法の情報を探し、ネットをさまよいました。

やっと該当しそうな Fixit を見つけ出して実行したら、さっき実行したプログラムと一緒でした。

(ここで、先に書いたように「自動的に該当するものをダウンロードしているらしい」と気づいた)



というわけで、現状では未解決のまま。

環境を残したままの修復インストール、という技が使えるのも Win8 のよいところなので、後で試してみようかしら。




Modern UI のほうも、いろいろと試してみました。


まずは、ガジェットの代わりになるものを…

自分は、時計とカレンダー、Google の ToDo list 、東京電力の電力使用率グラフ、CPU 稼働状況をガジェットで表示していました。


このうち、時計はデスクトップに表示されないと意味がないので、アプリを使用することにします。

CPU 稼働状況は好みのものが見つからなかったのと、別に必須ではないので見送り。



東京電力の電力使用率グラフは、「電力各社の」使用率を表示する Modern アプリがありました。

…起動は結構遅い。いちいち起動してみなくてはならない、というのであれば使いません。


でも、ここが Modern UI の素晴らしいところ。

「起動しないでも最小限の情報は表示できる」のです。Live Tile ってやつです。


必要とする電力会社を選択すると、その会社の電力使用率だけ表示してくれたので、設定して完了。



…以前も書いたけど、この Live Tile の仕組みは、ものすごく Wii 的。

任天堂が悩んで作ったインターフェイスは、結構良いものだったのでしょうね。


#ある意味 iPhone だって Wii のインターフェイスを真似しているわけだ。

 階層化は行わず、整然とアプリを並べ、アプリに更新情報があればアイコンで示し、横スクロールできて、画面一番下は固定情報、というインターフェイス。

 iPhone はその後階層化を取り入れたし、Modern UI は更新情報の表示を iPhone よりも Wii 的にした。

 Android はガジェットが置けるのでかなりインターフェイスが異なる。




でも、Modern UI は現在のところゲームに使うのが一番のようだ。

先に書いた通り、全画面を覆ってしまうインターフェイスはゲームに向いている。


マイクロソフト製の、Pinball FX2 と Solitia をダウンロードしてみた。無料。

まだダウンロードしてないけど、マインスイーパーもある。


…XP で人気だった付属ゲームを、しっかり復活させたね。

ただし、付属ではなくて「無料ダウンロード」だけど。


ここで、付属品でないのにはちゃんと意味がある。

Pinball FX2 は、ピンボールの物理シミュレーションエンジンがコアであり、テーブルのレイアウトはデータに過ぎない。

そして、無料で遊べるテーブルは1つだけで、別売りのテーブルがたくさんある。


「付属ソフト」だったら、OS に金払ってるんだから全部タダで遊ばせろ、という話になるかもしれない。

でも、Pinball FX2 は OS の付属物ではなく、「無料で配布されているソフト」だ。無料なのだから、どこかで儲ける仕組みがあっても、文句を言えるようなものではない。


#Pinball FX2 は X-BOX 360 でも販売されているゲームのようだ。テーブルデータは共通なのだろう。



Solitia も同じく。

基本ゲームは無料で遊べますが、「デイリーチャレンジ」というモードに入ろうとすると、30秒の広告動画を見せられます。同じモードを連続して遊ぶと、時々挿入されます。


無料だからこれくらいは我慢しないといけないのでしょうね。



Pinball FX2 も Solitia も、もともと僕がピンボールやカードの一人遊びが好きだという事実を差し引いても、よくできている。

というか、好きだからこそ、細かな部分まで作りこまれていることに好感が持てる。


多分、マインスイーパーも、マインスイーパー好きには大喜びできる進化を遂げているのだろうな。


▲目次へ ⇒この記事のURL

関連ページ

マインスイーパー【日記 13/01/15】

続々・Windows8【日記 13/01/10】

別年同日の日記

03年 Mac の新しい WebBrowser

17年 Android の cordova で file を扱う


申し訳ありませんが、現在意見投稿をできない状態にしています

続々・Windows8  2013-01-10 12:19:44  コンピュータ

▲目次へ ⇒この記事のURL

昨日のつづきです。


Windows8 を入れてみたけど、動きがおかしい。どうも、Windows Update が動作しない。

これ、思い当たる節があって、Win8 を入れる前の Win7 でも、おかしいことがあった。それと同じ症状。



Win7 では、Fixit を使って修復したが、Win8 では修復できなかった。

探したときにわかったが、Win7 には存在するが、Win8 には用意されていない、という Fixit プログラムも多い。

まだ十分に整備されていないのだろう。


つまり、Win8 はまだ「環境が十分整っていない」ともいえる。

今月末までに入れれば安いけど、それは人柱だからだということを肝に銘じよう。



Fixit が使えないし、そもそも自分の遭遇した状況の解決方法もわかっていないようで、手動解決もできない。

掲示板などで情報を集めると、「クリーンインストールしたら直った」という話ばかり。

それは面倒だから避けたい。


で、次善策。Win8 には、7 までにはなかった「リフレッシュ」という操作がある。




7 までは、クリーンインストールといえば、全部を消して、CD などのメディアからもう一度 Windows を構築することだった。

8 ではそうではない。「初期状態に戻す」という方法がある。


これを使うと、レジストリを初期化し、ディレクトリ構成を初期化し、インストール直後の状態に戻る。

すでに入っている Windows のファイルなどは、チェックサムなどをとって変更されていないか確認するようで、初期化にかかる時間はインストールよりも短い、らしい。


…らしい、っていうのは今回使っていないからね。



で、このクリーンインストールに準じたものとして、「リフレッシュ」がある。

Windows のシステムは初期化する。Program Files の下も初期化する。


でも、それ以外のディレクトリは残したまま。

ユーザーの設定なども保存される。


さらに、Modern UI のソフトに関しては、確かに一度消されるのだが、自動再インストールしてくれる。



デスクトップ環境の、従来のソフトに関しては、Program Files 下に入っているものは消えてしまうが、そうでないフリーソフトなどは残っていて、そのまま使える。


さらに素晴らしいのが、削除する直前の「インストール済みソフト」の一覧を、デスクトップに HTML ファイルで残してくれる。

ファイルの作成者がダウンロード可能な URL を示している場合、HTML ファイルからダウンロードページにリンクされている。


つまり、確かに一度ソフトは消されるのだが、再インストールがすごく楽。


多くのソフトが、Program Files とは違う場所にデータフォルダを作っている。

シェアウェアのレジストレーション情報などもそういう場所に入っている場合、レジスト済みの状態から復活できる。すごく楽。




というわけで、僕の遭遇したトラブルは、「リフレッシュ」によって短時間で解消した。

Win7 までには使えなかった、魔法のような技だ。

(もしかしたら、Fixit が整備されていないのは、「整備されていない」のではなく、リフレッシュがあるから不要、という考えかもしれない)




消えたプログラム群は、必要なものはすぐに再インストール。急を要さないものは後回し。

もう不要で使っていないソフトは入れない。ちょうどよいから大掃除だ。


バージョンアップしているソフトもあり、たまにこういう作業をするのも悪くないと思った。

…愛用していたソフトが、フリーではない有料新バージョンになっていて、旧バージョンを探すのにちょっと苦労した。

(作者ページには新バージョンしか置いておらず、別のページに旧バージョンを見つけた)




これから入れよう、と思っている人へ。


Win7 からは、環境をそのままにバージョンアップできます。


「不安定だからやめたほうがよい」という声も聞かれますし、実際自分がインストールしたものも不安定になったわけですが、まずはこれを試すのがおすすめ。


で、不安定だったら「リフレッシュ」を試しましょう。

これで多分安定します。代償として、せっかく保持していた環境が失われます。


でも、「完全に」失われるわけではなく、先に書いたように再構築は簡単。

クリーンインストールだと、環境の再構築に結構手間がかかりますからね。



Win8 のアップグレード時の環境保持は、Win7 の Windows ディレクトリをリネームし、新たな Windows ディレクトリを作ることで行われます。

ほかのディレクトリを消さない、というだけで、この作業自体はクリーンインストールと変わりません。


そして、この後、古いレジストリのデータを移行し、Win7 に上書きされているファイルなどを移行します。



おそらくは、Win7 のどこかの段階でファイルが壊れ、Update の動作がおかしくなったのだと思います。

Fixit は、これをさらに上書きすることで修正を行った。


でも、Win8 に移行する際に、Update をおかしくした「変更」は移行されたが、Fixit はマイクロソフト製のものなので、Windows7 専用の変更である、と認識して移行されなかった。

(もしくは、移行はしたが、Windows8 では仕組みが変わったので無意味になった)


この手順だと、Windows7 が不安定になったことがある場合は、Fixit してあっても、移行すると再発することになります。



でも、リフレッシュを行うと、これらの「移行された変更」を全部キャンセルしてやり直すため、問題が解消します。

そのかわり、レジストリの変更なども伴う「ソフトのインストール」も、なかったことにされるわけです。




▲目次へ ⇒この記事のURL

別年同日の日記

05年 Switch!

16年 国立科学博物館

16年 国立科学博物館(続き)

16年 上野公園

18年 原初のプログラム


申し訳ありませんが、現在意見投稿をできない状態にしています

マインスイーパー  2013-01-15 14:39:57  コンピュータ

▲目次へ ⇒この記事のURL

Windows 8 の話が続きすぎたのでどうするか迷ったが、書いておこう。


マインスイーパーも進化しているのだろうなと書いたが、あの時点では確認してなかったので遊んでみた。


…進化はしているが、異常進化だな。死に至る道。これはひどい。


と、思って軽くググると、やっぱ「すごく進化した」ことを書いてあるページは多数。でも、大抵は好意見。

ただし、好意見のほとんどは「紹介記事を見たら見た目がきれいになっていた」ことを歓迎するもので、遊んでいない。



自分はそれほどマインスイーパー好きではないが、会社勤めしていたときの先輩が好きで、昼休みに延々遊んでいた。(Windows 98 の時代の話だ)


僕はその時点でのマインスイーパーの印象は「マウス練習用ソフトでしょ?」程度だったのだが、その先輩にマインスイーパーの何たるかを教え込まれた。

そして、このゲームを愛してやまない人の気持ちは理解できた。


というわけで、その目で見ると、進化の仕方が間違った方向を向いていて、ひどい。




まず、愛してやまない人は何が好きなのか、軽く整理。

あくまでも、上記先輩の場合ね。「俺はそれとは違う理由で愛しているのだ」という人がいても許してほしい。


このゲームは、パズルゲームではなく「レースゲーム」だ。

マウスを操作して、すべての爆弾を探し出した時間を競う。


一気に開いたタイルの状況を確認し、爆弾が確実に埋まっている「パターン」を見つけ出し、該当箇所に旗を立てる。

旗が立ったことにより「安全マス」が明らかになるため、ここを素早く開けていく。


この開けた作業によって、新たな「確実パターン」が発生するので旗を立てる。

これを、ほぼ条件反射で行えるようになるまで練習する。


どうしてもパターンにはまらない、埋まっている場所がわからない局面が、必ず発生する。

少し論理的に考えればわかる場合もあるが、長考すれば時間は確実にかかる。


長考して安全策を取るか、一か八かで開けてみて、ハイスコアを狙うか…緊張の瞬間だ。

思い切って開けてみて成功しても、安堵の暇はない。すぐに次の箇所にかからなくてはならない。




これが、マインスイーパーを愛してやまない人の遊び方。

激しいアクションゲームなので、マウスの調子が悪いのは禁物だし、バックグラウンドで重いアプリが走っていたりしてはいけない。


で、Win8 のマインスイーパーを見てみる。

画面が美麗になった。それはまあいい。


パネルが開くときに、ふわっと文字が表れるアニメーションが入るようになった。

普通に見れば、美しい表示方法。


でも、アクションゲームだと思うと、この処理は余計だ。



パネル全体が画面の適切サイズに表示されるように、無段階ズームとなった。

これにより、タイルのサイズは無段階の可変となった。


普通に見れば、常に大きく表示されて見た目が良い。


そして、マウスホイールで、サイズを自由に変えられる。

これが余計。


元々、マインスイーパーは「左右同時押し」を多用するゲームだ。

数字タイル周辺に、その数字と同じ数の旗が立っている場合、数字を左右同時押しすることで、周辺の「旗が立っていない」タイルをまとめて開けることができる。


この「左右同時押し」は、ホイールマウスではホイールクリックでもよい。

でも、この時にホイールが「すべる」と、画面がズームされてしまうのだ。


アクションゲームとして、激しくマス目を指定して回っている際に急にズームが入ると…

当然、間違ったマスをクリックして、「そこには爆弾があるとわかっていたのに」爆発させるような事態が発生する。


これは、ゲーム性以前の、操作体系がおかしい、という問題だ。




たとえば、シューティングゲームで自機を動かす際に、本物の戦闘機のようにラダーやエルロンが動作するアニメーションが入ってから移動するとしたらどうだろう?

「リアルで美しい」という評価以前に、操作性の悪さが問題となるだろう。


タイルのサイズが可変となったのは、基本操作の混乱を招いている。

ジョイスティックが壊れているようなものだ。その状況でシューティングを遊べるだろうか?



以上がクラシックモードの状況。




Win8 のマインスイーパーの目玉は、むしろ「アドベンチャーモード」のほうだ。


だから、クラシックモードが多少ひどくても気にすることはない…



アドベンチャーモードは、最初に書いた「アクションゲームとして」のマインスイーパーを完全否定するものだ。

完全に、ゆっくり遊ぶパズルゲームであることを前提としている。



自分は遺跡を調査する探検家だ(インディージョーンズのようなイメージを思い浮かべるといい)。


行く手には魔物や罠がうようよしている。

そして、遺跡のほとんどは長年忘れ去られていたせいで、土に埋まっている。


この「土」を掘って、罠をよけながら進む。

土を掘ると数字が出てくる。この数字が周囲に存在する罠の数、というのは普通のゲームと同じ。


従来のマインスイーパーと決定的に違うのは、自分の位置を示す「カーソル」として、探検家のキャラクターがいることだ。


さて、問題は、このキャラクターだ。

基本的には掘ったマスに進んでくれるので、数字が見えない。わざわざ後戻りして、数字を確認してからまたすすむ、ということを繰り返さないといけない。



さらに、探検家の進行に合わせて、画面が横スクロールする。

「安全なマス」を連続してクリックしようとしたとき、スクロールによって「隣」をクリックしてしまうことがある。


慎重さを要求されるパズルゲームであるにもかかわらず、誤操作を誘発する仕組みになっているのだ。

これはいただけない。



この探検家が進めないところのマスは掘れない。

また、遺跡の中は壁で区切られていて、ここは土ではないので掘れない。



この結果、数字が得られない個所が散在する。


従来のマインスイーパーでは、どんなに考えても解決できない局面になったときは、別方面からパネルを開いて行ってヒントを増やす、という操作を行った。


でも、アドベンチャーモードでは、「ノーヒント」でマスを開けねばならない局面が激増した。

パズルゲームなのに、ノーヒントで解かないといけない局面が多すぎるのだ。



一応、対策はしてある。

探検家は1面ごとに3つの「ハート」を持っている。まぁ、ライフだな。

罠にはまるとハートが一つ減り、なくなるとゲームオーバーだ。


さらに、「ツルハシ」というアイテムもある。

周囲の8マスの土をいっぺんに掘れるうえ、普通は掘れない「岩」も壊してしまう。

そして、これを使用すると、罠を開けてもハートが減らない。


さらに、爆弾もある。

これはツルハシでも壊せない「壁」も壊せるし、罠も破壊して通れるようになる。



これらのアイテムは、土を掘った時に出てくることがある。


これらによって、解決できない局面が激増していても、すぐにゲームオーバーとなるわけではなく遊び続けられる。



アイテムはほかにもある。

ツルハシ、爆弾のほかに、


・矢。モンスターを倒せる。

・鍵。扉を開けられる。


矢と鍵は、事実上同じもの。扉と鍵が2種類ある、ということだ。

次の面には持ち越せない。



・ハート。ハートが増える。

・盾。ハートが減る局面で、替わりに盾が減る。


ハートと盾は事実上同じものだが、「ハートは各面3個でスタート」で、盾は次の面に持ち越せる。

微妙な違いだが、盾を手に入れたら罠を開けないように気を付けたいところ。


・宝物


コインだったり宝石だったり宝箱だったり。

目的は宝を集めることで、その価値が点数になる。


・四葉のクローバー


スペシャルフラッグだ。

これを入手以降、宝物の点数が2倍になる。でも、次の面には持ち越せない。



さっきから「次の面」と書いているが、出口に入ると次の面に行く。

従来のマインスイーパーと違って、全部の罠の位置を特定する必要はない。




アドベンチャーモードに関しては、「ワリオの森」との類似を感じた。


基本のゲームデザインが悪くて問題が生じているのだが、アイテムを増やしたり操作方法を増やすことで無理やり回避する。

素地が悪いのだが、華美に装飾すればなんとか見られる形になるだろう、という作り方だ。



まぁ、ワリオの森がそれなりに面白かったように、アドベンチャーモードもつまらないわけではない。

でも、1面が広いので結構時間がかかるうえに、面クリアするとライフも3個に戻るのでなかなか終わらない。


適当なところで切り上げてアプリを終了すると次回は続きから遊べるので、何日にもわたって遊ぶことになる。


すでに、マインスイーパーの気軽さはない。



なんか、ファミコン時代の「移植」を思い出す。

いいゲームだったのに、移植に際して追加モードが増え、従来の良さが台無し、みたいな。



▲目次へ ⇒この記事のURL

別年同日の日記

04年 ぎょうざ

10年 ポケモンスクランブル

14年 zepto で clone

17年 あの頃のインターネット


申し訳ありませんが、現在意見投稿をできない状態にしています

ピクミン  2013-01-20 09:58:48  コンピュータ 家族

▲目次へ ⇒この記事のURL

ピクミン

ちょうど1週間前、1月13日に友人宅で毎年恒例の新年会を行った。


その場で、友人が購入した Wii U 見せてもらった。

我が家ではどうも食指が動かず購入していないが、面白かった。


子供たちが興味を持ったのが、Nintendo Land 内の「ピクミン」。

興味を持った理由は、ピクミンというゲームの存在を以前から子供に話していたせいもある。


ただ、Nintendo Land のピクミンは、ピクミンをテーマとしてはいるが、本来のピクミンとはかなり違うゲームだ。



あまり興味を持っているから、家に帰ってからピクミン1を見せてみた。

すでにいろいろと忘れているが、それなりに順調に進めて、どんなゲームかは見せられた。


この1週間、要望に応じて少しづつ見せている。

(8歳の長男ですら、まだ難しいし怖い、というので僕が遊んで見せている)


でも、大水源に入ってイモガエルにかなりやられる。

あれー? どうやって倒すんだっけ?



#写真は、長女(5歳)が描いた「赤ピクミン」の絵。

 気に入ったようで、小さい紙にいろいろ描いて、並べて遊んでいる。




情報を探していて驚いた。

9日85人クリアが最短・最少人数だと信じていたのに、もっと記録を縮めている人たちがいる。


最短は6日らしい。ただし、この場合は「最少人数」という縛りは外れるようだ。


しかし、ピクミンというゲームの構造上、6日は絶対にそれ以上縮まない限界値である。驚愕する。

(全部で5ステージあり、最初のステージはチュートリアルを兼ねるので、必ず2日かかる)



最少人数である85人だと、8日になるらしい。

それでも、発売後しばらく信じられていた「9日」より1日少ない。

ピクミンの9日・85人クリアに挑んだことがある人なら、1日縮めるということがどれほど驚異的かはわかるだろう。



さらには、最少人数として50人でクリアできるという情報が。そんな馬鹿な!

…と思ったら、海外版では一番重い荷物が50人で運ぶらしい。日本版では85人なので、これは仕様の違いによるもの。日本では再現できない。


それでも、85人でも人数の割り振りに苦労したのに、35人も減らしてしまっては仕事の組み立て方が全く異なってくるはずだ。


9日・85人よりも少ない日数・人数でのクリアは、心底すごいなぁ、と思う。




85人9日クリアだって、友人に話しても真意が理解してもらえない話の一つだ。

「すごくやりこんだ」というだけの話だと思われてしまうことがほとんど。


そうではなくて、本来ピクミンが85人9日を目指すゲームになっている、ということなのだ。


やりこみ、という言葉について特に定義はないが、開発者も想定していなかったようなプレイをすることだと、僕は思っている。


でも、ピクミンは、85人9日クリアを「ゴールの一つ」として設定してある。

だから、これを終わらすのは「やりこんだ」のではなく、設計者の意図をちゃんと読み取って、投げかけられた謎をちゃんと解き終わった、というだけに過ぎない。


だから、85人9日クリアへの道は結構わかりやすいし、だれがやっても同じ結論にたどり着く。

そして、この結論にたどり着いたとき、ピクミンというゲームの設計(細かく言えばフィールドデザイン)の巧妙さに唸ることになる。



85人9日を目指すゲームでありながら、その3倍を超える「30日」を制限時間として設定し、人数も時間次第でほぼ無制限に増やせる。


ただ、人数を増やすと時間がかかるので制限時間を圧迫する、という問題はある。


これにより、下手な人は制限時間をいっぱいに使って人数を増やせば敵にやられても大丈夫だし、上手な人は時間を縮めようとして、その結果敵にやられてはならない、という緊迫感にさらされることになる。


初心者でも上級者でも、自分に合わせた遊び方が自然にできてしまう、誰もが遊べるゲームに仕上がっている。

この許容力、僕もゲームを作っていた人間なので、すごいことだと思う。




そして、人数を稼ぐ時間を最小に圧縮した場合、9日間ですべてのパーツを集めることができるように設計してある。

この時、85人をどこにどのように割り振るか、一切の妥協がない。


1人変わってもタイミングがずれてしまうが、正しい人数を割り振ると、全く時間の無駄が生じないのだ。

ここが、「最初から仕掛けられた謎」であって、「やりこんだ結果」ではない、と感じている根拠。

非常に設計が美しいのだ。




これを1日さらに縮める、というのは間違いなく「やりこみ」だ。

しかも、すでに「非常に美しく」設計されたものを上回るのだから、すごい偉大なやりこみだと思う。


ちなみに、人数を稼ぐのに時間がかかるにも関わらず、「6日」は最少人数ではない、というのは、人数が多いとものを運ぶ速度が上がるためだろう。


6日ルートを開発した偉業はたたえつつ、美しさにおいては最少人数で8日のほうがすごいことだと思う。




ともあれ、今この日記を書いている横で、子供が「ピクミンまた見たい」というので大水源に挑んできます。

すっかり1日1個集まればよい、という普通のプレイスタイルでやっております。


#でも、子供が悲しむからできるだけピクミンが死なないようにしている。

 これはこれで面倒な縛りだ。

 敵が断末魔をあげて倒れるのはショックではないらしい。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

家族

関連ページ

夏の家族旅行・福島【日記 15/08/12】

宮本茂 誕生日(1952)【日記 13/11/16】

別年同日の日記

06年 ウッドデッキ完成

07年 人生初ギャグ?

15年 高柳健次郎の誕生日(1899)

15年 SIMON は世界初のPCか?

15年 【追悼】森公一郎さん (LSI-C の作者)

17年 1996年のそのほかのゲーム


申し訳ありませんが、現在意見投稿をできない状態にしています

Tweetの取得  2013-01-22 23:56:16  コンピュータ

▲目次へ ⇒この記事のURL

後日追記

この日記に書いた方法、2013年7月半ばから使えなくなったようです。


TOPSYガジェットが停止した。


…っていきなり書いて意味が分かる人がどれくらいいるのだろう。


TOPSY は Twitter 関連サービスで、Twitter で発言されたことに関しては、Twitter よりも詳しい。


試しに同じ内容を Twitter と TOPSY で検索してみればわかる。

Twitter は最近の内容しか見つからないが、TOPSY では数年前の情報でも見つかる。


まぁ、Twitter というのは「垂れ流し」がよいのであって、わざわざ過去を詮索するものじゃない。

だから、TOPSY なんて知らない、という人のほうが多いだろう。


で、そのなんや知らん TOPSY とかいうののガジェット、といわれては、余計にわからないだろう。




ところで、外部から自分のサイトに見に来てくれた人がいると、その「参照元」のページを知ることができる。


趣味でサイトを作っていると、見てくれる人がいる、という事実がありがたい。

検索してきてくれた、というだけでも嬉しいのだが、誰かがリンクを張ってくれたとなると、なお嬉しい。


それが批判であれ賛同であれ、リンクされるということは、相手が「わざわざ人に教えたくなる」と認めてくれたということだからね。


そして、参照元がわかると見に行きたくなる。…あれ? ならない人もいる?

僕は見に行きたかった。見てどうなるものでもないけど、自分のサイトが話題に上っていればやっぱりうれしいのだ。



でも、この「参照元がわかる」という機能は、嫌いな人だっている。

特に、批判的なことを書く場合は、相手を怒らせるかもしれない。

僕だって、そういう時は参照元が知れないとよい、と考えることがある。


#僕の場合、知れたら嫌だな、と思う場合は最初から書かないことにしているけど。


というわけで、2ch なんかだと間に1枚、jump ページが挟まれる。

これで、たどれるのは jump ページまでになる。実際の参照元が知られることはない。


でも、2ch の場合はミラーを提供しているサイトが山ほどあり、そういうページからのリンクは jump ページを挟まなかったりするので、早かれ遅かれ参照元を知ることができる。



twitter では、「短縮 URL」が多用される。これもまた、jump ページと同じ効果をもたらす。

こちらは厄介だ。ミラーに相当するサイトがあったとしても、普通は短縮 URL をわざわざ展開したりはしない。


twitter では t.co ドメインが短縮 URL として使用される。

なので、このドメイン名に限っては twitter で検索をかけてみると、参照元が見つかることもある。


でも、twitter の検索機能は前述のとおり貧弱だ。そこで、TOPSY の出番となる。




ふたたび話が TOPSY に戻ったところで、ガジェットの話に移ろう。


TOPSY は、検索サービスを提供するだけでなく、特定の検索項目の Tweet を、リアルタイムに表示してくれるガジェットを配布していた。


検索項目としては、語句検索だけでなく「wizforest.com」なんてサイト指定までできた。

しかも、短縮 URL でもジャンプ先が当サイトであれば、ちゃんと検索に引っかかる。



これが非常に便利で、わざわざ自分で検索して情報を取得するよりも簡単だった。


そんなわけで、僕のページの中にもこっそり貼り付けてあった。

t.co から参照されたとしても、一生懸命参照元を探そうとするよりも、ガジェットで情報を見れば十分だ、というわけだ。




で、年明けには動いていたのだが、1月上旬に急に動かなくなった。

おかしいな、と思って TOPSY のページを見に行ったが、まだガジェットの配布は行っていたし、停止するようなアナウンスもない。


サーバー不調かな? と思ってしばらく様子を見るも、一向に直る気配がない。

そのまま10日くらいたったので、これはさすがに停止なのかな、と情報を集める。


そうしたら、ガジェットを停止したとは書かれていなかったが、1月8日に「TOPSY API を有料化した」というお知らせがあった。


ガジェットはおそらく…というか、十中八九 API を呼び出しているのだ。

配布を続けている理由は「金を払えばまだ動く」からであり、つまりは金払えと言われているのだ。



停止当初は日本語でこの件を発信している人もいなかったが、再度調べたら停止して困っている人、これが有料化問題であると気づいている人もそれなりにいた。

それどころか、TOPSY に依存していたサービスも存在したようで、サービス停止に追い込まれていた。




さてと、僕のページではどうするか。

しばらく TOPSY をいじりながら考える。API を有料化しただけあって、通常の検索方法は「差別化」されているようだ。


wizforest.com について調べても、以前のように「サイト全体」の Tweet が表示されなくなった。

www.wizforest.com について調べると、トップページをリンクした Tweet のみが出てくる。


他にもいろいろな URL を入れると、その URL へのリンクのみが出てくる。


うーむ。今までのような情報は金を払わない限り出してくれないらしい。



いじっているうちに、高度検索の機能を使うと「ちょっといい」ことがわかってきた。

wizforest.com サイト内で、「*」について検索すると、下位のパスへのリンクも含めて、かなりの Tweet が表示される。


最初は * はワイルドカードなのかな? と思ったが、そうではないようだ。- でも % でも = でも、ある種の記号ならよいらしい。

多分、検索時に「ノイズ」として扱われる文字種で、同様に「ノイズ」の含まれた Tweet であれば検索されるのだろう。




でも、これですべてが見つかるわけではなかった。取りこぼしがかなり多く、7割程度しか取れないようだ。


「自分のページの URL」がすべてわかっていて、大した分量でなければ、総当たりで取得するのがよいようだ。

「7割」という数値は、最終的に総当たりでとったデータ数から導いたもの。


しかし、これは TOPSY に攻撃を仕掛けているようなものなので、何度も行うのはよくない。



誰かが Tweet すれば、自分のページに閲覧者が来て、t.co が参照元だとログに記録されるだろう。

この時だけ、TOPSY に検索をかけてみるのがよさそうだ。



というわけで、以上の操作を自動的に行うプログラムを作り、cron に登録。


最初の1回のみ、プログラムを少し書き換えて、できる限りのデータを取得したが、今後は少しづつデータを取得しようとする。




ところで、TOPSY の検索結果は「おかしなデータ」が時々含まれるようだ。


・Twitter 上では消去された tweet が残っている

・TOPSY 上でデータが壊れている


の2つのパターンがあるように見える。


消去された Tweet は、いくつかの必須パラメータが取得できない。

このため、当サイトでは取り込み時に記録されずに消えている。


TOPSY 上のデータが壊れているのは、なぜかユーザー名が変わっているとか、日付が変わっているとか、そういう状態だ。

取り込んだデータを元に Twitter の該当データを取り寄せて突き合せれば、壊れたデータかどうかわかる。


でも、今はそこまでやっていない。厳密性はあまり重要ではないからだ。




最後に、収集したデータを表示するプログラムを作った。


各ページの一番下、1行掲示板よりも下に、該当ページに関する tweet が表示される。

…話題になることなんてそれほどないから、ほとんどのページで表示されないけどね。


また、reverse link のページでは、最新の関連 tweet 20件と、よく tweet されるページ上位20件を、各ページへの最新 tweet1件を付けてを表示している。



▲目次へ ⇒この記事のURL

別年同日の日記

03年 FCE Ultra for C700

04年 2冊のファミコン本

07年 ドーラと大冒険!

14年 ボタンの左右位置

16年 デビッド・ローゼン 誕生日(1930)

19年 SEGA TETRIS


申し訳ありませんが、現在意見投稿をできない状態にしています

いろいろ書きたいなぁ  2013-01-31 17:15:45  コンピュータ 料理

▲目次へ ⇒この記事のURL

ずいぶん長いことほったらかしのページだが、いろいろ書きたいなぁ、と思ってはいる。


仕事が忙しくて現実逃避したいだけかもしれない。



算数コーナー、虚数と複素平面の話を書きたい。

最終目標である、マンデルブロ集合の理解のためには必須だからだ。


ネットで調べると、虚数が何の役に立つかわからなくて、勉強するモチベーションが維持できない高校生は多いようだ。


虚数、むっちゃ役立つよ。日常生活にすごく浸透しているよ。

惜しむらくは、計算がブラックボックスになってしまっていること。


現代の生活は、虚数がなくては成り立たないといっても過言ではない。

でも、その計算はいたるところに組み込まれたコンピューターが勝手にやってくれているので、虚数が利用されていることに気づきもしない。


もちろん、虚数のことを知らなくてもその機械は使えるわけだ。


でも、そんなことを言ってしまうと、掛け算すら勉強する意味がなくなってしまう。

いまどき、ちょっとややこしい掛け算ならすぐ電卓を使えるわけで。


虚数はすごく役に立つ。知らなくても大丈夫だけど、ちゃんと役立つし面白いから勉強しましょう。



虚数、というか、虚数を含む「複素数」の話だな。

そして、複素数平面を紹介して、話はマンデルブロ集合へ進む予定。



そのあとはフーリエ変換も書きたいなぁ。

これも非常に面白い話。


フーリエ変換を書くなら、当然「この世で最も美しい数式」であるオイラーの公式も登場するしね。


日常生活に浸透している、という意味では、マンデルブロよりもフーリエ変換だな。

だから、順序は逆になるかも。




OldGood COMPUTER!! も更新したい。

一番書きたいコーナーなのにすっかり更新が停止している。


停止している理由は、変なプレッシャーからなのだ。

このサイトを書き始めた時は誰も気にしていなかった Jobs が、その後有名になり、死んで、直後に伝記本が発売になり、すっかり英雄になってしまった。


面白おかしく書こうと思っていたのに、うかつなことを書いたらファンから苦情が殺到しそうだ。



とりあえず、歴史の話は疲れるので軽い話題をやりたいと思っている。


たとえば80年代のデータ保存機器の話。

音楽用カセットテープに保存していた、と妻に話したら、最初は信じてくれなかった。

(もう10年以上も前、妻と知り合ったころのこと。その後論理的に話して理解してもらえた)


今の人の多くは、8 inch 「標準」フロッピーディスクすら見たことないんだよなぁ。

このフロッピーから、QuickDisk を5枚自作できる、なんて話を覚えている人がどれくらいいるのか。



一番書きたいのは、記録媒体よりも、「そのコピーを作らせないための技術」のほうかな。

少し前に CCCD っていう、CD のコピープロテクトがあって…大々的に失敗していたけど、カセットテープや Disk の時代はいろいろと面白いプロテクトがあった。


あの話を書きたい。




たとえばスプライトの進化の話。


自分が使ったことあるのは、MSX から SEGA SATURN までだ。

X68k は使い込んだから思い入れがあるが、PC-88VA とか FM-Towns のスプライトも味があって捨てがたい。


スーパーファミコンが、スプライトの優先順位の先頭位置を変える機能があったなんて、どれくらいの人が知っているだろう?

(ファミコンのときは「ちらつき」をソフトで作っていたが、スーファミではハードでちらつかせることができる)


でも、あまり個別論に入ると面白くないので、概説のみになる予定。


実は、これは軽く原稿を書いてみてお蔵入りしている。

スプライトは「画面表示」の一部機能なので、先に画面表示の話をしないといけない、とわかったから。




あと、料理コーナーね。

以前にも日記に書いたけど、昔よりもずっと料理を作るようになった。


ただ、「男の料理」というよりは、「主夫の料理」になっちゃってるけどね。

冷蔵庫にあるもので、ちゃっちゃと料理する感じ。わざわざ人様に伝えるほどのものではない。


それでも、時々「これは」と思うようなものがあって、自分のためにもレシピを記録しておきたいと思っている。


去年のクリスマスの鳥とかね。




と、取り留めなくだらだら日記に愚痴を書いてみた。


実のところ、そろそろ更新復活したい、と公言して自分を追い込んでいるのだ。

あと、うかつなことを書いても総攻撃しないで、という言い訳(笑)



子供が大きくなってきたので、土日に多少、時間が取れるようになってきた。

上に書いたように「スプライトについて用意した原稿」はこの時間に書いてみたもの。


平日は仕事で忙しいけど、土日くらいは個人的な作業をしてもよいかと思ってる。

ただ、時間はやはり少ないので、ゆっくり更新になるだろうけどね。


▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

料理

関連ページ

10年ぶりの更新【日記 13/02/10】

ページ4つ【日記 13/08/01】

別年同日の日記

03年 映画鑑賞

03年 アンティキュティラ

05年 ねずみの手も借りたい

10年 PS3

11年 見上げてごらん、夜の星を

15年 Landiskと格闘中

15年 Landisk のデータ復旧

17年 【追悼】中村雅哉さん


申し訳ありませんが、現在意見投稿をできない状態にしています

10年ぶりの更新  2013-02-10 09:15:37  コンピュータ

▲目次へ ⇒この記事のURL

OldGood COMPUTER!!」のページを更新しました。


更新してから気づいたけど、前回更新は 2003年2月1日。ちょうど10年ぶりの更新でした。


2週間前の日記に更新再開をほのめかすようなことを書きましたが、実はあの時点である程度原稿を書いていました。


ただ、今までも「原稿を用意した」ことはあったのね。それが「更新」に結びつかなかったのは、書いているうちに「書きたいこと」を見失いがちだったから。


自分の書きたいことは、いまみんなが使っている PC に至る歴史なのですが、「このテーマで書こう」と考えても、どうも外れて行ってしまうことが多かった。

2週間前の日記は、「途中であきらめず、原稿を最後まで書きあげる」ことを自分に課そうとしたのです。




ところで、該当日記にも書いたように、この時点での原稿は「スプライト進化の歴史」でした。


スプライトって、基本的に「2つの異なるアドレスの VRAM 内容を混合するハードウェア」です。

画面重ね合わせってことね。


あれ? じゃぁ、最初の VRAM ってどんなんだったんだ?

そもそも、最初はベクタースキャンだったはずなのに、VRAM は存在したのか?


…って、いろいろ疑問が出てきました。

悪い癖です。いつも、こうした疑問で話が横道にそれ、原稿は途中でほったらかしになるのです。



でも、今回は少し違いました。

最初の CRT 接続マシンを調べていたら、PDP-1 にはすでに搭載されていたことが判明。

PDP-1 は、TX-0 を参考にしたマシンです。調べてみると、やはり TX-0 に搭載されています。


TX-0 は、名著「ハッカーズ」に登場するマシン。プロトタイプマシンだったので量産はされず、それが故に歴史に埋もれているのですが、いつか詳細に調べて書きたいと思っていたマシンでした。


いい機会だ。ここは TX-0 を調べよう…と調査を開始すると、TX-0 は Whirlwind というマシンをベースにしていることがわかります。そして、Whirlwind には CRT が搭載されているし、どうやらこれが「世界初の CRT 搭載マシン」だったのです。




…で、スプライトの話は置いといて、Whirlwind の話になりました。

本当は TX-0 も一緒に扱うつもりで書き始めたのですが、調べれば調べるほど Whirlwind が興味深いマシンで、話をぶれさせないためにこれ一本に絞りました。



今の我々が使っている PC は、明らかに「PDP」の流れを汲んでいるコンピューターです。

でも、いわゆる「コンピューターの歴史」には、UNIX が PDP-7 上で作られた、という記述以前には、PDP は登場しないことが多いのです。


だから、PC がどうしてこういう設計になっているのか、調べてもすぐにはわからない。



コンピューターの歴史の開始当初は、ENIAC の流れを汲む UNIVAC がコンピューターの花形。

IBM もこれを後追いしてコンピューターを作り始めます。


でも、いつしか状況は逆転し、IBM が最大手になります。


そして、UNIVAC も、IBM も、ENIAC の流れを汲んで実用性重視の「つまらない」マシン(といっては失礼だが)を作っていたはずなのに、いきなり突然変異のように PDP-7 という「非常に洗練された」マシンが登場する。



ここらへん、どうなっているのだろう? 長年の疑問でした。

でも、ミッシングリンクのように感じていたこの部分を、Whirlwind が埋めてくれました。




▲目次へ ⇒この記事のURL

関連ページ

WWIの命令と画面

50年代の画面表示技術

別年同日の日記

03年 大人の社会科見学

05年 さて困った

08年 浄水器

17年 西和彦 誕生日(1956)


申し訳ありませんが、現在意見投稿をできない状態にしています

goto不要論を本当に理解する  2013-02-20 00:18:33  コンピュータ

▲目次へ ⇒この記事のURL

OldGood COMPUTER!! のコーナーを10年ぶりに更新した、と書いたのが数日前。


その後、新資料が見つかってさらに追記している。

特に、Whirlwind の命令コード体系や、アセンブラの記述方法などは興味深い。


8bit 時代の PC でマシン語プログラムやっていた人にはわくわくできる内容だと思うし、最近の高級言語しか知らない世代には、こんな時代があったこと自体が衝撃だと思う。



で、急に思いついて検索してみた。

goto 不要論争って、最近のプログラマ諸氏は知っているのか?




goto 不要論について論じたページを見る限り、まだ心あるプログラマの方には、この論争は認識されていたようだ。

最近の言語では goto が排除される傾向にあるので、もう論争自体過去の遺物かと思っていた。


でも、「認識」はしていても、どうも認識がずれている方向にある。


#もちろん、正しく認識できている人もいるのだが、そういう人は稀なので。




goto は「使いすぎるとスパゲティプログラムになる」のではない。

1980 年代の BASIC のような、GOTO と GOSUB だらけのプログラム、というのも間違いだ。


そもそもこの論争がなんで起こったのか理解しないまま、goto 不要論を持ち出してもおかしな議論にしかならない。





というわけで、goto 不要論争がおこった時代の goto はどんなだったか、という例として、Whirlwind のアセンブラプログラムを見てもらうと面白いと思う。


Whirlwind では、サブルーチンを作る方法は準備されているのだが、それはいわゆる「goto」なのだ。

サブルーチンから戻る命令も、もちろん goto 。


それじゃ、全部同じところに戻ってしまうから、サブルーチンとして使えない?

そんなことはない。サブルーチン終了時の戻り先アドレスを、自己書き換えで変更すればよいのだ。


アセンブラだから、if に相当するのは条件分岐。「分岐」つまり goto だ。


かくして、プログラムの流れはあっちこっちに飛び回り、しかもプログラムリストに書いてあるとび先は、本当のとび先ではない。実行中に書き変えられることが「当然」なのだ。




高級言語から goto を排除する、というのが不要論なのに、アセンブラを例にするのは不適切だ、という声が出そうだ。


でも、アセンブラは当時の「当たり前の」プログラムスタイルなのだ。

そして、これを受け継いだ FORTRAN でも、同じスタイルが適用される。


FORTRAN は、アセンブラの「演算部分」を簡易化する言語だった。だから、FORmula TRANslation なのだ。

そして、演算部分以外の、流れ制御はアセンブラと同じ概念だった。


初期の FORTRAN では、条件を調べた後にできることは、goto のみだ。


その一方で、条件を調べないでも、goto と変数の組み合わせでいろいろな場所に分岐できる。

これは、アセンブラの「自己書き換え」テクニックを高級言語に取り入れたものだった。


もちろん、サブルーチンを呼び出すのも goto で、戻るのも goto だ。


サブルーチン呼び出し時に、どこから呼び出されたかを変数に入れておき、その変数を見て goto 先を変えることで「戻る」のだ。

なんて回りくどいやりかた、なんて思ってはいけない。当時は、先に書いたようにアセンブラも含めて、これが標準的な方法だったのだから。



ところで、FORTRAN には制御構造が3つある。

一つは goto で、もう一つは if 。if でできることは goto だけ、というのは先に書いた通り。


そして3つ目は、ループ命令(DO)だ。


ループ命令は、その後の言語のように、ループブロックの「はじめ」と「おわり」を指定したりはしない。

頭の部分で、どこまでがブロックかを、アドレス(行番号)によって指定するのだ。


つまり、ループ命令でもアドレスを意識した goto の呪縛が残っている。

制御構造がアセンブラと変わらない、というのはそういう意味なのだ。



かくして、FORTRAN の記述は goto だらけ、行番号だらけとなる。

これを称してスパゲティプログラムというのであって、C 言語ではどんなに悪意を持ってgoto を駆使したとしても、FORTRAN の「当たり前」ほどの混乱には至らない。


#C 言語で混乱を起こしたいなら、goto なんかより、もっと別の悪意の使い方があるわけだが。


#FORTRAN の名誉のために書いておくが、これは初期の FORTRAN の話。

 現代の FORTRAN はもっと洗練されている。



この状況からみると、if の後ろに命令が複数書ける、1980 年代のマイクロソフト BASIC など、「goto が劇的に少ない」言語だ。goto 不要論で引き合いに出すのは間違いだ。


GOSUB を使ったって、ちゃんと RETURN で呼び出し元に帰れるのだ。

自己書き換えを使ったり、変数でとび先が変わる GOTO と違って、プログラムの流れが追いやすい。何の問題もない。




初期の FORTRAN をはじめとする、当時のプログラム言語の状況はあまりにもひどいものだった。


見かねたダイクストラが「goto を使わないで論理を表現する方法があるはずだ」と示したのが不要論の始まりだが、よく知られているようにダイクストラは goto がダメだと言ったのではない。


プログラムを、ブロックの入れ子構造で示す「構造化」を取り入れると、if の後で goto しかできなかったり、変数によって分岐先が変わったりする goto を使わないようにできるよ、と示したに過ぎない。



ちなみに、ダイクストラが示したのはつまり、ALGOL の表記法だ。

ダイクストラは ALGOL の設計者の一人だった。


初期の ALGOL はプログラム言語というより、アルゴリズム記述方法といったほうが正しい。


実際の動作させることには重点を置いていないので、ブロックを明示的に打ち切って処理を早くするようなことは考慮されていない。


だから、ダイクストラは「そういう場合のために、goto は必要なんじゃないかな」とは思っていたようだ。



じゃぁ、使ってもよいのかというと、使おうにも現代の言語には goto がない。

でも、C 言語は 40年も昔の言語なのにまだ広く使われていて、 goto がある。


ここで、「goto を使ってはならないか」で論争がある。

まぁ、この論争はだいたい決着がついていて、C 言語の機能不備により、使ったほうがよい局面がある、となっている。




でも、みんなこれ以上の突っ込んだ議論にはならないのね。


FORTRAN の goto の嵐と、ダイクストラの「構造化」の思想を知っていれば、C 言語には goto 以外にも goto があることに気づくはずなのに。



先の説明で感がよい人は気づいたと思うが、break と continue は goto を特殊用途向けに改良したものだ。

break はブロック終了後の最初の命令に goto する。continue はループブロックのみで使用可能で、ブロック最後のループ条件判断に goto する。


まぁ、これくらいなら「ブロックの入れ子構造」を壊すほどじゃないから、禁止されるような goto ではない、という意見もあるだろう。

むしろ、積極的に「ブロック」を解釈することで、goto のとび先である「ラベル」を排除している。goto を残すにしても、現代的な、うまい解釈だとほめてよいと思う。


#もっとも、CONTINUE という命令は最初の FORTRAN にもあった。

 ただし、ループ末尾で「先頭に戻る」ことを明示して可読性を上げることを目的につくられた命令で、この命令には何の意味もない。

 (先に書いたが、FORTRAN のループ末尾は行番号で示されるため)



しかし、形を変えたとはいっても、ダイクストラが示す方法論によれば、break も continue も goto だということになる。

ところが、絶対禁止、という強い否定論者であっても、なぜか break や continue には寛容であることが多い。


#break や continue に当たるものを、「飼いならされた goto」と呼ぶ表現があるらしい。

 この呼び名を使う人は、この議論の本質を理解していると思う。



C 言語のプログラムだって、break や continue を使わないで、ALGOL 風に記述することは十分可能だ。


強い否定論者を自認している人がいたら、break 、continue なしでプログラムを書いてみてほしい。

皮肉でいっているのではなく、ちゃんと記述できるし、それはそれで美しいプログラムになるはずだ。


#多少冗長になるが、その冗長さによって、プログラムの流れがわかりやすくなる。

 この冗長さはプログラムリスト上のもので、ちゃんと適切に記述すれば、処理が遅くなったりはしない。




goto を否定する人に言わせると、goto がダメな理由は、だいたい3点。


・処理の途中から飛び込んだりするため、非常に読みづらい

・goto の次の処理がどこにあるのか、ラベルを探さないといけない

・そもそもラベルをつける、というのが面倒くさい


すべてまとめていうなら、「プログラムの流れを追いにくくなる」ということだ。

流れが理解できず、プログラマが動作を把握できなくなれば、当然バグの原因となる。


だから、goto 文はダメなのだ、という論理だ。




でも、わざわざこの「ダメな」特徴を持たせた命令が C言語にはある。


存在しているだけでなく、使うことは積極的に推奨されている。

C言語の影響を受けた多くの言語でも、この命令は受け継がれている。



それが switch 文だ。


switch は、指定された変数によって、「ラベルを頼りにして」「ブロックの途中に積極的に飛び込み」、break によって「積極的にブロックから飛び出る」ための命令だ。


つまり、FORTRAN の「変数によるジャンプ命令」…さらに遡れば、アセンブラの自己書き換えテクニックによる各所へのジャンプを、形を変えて残したものに過ぎない。



switch による goto では、case がラベルとなる。

ラベルだから、「実行される」命令ではないし、最後に : を付ける文法になっている。

(一般的に、アセンブラのラベルは末尾に : を付ける)



ラベル部分から飛び込んで処理をはじめ、通常はラベル1つ分の処理が終わると、break で飛び出す。


でも、break しないまま複数のラベルにまたがって処理を続けてもかまわないし、むしろこのテクニックは積極的に利用されている。


この場合、goto を忌み嫌う人の主張する「処理の途中から飛び込む、非常に読みにくいプログラム」を作り出しているわけだが、どういうわけが goto 否定論者でも switch を当たり前に使う。




さて、goto が不要なのか必要なのか、ここでは結論を出そうと思っていない。

というか、これは誰かが結論を出すような問題ではないだろう。


でも、不要論を…どちらの立場からでも…論じようという人は、このレベルの知識は持ってほしい、と思っているだけだ。

それでないと、議論が非常に浅はかなものになるから。



僕個人の見解としては、switch は便利に使っている。

やはり処理の流れが混乱しやすいし、break 忘れ、という凡ミスもよくやるけど、処理の流れに飛び込める便利さは捨てられない。


goto だって同じで、使ったほうがよい局面があれば使う。

ただ、そんな局面になったことは、まだない。




2016.8.24追記


ダイクストラの論文の後に、クヌースが「むしろ適切に goto を使ったほうが良い」ことを示した論文を書いているそうです。


詳細を書いた記事が書かれていました。

「有害なgoto」「時期尚早な最適化」、そしてプログラミングにまつわる神話は諸悪の根源である


ダイクストラ自身 goto の必要性を認めていた、というのは知っていたのですが、上に書いた記事の中には、その根拠や、ダイクストラ自身が自分の論文が曲解されていることを憂いていたことなどが書かれています。



僕の記事に興味を持っていただけた方は、是非上の記事も読んでみてください。


▲目次へ ⇒この記事のURL

関連ページ

エドガー・ダイクストラの誕生日(1930)【日記 14/05/11】

OSの登場

「計算機言語」が生まれた日(1956)【日記 14/10/15】

「計算機言語」が生まれた日(1956)【日記 14/10/15】

ジョン・バッカスの命日(2007)【日記 15/03/17】

別年同日の日記

03年 ホウレン草

05年 カーオーディオ

06年 待たされる1日

15年 スタッフロール

17年 ケン・オルセン 誕生日(1926)

17年 続・家の10年目メンテナンス

19年 クレジットカード不正

19年 故障続き


申し訳ありませんが、現在意見投稿をできない状態にしています

【KyonKyon】 少し違うかな。K&Rの「プログラミング言語C」にgoto文は使うべきでないという一文を読んだFORTRNの技術者がC言語に移行するときに使ってはいけないのかと構造化プログラミングを理解せず、妄信した結果でしょう。彼らは理解していないからgoto文をreturn文に置き換えててドヤ顔しているというのが一般的でしょう。 (2015-10-05 16:00:01)

【ばしくし】 SeleniumRCのテストケース記述で使うgotoIfは重宝しますね。while…EndWhileのループ抜けるときとか必須ですし、setEvalやgetEvalと組み合わせた柔軟な記述は便利です。user-extensions.js使わない限り、これがないと条件分岐したテストケース書けませんからね。 (2015-05-11 23:24:14)

あきよし】 まぁ、Switchも「飼いならされた」gotoですから、ひどいことにはなりません。文章の趣旨は、goto不要論を論じる場合はこれくらい知っておいてね、ということだけなので、良し悪しもまた別です。 (2013-07-02 09:15:01)

【山本】 そりゃswitchは近代の言語が禁止してるループからループの真ん中に飛び込みやifからifの真ん中に飛び込みをしませんからねえ(入れ子でない状態に限り)。それでもgoto排斥派が寛容な理由は解りませんが。 (2013-07-01 09:08:48)

記事の更新  2013-05-04 10:16:00  コンピュータ

▲目次へ ⇒この記事のURL

3か月ほど前、10年ぶりに OldGood COMPUTER!!に記事を追加した。


その時に興味を持っていたが、調査不足で書き切れない内容があった。

少しづつ書き進めていたのだけど、G.W.前半で一気に記事をまとめ上げたので公開した。


Auto Programming Tool。略して APT 。

Whirlwind I (以下 WWI) のアプリケーションの話…のつもりだったんですけどね。


WWI で「前身となるソフトが作られた」というだけで、アプリケーション自体は IBM 704 用でした。

意外なオチ(笑)


でも、WWI 関連の話題として公開しちゃったよ。



しかし、調べれば調べるほど新事実がわかって混乱した…

というのは、資料が十分ではなかった、ということでもありますが。


名前に「2D」とつくのと「3D」とつくのと、二つのバージョンがあるので、2D は 2D なんだとおもってたら、実際には 2D でも 3D に対応していた。


3D の方は、「もっと上手に対応する予定」で、結局難しすぎて頓挫。

ここでやろうとしていたことが、数学的・プログラム的に解決されるのは 30年後なので、当時としてはやろうとしたことが難しすぎたのだ。



この、「30年かかって解決した経緯」も、興味深い。

興味深いけど、APT 「以降」の話なので、APTの話に混ぜると話が分かりにくくなる。


結局、APT で WWI 関連の話を〆る予定が、さらに関連話題を書きました。




記事を書こうとするといつもこんな感じ。


書いているうちに疑問が沸いて、さらに資料を集めると考えていたことが少し違うことがわかり、別の部分との整合性がおかしくなって、新たな疑問が沸く。

そして調べているうちに関連する興味深い話が出てきて、話がまとまりきらなくなってしまう。



元々、10年ぶりに更新しよう、と思ったときには「ファミコンの画面構成」を書く予定だったのだ。

それがなぜか、全然違う WWI コンピューターの話になった。


実は、WWI 関連ではコアメモリの話も書きたかったけど、これは WWI だけの話にとどまらないのでそのうち書く予定。


現在の予定では、次は TX-0 を書きたいと思っている。


でも、書くのが大変な OldGood の更新より前に、料理ページに記事を追加するかも。



▲目次へ ⇒この記事のURL

別年同日の日記

19年 Minit


申し訳ありませんが、現在意見投稿をできない状態にしています

デザイン変えた  2013-05-16 17:33:11  コンピュータ

▲目次へ ⇒この記事のURL

ここ数日で、この WEB サイトのデザインを少しいじりました。

…本当に少しね。絵心あるわけでもないし。それほど変えられないから。


今までは左側に「ページナビゲーション」、右側に google の広告などを出していました。

これは、Netbook (すでに死語だ…) などが流行した時に作ったデザインで、「画面が狭くて右側が見えなくなっても致命的でない」デザインを目指したものでした。


でも、本文が少し狭かった。


Netbook 対応以前は画面横幅いっぱいに本文を表示する、「WEB黎明期」スタイルだったので(だって、黎明期の時代に作り始めたのだもの…)、一部の文章は横幅が狭くなりすぎたことで非常に読みづらくなっていました。

(あまりにひどいところは気づいたときに手直ししていましたが)



で、いまどきスマホでも Netbook より広い画面になっているのだから、Netbook 対応はいらないよね、ということで、本文の領域を広げました。


左側にあったナビゲーションを無くし、右の広告スペースの下に押し込めました。

以前から「長いページでナビゲーションに戻るのが面倒」と自分で思っていたので、スクロールしても画面内にナビゲーションだけついてくるようにしました。

(広告はスクロールで消え去ります)


…が、これ、使いにくくなった、と自分でも思った。

視線の移動を考えると、右下っていうのは一番最後。目次を探しにくいし、ページを表示してすぐに「別のページに移動したい」と思ったときに面倒極まりない。

(そういう読み方するのはおそらく作者である僕だけですが、僕が使いにくいのは問題がある)


そこで今度は画面上部に、いわゆる「パンくずリスト」を付けたのですが、微妙にいままでの「ナビゲーション」と機能がかぶる。


じゃぁ、いっそのことパンくずリストに統一してしまえ、というわけで、パンくずリストの「階層表示」に、階層の水平移動機能を付けました。

マウスオーバーで、同じ階層の別コンテンツが表示されます。


この、新しいナビゲーションは常にコンテンツ上部に表示されています。

あまり大きな表示は邪魔くさいので、縦 30px だけね。


パンくずリストは、よくありがちなのは「→」や「>」で階層を表示するのだけど、そこは技術者なので、URL っぽくしてみました。

一番上の階層が // で始まって、以降は / 区切りです。


UNIX の path や DOS の C:\ で始まる表示も考えたのだけど、一般的には URL がわかりやすいかな、ということで。




ついでに? こっそり、日記の整形方法も変わっています。


いままで、本文は p タグで行を区切っていたのに、日記は br でした。

自分としては p に統一したかったのだけど、「面倒くさくて」分断されたままだったの。


…もしかしたら、日記表示がおかしくなっている個所もあるかもだけど、気づいたら直します。


▲目次へ ⇒この記事のURL

関連ページ

デザイン変えた【日記 16/11/03】

システムちょっと改変【日記 13/05/23】

別年同日の日記

14年 アイバン・サザーランドの誕生日(1938)

16年 フェスタと祭り

16年 ブレッドボードと IchigoJam


申し訳ありませんが、現在意見投稿をできない状態にしています

システムちょっと改変  2013-05-23 11:25:04  コンピュータ

▲目次へ ⇒この記事のURL

先日もサイトのデザインを少し変えたばかですが、システムを改変しました。


えーと、先日の変更は、ほぼ CSS の改変のみでした。

だから「デザインの」変更だったのね。


今回は、システムのプログラムをいじったのですが、CSS はほとんど変わっていません。

だからシステム改変。読む人には全くどうでもいいことだけど。




僕が書いた文章は、やたらと長文です。

これは、自分に情報をまとめる能力が欠如しているせいでもあり、恐縮至極。


一応関連話題であっても「違う話」であれば、ページを変えています。

これで読みやすくしている…つもりだったのだけど、実際読みやすいかと言えばそうではない。

自分でもわかってはいましたが、うまく解決できていなかった。


で、自動的にページ分割するようにシステムに機能を追加しました。

もうかなり前(数年前なので詳しくは忘れたが)に、見出し部分を拾い出して自動的に目次を作る機能を追加していたのですが、これで自動的に拾った情報を元に、「ページの長さが5画面を超えないように」分割するようにしました。


まぁ、5画面と言うのはブラウザのウィンドウサイズによっても異なるし、フォントサイズでも異なります。

そもそも、HTML のレンダリングをシミュレートしているわけでもなくて、単に目安としてのざっくりした値。



単純に分割しちゃうと、ページ内リンクとかが破綻するのですが、これは Javascript で解決しています。

ページ内リンク(ハッシュ)はサーバーには送られてこないので、ブラウザ側で解決する以外に道がないのですが。


今までに外部サイトからリンクされている URL に関しては、問題なくそのまま動作し、複数に分割されたページの1ページ目を示すようになります。

もし、ハッシュ付きの URL でリンクされていた場合は、1ページ目が読み込まれた直後にハッシュ部分を解決し、分割されたページの適切な位置にリダイレクトします。



先に書いた「自動目次作成」機能を使っていないページは、ページ分割にも対応していなかったりします。

これは、追々調整予定。


まぁ、あまり古いページはそもそも長文ではなかったりもするので、そのままでもあまり問題はありません。



▲目次へ ⇒この記事のURL

別年同日の日記

02年 5/23

02年 5/23


申し訳ありませんが、現在意見投稿をできない状態にしています

キーボード  2013-05-25 13:00:30  コンピュータ

▲目次へ ⇒この記事のURL

キーボード

2年ほど前に購入したPCのキーボードが調子悪い。


そのPCを購入する前のキーボードは、秋葉原で1490円で購入した安物で、Compaq のロゴ入りだった。

本来付属品だったものを、どういうわけか大量に仕入れて安売りしたのだろうね。

(当時は Compaq は急速に売り上げを落としていた。直後に HP に吸収合併)


しかし、安物にも関わらずこのキーボードは10年間問題なく使えた。

DELL のキーボードが2年で壊れたということは、付属品の品質が10年間で急激に落ちている、ということか。


(もっとも、10年間で PC の値段も急激に落ちている。しわ寄せがキーボードなどに来ても不思議はない)




一緒にPCを買い替えた妻に聞いてみると、妻のキーボードも調子が悪いという。

僕と妻の症状は同じで、キーががたついて、押す時に引っかかる。


僕は CTRL および SHIFT を押す時に引っかかって押しづらい。

妻は、ENTER を押した際に引っかかって戻らず、押されっぱなしになる。


こんなんじゃ仕事の効率が上がらない、と買いに行くことにした。

昨日書いた外食は、この時に食べたわけです)



ちなみに、キーの刻印も一部がすり減って消えかかっている。

Compaq キーボードは10年使っても大丈夫だったのに。




「キーボードは馬の鞍」だと思っているので、10年は使えるものを、と思っていた。余分な機能はいらない。

ただ、109個のキーが、どれも正しい位置に並んでいて、しっかりした作りになっていること。これは譲れない。



近所の電気屋に行ったらいろいろキーボードが置いてある。

半数程度が無線キーボードだった。


…デスクトップで使うのだから、無線いらない。

電池切れとか面倒だし、無線にする意味がない。


USB 接続を探すと、それだけで選択肢が半減する。



近年の流行はアイソレーションキーボードみたいで、半数程度がそれ。

アイソレーションキーボードの近年の流行は、MacBook が使い始めたことに由来する、らしい。


でも、HP200LX とか、PC-6001 みたい、というのが率直な感想。

キーボードが小さいときには効果があるが、デスクトップマシンでメインに使うキーボードにはしたくない。

というわけで、選択肢さらに半減。



置いてあるキーボードを試し打ちしてみる。

ここで問題があった。置いてあるのは、ほとんど無線キーボード。

USB だと、線が邪魔になっちゃうからだろうね。


MS のキーボード、悪くない。でも、グネグネしたご自慢のやつより、安物っぽいやつの方が使いやすい。


よく見ると、グネグネキーボード、キーの手前に文字が書いてある。

最下段の左端から、「1つ戻す」「切り取り」「コピー」「貼り付け」…って、CTRL キーとの併用時動作だ。


U には「下線」とか書いてあるし、よく見たら Ins キーがなくしてあり、その分 Del キーが2倍幅になっている。

(Ins キーが打鍵できないわけではなく、本来の位置の上にある PrintScreen と Fn キーの同時押しになっている)


…えーとつまり、これは初心者用?

Ins キーでモードが切り替わる、というのは初心者にはわかりにくいし、初心者はよく間違えるから Del を大きくするのでしょう。


自分は初心者用はいらないけど、これはこれで需要がありそうだな、と思う。


安物っぽい奴は、ごく普通のキーボードらしい。でも、マウスと同梱。マウスいらない。




触った中では、ELECOM と Logicool のものも悪くなかった。

でも、ELECOM 製品は、同じと思われる有線製品が見当たらない。


Logicool は、サンプルに置いてあった無線製品は K270 というやつだったが、ほぼ同じと思われる USB 版の K120 を2つ購入。1280円だった。


散々選んだ結果、結局安物を買っているが、つくりはしっかりしている…と思う。

一応、1000万回のキーストロークに耐える設計らしい。なぜか NumLock だけ「対象外」と明記されているが。



このキーボードがいいところは、カーソルキーの上の6つのキーが標準の並びをしていることだ。

以前使っていた Compaq キーボードもそうだった。僕は Emacs の設定で、この6つを駆使する使い方にしているので、標準の並びはうれしい。


とはいえ、すでに DELL の変則並びに慣れてしまっている。

6つのキー以外の並びはほぼ同じとはいえ、配置の微妙な位置の違いで、まだタイプミスしたりする。


▲目次へ ⇒この記事のURL

関連ページ

キーボード【日記 16/05/12】

別年同日の日記

02年 故障の原因は?

06年 親離れ・子離れ

09年 雨上がりの散歩


申し訳ありませんが、現在意見投稿をできない状態にしています

LUMIX Phone 不具合  2013-05-31 11:05:48  コンピュータ

▲目次へ ⇒この記事のURL

この記事で書いた不具合、その後のアップデートで解消されました。

現在は問題なくなっています。


LUMIX Phone こと P-02D がアップデートして1か月がすぎた。


良い面と悪い面が半分づつ。

全体によくなった。すでに時代遅れの OS とはいえ、古すぎる OS よりは良い。


Gingerbread(Android 2.3)だったのが Ice Cream Sandwitch(Android 4.0) になったのだが、時代はすでに Jelly Beans(Android 4.2)が主流だ。先日 4.3 が発表されたばかり。


#Android の OS のコードネームは、先頭の文字が ABC 順のお菓子になっている。

 上に書いた中では H から始まるものが抜けているが、Honeycomb(Android 3.0) で、タブレット専用だったため、携帯電話には関係がない。



2.3 に比べ、4.0 は電源管理がしっかりしている。

その一環として「使わないアプリ」を強制停止できる。

当たり前のことに見えるが、2.3 のころはメーカーなどが仕込んだアプリを「使わない」方法がなかったのだ。


これによって、2.3 のころは、ほとんど電話を使わない状態でも1日に 40% 程度使用していた電池が、25% 程度の使用で済むようになった。

電池がなくなるんじゃないか、とハラハラしなくてよいのは非常に良い。




2.3 のころは、一つ困った問題があった。

先に書いた「1日に40%程度」というのは、普段の状態だ。


時々、異常状態になる。ドコモ純正の「電話帳」アプリが暴走することがあるのだ。


これは、LUMIX Phone に限らず困っている人が多いらしい。

暴走と言っても完全に動作しなくなるのではなく、普段に比べて無駄に CPU を使うようになり、電池を消費してくれる。


もっとも、明らかな動作異常ではないというのが逆に問題で、気づかないまま電池切れになることがある。


このような「アプリごと」の電池使用率は、BatteryMix などのアプリで調べられる。

通常なら、無駄に電池を使うアプリはアンインストールすることになる。


しかし、電話帳アプリは、常に上位に位置していたにも関わらず、プリインストールアプリなのでアンインストールできなかった。



4.0 になって、先に書いたように、このようなアプリも強制停止が可能になった。


でも、4.0 になったら電話帳自体もアップデートされ、不安定ではなくなった。

1か月使っていて、暴走したことはない。


このこともあり、電話帳自体は僕は電話を使用する際に使っているため、動作停止しようとは思っていない。

(動作停止したら、Android 標準の電話帳使えるのかな? 未確認)




しかし、やはり「別の部分」で不安定さがある。


LUMIX Phone のアップデートが半年もずれ込んだのは、開発がかなり厳しかったのだろう。

多分、OS 内部のどこかにひずみがある。…暴走するのは、アプリではなく OS 自体になった。


BatteryMix で見ても、特定アプリが電池を使用しているわけではない。

そして、OS 設定の「電源管理」で見ると、アイドル状態が一番電池を使用していることがわかる。

つまり、何もないときに、CPU が無駄に回って電池を使っているのだ。


気づくと本体が熱くなっている。ボタンを押しても何も反応しない。

おそらくは CPU がフルパワーで回り続けている。そしてもちろん、電池が大幅に消耗する。



僕は携帯電話を目覚まし代わりに使っているが、夜中にこれが起こると翌朝目覚ましが鳴らない。

暴走中でも鳴らないし、電池切れでも当然鳴らない。


昨日もこれが起こったので日記に書いてみようと思ったのだが、以前にも起きている。1か月で2度だ。



昼間に暴走したのに気付いて、すぐに電池を抜いてリセットしたことも2度ある。

昼間のときは、どちらもすぐに気づいたので問題は出なかった。

しかし、外出中に電池を完全に消耗されると、場合によっては困ったことになったろう。




さて、困った。

相変わらず電話帳が問題だ、と言うのであれば、4.0 になったので停止もできる。

しかし、OS が問題だとなると停止なんて出来るわけがない。


1か月で4度の暴走、というのはかなり不安定な部類に入ると思う。


4.0 の機能で、毎週1回の「再起動」も自動的に行っているので、長時間使ってメモリリークしている、とかいう問題でもなさそうだ。


ネット上を探しても、今のところ「困っている」人は多くても、解決できた、という人はいないようだ。

まだ1か月なので、原因特定にはもう少し時間がかかるのかな…



#数時間後追記。とりあえず、「電話帳サービス」を停止してみた。

 「電話帳」とセットだが、なくてもとりあえず問題のない機能で、暴走するのは主にこちらだった。


▲目次へ ⇒この記事のURL

関連ページ

LUMIX Phone Update【日記 13/07/30】

別年同日の日記

02年 新しいFinePix

06年 ゲンジボタル

11年 Smalltalk,Squeak, Etoys, and Scratch!

16年 色数と VRAM 構造

16年 WEBセーフカラー


申し訳ありませんが、現在意見投稿をできない状態にしています

コードゴルフの起源  2013-06-04 22:51:20  コンピュータ

▲目次へ ⇒この記事のURL

起源、と言ったところで、そもそも「コードゴルフ」なんて言葉を初めて聞く人も多いだろう。

僕もそうだった。


メールアドレス暗号化を作ったのは、もう2年近く前。

それから1年近くかけてJavascriptのコードを、1バイトでも小さくする方法を考えた。

今でも時々、もっと短くならないかと見直し、知らないテクニックがないかとググってみる。


で、とあるページでJavascriptの短縮化テクニックをまとめてあり、そこに「ゴルファーな人は知ってそう」と書かれていた。


ここでは「コードゴルフ」の単語は出ていなかったのだが、言おうとしている意味はすぐに分かった。

そんな懐かしい言い回しを覚えている人がいたか…と思ったのだが、これは僕の早とちりで、1バイトでも短縮すべく競う遊びを「コードゴルフ」と呼ぶのだと知った。




Wikipedia の日本語ページはほとんど情報がない。でも、英語ページにはそれなりの解説がある。

それによれば、コードゴルフ、という名称は、1999年に perl 向けに使われたのが最初だそうだ。


しかし、この「1バイトでも縮める」という遊びをゴルフと言うのには、少し違和感を感じる。


僕は本物のゴルフはやったことがないが、ゲーム好きなのでゴルフのルールを取り入れた遊び…パターゴルフだとか、フライングディスクゴルフだとか、レーザーガンゴルフだとか…そういう遊びはやったことがある。

ゴルフルールを取り入れた遊びの共通点は、3つ。


1) 何かを達成するまでの「打数」を競う。少ないほど良い。

2) 1つの「ホール」での標準打数(パー)が決まっていて、複数ホールの合計で競う。

3) 通常、パーは3~5。そのため1点の重みが非常に重い。


コードゴルフには、パーは存在しないし、1点の重みはゴルフほど重くない。

問題や言語にもよるが、4バイトでなにか実用的な処理ができる、なんてことはあり得ないだろう。




さて、最初に「ゴルファー」という単語に対して「懐かしい」と書いた。


コードゴルフという言葉がはじめてつかわれた、とされる1999年より以前…1980年代中盤に、すでにプログラムの短縮競争を「ゴルフ」と呼んでいたのを知っているためだ。


正確な記憶ではないのだが、1984年ごろではないかと思う。

NECのパソコン向け専門誌、Oh!PC の連載(読者投稿コーナー)だったはず。

(僕はOh!Xは買っていたがOh!PCは買っていなかったので、記憶違いがあったら申し訳ない)


#翌日訂正:Oh!PC ではなく、PCマガジンだった模様。

 こちらのサイトの掲示板に情報が…って、これ15年前の自分の書き込みだよ (^^;


#2014.10.28 追記

 10年前の2chで話題に上ってた

 これ、当時の紙面に載っていたルールの抜粋だ。



毎月お題が出て、BASIC で「出来るだけ短く」書く競争をするコーナーだった。

「Proゴルフ」という連載名だったと記憶している。

Pro は、Program の意味だ。もちろん、職業ゴルフの意味の「プロゴルフ」と掛けているわけだが。



ここで「短さ」の定義は、行数。1行にどれだけ詰め込んでもよいが、今の言語と違って行には重い意味があったため、詰め込みに限度があった。

(分岐を使うには「行番号に」飛ぶしかないため、処理上どうしても改行が必要な場合がある)


そもそも、詰め込もうにも1行の文字数は仕様上の制限があって、PC-8801の場合で255文字、PC-6001だと71文字が限度だった。


機種によってハンデがあるため、パーは機種ごとに設定されていた。

しかし、基本的にはパーは3~5程度。本当のゴルフと同じような感じだった。


出題内容はよく覚えていないが、「任意のメモリアドレスから入っているデータを文字列として画面いっぱいに表示し、キー操作によって自由に上下スクロールさせながら閲覧させる」という出題があったことは覚えている。


他の月の出題といくつか合わせると、エディタの基本が出来上がる、という説明がついていた。

最終目標がエディタだからこそ、1つ1つの機能は出来るだけ小さく作り、エディット可能なメモリを大きくとりたい、という出題意図だった。


パー4くらいのところを、2行まで縮めてきたのが数名、1人だけ1行で書いてきて出題者が驚いた、とかではなかったかと思う。(別の月の話だったかもしれないが、時々超絶技巧による「ホールインワン」が出た)



投稿者は常連が多く、1年間の合計行数で競っていたように思う。

ちゃんと、ホールを回っているのだ。ここでもちゃんと、ゴルフらしさを出している。




Wikipedia の英語版にあるように、短縮競争を「ゴルフ」と呼ぶのは1999年にNetNews のperlのコミュニティに登場し、なんの違和感もなく(その考えは面白い、というような賞賛もなく)周囲も受け入れている。


先に書いた Proゴルフは、BASICの「行」が非常に重い意味を持っていたから成立する遊びだった。

Apple // の頃も、「2行」で何ができるか、を競う遊びが流行っている


だとすると、アメリカでも BASIC の行数削減を「ゴルフ」に例える遊びはあったのではないだろうか?

Oh!PC のアイディア自体、オリジナルではなかったのかもしれない。


BASIC での行数短縮を「ゴルフ」と例えるのであればわかるのだが、perl のバイト数短縮を「ゴルフ」と呼ぶのは、どうも不自然に思えてならない。

まだ想像の域を出ておらず、裏付けも難しそうだが、コード短縮を「ゴルフ」と呼ぶのは、BASIC 時代に端を発しているのではないか、と考えている。


▲目次へ ⇒この記事のURL

関連ページ

ベーマガ投稿【日記 15/03/27】

ベーマガ投稿【日記 15/03/27】

Scratch の舞台裏【日記 16/06/16】

別年同日の日記

03年 今年もまた

07年 結婚記念日

18年 三笠


申し訳ありませんが、現在意見投稿をできない状態にしています

WEB上でのドット絵の拡大  2013-06-09 17:46:14  コンピュータ

▲目次へ ⇒この記事のURL

急にドット絵を綺麗に拡大したくなり、調査したので記事にしました。

やり方はそちらの記事を読んでもらうことにして…。


このWEBページを毎日見ている、なんて人はいないと思いますが、ここしばらくの間、ページの大幅見直しを行っています。


システムが古すぎるので、ちょっと今風にして読みやすく、ということですね。

で、見直していたら、7年前(2006年)に書いたページが気になった。


そちらのページでは、ドット絵をたくさん載せています。

ただ、ドット絵のサイズとしては原寸でも、見やすさを考えて縦横4倍に拡大していたのね。


2006年時点では、画像の拡大は大抵「補間なし」のジャギーだらけでした。

だから拡大でよい、と思ったのですが、その後拡大時に滑らかに補間されるようになりました。


これもまた仕方がないこと。

古いページだし、当時はもうあきらめていました。


でも再び見直して疑問が出ます。

当時に比べて CSS なんかの設定も多彩になったし、いまならドット絵を綺麗に拡大できるんじゃないの?




で、調べてみたら…なんとも謎な事態でした。

複雑な経緯があって、仕様がコロコロ変わっています。


その最中に書かれたブログ記事がたくさんあって、古い仕様に依拠した記述が、書かれた日付もなしに氾濫している状態。

技術に詳しくない人がこの件を検索したとしたら、きっと何を信じてよいのかわからなくなるでしょう。


技術系の文章書く人、日付はしっかり入れましょうよ。

技術は日進月歩だから、日付ないと本当に困ります…



もちろん、現時点での仕様で書かれているページもありますが、問題は「正しいページと間違えたページを見分ける方法がないこと」なのです。

そこで、事態の経緯を含めて解説する記事を書いてみた、というわけ。


僕自身は chrome を愛用していますが、chrome でドット絵の拡大を実現する方法がない、というのが残念なところ。

Javascript まで使えば出来るのだけど、そこまでやりたいほどの内容ではないんでね…



▲目次へ ⇒この記事のURL

関連ページ

Chrome でもドット絵拡大!【日記 13/06/10】

別年同日の日記

02年 最終戦略

05年 spring has come

05年 3ヶ月点検

16年 8086 発表日(1978)

17年 計算機の同人誌


申し訳ありませんが、現在意見投稿をできない状態にしています

Chrome でもドット絵拡大!  2013-06-10 17:36:28  コンピュータ

▲目次へ ⇒この記事のURL

昨日の日記の舌の根も乾かぬうちに。


Chrome は CSS だけではドット絵を綺麗に拡大できないけど、Javascript 使えば出来るよ。

でも、面倒くさいからそこまでやらないよ。と昨日書いた。


しかし、僕が Chrome 使いなので、「できない」というのはどうにも悔しい。

そこで、やらないと言っていたのに Javascript で実現してみた。



方法は、昨日仕上げたドット拡大方法に追記してある。

誰でもコピペして使ってもらえるように、出来るだけ短いコードにするようにした。


…短くした都合もあって、動作は最適ではない。

というのも、ユーザーエージェントだけ見て Chrome と判断しているので、エージェント偽装があると間違えるかもしれないし、ページを全て読み終わってから動作するので動作が遅い、など多少の問題がある。



Javascript を使っている、といっても、1ドットづつドットを見て拡大している…というわけではない。

単に、Javascript の「拡大コピー」機能を使っているだけ。


javascript で拡大コピーすると、普通は HTML で画像を拡大するのと同じことになる。

なのだけど、なぜか Chrome では HTML +CSS では「スムージングしない」設定ができず、Javascript では出来る。


だから、読み込み終わったすべての画像に対して、拡大したいサイズの Canvas を用意して拡大しているだけ。



#翌日追記

 昨日日記を書いた時点では、Chrome で CSS が使えないのを「なぜか」だと思っていた。

 でも、いろいろ調べると、使えないことこそが妥当で、それを javascript でカバーできるのも妥当のようだ。

 CSS 草案には方法が書かれておらず、javascript 草案には方法が明記されている、という事実があるため。

 いずれも草案なので、今後状況が変わることはあるかもしれない。


▲目次へ ⇒この記事のURL

別年同日の日記

03年 サンプルプログラム

10年 サーバークラッシュ


申し訳ありませんが、現在意見投稿をできない状態にしています

古いコンピューターを長持ちさせる  2013-06-20 15:37:44  コンピュータ

▲目次へ ⇒この記事のURL

1か月ほど前、仕事先でのこと。


自分のマシンではないが、一緒に仕事をしている人のノートパソコンが起動しなくなった。

原因はこの時点で不明。 Windows の読み込み中になにか失敗しているようだった。


つまり、ハードディスクのデータが壊れたのだろう。



このノートパソコン、自分持仕事先で同じものを使っていたのだが、もう5~6年前のもの。

Windows 8 入れようとしたが「性能が足りないよ」と言われて入れられない。そんなシロモノ。


もうかなり遅いマシンなのだが、僕は少しでも快適に使えるように、頻繁にデフラグしたり、不要なファイルを消去したりしていた。

一方、壊れたマシンではそういう作業はしていなかったようだ。



壊れたマシンは、その後の調査でセクタリードエラーが出ていたようだ。

仕事で使うのに不安定では困る、ということで、ハードディスクごと入れ替えて再インストールとなった。



で、自分のマシン。同時期に買ったものなので気になる。

とりあえず、全セクタチェックしておいた。非常に時間がかかるので、仕事終了後にチェックをかけてほおっておく。

(終了すると電源が切れる設定)


ハードディスクのデータは、磁気で記録されているが、徐々に磁気が失われる。

チェックする、と言う名目で読み出しを行うと、その際に磁気の強さも測定され、弱っていたら再書き込みされる。


これでしばらくは安心のはず。

(頻繁にデフラグしていたのも、デフラグによる高速化も目的ではあるが、セクタにアクセスしてほしいため。

 ただ、デフラグの場合は「問題ない」セクタまでは読んでくれないため、時々全セクタチェックした方が良いのだろう)




さて、今週の話だが、その仕事先で使っているサーバーを、都合があって別の部屋に移動した。


まず、すべてのサーバーを停止する。

xen のバーチャルサーバーの停止から始める。


…いくつか、正常に停止しないサーバーがある。

調べてみると、xen にバグがあって、システム終了を正しく認識してバーチャルサーバー終了を行えないことがあるようだ。


バーチャルサーバー起動後にマシン設定を変えたり、サーバーの OS をアップグレードしたりするとなりやすいバグだ、とのことだが、今回うまく動作しなかったのは、古い(Xenの準仮想化対応でない) Linux を、完全仮想化で動かしていたサーバー。



さて、全部停止したら、移動後再起動。

…再起動しないサーバーがいくつか。


物理的にはハードウェア4台なのだけど、バーチャル化したものが十数台ある。

このうち数台が起動しない。


再起動しないバーチャルサーバーが、ある1台の物理サーバーに集中していた。

念のため、物理サーバーのファイルシステムをチェックする。


結構時間がかかり、サーバー移行作業が予定時間よりもオーバーしてしまったのだが、大きな問題はないようだった。

(いくつか、不整合の修正は行われたようだ)


もっとも、fsck では全セクタチェックしてくれるわけではないし、ファイル情報に矛盾がなければ OK になってしまうのだけどね。



再起動すると問題なくバーチャルサーバーも起動。

fsck したから起動した、というだけでなく、他に設定がおかしくて起動しない部分もあったので修正したりしたのだけど。


#自分がやったように書いているが、サーバーの再起動関連は全部サーバー管理者がやったこと。

 僕は念のためのダブルチェックや、再起動しなかった時の設定確認などを手伝ったけど、それだけ。



これらのサーバーも古いので、移行作業で思わぬトラブルが発生する危惧もあったのだが、それほど大ごとにならず終了。


先に書いた完全仮想化で動く古い Linux サーバーなどは、停止できるようにしばらく前から準備している。

この面では今後の問題はないだろう。




▲目次へ ⇒この記事のURL

別年同日の日記

02年 SOHOっていうものは

05年 2台のRoomba

12年 続・おたふく

16年 顔文字 (^_^) の生まれた日(1986)


申し訳ありませんが、現在意見投稿をできない状態にしています

「暗号の歴史」と、アメリカの盗聴問題  2013-06-21 12:27:06  コンピュータ 歯車

▲目次へ ⇒この記事のURL

「暗号の歴史」という電子書籍を無料配布中、というので読んでみた。


まぁ、暗号好きなら知っている話ばかりだけど、あまり複雑な理論には踏み入らず、24ページという短さで上手にまとめてある。

あまり詳しくない人ならちょうどいい分量。


暗号好きの自分としては読んだことある話ばかりだな…と流し読みしていったら、最後に参考文献として、サイモン・シンの「暗号解読」がただ1冊だけ挙げられていた。


その本は読んでいる。他に参考文献はないようなので、読んだことある内容なのは当然だった。


無料配布の書籍を読んで興味を持った人は、「暗号解読」も読んでみるといい。

個々の暗号の詳細もわかるし、何より情報を守りたい側と、解読したい側の熱い人間ドラマが楽しい。



ところで、「暗号の歴史」を配布しているのは日本ベリサイン。

暗号のお仕事としてはかなり有名だけど、どういう仕事をしているのか理解してもらうためには「現代暗号」を知ってもらわないといけない。


現代暗号、というものが存在するからには近代や古代の暗号もあるわけで、現代暗号はそれらの欠点を克服するように作られている。


しかし、欠点を克服するための仕組みは非常に難解で、いきなり説明してもわかって貰えない。


…というわけで、ベリサインのお仕事を知ってもらうためにも、古代暗号から近代暗号、現代暗号までをわかりやすく説明する必要があったのだと思う。




暗号解読がらみなので、最近アメリカで大問題に発展している、NSA が市民の通信を盗聴していた問題について書いておこう。



先ほど紹介した本と名前が似ていてややこしいのだけど、「暗号化」と言う本がある。


これは、時々自分のページでも顔を出す名著「ハッカーズ」を書いた筆者による本。



この本の主な舞台は現代暗号が開発された1970年ごろから、2000年までのアメリカ。


NSA が如何に市民の通信を盗聴することを重視しているか書かれている。

主題は、それをプライバシー侵害と感じて阻止しようとした男たちの、熱い闘いの記録だ。

(盗聴を阻止するのだから、本の題名通り「暗号化」が武器となっている)



NSA はこの本の中では、完全に敵役だ。

暗号開発を行うものに圧力をかけ、暗号を扱うソフトウェアを認めない。


…認めないと言っても、開発を止める権限は NSA にはなかった。

ただ、暗号は武器の一種として規定されていたので、国外輸出は許されなかった。


2000年以前にネットをやっていた人なら、Netscape Navigator にはアメリカ国内版と国外版があって、国外版の SSL は強度がはるかに低かったのを覚えているだろう。


同時期に Linux をインストールしたことがある人なら、標準では DES 暗号が使えず、わざわざヨーロッパから互換ライブラリをダウンロードしなくてはならなかったことも覚えているかもしれない。



ともあれ、NSA は「市民が暗号通信をあたりまえに使うようになり、傍受できなくなるなんて悪夢でしかない」と考えている。その良し悪しは別として、多分これは今でも変わっていない。


結局、暗号化技術への規制は(一部の人々の、人生をかけた闘いにより)解除され、暗号化は一般に許可されることになった。

本としては、ここで終わっている。めでたしめでたし、だ。



でも、NSA は当然あきらめていなかった。

というか、闘いの歴史を知っている人々は、NSA が通信を傍受すること自体は当然と思っていた。


今でも、気の利いたメールエージェントなら「PGP」というプラグインで本文を暗号化して送信・受信できるはずだ。

使えなくても、PGP であらかじめ暗号化した内容をメールで送ってもよいが…こちらはかなり使い勝手が落ちる。


この PGP が、「暗号化」の話の中で中心になるソフトウェア。

NSA は暗号化ソフトに広く圧力をかけたが、PGP の作者は逮捕されないように定住せず、アメリカ国内を転々としながら PGP を作り続け、公衆電話からネットにアップロードし続けた。


NSA は PGP の開発者を逮捕しようと躍起になり、最終的にはこれが非合法ではない、と認めざるを得なかった。


そこまで NSA がこのソフトを嫌がったのは、このソフトで暗号化されてしまうと、NSA が通信内容を知ることが出来なくなるためだ。


逆に言えば、暗号化していなければ NSA は自由に通信内容を知ることが出来る。

これはもう、公然の事実だった、はずだ。



今回騒ぎになっているのは、Microsoft や google 、yahoo などの協力を得て、Gmail や hotmail のような「WEB メール」サービスを全て盗聴していた、と言う問題。


…なるほど、NSA さすがに頭いいな、とおもう。

気の利いたメールエージェントには PGP を簡単に使う方法があるものだが、WEB メールにはプラグインなどの仕組みがないのが普通だ。


PGP で暗号化できないところを狙って盗聴している。

もっと言えば、世の中の Cloud 化の流れが進めば、NSA にとっては暗号化がされにくいことになり、盗聴しやすいわけだ。


NSA に協力しているくらいだから、Gmail に PGP オプションが付くこともあり得なさそうだし。




多分、「暗号化」に出てくる登場人物たちにとっては、NSA が盗聴しているなんて言うのは、いまさら騒ぐようなことではないだろう。


これが騒ぎになるのは、コンピューターの利用者層がどんどん広がっているから。

ずっと昔から知られていたことも、新しく始めた人たちには「知らなかった」事実で、大騒ぎになる。


ちなみに、Gmail とか使っていたら、日本人のメールも盗聴されている、ということなので、気になる人は暗号化して通信するように。


NSA の職員だって、一日に何十億通ものメールをいちいち見ていられないから、ここでいう「盗聴」というのは、プログラムがフィルタしている、と言う意味だけど。


このフィルタで引っかかるような危険なことを書いている人のメールは、実際誰か人間が読むことになるのでしょう。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

歯車

別年同日の日記

02年 飲んだくれの日々

03年 なんだか色々入手

14年 ファミリーベーシックの発売日(1984)

15年 山歩き

16年 コンピューターが初めてプログラムを実行した日(1948)

17年 ゼルダ雑感


申し訳ありませんが、現在意見投稿をできない状態にしています

TX-0の命令  2013-06-26 10:37:56  コンピュータ

▲目次へ ⇒この記事のURL

少し前に書いたTX-0 の紹介の関連記事として、TX-0 の命令について書きました。


命令、全部紹介しきれていません。

たった4命令しかないのに、すごく機能豊富なんですよ。


というか、途中で改造されたから、今回書いたのは改造前のものだけ。



近いうちに改造後の命令も公開します。

というか、両方一緒に書いていたのだけど、長すぎるから2つに切ったの。


だから、改造後の命令の記事はだいたいできている。


その後もう一つ書きたいこと書いて、TX-0 は終わりかな。


次は PDP-1 行きたい気もするけど…


もともと Whirlwind や TX-0 に興味を持ったのは、コンピューターの画面表示方法をまとめる記事を書きたかったから。


そちらを先に書くか…

しかし、PDP-1 を紹介せずに、画面の話を「まとめ」ることが出来るのか…



▲目次へ ⇒この記事のURL

別年同日の日記

02年 静かな車

14年 ロバート・エバレットの誕生日

15年 バーコードが初めて使われた日(1974)


申し訳ありませんが、現在意見投稿をできない状態にしています

TX-0完了  2013-06-27 23:21:14  コンピュータ

▲目次へ ⇒この記事のURL

OldGood COMPUTERに書いていたTX-0の話題を書き上げました。

1日のうちに、改造後の命令の話と、NOP命令の成立過程(推察)の2本を公開。


…というか、以前も書いたけど、まとめて1本にしようとしていたのを、長すぎたから分割しただけ。


内容がマニアックすぎてパソコン技術者じゃないとわからない気がする。

いや、パソコン技術者でもわからない可能性も…



疲れたから、しばらくあまり古い歴史話はお休み。

PDP の話書きたいけど、それはしばらく後で。


料理のレシピでもしばらく書きながら、スプライト関連の話でも書くかなぁ。


▲目次へ ⇒この記事のURL

別年同日の日記

02年 大長編

02年 ばかうけ?

02年 旅に出ます

04年 自転車壊れた

04年 風呂釜壊れた

05年 カワセミ

07年 水疱瘡

14年 MSX規格発表の日

18年 エミュレーターの法的権利


申し訳ありませんが、現在意見投稿をできない状態にしています


戻る
トップページへ

-- share --

0000

-- follow --




- Reverse Link -