ぜんぜん日々更新ではない日記です

まぁ、ぼちぼちやっていきます。
このページは最新7日分で、逆順(最新が上)で並んでいます。
過去のものはヘッダ部分のリンクから選べます。

目次

2017-01-21 風邪ひき
2017-01-21 家の10年目メンテナンス
2017-01-20 1996年のそのほかのゲーム
2017-01-15 あの頃のインターネット
2017-01-14 WaveRunner
2017-01-11 アントニー・ホーア 誕生日(1934)
2017-01-09 Android の cordova で file を扱う
 今月の日記
風邪ひき  2017-01-21 12:00:14  家族

▲目次へ ⇒この記事のURL

先週の週末、次女が熱を出した。


39度を越える高熱。インフルエンザを疑ったが、関節などは痛くないというし、結構元気。

そして、翌日には熱も下がってケロリとしている。


火曜日に、僕も発熱した。このときは 38度くらいまで。

翌日水曜日には 39.5度まで上がったのだけど、「次女と同じっぽいから、明日には下がるだろう」と楽観視した。


…しかし、そんなに甘くなかった。翌日木曜はずっと 38度台。さらに翌日金曜日朝、やっと下がって 37度弱。

夜には平熱に戻ったのだけど、今日土曜日もまだ体力的に回復しきれていない感じ。


この間に、長女も木曜日の朝に 38度越えの熱を出した。

でも、翌日朝には平熱に戻って元気に学校に行った。



なんだろう? 子どもなら軽く収まるのに、大人がかかると重症化するような風邪?


探してみたら、「インフルエンザC型」というのがあるそうだ。


インフルエンザではあるが、変異せず、1種類しかない。そのため、一度かかると生涯免疫を獲得する。

普通は5歳までにかかるらしく、感染してもすぐ治る。


しかし、大人になってからかかると重症化するらしい。


もしかしてこれか? …と思っていたら、妻も同じような症状が出た。

ちょっと熱が出て、すぐ治った。長女や次女と同じ反応。



大人になってからかかることは珍しい、というのに夫婦そろって大人が罹ったのだから、違うだろう。

そして、妻はすぐ治ったのだから、大人が重症化、ということでもなさそうだ。


単に僕が体力が無くて、それほど強力ではない風邪に負けたというだけの話だと思う。



▲目次へ ⇒この記事のURL

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

家族

別年同日の日記

03年 うざいやつ

04年 レベルX

15年 RAID NAS 、QNAP T-220 購入

16年 ポール・アレン 誕生日(1953)


名前 内容

家の10年目メンテナンス  2017-01-21 11:51:42  住まい

▲目次へ ⇒この記事のURL

現在、家の10年目メンテナンスを行っている。


家の完成は2005年なので、10年目は2年前だ。

実際、「10年目点検」は 2年前に受けている。


その点検の際に、ハウスメーカーの想定以上に屋根葺きスレート板が割れていたらしい。



いわゆる「屋根瓦」ではなく、薄い板で作られた屋根を見たことがあるだろう。

あれが「スレート」だ。本来は、頁岩のこと。バージェス頁岩で有名な、あれだ。


頁岩は薄く剥がれる。その特性を活かして薄い板を作り、屋根葺きに使うのだ。


でも、天然物は高いので、人工品のほうがよく使われる。

そして、昔は人工品を作るのに石綿を使った。製品名として「カラーベスト」というものが有名なのだが、ベストはアスベスト(石綿)の意味だ。


しかし、石綿は発がん性があるというので、今は使用禁止になっている。

ちょうど我が家を立てた10年ほど前は、スレート材に石綿が使えなくなり、各社が試行錯誤を繰り返していたころで、今から見ると品質が悪かったそうだ。


それで、あまりにも割れが多いので、メーカー保証として無料にできないか掛け合ってくれることになった。




ところが、その後音沙汰がなかった。

こちらも忘れてしまっていたのだけど、年末になってハウスメーカーの営業の人が訪れた際に思い出し、話してみた。


#購入時の営業の人は、毎年年末にカレンダーをもって訪問に来てくれて、その後家で困っていることが無いか話を聞いてくれる。

 非常にこまめな方で、このようなサポートが非常にありがたい。



それから数か月後には、再び連絡があり、メーカー保証してもらえることになったと伝えられた。

そして、それを織り込んだうえで、そのほかのメンテナンスの見積もりも行われた。


