春ですね、火頭です。
せっかく田舎に住んでいるので、畑を借りて色々育てているのですが、畑に付きっ切りにはなれない生活ですので、手のかからない野菜が中心です。
去年から、上手く育てたら１０年近く収穫可能というアスパラガスを育てています。
種から育てたので初年度は収穫はできず、２年目の今年からボチボチと採れるようです。
最近の暖かさもあり、ついに出ました。↓
にょいーん。
食卓を助けてくれることを祈ります。
家計はいつでも厳しいんだよ！
go言語でsqlite3を動かすのに苦労した話 その２。 【Windows7 64bit】
前回からの続きで、次はgolang側の苦労。
ちなみに今回目指すのはブログの仕組みを作ること。
とりあえずSQL操作のおさらいと、go言語側での操作を学習。テーブルへのデータの追加・削除・検索・上書きなどを確認。とりあえずこれだけで動作するでしょう。
なにせ以前手がけたWikiページを改造し、楽をすることしか頭にありません。
Wikiページは記事の内容をテキストファイルに書き込んで保存する仕組みだったのですが、これをsqlite3のために書き換えていく、という作業。
特に問題もなく進んだのですが、新規作成ページと記事一覧のページを新しく作ることに。
記事のリストを一覧表示させるのに、SQLのテーブルに割り当てておいたprimary key の idを頼ろうと思っていたのですが、記事を削除するとidが歯抜けになる。なんとなく気持ち悪いなって調べ始めたのが良くなかった、無駄に頭を悩ませました。
autoincrement はどうかと調べたらパフォーマンスが悪いとか（気になる規模なわけないですが）。それにautoincrementを採用しても歯抜け問題はそのままになるようで、結局放置することに、ユーザーに見せなきゃ良い話だし。
別問題で、記事の一覧表示は作成日時で並べるのが普通だ、これはタイムスタンプが良いだろう、ということで採用。でもそしたら新規作成（タイムスタンプ記録する）と記事の再編集（しない）は別の処理になってしまうなー、いやいや、編集日時も保存すべきか．．．など、こうして作業が増えていくわけです。
上の内容を採用したりしなかったり、今回はこの辺で作業終了。
車輪をバリバリと再開発している火頭でした。
実際の挙動はこんな感じ。
新規作成ページ、保存すると↓
記事一覧に追加されます↓
編集ページ↓ 画像タグを直接打ち込むと．．．
閲覧ページでちゃんと反映されます。↓
go言語でsqlite3を動かすのに苦労した話。 【Windows7 64bit】
以前アンインスコした sqlite3 を再度インスコし、go言語で使ってみた話。
めちゃくちゃ苦労した。
結論から言えば Windows7 64bit の環境でgolangからsqlite3使うには、まずsqlite3をインスコ SQLite Download Page
githubにおいてあるsqlite3用のドライバをgo getでインスコ http://mattn.github.io/go-sqlite3
さらに mingw をインスコして gcc と呼ばれるものを入れないといけない、ということでした。http://mingw-w64.org/doku.php/download
なぜgcc（コンパイラです）を新たに追加しないといけないのかはよくわかりませんが、海外でも同様の悩みが多発しているようです。
あとsqlite3の実行ファイル類（exe, dll等）は作業中のフォルダに入れなければいけません。
激烈苦労した後、どうにか動作した、と思いきや．．．なんか遅い。
動作が遅いのです。コンパイルに２０秒くらいかかる。
これはわりとすぐに解決しました。sqlite3のドライバをgo install をすると動作が軽快になるとのこと。私はliteideを使っているのですが、作業ウィンドウ内でinstallボタンを発見、この操作一発で解決しました。どこぞのフォルダが若干汚された気がしますが、まぁいいや。
ここに辿りつくまで、環境変数を無駄にイジイジしたり．．．こういう環境整備系はホントに苦手です。
普段ソースコードを公開せず、全くコミュニティに貢献していないので、せめての備忘録でございます。
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"パッケージをインポートしてフォルダーとファイル作成、それから書き込み処理（というかコピー処理）。フォルダーとファイルは連番で作成できるように作りました。
こんな所で作業終了。学習のために作ったものですので、むやみにクロールをかけることはしませんので、ご安心を。
