Canvas + HTML5

前ブログで扱った記事を一つ移します。全部引越ししたら良いじゃないか、と思ったのですが、丸ごと移すには前ブログはカテゴリーが増えすぎた感があるので．．．。

主にHTML5のCanvasを扱ったものです。
Canvasというのは、ブラウザ上で図形やら何やらを描画するための機能で、以前からjavascriptの学習の一環でお世話になっていました。

自身のサイト  火頭工房 Hiatama Workshop  で楽曲を公開するにあたって、音楽だけだと少し寂しいので曲に合わせて視覚的にアッピルできるものを作ろうと、改めて触り始めたこの機能。

始めてみると面白いことに曲作りも進むんですよね、映像に合わせて音楽のインスピレーションが沸く、ということでしょうか。歌モノ作りの時の苦労はどこに、すんなりと数曲を公開するにいたりました。

その楽曲達が以下↓

フラクタル木を改造した視覚効果。曲を再生するたびに枝の本数や、大きさが変わります。

Boidsという鳥の群れの動きをシミュレートしたプログラムを改造したモノ、宇宙っぽい何かをイメージしています。ちなみにCanvas領域内をクリックすると群れがついて来ます。

建物と線をテーマにした何か、細い線を引くだけで綺麗なものです。

これらの視覚効果を見ていると不思議と音楽のイメージが沸いてきます。まとめて３曲も出来ちゃいました。あと、今手がけている歌がちょっとエレクトロニカっぽい要素があるので、その練習という噂もあるようです。

