読者です 読者をやめる 読者になる 読者になる

letsspeak's diary

世界を大いに盛り上げるためのletsspeakの日記。

Ruby on RailsのMySQLバックアップタスクを書いてみた

以前Fuelで書いたバックアップタスクがあるのですが、あれの安心感が結構あったのと、いま作っているものが Ruby on Rails だったので、さっくりrake版を書いてみました。
大したものではありませんが、なんとなーくConfigの触り方が分かりました。

rubyyaml読むの楽ですね!
database.ymlに追加でbackupdirを設定できるようにしてみました。
コマンドラインと自動実行、apacheから呼ばれた際のユーザーの違いによる権限エラーにご注意ください。

mysql.rake
https://gist.github.com/letsspeak/7988055
Ruby on Rails mysql backup rake task

javascriptのcanvasで画像を自由にトリミングしてアップロードする機能を作ってみた

今回はjavascriptで画像をアップロードする際にトリミングするコードをcanvasを使って書いてみました。


趣味でゲームのスクリーンショットをアップロードしてみんなで見せ合うようなWebアプリケーションを作っていたのですが、元の画像サイズやファイル形式って人によってまちまちだったりします。


ゲームということもあり、デジカメのような大きすぎる画像サイズになることはないのですが、どうしてもプライベートなチャット内容が入ってしまうのは嫌です。できれば自分の見せたい範囲だけをアップロードしたいものです。


また無圧縮のpngやbmpなんかでアップロードされた場合、数MBの画像をやりとりする分けにはいきません。そこですこし劣化したjpeg等の圧縮された画像形式に変換することになりますが、これをサーバー側で行うと、プレビュー画像をユーザーに見せるタイミングがサーバーで処理を行った後になってしまい、ユーザーの時間とサーバーリソースが無駄に消費されてしまいます。


そんな訳ですべてjsのcanvasでやってしまおう!という感じで実験しつつ作ってみました!

trimming_upload.js
https://github.com/letsspeak/trimming_upload.js


行っていることは、

1.ファイルが選択されたら画像を読み込む
2.この際、画面表示用のlayer1には設定された最大サイズで比率を維持して読み込む
3.また裏のbaseに元画像のサイズのまま読み込んでおく
4.画面表示部分がクリックされた際にlayer2にトリミング用の矩形を描画する
5.画面には常にlayer1とlayer2を合成して表示する
6.トリミング確定後、アップロードボタンが押されたら元サイズのbaseボタンからトリミングサイズに基づいた比率で切り抜いてデータを送信する。

という感じです。

f:id:letsspeak:20131122020607p:plain


こんな感じで設定した最大さいずでプレビューしつつ、トリミングは元画像の比率で行うようになっています。

今回のハマりポイント
context.drawImage() の際の第一引数になるcanvasサイズが width, height ともに 0 の場合に例外が発生するようです。これに気づかず20分程はまってしまいました...。


書いていて気がつきましたが、元のトリミングサイズのままアップロードしたい場合の処理がありませんねwこの辺を次の課題としつつ今回はこの辺で終わりとさせていただきます。

ではよいお年を。

電脳化の話メモってなかったので

忘れる前に書いておく。
インプットにせよアウトプットにせよ、その信号が何を表すかというのには個体差があるのではないだろうか。
全ての存在する概念について人間個体の脳結合要素を洗い出してるうちに人生が終わりそう。

と思って結構悲観的に考えてたけれども、今思ってみると概念まで直接伝達する必要は微塵もないな。
むしろそれは200年後の話で、とりあえずのところは5感にインプットすればいいじゃん。はい解決。

ec2にhaskell-platformをインストールする

噂のyesodさんを試してみたいと思いつつ、手元のmacで失敗した経緯をもとにインスタンスをすぐ消したりできるec2を使って試してみました。

インスタンスの立ち上げ方については詳しいページがあると思うので割愛!
最初はさくらVPSで使っているCentOSと同じRed Hat Enterprise Linux Server release 6.4 (Santiago) を選択しましたが、haskell-platformのmakeで失敗しました。
はっきりいって初心者の自分には何が理由で失敗したのかさっぱり分らなかったので、気を取り直してAMIでインスタンスを建て直し、試しにRed Hat と同じコマンドを打ってみたところhaskell-platformのmakeが順調に進み....謎の失敗。