…その後、また連絡がない。

いや、途中で屋根材メーカーからサンプルが送られてきた。

これをもとに色などを決定するのだろうな、と思いつつ、サンプルが送られてきたのだからまた担当者から連絡が来るだろう…と思ったまま、長い時間が過ぎた。


また年末が来て、営業の方が来る頃になって「そういえばメンテナンスの話進んでない」と思い出す。

営業の方が来て相談して、年明けに今度は担当の方が交代して連絡があった。


あとはトントン拍子に話が進む。

年が明けてから計画を再始動したのに、すでに我が家の周囲には足場がめぐらされ、今も屋根の上から工事音が響いている。



壁の塗り替えなどもあり、外観は大きく変わるはず。

最も、色は「大まかな希望」は伝えてあるが、最終決定は実際に塗ってみて決めるそうだ。


#小さな塗装サンプルでは実際の色とイメージが違うことが多いため。

 実際に壁の一部をいくつかの色で塗ってみて、それで決めるそうだ。


工期は 1か月ほどの予定。



▲目次へ ⇒この記事のURL

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

住まい

別年同日の日記

03年 うざいやつ

04年 レベルX

15年 RAID NAS 、QNAP T-220 購入

16年 ポール・アレン 誕生日(1953)


名前 内容

1996年のそのほかのゲーム  2017-01-20 09:52:52  業界記

▲目次へ ⇒この記事のURL

20年たったら書く、というつもりで書いているけど、そろそろ「語ることが何もない」ゲームが増えています。


新人の頃は、雑用仕事でいろんなチームに駆り出されたし、部内テストプレイ筐体で遊ぶこともありました。

しかし、この頃になると中堅社員になっていて、雑用流行らないし、忙しくて部内ロケテスト台でも遊ばないことが多いのね。


先に書いた WaveRunner も、「アイディアコンテスト」のことは覚えているのだけど、自分で遊んだ覚えがほとんどない。



▼SEGA SKI SUPER G


96年末…冬シーズンに発売されたと思います。

スキーゲームね。ストックを支えに、足を動かすことで操作します。



よく覚えていないのだけど、冬に部内の有志でスキーに行った覚えがあります。

セガは羽田が近いので、会社の仮眠室で泊まらせてもらって、翌朝羽田からの始発便で(チケットが安いので)北海道に行きました。


AM1研では、お金を積み立てての「社員旅行」もあったのだけど、このスキーはそれとは違う、有志の集まりでした。

社員旅行だと、積み立てもするけど会社から補助が出るので、それなりに豪華旅行だった。

でも、このときは有志だけの貧乏旅行(笑)


たぶんそれが 95年~96年の冬シーズンだったと思うので、その時から企画の片鱗があって、取材を兼ねていたのかもしれません。




たしか、冬発売なのでコラムス 97 と同じ頃が締め切りだったと思うんですよ。

夜、ほとんど人のいない部署内で、企画やってた人と会話していたのを覚えている。


その人、いつも夜になると「さらっとトマト」飲んでてね。当時発売されたばかりのジュースだった。

その日も飲んでたので「好きですねー」って言ったら、「だって、すごくおいしいよー」とか、そんな他愛もない会話。


だからどうしたということではなくて、その程度しか記憶に残ってないのです。



▼ダイナマイトベースボール


以前に僕も在籍した「ファイナルアーチ」という野球ゲームを作ったチームがあります。


ファイナルアーチは、決して人気が出たソフトではないのだけど、ゲームセンターにとって「必要なソフト」と考えられました。

野球ゲームって、外回りの営業サラリーマンとかにウケがいいのね。


で、ST-V ではなく Model2 で作ったのが本作。

特徴として、アナログな「バットスイッチ」というのがあります。


90度ほど回転する棒なのだけど、引っ張って離すと、バネの力で元の位置まで戻ります。

これで、野球盤のようにバットを「振る」ことができて、スイングの力も調整できます。



ファイナルアーチって、「サヨナラ打」の意味でつけられたのだけど、わかりにくかった。

和製英語だし、一部の野球ファンはそういう言い方をするけど、一般的な用語ではないのね。


「ダイナマイト」ってつけろというのは、営業側からのリクエストだったと思います。

「ダイナマイト刑事」のヒットがあったので、同じ部署が作ったゲーム、として売り込みやすいという判断。



