カテゴリー: プログラミング

おい、あっち側かよヽ(`Д´)ノ

ゼルダの伝説 ふしぎの木の実 時空の章をクリアしたヽ( ・∀・)ノ

レベル8のラスボスの最終形態の倒し方のみ分からなくて攻略を見てしまった(ヽ'ω`)
だって伸びてる方は掴めなかったから、てっきり違うのかと…(´;ω;`)

まあそれ以外の謎は自力で解いたので良しとしよう。

このゼルダはジャンプが出来るので良かった。
無駄にジャンプして移動するのが好きなので(・∀・)

まだ大地の章をクリアしてないので詳しくぐぐってないのだけれども
カプコンゼルダの裏話とか早く読みたい。

しかしちょっとゼルダ疲れが…(ヽ'ω`)


塗り潰しツールだけでもつけようと思ってハマる。
ペイント・ルーチンで何となくロジックは分かった。

javascriptでのサンプルはないかとぐぐったらあった(・∀・)
JavaScript, Canvas スキャンライン・シードフィル アルゴリズムによる塗り潰し

でも自分のコードで使おうとしたら、うまく描画されない(ヽ'ω`)

更にぐぐったら他のサンプルもあった。
JavaScriptでバケツ塗りつぶし

これは一応描画されるけど、なんか違う色になってしまったり、
何回かやるとエラーになる。これは使い方を間違えてるのかもしれない。
あと何故か塗り潰しが不完全だったりする。これはもしかするとアンチエイリアス絡み?
透明度とかの問題?

画伯によるWeb上で見かけたゴードンのぬいぐるみ写真の模写
gordon01

拡大すると…
gordon02

んーまあ簡易ペイントなのでこれくらいでも良いような気もする…
今週で完成させる予定だったのに、来週になるな…(ヽ'ω`) ゼルダヲヤリスギタカ…

仮面ライダーを観終わった…(ヽ'ω`)

長い戦いだった…_| ̄|○
全98話もあったのでウルトラマンAの時と同じように
最後の方はちょっと流し見っぽくなった(ノ∀`)

ウルトラマン系と違って、なんか時代劇の剣豪みたいな流れがあるように感じた。
戦闘員をバッタバッタとなぎ払う所の爽快感はまさしく時代劇の〆の殺陣だった。

リアルタイムで初めて観た記憶があるのがスカイライダーであり、再放送でも
観たことのない時代の作品だったので色々と面白かった。

wikipediaの仮面ライダーの項に裏話的なものが
結構あって読み応えがあった(・∀・)


本郷猛役の「藤岡弘、」が怪我をして一文字隼人役の佐々木剛が
起用されたのは知っていたが、かなり初期の段階で変わったので
ちょっと笑ってしまった。

佐々木剛がその後の人生が火事を起こしたりして大変だったというのも初めて知った。

FBIの滝和也役の千葉治郎が千葉真一の弟であると知って驚いたΣ(゚∀゚;)
滝が異様に出てると思ったけども「藤岡弘、」の穴を埋めるための
苦肉の策でもあったというのを知り、なるほどなぁと思ってみたり。

緑川ルリコ役の人が良かったのに山本リンダとかに変わってしまって
がっかり(´・ω・`) 山本リンダの話し方というか発声が嫌だった。
ミミーことミミ萩原はなんか美人ではないが何か魅力的な感じだった。

ショッカー戦闘員の衣装は知っていたけどゲルショッカー戦闘員の衣装は
知らなかった。エンディングが逆回しでゲルショッカー戦闘員が飛び上がってくる感じになっていたのは凝ってるなと思った。

ゲルショッカーになってから24回くらい、つまりは2クールしかやってないのはなんでだろう?
もうちょい続ける気があったけど視聴率的な問題があったのだろうか。
短かった所為かゲルショッカーはブラック将軍しか幹部が居なかったな。

少年仮面ライダー隊の通信方法が伝書鳩で笑ったw
読んだことないけど「レース鳩0777」っていう漫画があった時代か。

ちょっと他のを観てからV3を観るか。
仮面ライダーもXからBlackまでが無いんだよな(´・ω・`)
ウルトラマンもタロウから80まで無いのはなんなんだろうか。

※配信終了してるかも


undo
Paintingに以下の2件の記事を参考にしてUndo/Redo機能を追加した。
Undo and Redo with HTML5 Canvas
HTML5でお絵かきツールを作ってみた

無限Undo出来るかなと思ったが、320x240のcanvasを35~36枚くらい
配列に格納した時点で3DSブラウザが灰色表示になって
「メモリ不足です」みたいなエラーメッセージを吐いた(ノ∀`)

余裕を持たせて24回で0に戻るループにした。


もう少しいじったら統合して終わりにしよう…(ヽ'ω`)

Javascript Japanese Keyboard

Javascript Japanese Keyboardを公開したヽ( ・∀・)ノ

ただの単漢字変換のみ対応しているだけのVirtual Keyboardだけどね(ノ∀`)
いずれ消しちゃうけどここで動作確認出来る。
漢字選択はマウスオンリー。

対応ブラウザは3DSブラウザとchromeとFireFox。
Androidのchromeでも動いた。

だがしかしIE、てめーは駄目だ(・∀・)

XMLHttpRequestとイベントソースとファイル読込のところを
いじらないと駄目なようなのでほっとくことにしたw


事の起こり
全てはFoto-Haikingを作っていた時に3DSブラウザの仕様というか
3DSの入力システムの壁にぶち当たったことから始まった。

と言っても入力システムの仕様はFoto-Haikingの機能に対して何の問題もなかった。
問題だったのは特に必要もないのに適当に思いついて実装した入力支援機能(´・ω・`)

入力支援機能はカーソル位置(selectionstart?)から挿入位置を取得するように
していたのだが、これがいけなかった。
3DSの入力システムはどうも閉じられた空間で文章の編集を行うようで、
入力終了後、カーソル位置は必ず文末になるという仕様だったのだ…_| ̄|○

このままでは入力支援機能は3DSブラウザ上で機能しないヽ(`Д´)ノと慌てて対策を考えた。
色々考えているうちに、

「3DSの入力システムに依存しない入力システムがあればいい( ・´ω・`)」

と閃く。つまりJavascriptの日本語入力システムがあれば(`・ω・´)

ということで色々ぐぐったが、どうも欲しいものが見つからなかった。
需要がないからか実用性に乏しいからか、はたまたかつては存在したけれども
絶滅したのかJavascriptのVirtual Keyboardというものはヒットしなかった。

ime.jsやGoogle CGI API for Japanese Inputもあることはあったが
「ちょっと使うのが面倒くさそう(´・ω・`)」と思い回避した。
というか頭の中がいっぱいいっぱいだったのでそれらに手を出す余裕がなかった(ノ∀`)

最終的に挿入位置を自分で指定するというド阿呆で屈辱的な実装で誤魔化した(´;ω;`)


何となく作り始める
なんやかんやで一応Foto-Haikingが完成し、一週間くらいダラダラしようヽ( ・∀・)ノっと
思っていたが、何となく頭に引っ掛かるのはJavascriptの日本語入力。

この引っ掛かりをなんと表現していいのかわからないけれども可能性的何か( ・´ω・`)?
より細かく表現すると可能性とその実装方法のセット?「作ろうと思えば作れる」の
もう一歩進んだ状態の「You 作っちゃいなよ(・∀・)」的状態というか。
自分で言っていてよくわからないが(ノ∀`)

まあ別にこれが出来たからと言って実用的でもないし金にもならんし
職にもつながらないんだけども、Javascript 日本語入力というか
Javascript IMEっていうものが有ってもいいんじゃなかろうかという
可能性の視覚化というか具現化をしたくなり、ちょろちょろと作り始める。
一応3DSブラウザで動くことが目標だった。


余裕綽々(・∀・)

入力変換用のテキストフィールドを用意して、押した入力ボタンの文字を格納。

変換ボタンを押す。ヘボン式のアルファベットに変換して変換ルーチンに渡す。

連想配列?みたいな感じに単漢字データを用意して、ヒットした漢字を
コンテキストメニューに表示。

入力変換用のテキストフィールドの内容を選択された漢字に変更する。

確定ボタンを押して、最終的な入力先に追加する。

というような流れは頭にあったので、システム部分はちょこちょこと
コーディングしてたら一週間も経たずに出来た(・∀・)

chromeでも3dsブラウザでも動いた。
FireFoxは最初、漢字選択が動かなかったが、thisでイベントソースを渡したら動いた。
IEはちょっと試したが時間が掛かりそうなので放置した(・∀・)

ime.sysは凄いけど、中身を理解するのが難しそうなので使わなかった。
Google CGI API for Japanese Inputは一応JSONPで結果を
取得出来るようにはなった。

実際にFoto-Haikingに実装する際には併用型にしようかなと思った。


甘い予測( ・´ω・`)

さてシステムは単漢字変換だけとはいえども出来上がった。
次に必要なのは辞書データである。単漢字なので読み方だけを対象とした。
問題は何処までを範囲とするかである。

当初は常用漢字だけにしようかと思ったが

常用漢字 1945字(1981年制定)…… 高校教科書はここまで(下限は不明)
第1水準 2965字 …… 都道府県名・市区郡町村名は全部カバー
学校で習う漢字の数は?

とあったので、どうせ単漢字だから第一水準までやってしまうかと考えた。
第一水準まであれば一般的な文章なら大体カバー出来るだろうしと。


どっかからデータを引っ張ってこれたらいいなぁと思ってぐぐった。

仮名漢字変換システムwnnがインストールされたLinuxがあれば、単漢字変換辞書のデータにあります。

kakasidictというデータが使えると思います。
http://kakasi.namazu.org/stable/kakasi-2.3.4.tar.gz
フリガナ付漢字のデータベース

今Linuxのシステムがない…_| ̄|○

kakasidictとその大本にあるskk辞書は良さげだけど、
GPLでライセンス的な問題と内容そのものを流用してもいいのか
よくわからない……ということで自作することにした。
自分の判断で内容を変えられるデータが欲しかったし。

ちょこちょこやればすぐ出来るだろうと考えていた(・∀・)


苦行と後悔(ヽ'ω`)

ということで辞書データを自作を始めたのだけれども、
さすがに一文字一文字を入力しながらやっていくのはきついので
ぐぐってヒットした文字コ-ド表(第一水準漢字)の並びを
コピペ整形して作業を開始した。

単純に並び順に一つの漢字につき一つの読み方(ヘボン式ローマ字)を
付与するだけで3日くらいかかった……(ヽ'ω`)

更にそれだけでは使い勝手が悪かろうと読み方の追加を試みる。
Google日本語入力で出た候補やウィクショナリー漢字辞典ネット
その他の辞書サイトなどを併用しつつ音訓がある程度まで揃うようにした。
余りにも使用頻度が低いと思われる読み方等は追加しなかった。
この際に第一水準ではない漢字もちょろちょろと足した。

明確な日数は覚えていないが10日くらいかかった……(ヽ'ω`)
だらだらするどころか苦行の日々であった。
いや、まあゲームとかもちょこっとはやったがどうぶつの森の日課と
リンクの冒険をちょっとやったくらい……


公開と感想

なんやかんやで辞書データも完成したのでGoogle codeに上げて公開した。
やり方忘れてて少し戸惑った(ノ∀`)

単漢字変換のコードなんて他の人は要らんやろぉ(・∀・)と思わぬこともなかったが、
折角作ったし、自分でコードを管理し続けられるかというとそれも怪しいので公開した。


作成後の感想としては、意外とJavascript IMEってアリじゃね( ・`ω・´)であった。

プロトタイプ的作成だったので、色々と手抜きをしているがw、
単漢字変換の部分を複文節変換にしたり、辞書データの配列のjoinを使って
複数辞書の併用出来るようにしたりも出来なくはないので、頑張ったら
それなりの実用性を持ったIMEが出来るんじゃないかなと思った。

今回のコードでは3DSブラウザでの使用を目的にしてる為、
マウス向けのUIになっているが、PCキーボード使用にも
対応させることは可能だし。

主に単純作業の方で疲れたけれども、まあ挑戦してみて良かったかな(・∀・)


今度こそダラダラするぞ(ヽ'ω`)

不正なトークンの正体が分かった気がする( ・´ω・`)


ダラダラと作り続けているというかちょこちょこ手直ししていて
中々完成しない、はてなハイク投稿用ツールには2つのエラーを孕んでいた。

どちらもOAuthトークン絡みで、一つはOAuthトークンがリジェクトされてしまうケース
("token_rejected")、もう一つは"不正なトークン"として処理が進まないケースであった。

前者ははてなハイクへの投稿に失敗してしまい、クッキーを削除して
もう一度OAuth認可からやり直さなければならず、投稿内容は
当然失われるという致命的なエラー、後者はOAuth認可に進むことが出来ず、
もう一度アップロード作業をするとうまく行ったりまた失敗したりと
いう原因不明のエラーだった。


最初の頃は2つの違いも分からず発生タイミングも理解してなかったが、
色々と調べていくうちに前者のケースはOAuthトークンを用いて
はてなハイクに投稿するタイミングで発生することが分かってきた。

加えてそれは複数のデバイス(例えばPCと3DS)でOAuth認可を行った後、
古いトークンを持つデバイスで投稿をしようとした時にrejectされる
ということがわかった。

ということでこれに関しては常にトークンの有効性を確認してから
投稿ツールに遷移することにしたのでこのエラーは出なくなった。

もう一つの"不正なトークンのエラー"については今ひとつ
発生原因がつかめず、発生頻度もそれほどでもなかったので後回しにしていた。


その後、放置したり作ったりを繰り返し、ようやっとツール作成も最終段階に突入。
未だに発生原因が分からない"不正なトークンのエラー"は余り気にせず、
連携機能のテストを行っていた時のこと。

クッキー削除→fotolifeにアップロード→OAuth認可の為に認可URLに移動→
不正なトークンエラー→戻って再アップロード→OAuth認可の為に認可URLに移動→
不正なトークンエラーという事態が発生した。

今までだと大体なら一回やり直せばうまく行っていたのに、
この時はうまく行かなかったので気になる。
もう最終段階でもあるし、後回しにしすぎていたという
思いもあったのでようやく重い腰を上げて調べ始めた。

初めは古いRequestトークンがセッションで残っていて
それが悪事を働いてるのかと思って、OAuthトークンを正しく取得出来た後に
明示的に削除するようにしたが状況は変わらず。


何がなんだかよくわからないのでlog.infoしていたRequestトークンの内容を見てみた。

不正なトークン
111

うまくいったトークン
222

一見してRequestトークンの末尾がおかしい。
これか(・∀・) ワイノカチヤデ

と喜び勇んで一旦tempのTokenに食わせて取り出してtrimして
再度Tokenにしてみたが状況は変わらず…_| ̄|○

Token.toStringの中を見ても

return String.format("Token[%s , %s]", new Object[] { this.token, this.secret });

という感じなので、これは関係ないか…__◯_

よくよく見るとフォントが違うだけの問題なのかこれは。


だがしかし、エラー画面のURLを見つめるうちに何かを頭の中をかすめた。
333

( ゚Д゚)ハッ これ普通に考えたら"+"が空白として解釈されるんじゃね( ;・´ω・`)ゴクリッ?

幾度かOAuth認可を試してみると、確かに不正なトークンとしてエラーが出るのは
"+"が中に含まれている時のみ……


というわけで取り敢えずindexOfして"+"があったらRequestトークンを
再取得するループを入れたコードにして試してみる。
20回程試してみたがエラーが発生しないヽ( ・∀・)ノ

だから多分今までのエラーの原因は"+"だったのであろうという結論に達した。
つまりRequestトークンをパーセントエンコードしてなかった俺が悪いのか (ヽ'ω`)
自分でやんないと駄目なんだな。


再取得ループは間抜けなのでパーセントエンコードの方に直さないといけないな。
まあでもこれで致命的なエラーはなくなったから良かった良かった(・∀・)

後、エラーというほどでもないけど謎なのは、3DSから認可をした場合に
何故か複数回OAuthトークンが返されるのだけれども、あれは3DSブラウザの
仕様なんだろうか。PCでは一回だけのようだけれども。うーむ(´・ω・`)