ググってみると下記のブログがヒット!

AWSのアカウントを作ってみた
http://amkkun.hatenablog.com/entry/2013/02/06/183901

どうやらマイクロインスタンスではメモリが足りないという事で、一時的にスモールインスタンスに変更してmakeを実行します。いつもいつも先駆者の方々に感謝です。

macであれほどうまくいかなかったcabal-installについても、一度は失敗したものの先述のmake時と同様にスモールインスタンスで実行したところ無事成功しました。
一通りの手順は下記に纏めておきました。

set up yesod on ec2 Amazon Linux AMI 2013.03.1 64bit
https://gist.github.com/letsspeak/5650158

haskellぐぬぬって感じは未だに拭えないです。
無事yesod環境構築できた暁には、AMIのスナップショットを保存しておきたいなー

ファイルの所有権について

ファイルシステムって概念自体を理解する事が難しい。

デジタルネイティブなら普通に理解していたりして、現状のままでも良いのかもしれないけど、もうちょっと理解しやすいファイルシステム無いのかなーとか、なんで理解しづらいのかなーとか、ファイル名以外からファイルを特定する手順についてほんの少しだけ考えてみた。

そこで思ったのが所有権。

ファイルから名前という属性を取った時に一番最初に思うのは、○○さんから貰った○○。
今のPCってファイルを端末間でコピーしたら所有権は基本的に委譲されるけど、これってかなり重大な設計ミスなんじゃなかろうかー

真逆の発想をとると、ファイルの所有権なんて無視してすべてのファイル誰でもいつでも見れるようにしてしまう。

私の煩雑なデスクトップをコンピュータさんが自動的に整理するためには、どちらかが必要なんじゃないかなと、なんとなく思ったのであった。

追記:

ファイル共有で動画でもアニメでも音楽でもなんでも無料で配信してしまってから、支援者がお金を払うシステムっていいんじゃねってちょっと前に思っていたけれども、人間無料で手に入れられるものは無料で手に入れてしまう。(それによって相対的に自分の価値を下げてしまうにもかかわらず。)

で、これの問題点を解消するべく、お金を払って得た人と、はらわずに得た人を晒しものにしてしまえば良いのではなかろうか。などと思ったところで、ニコ生ってすげえなと思いつつ寝るのであった。

ビジュアルプログラミング

ビジュアルプログラミングがいま熱い!

enchantMOONの登場でさらに加熱して、自分ならタブレット端末でどんな風にプログラミングできる環境を作るかを妄想しながら寝た。

まずもって時が小さかったり情報が詰まってるのはアウト。
よく使う制御構造や機能は簡単な記号の手書き認識化。
挿入文字列はすべて別の辞書化。
制御構造の逐次記述は多くても1画面4行程度。

関数型言語をまじめに勉強していないので、
逐次記述がほんとうに必要なのかどうなのかをもう少し煮詰めて、
モジュール化とその関係性のビジュアル化の可能性を突き詰める必要あり。

起きてから、MOON block 見てみたけど...
ごちゃごちゃしてる作業場にするならタッチペン使う必要ないじゃん...。
ほんとうにさっと端末を取り出して、さっと書けるようにするのが理想。

宇宙の外側

宇宙の外側がどうなってるのかってのは、人間として生きてる以上、気になって夜も眠れないレベルの問題なんだけれども、

地球上のもの < 地球
地球 < 太陽系
太陽系 < 銀河系
銀河系 < 銀河団

みたいな感じでスケールして、宇宙すげー!
ってことは

宇宙 < ???(宇宙がたくさんある?)

っていう考えはまず間違いであることに気づいた。
というのも次元で考えると全部同じ範囲に収まるからで、

地球上のもの < 地球 < ... < 宇宙 < ????

という比較は、

もの < 宇宙 < ????

と変わらず「もの」の中の規則をそのまま外にあてがうのは間違っている。
あまりにも宇宙ヤバイインパクトが強すぎて目の前が見えなくなってしまっていた。
比べることで規則性を見いだすのであれば、

素粒子のふるまい < 宇宙 < ????

の方がよっぽど妥当じゃないか、と風呂に入りながら考えた。