ダイナマイトベースボール、この後シリーズ化されて毎年バージョンアップ版が発売されます。




AM1研では、基本的にゲームごとに人員が集められ、作成が終わると解散していました。

だから「チーム」って考え方はあまりないのだけど、この「チーム」は、The J League 1994、ファイナルアーチ、ダイナマイトベースボールとスポーツゲームを作り続けていました。


特にプログラマーが、かな。企画やデザインは、ゲームごとに違っていた気がします。




▲目次へ ⇒この記事のURL

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

業界記

別年同日の日記

06年 ウッドデッキ完成

07年 人生初ギャグ?

13年 ピクミン

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

15年 SIMON は世界初のPCか?

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


名前 内容

あの頃のインターネット  2017-01-15 15:06:40  コンピュータ 業界記

▲目次へ ⇒この記事のURL

ふと気づくと、このサイト「魔法使いの森」も、いつの間にか20年を超えていた。

最初に書いた記事はファミリーBASICで、1996年の10月1日に公開していたようだ。


僕がこのサイトを作り始めたきっかけは、セガ社内での「流行」があったからだった。

なので、個人的なことなのだけど、業界記タグで書いてみよう。




以前に書いたことがあるのだけど、パソコン通信は、1991年に始めたと思う。


電話事業の民営化でパソコン通信が可能となったのが 1985年。

高校の頃読んでいた MSX マガジンでも、パソコン通信の記事とかがずいぶん出ていた。


1991年だとすでにブームもひと段落して、機材が手ごろに購入できるようになってきた。

そこで、「すっかり出遅れた」と思いながら始めたのだった。



1994年には WWW が普及し始め、「ホームページ」が続々作られ始める。

それまでは、インターネットに接続しようと思うと、大学などの研究機関同士のネットワークに参加するしかなかった。


同じ 1994 年には IIJ が接続サービスを開始。

でも、まだ非常に高くて、個人が使うようなものではなかった。



1996年頃になると、個人でも使える接続サービスが増えて、競争で値段が下がってくる。

でも、やっぱり僕はパソコン通信で十分で、インターネットには接続していなかった。




大学の卒業研究が「ハイパーテキストによる執筆環境」だったので、 WWW に興味はあった。


セガの社内は、当時まだ 10Mbps だったのだけど、Ethernet で接続されていた。

社外にも接続されていたのだけど、使用するには許可が必要だった。


でもある日、当時セガが作成していた「ホームページ」(当時は WEB サイトのことをそう呼んでいた)が、社内から見られるようになっているのを知った。

セガ公式とはいえ、情報はわずかで、ほとんどがファン同士の交流掲示板だった。


そして、社内で見られるのは深夜 0 時時点のスナップショット。

掲示板の話題は最新ではないし、こちらからは発信できない。

でも、WWW を体験してみるには十分だった。



ホームページは社内の情報部署が作っていたようなのだけど、その部署の人が「個人ホームページ」もサーバーに置いているのを知った。

こちらは非常に個人的なことしか書いてなかったし、当時の個人ホームページらしい、自分の趣味の紹介を書いてあるだけ。


ほとんど更新されなかったけど、時々見に行っていた。



そして、さらに全く違う部署の人も、「個人ホームページ」を公開していることがあると知った。

その人のマシンの IP アドレス直打ちで接続しないといけないし、案内はどこにもない。

でも、出来の良いページを作っている人の IP アドレスは口コミで広まっていた。




そんな社内で人気の WEB ページの一つが、どこかの部署のデザイナーさんが作っていたページだった。


当時の Mac … OS 9 には httpd 機能があって、ページを公開できたのを利用して作られていた。

個人のマシンで直接公開しているので、その人が勤務中しか見られない。


週一回更新されていて、デザイナーさんらしく「扉絵」を 3D CG で描いていた。

毎回ゲームをテーマにしたイラストで、主人公キャラが必ずミッフィーちゃんになっている。


まず、この CG の出来が良かった。

簡単なつくりだけど、ちゃんとそのゲーム「らしさ」を出していたし、主人公をミッフィーちゃんにしてもちゃんと成立するような図柄にデフォルメしてある。

それを、毎週描いているというクオリティの高さ。



もっとも、ページ内は、非常に短い4コーナーだけ。

写真主体で、ちょっと文章がついていただけじゃなかったかな。