(； ･`д･´) ｻｽｶﾞ､ﾔﾘｶﾀｶﾞｷﾀﾈｪ !! (`･д´･ (`･д´･ ;)

以上です。

【go言語】wiki制作をなぞってみた。

どうも火頭です。

最近はgo言語の学習モチスタベーションが低下し、特に何もしていなかったのですが。
これじゃいかん、とこちらの「wikiを作ってみよう」的なページをなぞってみることに。http://golang.jp/codelab-wiki

せっかくプログラミングを学んでるのだから、本当はビシビシとウェブアプリケーションを作ってみたかったのですが、いいわけを列挙しますと．．．

・http関係のことが全然分かっていない、ドキュメントを読みこなす知能もない。

・セキュリティ関連が怖い。

・デプロイするのが大変そう。

・データベースをgo経由で動かす方法を学ぶのが面倒（sqlite3を以前学習しましたが、その後アンインスコしちゃいました）。

しかし、今回の学習で少しだけhttpに関する理解が深まりました（２mmほど）。ちなみに参考にしたページのコードは古くなっているようで、一部動作しなくなっていたようなので注意が必要です（エラーに関する記述など）。

さて、上のwikiページをなぞると以下のように動作します。

・まずユーザーが　http:省略/edit/xxx　にアクセスする。xxxにはユーザーが編集したいキーワードを入力する。記事の新規作成のやり方というわけです。

・サーバーはリクエストを受け取り、編集用ページのhtmlテンプレートファイルを読み込み、それをユーザーへ渡す。ユーザー側に編集ページが表示される。

・編集ページ内で記事情報を入力・送信。この辺はPHPでおなじみのフォーム送信の仕組み。

・サーバーは受け取った情報をテキストファイルとして保存（ここで本当はデータベースに保存するわけですね）。その後、閲覧ページのhtmlテンプレートファイルを読み込み、さきほど保存したファイルも読み込み、合体させてユーザーへ渡す。つまりユーザーは自分が作ったばかりページへ飛ぶことに。 例： http:省略/view/xxx

と、こういう仕組みになっているのですね。テンプレートファイル内にユーザーが入力した情報を埋め込むのに　{{.うんたらかんたら}}　という書き方をするのですが、この記述は始めてだったので面倒でした。

しかし動作させてみると、go側のデータが．．．ページに反映されてるぅ！ 繰り返し処理などもrangeで対応できてるぅ！ なるほどよぉー、とてもフレキシブル、すごいぞテンプレート！　そういや自分のブログのテンプレートにもこれに似た記述があるなー、そういうことだったのか．．．。

チョ、マテヨ。
これ仕組み的にほぼブログじゃね？　自分でブログ作れんじゃね？

ということで次はブログを作ろうかな、と。
すでに記事の管理などは下記の追加学習で行いましたので、あとは画像の埋め込み方法などがわかれば特に問題はなさそうです。ま、デプロイしないので運用もなにもありませんけど．．．学習学習ゥ！！。

追加学習：

タイトルや記事内容のバリデーション・作成された記事の一覧表示・記事の削除、などを行いました。結局はデータベースとつなげれば色々と楽なこともわかりましたが、アンインスコしたsqlite3は私を許してくれるのでしょうか。

おわり

Web Audio API 布教活動。

少し前に見た音楽関係の記事にグレン・グールドのインタビューが抜粋されていました。この記事ですね。

ASCII.jp：なぜ音楽は無料が当たり前になってしまったのか (5/5)｜高橋幸治のデジタルカルチャー斜め読み

～将来、リスナーが自分の好きな演奏を組み合わせて、自分だけのベスト版を完成させるような時代になる、自分はそういうことに取り組みたい～　ということを語ったようです。詳しくは上のページでご確認ください。

クラシックの奏者が聞けば激怒しそうな内容ですが、グールドに言われちゃ文句も言えないでしょう。グールドは同じ曲を何パターンも弾き分けて録音し、それらをツギハギして一曲を仕上げる手法を試みていました。自分の耳を頼りにベストな録音を紡ぐ行為を延々と繰り返したグールドですが、それはリスナーが自分でやる時代になるだろう、という予言です。

楽曲をCDに落とし込む、というのが大前提の考え方では、混ざってしまった音を「後から組み合わせる」ということは出来ません、パートの分離処理がまず無理です。また気に入った部分をPCに取り込み波形をつないで一曲として編集したとしても、作り手側がそういう行為を意識していないと、やはり自然には聴こえないと思えます。

かといって同じ曲のパターンA、パターンB、パターンC、を用意してあげる、ということも非現実的。（どこぞの歌手が全て同じ曲のアルバムを作っていましたが）

しかし、ようやくこれらが可能な世界になりつつあります。
そう、Web Audio APIならね。

私が手がけているこちらのサイトは　火頭工房 Hiatama Workshop　まさにグールドが取り組みたかったことと似た発想です。リスナーが自分の好みで、楽器ごとの音量を決めることが出来、楽器の位置も決めることが出来ます（現在Track6）。

やろうと思えば、ギターソロパターン１、パターン２や、伴奏のパターンを選ばせたりすることも可能です。コンプレッサーやリバーブなどのエフェクター類のかけ具合も実装可能ですが、これらの性能はブラウザ任せです。

欠点はというと、パートごとの音源をサーバーにアップする必要があるので、パートが増えると容量が増加することです。再生のためには、結局リスナーが音源をダウンロードすることになりますので、ダウンロードにかかる時間も考慮する必要があります、親切さを考慮するとせいぜい５～６パート分、mp3だとしても２０メガバイトほどになるでしょうか。

あとは対応していないブラウザがまだあります、これはたぶん時間の問題。

とても素敵なWeb Audio API。
当初、こういう使い方ってミキシング・マスタリングに対する冒涜なのでは？と思ったりしたのですが、なんかグールドのインタビューを読んでからすっきりしました。

ミキシングや録音技術には敬意を払いつつ、新しいテクノロジーを楽しみましょう。まだまだ取り組んでいる人が少ない分野だと思いますので、おすすめですよ。

go言語で画像収集クローラを作ってみた話、続き。

go言語で画像収集クローラを作ってみた話、続き。

作業を続けてわかったことなどを記します。

まず、サーバーの負担を減らすため、httpリクエストを一度だけにまとめたい問題から。

ぐぐって色んな人のコードを見たところ、画像データを取得するには画像URLに対して毎回http.Get()しているようです。

そういうものですか。ええい、なら別の手段だ！

というわけで、別の方法でサーバーの負担を軽減させることに。

考えたことその１。リクエストの間にちょっと時間を置く。

これはtime関数で簡単、ただしサーバーに無知なので、どれくらい時間を置けばどれくらいの影響があるのかよくわかりません。

その２。リクエストの数を減らす。

最初のhttp.Get()では、指定したウェブサイトをパースします、返って来た値を元にページの全ての要素をチェックし、srcタグに対してのみ取得処理を行う、というのが今回のクローラの動きなのですが、この最初のリクエストで取得したデータでなんやかんや判断する必要があります。

まずは正規表現で拡張子の選別。画像収集が目的なら大抵はjpgかpngになると思いますので、それ以外は無視。これで無用なリクエストが減らせます。

それから、とあるサイトで全く同じURLを持つ画像がありました。これはハジきたいということで、洗い出したURLをスライスに保存、その時for rangeで同じ値がないかチェックをかけることに、一度保存したURLは無視です。正規表現処理と合体させて、保存を扱う関数としてまとめました。

URLを保存するスライスを作るのなら、上限を決めとけばいいや、ということで １サイトにつき１０個のURLしか保存できないように、とかしておけば、あまり無茶なことにはならんだろう、と。 パースしたデータの後ろの方に激ヤバ画像があった場合、残念ながら取得できませんね。

そもそも、データサイズが数キロバイトのものは無視したい、サムネイルとかバナー、ボタン等、 なんとか出来ないかと 以下を試しました。

サイトによってはhtml内の画像データにwidthやheightを指定しています、 これは最初のリクエストで閲覧可能なため、ここでwidthが200px以下のものなどは無視するようにしましたが、 サイト側がサイズを指定していない場合はスルーされてしまいます。サイトによってマチマチですが、おおむね効果があります。

それより画像のデータサイズを取得できれば大体判断できるな．．． どうにかしてデータサイズを．．． あ！http.Get()で画像URLを指定しデータを取得すれば ContentLength　プロパティが含まれる！これでデータサイズを取得できるぞ！やった！って、おバカ。

リクエスト投げちゃ主旨から外れます。 ただしリクエストを投げた後、データサイズを見て画像を保存するどうかは決められるので 採用しましたが「httpリクエストを減らす」という目的には一歩届かず。

その後は、画像を保存するために"os"パッケージをインポートしてフォルダーとファイル作成、それから書き込み処理（というかコピー処理）。フォルダーとファイルは連番で作成できるように作りました。

こんな所で作業終了。学習のために作ったものですので、むやみにクロールをかけることはしませんので、ご安心を。

Scalaかgolangか、それが問題だ。

タイトルの通りそれが問題だ、いや、だったのだ。

javascriptを学習して以来、もう一つくらいプログラミング言語を学びたいと思っていたのですが、候補のScalaかgo言語（golang）どちらにするか決められずにずっと悩んでいたのでした。更に、Pythonも良いかもなぁなど、気づけば半年ほど流れてしまったわけです。

これじゃいかん、とついに決心。go言語で行きます。なんか環境構築が一番簡単そう、かつIDEが軽量っぽかったので　笑。（実際中々快適です）

使ってみた感想は．．．「難しい」です。
型宣言？　なんでこんな面倒なことを．．．
引数にも型宣言すんの？
ポインタ？　初心者キラーとして有名なアレ？　やっぱ全然ワカンネ。
とまぁこんな感じでした。

ログ出力もjavascriptならブラウザのログをクリックすればプロパティが調べられたりして楽だったのですが、go言語はそういうことが出来ず、ちゃんとドキュメントを読む努力をしないといけないようです。そもそもgo言語で作りたいものがないという噂も出るシマツ。

チョ、待てよ。そういや近所の図書館でgo言語入門書があったぞ。

シケた図書館にしては珍しい蔵書だったので、覚えていたのです。そこでサイトで貸出状況をチェックをしてみたら．．．残念、貸出中。実はこの状態が２週間以上続いていて、誰か知らんが年末手前からずっと借りてやがるんですよね。

まぁそれは良いとして、毎回あの図書館のシケたサイトにチェックしに行くの面倒。キーワード打ち込んでクリックをするのにもカロリーを消費します、自動で確認してくれる機能があれば．．．

チョ、待てよ。こういうのどっかで聞いたことあるな．．．と思い出したのが「HTML解析」です。パーサーとかクローラと呼ばれるものです、これを試しに作ってみようというお話。

実際はセッションだかの関係上、図書館の在庫チェックには使えなかったので、方向転換して画像収集クローラを作ることに。

ちなみに実際、図書館のサイトに情報収集クローラをかけて犯罪に間違われたという話があります。悪意はなかった、ということで大きな事件には至らなかったと記憶していますが．．．サイト巡回は気をつけないとサーバーに負担をかけてしまうということですね。

私がこの手の記事を書く時は大体の作業は終わっていて、このクローラも多少ムリヤリですが、目的は達成しております。

しかし現状では画像の数だけhttpリクエストを発行しており、なんとなくサーバーフレンドリーとは言えない気がします。httpリクエストは一度だけで済みそうなものなので、もう少し勉強してみます。

サイトに設置されているボタン用画像などは保存しても仕方ないので、正規表現を使って特定の拡張子のみを保存する、といったことが出来ればと思います。

というわけでgo言語、始めてみましたというお話。

ハバネロ栽培とその使い道。

今年育てたハバネロ、最終のご報告です。

寒い地域に住んでいるのですが、生育自体には問題なかったように思います。

寒い分、栽培のスタートが遅れ気味でしたが沢山収穫できました。
生育が悪いものは早めに撤去した方が良いですね、残しておいても実が小さくあまり意味がありません。

霜が降りると要注意、果実の状態が一気に悪くなります。
実がクニャクニャになってしまい、その後あわてて収穫してもすぐに腐ってしまいます。この点は寒い地域住まいの私は不利です、回避するには事前に未熟なハバネロを収穫することになります。

こんな感じに↓　これでもかなりの量が霜にやられ、腐りました。 

さて、ハバネロは収穫してからの処理が大切、適当に放置しておくとカビが生えてしまいます。ハバネロは水分が多くうまく乾燥しないようですので、実を割り、良い天気が続く時に一気に乾燥させる必要があります。

乾燥が難しい場合、保存には冷凍がおすすめ。あるいは醤油漬けやオリーブオイル漬け。

オリーブオイルオイル漬けはあまり日持ちしないという噂ですが、作って２ヶ月目の現在問題ありません。この様子ならおそらく４ヶ月～半年は大丈夫だと思いますが、カビにはくれぐれも注意してください。繰り返しますが、ハバネロはとてもカビやすく、オイル漬けにしても果実の中に含まれる水分からカビ毒を出すかも知れません。

ハバネロの辛さはとても有名ですが、その真価は香りにありまぁす。
唐辛子とピーマンをブレンドしたような独特の香りを持ち、他のスパイスでは代替がきかないと思います。

試してみた調理例としては．．．
アヒージョにハバネロオイルをちょい足し、鳥や豚の素焼きにハバネロオイルかハバネロ醤油、カレーや洋風煮込みに実を半分～１個、など。活躍の場は広いです。

今年の目的は実よりも種を取ることでしたので、その目的は十分に果たしました。次は５月頃から栽培を開始しますので、お楽しみに。

雨降らしサイト「レインマン」のその後

公開して以来しばらく様子を見ていた雨降らしサイト「レインマン」ですが、

ちょっと手を加えました。

http://imrainman.com/main.html

今までは雨、しずく、雷の３種の音源を鳴らすのみだったのですが、いくつか音源を追加しました。新たに加えたのは、風、鳥、虫です。

これらは最初は音源を読み込んでおらず、ユーザーがクリックによりダウンロードし
Web Audio APIで再生を開始するオプション音源となっています。さらに雷もオプション扱いにしました。

やはり後から機能を追加するのは色々と面倒で、最初から拡張を予測する必要性を
痛感しております、保守って大事。とてもいびつなコードが出来上がってしまいましたが、また追って直していこうと思います。

 

あとボチボチデザインもなんとかしようかなぁと思いつつあります。