先に書いたけど、この頃のホームページって、自分の趣味を紹介したりするのが普通。

その紹介も「プログラムと料理が趣味です」とか書いてある程度で、詳細に踏み込まない人が多かった。


それを、毎週短い記事とはいえ、趣味丸出しで情報を発信している。

これが、会ったこともない人なのに性格がわかって面白い。



僕もこういうページを作ってみたい、と思い始めた。

幸い、パソコン通信環境はある。あとはプロバイダに申し込めばインターネット接続できる。


プロバイダへの申し込みを進めると同時に、どんなページを作ろうか考え、記事を書き始めた。

やっぱりページは4コーナーで構成して、自分が趣味丸出しにできるものにしよう。


作成期間は、確か 2週間くらい。

「Old Good Computer」「社会の歯車」「男の料理(現在「簡単料理の作り方」に改題)」「森の生活」の4コーナーで構成される「魔法使いの森」はこうして公開された。


当初は真似をして毎週更新していたのだけど、だんだん記事が長くなり、書くのが辛くなって毎週更新はやめた。

(今はほぼほったらかしで、申し訳ないと思っている)




先に書いた、デザイナーさんが作っていたページに、告知が出た。


せっかく作っているのだから、インターネットで公開します。URL が添えられていた。

そして、しばらく後には、社内ページは閉鎖されて、インターネット公開のみとなった。


それまでは作者さんに連絡する手段がなかったのだけど、ネット公開になって連絡できるようになり、しばらく仲良くしていただいた。

その後、ベンチャービジネスに参加するためセガを辞める、と聞いた。


そしてさらに後、作成していたソフトが完成したと、ご自身のページで公表していたと思う。


ピンク色のクマのぬいぐるみがメールを運ぶ、不思議なメーラーソフトだった。




ポストペットの公開は1997年 1月だったそうで、20周年のお祝い記事を読んで、上記のことを思い出した。


当サイトが参考にしたページは「ナミ通」。

ポストペットのキャラクターデザイナーである、真鍋奈見江さんが作成していた。



WEB ページ作成時も参考にさせてもらったし、ポストペットの成功は「うまくやったなぁ」と、正直羨ましかった。

僕も何か自分の力でやってみたかったけど、そのために会社を辞めて独立するというのは、なかなかできるものではない。



僕も後でセガを辞めて独立したのだけど、こうした成功者に触れていたことは後押しになったように思う。


#直接的にはやはり同じ部署で独立した、同期の女性デザイナーの成功のほうが大きかったと思うのだけど。

 こちらの話はまたそのうち書きます。



まぁ、そんなわけでポストペット 20周年おめでとうございます。

今は交流はないのだけど、その当時仲良くしていただいた者として…そして、会社経営者として、20年会社を維持したことはすごいと思うのです。



▲目次へ ⇒この記事のURL

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

コンピュータ

業界記

別年同日の日記

04年 ぎょうざ

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

13年 マインスイーパー

14年 zepto で clone


名前 内容

WaveRunner  2017-01-14 09:45:27  業界記

▲目次へ ⇒この記事のURL

WaveRunner は、1996年の秋に発売になったはず。

Model2 で作られた、マリンジェット…もしくジェットスキー、水上バイク、パーソナルウォータークラフト(PWC) などと呼ばれる、海の上を走る小型船舶のレースゲームです。



念のため書いておくと、水上バイクは日本でよく使われる一般名称で、PWC は英語圏でよく使われる一般名称。

マリンジェットはヤマハの商標、ジェットスキーはカワサキの商標です。


そして、WaveRunner というのは、ヤマハが発売しているマリンジェットの機種名。

というわけで、ヤマハに許可を得て実機を登場させた、水上バイクのゲームなわけです。


http://www.gamesdatabase.org/から引用


マリンジェット、WaveRunner なのに、広告チラシ下部の英文では jet ski って書いてある。

わかってないとしか思えない。




たしか1996年の春ごろ、部署内でアイディアコンテストをやる、と企画課の課長が発表しました。


企画は当然アイディアを考えるのが仕事なのだけど、企画以外でも「こんなゲームを作りたい」というようなアイディアを誰しも持っているもの。

でも、そうしたアイディアは埋もれがちなので、みんなに課題として提出してもらって、いいアイディアのものをゲーム化したい、という趣旨でした。


しかし、漠然と「考えて」と言っても、アイディア出しに慣れていない人には難しいだろうから、と、方向性が示されます。


レースゲームとすること。

他にないようなアイディアを入れること。

普通の車のレースゲームはたくさん出ているので、目を引くような変わった操作性が欲しいこと。


この方向性で、各自1つは企画書を提出して、とのことでした。



僕もアイディアを出しはしたのだけど、それはまぁいいんだ。

しばらくして、良いアイディアだと皆の前で発表されたものがあって、そこで「あぁ、最初から出来レースだったのか」と気が付いた。


出来レースといっても、受賞者が決まっていたという意味ではないのね。

ただ、あらかじめ上層部が考えているアイディアがあって、それに沿うアイディアが出てきたところで掬いとる、というだけだった。


マリンジェットを使ったレースゲーム、というアイディアを、何人かが提出したそうで、それらのアイディアが良かった、と褒められます。

これから夏だからタイムリーだし、水上の挙動というのはお客様も慣れていないので新鮮な感じがする…などなど。




僕としては、選出理由を聞いていて、まるっきり白けてしまいました。


この頃、水上バイクがちょっと流行の兆しを見ていました。

テレビのバラエティなんか見てても、「これから流行する新しいマリンスポーツ」的な感じでよく出てた。



今調べてみたら、水上バイク自体の歴史は古いのですが、流行し始めたのはカワサキの Jet ski 以降なのね。

というのも、他の会社は「一人載りのモーターボート」として考えているのに、カワサキは「引っ張ってもらわないでできる水上スキー」と考えていたから。


他社が乗り物を作っているのに、カワサキはスポーツギアを作った、ということでしょうか。似て非なるもの。

これで、1980年代の中ごろにアメリカで流行し始めます。ヤマハが参入したのもこの頃。


1990年ごろにはブームが起きて、これをきっかけに 1990年代半ばから次々と「規制」が作られます。

規制しないといけないほどの大ブームになったという事ね。



その流行が日本に数年遅れで入ってきていたようで、それが先に書いたテレビ番組などの例になります。

たしか、この年の春のショーでも、海外のゲーム会社が、3D視点の水上バイクのレースゲームを出展していました。


つまり、話題になっているし、他社が作っているから、うちも同じようなの作ろう。

ただそれだけのことだし、それを「アイディア」とは言いません。




別に他社の真似が悪いわけではないです。


以前も書いたけど、全く新機軸のゲーム、っていうのは、実は受け入れられない。

どこかで見た、という既視感と、それなのに新しい、という新規性の両立が大切です。


つまりは、真似をしつつ新しいものを入れるのが大切。



今探しても、その海外のゲームが見当たらないのだけど、たしか拡大縮小スプライトで作られた3Dゲームだった。

アウトランとか、パワードリフトとか、そういう感じの画面構成なのね。


時代的に「一昔前」の作りだったのだけど、水上バイクというアイディアは悪くなかった。

じゃぁ、3Dの技術で作り直したらイケるんじゃないか、ってこと。



でも、「アイディアコンテスト」として、これを評価するのは筋が悪い。

「他社にないようなアイディア」という課題だったのに、思いっきり真似です。


さらに、すでに春なのに「これから夏だし」はあり得ない。

ゲーム開発は6か月くらいかかるんです。


もう、この選定の時点で悪い予感しかしませんでした。


…はい、あたりです。


Aqua jet (1996 namco)


jet wave (1996 konami)


wave race 64 (1996 nintendo)



その年の秋は、セガの WaveRunner を含め、4種類も水上バイクのレースゲームが出たんです。

うち一つは家庭用だけど。


特徴的なのは、セガだけがヤマハのマリンジェットをゲーム化し、他の会社はカワサキのジェットスキーだという事。

先に書いたように、水上バイクブームはカワサキのジェットスキーによってもたらされたものだから、そちらにするのが当然と言えば当然。




ゲーム自体はよくできていました。

基本的には、インディ 500 のチームが引き続きレースゲームを作った、という形なのかな。


何作も作っているので、ノウハウは持っている。

ひいき目かもしれないけど、アーケード3機種の中では、WaveRunner が一番人気出たんじゃないかな。


でも、お客さんからすると「似たようなゲームがいっぱい」という状況にはなるよね。

人気が分散してしまい、大ヒットとはなりませんでした。


▲目次へ ⇒この記事のURL

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

業界記

別年同日の日記

03年 libSDL

04年 アンケート

11年 おさんぽ

16年 トーマス・J・ワトソン 誕生日(1914)


名前 内容

アントニー・ホーア 誕生日(1934)  2017-01-11 11:39:18  今日は何の日

▲目次へ ⇒この記事のURL

今日は、アントニー・ホーアの誕生日(1934)


コンピューター科学者で、クイックソートの考案者です。


わかる人には「じゃがいもソート」を思い出してもらえばいい。

…もう4年前になるのか。今では毎年正月の恒例となったNHKの教育番組「大人のピタゴラスイッチ」の、初めての放送時に紹介された動画でした。

ジャガイモの重さを比べながら、軽い順に並べていく。この際のアルゴリズムが、クイックソートでした。


#ちなみに、「しめじソート」もあり、しめじをマージソートで長さ順に並べていました。



ソートというのは「何かを基準に並べること」です。

いろんなアルゴリズムがあるし、適材適所で使い分ける必要がある。


クイックソートは、考えられた当時としては超早かったので「クイックソート」と名付けられましたが、今ではもっと高速なアルゴリズムもあります。

でも、ソートって「理想的な場合」と「最悪の場合」で速度が違うのが普通だし、理論上は速くてもプログラムがややこしくなるのであれば結局遅いし、今でもクイックソートはイイセン行っています。



上は YouTube にあったソートアルゴリズム比較。真ん中がクイックソートです。

繰り返し、いろんな条件でソートを行っているのだけど、クイックソートが平均的に速いのがわかります。




ソートっていうのはアルゴリズムの基本で、いろんな考え方がある、くらいには知っておいた方がいいです。

プログラマでない限り、詳細に知っている必要はないけど。


「検索アルゴリズム」も基本なのですが、検索前に並べてあるのが前提というのも普通だったりもします。

だから、やっぱりソートは重要。


例えば、辞書はすぐに目的の語を検索できます。

これは、辞書の項目が「あいうえお」なり「ABC」なりの順にソートされているためです。


そして、ソートアルゴリズムの中には、「すでにソートされている」ことを前提に、新しい要素を入れる場所を高速に探し出すものもあります。

これ、「ちょうどよい位置を探す」なので、検索アルゴリズムなのね。ソートと検索は密接な関係にあるのです。




「順番に並べる」ための方法をソートと呼ぶので、何もすべてが「計算機で実行できる」わけではありません。


昔、「パスタソート」という話を聞いたことがあります。折れてしまったパスタを長さ順に並べる方法。

パスタをまとめて立てたら、「輪っか」を下から持ち上げていくだけ。

短いものから順に、支えを失って倒れます。倒れたところを傾斜にしておけば、転がって短い順に並んでくれます。



僕は世代じゃないので実際に見たことが無いのだけど、昔の図書館では目録を「検索カード」で管理していたそうです。

著者名順とか、署名順とかで並べられている箱があって、その中でカードを探し出せば、どこの棚に本が置かれているかわかる。


カードの上部…肩の部分には、すべて同じ位置に穴があけられています。

でも、この穴は、「穴」として存在しているものと、穴の上部を切り欠き、カードの辺の「凹み」として存在しているものがあります。

カードを束にして、穴に棒を通して持ち上げると、「穴」のものだけが釣り上げられ、「凹」は下に残ります。


これで、カードを2つに分類できました。


実は、穴は複数空いています。

カードを2つに分けた後、それを「前後」になるように束にして、再度別の穴で持ち上げる。

実は、穴か凹かは2進数になっていて、繰り返すことでカードの束を順番に並べられるのです。


(下の桁から繰り返し、最後に一番上の桁を処理すると、ちゃんと並ぶ)


これもまた、ソートアルゴリズムです。




僕が作るようなプログラムは、ゲームなんかが多いので、使うのはもっぱら挿入ソートです。

非常に単純なアルゴリズムで、あらかじめソート済みの時には十分な速度で動く。


10位までのハイスコアランキング、とかなら全く問題ないし、アルゴリズムが単純なのでむしろ速い。


3D描画のためにポリゴンをZ軸に従って順次並べる…なんてことになると、もっと高速なアルゴリズムが必要になります。

何百も、場合によっては何万ものデータを、かなり短い安定した時間で並べる必要があるからね。


Amazon とかでお買い物をすると、他の類似商品をお勧めされることがあります。

これもソートアルゴリズム。何らかの指標で購入製品と別の製品の「類似度」を測り、類似度が高いものから順にお勧めしているのです。


同じように、google 検索も検索文にマッチしたものの中から、様々な指標で「お勧め度」を算出して、ソートして表示しています。


ページそのもののお勧め度もあるし、更新日付の近さや地理条件なども順位に関連する。

だから、同じ検索内容でも、日によってソート順序が変わったりもします。


何十万もあるページの中から瞬時にソートするには高度なアルゴリズムが必要です。




コンピュータープログラムでは、ソートは基本です。

今の世の中はコンピューターがいたる所にありますから、そこらじゅうソートアルゴリズムだらけ。


もちろん、用途に応じて新しいソートアルゴリズムなんかもまだ考案されたりしています。

でも、クイックソートは古典でありながら、今でも十分利用されているソートアルゴリズムの一つです。



▲目次へ ⇒この記事のURL

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

今日は何の日

別年同日の日記

04年 住宅展示場

06年 自宅で新年会


名前 内容

Android の cordova で file を扱う  2017-01-09 12:31:43  コンピュータ

▲目次へ ⇒この記事のURL

仕事でハマった事例があって、同じことで悩んでいる人がいそうだと感じたので書き記しておこうと思う。

最初に、事象を説明しておこう。ここで意味が分からない人は、この記事を読んでも意味が無いと思う。



・Cordova / Phonegap でスマホ用のコンテンツを作っている。

・<input type="file"> を使ってスマホ内のファイルを選択し、Javascript でその内容を得る。

・iOS とブラウザでは動くのだけど、Android では環境により、ファイル選択できたり、できなかったりする。


まずは、上にある事象を「乗り越えた」。

上の事象で困っている人もいるかもしれないから後で解説するけど、乗り越えたうえでさらに問題がある。


・ファイル選択は出来たが、得られるものが違う。

 iOS と同じ動作にさせるのに、どうしたらいいのかわからない。



原因は、Android ではセキュリティの問題で WebView からローカルファイルが扱えないこと。

ただし、これは途中のバージョンからの仕様なので、「過去との互換性」を気にして、扱えるようにしてある端末もある。


だから、端末によっては動くのに、別の端末では動かないことがある。

原因が特定しづらい、最初のハマりポイントだ。



この問題を「乗り越える」には、Android では file chooser の plugin を使う。

プラグイン自体は多くの人が作っていて、ほぼ同じ動作なので好きなものを使えばよい。


僕はdon / cordova-filechooserを使った。

他のものに比べ、制御用のオプション指定が無い。制御が不要であれば軽量で使いやすい。


HTML の Content-Security-Policy に file: blob: cdvfile: を追加すること。

そうしないと、Javascript からローカルファイルを扱えない。


file: はローカルファイルを意味する。blob: はローカルファイルの中身をデータとして扱う指定だ。

cdvfile: は、Cordova 独自の file 拡張機能を扱うことを意味する。



さて、これでファイル選択ができるようになっても、得られるものが HTML5 で得られるものと違う。

この違いを乗り越えるのが結構ややこしいことになる。




HTML5 の input file で得られるのは、Javascript の「file object」だ。

ファイル名やサイズ、更新日などと共に、ファイルの中身を読み取れるようになっている。


android の fileChooser で得られるのは、ファイルの「コルドバ拡張の」パスだ。

これは cdvfile: スキームで表現される。


特殊なスキームだけど、気にすることはない。

例えば、img タグにこのスキームを渡せば、そのまま画像ファイルを表示できる。


まぁ、ファイルを選択するという目的にはかなっているのだけど、得られるものが違う。

HTML5 / iOS で動くプログラムでは、file object を得られているのに、cordova では file path しか得られないのだ。


僕の場合、file object をそのまま受け渡すライブラリを使っていたので、できれば file object が欲しかった。



window.resolveLocalFileSystemURL を使うと、ファイルのパス名を fileEntry オブジェクトに変換できる。


fileEntry には file メソッドがあり、file object を取り出せる。

これで目的の file object を得ることができた。



// iOS / HTML5 の file タグ
$("input:[type=file]").on("change",function(e){
  getFile(e.target.files[0]);
});


// 上と等価な Android の fileChooser
function fail(){alert("error");};

fileChooser.open(function(path){
  window.resolveLocalFileSystemURL(path,function(fileEntry){
    fileEntry.file(function(file){
      getFile(file);
    })
  },fail);
},fail);


getFile に file object が渡されればよい、というプログラムであれば、こんな感じかな。




ただし、まだ問題がある。


cordova の File API 関連は拡張されている。

というのも、アプリを作成するのであれば、自由なファイルアクセスや、ファイル書き込みも欲しいから。


Javascript では、セキュリティのためにファイルアクセスは基本的に禁じられているし、書き込みもできない。


これらを実現するために、cordova では File API 関数群は全部互換品に置き換えられている。


しかし、ここで問題が生じる。

Android で得られる file object は、cordova による「互換品」であり、HTML 5 の file object とは違うものだ。




HTML5 には、Blob がある。


Blob っていうのは捉えどころのない塊の意味合いがあるのだけど、プログラムの用語としては binary の塊のことだ。

旧来の Javascript では、バイナリは「文字列」として扱ったのだけど、HTML5 ではより効率よく扱える Blob という概念ができた。


file object は blob object から派生したものになっていて、バイナリの塊と共に、ファイル名やサイズ、更新日付などを持っている。


そして、blob も file も、「とらえどころのない塊」なので、そのままではデータとして扱えない。

必ず、データを取り出したり変換したりするメソッドや関数を使用して扱う。



さて、cordova では、こうした「関数」レベルで互換性を保っている。


ところが、僕が使っていたライブラリでは、blob を渡されたかどうかを、データの型を確認して確かめていた。

file は blob から派生したものだから、blob として認識される。でも、それ以外のものを渡されると、エラー終了する。


まぁ、当然の処理なのだけど、cordova の file object は、HTML の blob の派生ではなく、独自の構造体に過ぎなかった。

だから、cordova の file object が得られたからと言って、iOS の file object と同じように処理を行っても、動かない。


ここは非常に厄介なハマりポイントだった。




結局のところ、Android では「そのライブラリを使わない」という決断をせざるを得なかった。


ライブラリを改造しても良かったのだけど、ある程度の規模のものを改造するのであれば、改めて「動作検証」をしないといけないし、今後ライブラリがバージョンアップされるたびにそれを繰り返す必要がある。

そうした手間はかけたくなかったんだ。


幸い、そのライブラリは「各実行環境での差異」を吸収するためのものだったので、Android だけなら独自に書いてもそれほど難しくはなかった。



別の手段として、自前で blob を用意してライブラリに渡す、という方法も考えた。


file object は当然データを得られる。これは cordova でも一緒だし、そうでないと意味がない。

そして、データがあれば blob を生成できる。


ところが、調べてみるとこちらにも問題があった。


blob は元々「ファイルや、ネットから得たデータなどを上手に扱う」ためのもので、入力を前提としていた。

生成する方法も後から策定されたのだけど、ドラフト時点と正式決定時点で方法が違っている。


このため、Android のバージョンにより、blob を生成する方法に差異がある。

Android 4 までと、5以降で実装されている方法も違う…「らしい」。


らしいというのは、僕自身が実機確認できていないから。

確認できない不安があるのであれば、比較的古くて安定動作が望める仕様を使ってプログラムを作るしかない。




最終結論としては、Android の file 周りは、iOS / HTML5 と「共通化しづらい」ことになる。


iOS や HTML 5 では、ファイルを選択した結果 file object が得られる。

しかし Android では file path しか得られず、fileEntry に変換したうえで file object を得ないといけない。


そうやって得た object は、できるだけ互換を保つ努力はされているが、完全互換ではない。

file を受け取るライブラリ等を使用している場合、そのライブラリは動かないかもしれない。


Android で blob を作り出せれば問題は解決しそうなのだが、Android のバージョン間で blob の生成方法には違いがある。

そのため、この方法を使うのは注意が必要だ。



しかし、問題は所在が分かれば解決できる。

解決方法は、そのプログラムごとに違うだろうが、ここに書いたことがヒントになれば幸いだと思う。



▲目次へ ⇒この記事のURL

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

コンピュータ

別年同日の日記

03年 Mac の新しい WebBrowser

13年 続・Windows8


名前 内容


戻る
トップページへ

-- share --

0020

-- follow --




- Reverse Link -