粘土のようなシリコンラバー「Sugru」がキニナル

http://www.lifehacker.jp/2012/05/120511sugru.html
で紹介されている粘土のような感覚で使えるシリコンラバー「Sugru」がキニナルのです。
こちらで紹介されているLEGOとの組み合わせがなかなか楽しげです。

http://www.sengoku.co.jp/mod/sgk_cart/detail.php?code=EEHD-0FRX
で購入できるようです。

他にSugruを知るには以下のようなサイトがあるようです。
http://sugru.com/
http://arata.tv/camera2/2012/01/-sugru.html

中とじ製本用ホッチキス「ナカトジ～ル」がキニナル

中とじ製本用ホッチキス「ナカトジ～ル」がキニナルのです。
この手の名前は個人的には好感をもてるのです。

使い方は、以下をご覧ください。
http://wis.max-ltd.co.jp/op/product_catalog.html?product_code=MC90001

簡易コンパスや分度器の機能もあるようですが、そういうなんかどうでもいい機能がついているのも好感が持てます。


で紹介されていたのです。

サン描画シルクスクリーンセットがキニナル

手作り年賀状もこれでできる！【孔版・サン描画技法】シルクスクリーンセット　サン描画キット 価格：2,550円（税込、送料別）

お手軽にシルクスクリーンを楽しめるセットのようです。
ちょっとキニナルのです。



で紹介されていたのです。

カレー粉とかも使っているのが、楽しげです。
色はよさそうだけど、いいにおいもしちゃいそうです。

railsのrespond_toでcsv

railsで一つのアクションでhtmlを表示したりxmlを表示させたりするときは、respond_toを使うわけですが、csvもできます。
検索すればいろいろ出てくるのですが、私はこんな感じにしてみました。
ちなみに1.8.7の場合です。

show_dataというアクションでhtmlとcsvに対応しているケースです。
csvファイルはダウンロードされて、ファイルはsjisになるようにしています。
データの取得は、Hogeモデルのget_dataでなんかしているものとしています。
html表示用のviewは別途show_data.html.erbなどが用意されているという前提です。

  def show_data
    @data = Hoge.get_data
    respond_to do |format|
      format.html
      format.csv do
        require 'fastercsv'
        csv_text = FasterCSV.generate do |csv|
          csv << ["head1","head2","head3","head4"]
          @data.each do |d|
            csv << [d[:col1],d[:col2],d[:col3],d[:col4]]
          end
        end
        send_data(csv_text.tosjis, :type => 'text/csv', :filename => "download.csv")
      end
    end
  end

viewからは以下のように呼び出します。

<%= link_to "HTML表示",:action=>"show_data" %>
<%= link_to "CSVダウンロード",:action=>"show_data",:format => :csv %>

sinatraで複数選択のcheckboxの値を取得する

sｉｎａｔｒａに限らないのかもしれませんが、複数選択する場合のcheckboxの取り扱いです。

ケース１
一番単純なのは、それぞれ別の名前のチェックボックスを用意することだと思います。
以下のような感じです。

好きな色は？
<input type="checkbox" name="like_red" value="red">赤
<input type="checkbox" name="like_blue" value="blue">青
<input type="checkbox" name="like_green" value="green">緑

この場合は、paramsの値をチェックすればOKです。
チェックされているときだけ、値が入りチェックがなければ値が入っていません。

チェックされていれば
params['like_red']
で"red"が取れます。


ケース２
他にparamsで配列で受け取れるようにする方法もあります。

以下のような感じです。
nameの書き方がポイントです。

好きな色は？
<input type="checkbox" name="like[]" value="red">赤
<input type="checkbox" name="like[]" value="blue">青
<input type="checkbox" name="like[]" value="green">緑

この場合は、params["like"]にチェックした値が配列で入っています。
赤と青がチェックされていれば
params['like']
で['red','blue']が取れます。


ケース３
他にnameが同じになっているケースがあります。
以下のような感じです。

好きな色は？
<input type="checkbox" name="like" value="red">赤
<input type="checkbox" name="like" value="blue">青
<input type="checkbox" name="like" value="green">緑

この場合は、仮に複数の値がチェックされていてもparams["like"]で取れるのは、どれか一つだけです。
なので上記二つの書き方に変えるのがよいとは思うのですが、この場合でsinatraで受け取る方法です。

以下のような感じで受け取れます。
以下ではとりあえず複数受け取った値を,で連結しています。

  data = {}
  env["rack.request.form_vars"].split("&").each do |d|
    (k,v) = d.split("=")
    k = URI.decode(k).toutf8
    v = URI.decode(v).toutf8 unless v.nil?
    if data[k].nil?
      data[k] = v
    else
      data[k] = data[k] + ", " + v
    end
  end

これで赤と青がチェックされていた場合は、
data['like']
で"red,blue"が受け取れます。

railsでhas_manyで関連したモデルのデータを一気に消すとき

railsでhas_manyで関連しているモデルで親モデルのデータを消したら関連するモデルのデータも連動して消したいときのお話です。

そんなときは、
:dependent
を指定してあげればよいわけですが、
:dependentに指定できるものに
:destroy
と
:delete_all
があります。違いはひとつひとつ消していくか、一気に消すかの違いです。 詳しくは、
http://rubyist.g.hatena.ne.jp/rochefort/20091126
が参考になります。

関連が1段階ならば、:delete_allの方がよさげな感じなのですが、
関連が2段階以上まであって、最後まで連動させてdeleteしたいときは、delete_allではだめです。
少なくとも子はひとつひとつ処理をする:destroyにしないと孫まで消えないです。

以下みたいな感じにしておけば、
fooを一つ消せば、これに関係するbar、barに関連するbooのデータが消えるようになります。

class Foo < ActiveRecord::Base
  has_many :bars, :dependent => :destroy
end

class Bar < ActiveRecord::Base
  has_many :boos, :dependent => :delete_all
end

class Boo < ActiveRecord::Base
end

WBS「トレたま」で放送された商品をAmazonで検索してみた(201204放送分)

WBSのコーナーの「トレたま」で放送された商品をAmazonで検索してみました。
今回は一つしか見つかりませんでした・・・

鶏のケンカ防止に (放送：4月30日)
見つかりませんでした

３工場まとめたシステム (放送：4月27日)
見つかりませんでした

燃えにくい段ボール (放送：4月26日)
見つかりませんでした

オートネイル (放送：4月25日)
見つかりませんでした

首ふり洗浄機 (放送：4月24日)
見つかりませんでした

人混みでも撮影ＯＫ (放送：4月23日)
見つかりませんでした

100％再生ペットボトル (放送：4月19日)
見つかりませんでした

車を守るバッグ (放送：4月18日)
見つかりませんでした

魚グリルで石釜風ピザ (放送：4月17日)
見つかりませんでした

進化する教科書ガイド (放送：4月16日)
amazonにありました


つまみテープカッター (放送：4月13日)
見つかりませんでした

名刺サイズＰＣ (放送：4月12日)
見つかりませんでした

奥の奥まで… (放送：4月11日)
見つかりませんでした

光で操る (放送：4月10日)
見つかりませんでした

触れたら警報 (放送：4月9日)
見つかりませんでした

つり革も気分よく♪／腕財布 (放送：4月6日)
見つかりませんでした

“指”ジェスチャーカメラ (放送：4月5日)
見つかりませんでした

電池不要のリモコン (放送：4月4日)
見つかりませんでした

書き込みプロジェクター (放送：4月3日)
見つかりませんでした

高性能パンクレスタイヤ (放送：4月2日)
見つかりませんでした

任天堂のキーボードをAndroidにつないで、「j」を押したら「に」が出てきた

AndroidやiPhoneとも接続できてしまって、おまけに使いやすいと評判の
バトル＆ゲット　ポケモンタイピングDS
についているキーボードが1600円ちょいで買えるようになっていたので思わず買ってみました。

接続は簡単でBluetoothを有効にしてキーボードの「Fn」キーを押しながらキーボードの電源を入れれば認識されてパスコードを入力すれば使えるようになります。

あっさり使えるようになったので、さぁ使ってみようと
キーボードの「j」を押したら、「に」と入力されてしまいました。

どうやらGoogle日本語入力を「ケータイ配列」で使っているのがいけないみたいで、「QWERTY」にすれば、ちゃんと入力されました。

GaraxyS2を使っているので、Samsung日本語キーボードに切り替えることでも使えるようになりました。

とりあえず使うときは設定を変えればよいということが、わかったのでそのようにしようと思うのですが、つなげたら何もせずに利用できるようにできたらよいなぁとか思ったりします。

ちなみに初代iPadでもきちんと利用できました。

railsで利用しているmysqlテーブルでパーティショニングを試してみた

あるrailsアプリで利用しているmysqlテーブルでパーティショニングを試してみました。

パーティショニングとは、テーブルのデータ格納領域を分割することで大量データを保持するテーブルのパフォーマンスを改善する手段の一つです。

以下が参考になります。
http://www.s-quad.com/wordpress/?p=62

パーティショニングをするには、分割に利用するカラムを決定する必要があります。
利用状況に応じた適切なカラムを選択しないと帰ってパフォーマンスが落ちることがあります。

今回、試したmysqlのバージョンは5.1で
以下のような毎月一括でデータを登録するようなテーブルです。

テーブル名：hoges
カラム：
id：int(PK)AUTO INCREMENT
nengetu：varchar
その他カラム多数

このテーブルには、毎月一度一括で大量のデータを登録し、検索する際にもnengetuが多くのケースで利用されています。
なのでnengetuで分割することを目指します。

調べてみたところ以下のことがわかりました。
・分割に利用するカラムは、プライマリキーの一部である必要がある
今回のhogesはrailsで普通に利用しているテーブルなのでプライマリーキーはidだけで構成されています。
なのでnengetuもプライマリーキーに含めて、idとnengetuの二つのカラムで構成されるプライマリキーにします。
ユニークインデックスの一部になっていれば、よいかとも思ったのですが、プライマリーキーの一部でないとダメでした。

・文字列カラムで利用できる分割はKEYパーティショニングのみ
パーティショニングの方法にはRANGE,LIST,HASH,KEYとあるのですが、文字列カラムで分割できるのはKEYパーティショニングだけのようです。
mysql 5.5だとRANGEでも文字列カラムを利用できるっぽいです。
なので今回はKEYパーティショニングを利用します。
分割数は、毎月分割して10年分も格納できれば文句もなかろうという安易な考えから128とします。


以上のことから以下のようなmigrationを用意しました。

class AddPartitionToHoge < ActiveRecord::Migration
  def self.up
    execute("ALTER TABLE hoges DROP PRIMARY KEY, ADD PRIMARY KEY (id, nengetu);")
    execute("alter table hoges PARTITION BY LINEAR KEY (nengetu) PARTITIONS 128;")
  end

  def self.down
    execute("ALTER TABLE hoges REMOVE PARTITIONING;")
    execute("ALTER TABLE hoges DROP PRIMARY KEY, ADD PRIMARY KEY (id);")
  end
end

以下を参考にさせていただきました。
http://d.hatena.ne.jp/d2mr/20080522/1211447409

今回利用しているLINEAR KEYに関しては、以下が参考になります。
http://nippondanji.blogspot.jp/2009/05/linear-hash.html


これでアプリには変更なしで動きました。

ただテストの方に問題が出てしまいました。
test用dbのhogesの主キーがうまく設定されずにidがAUTO INCREMENTされなくなり
このため多くのテストが失敗するようになってしまいました。

確かに
db/schema.rb
を見るとidの設定がおかしな感じになっていました。
どうも複合プライマリキーが設定されているテーブルだとこんなことになるようです。

これを改善するには、

config/environment.rb
に
config.active_record.schema_format = :sql
と記載してテスト用db作成に
db/schema.rb
を利用しないようにすればOKな感じです。

参考までに35万行程度のテーブルでのパフォーマンスの変化です。
時間はrailsのログから判別したのと、それぞれ一回しか試していないので本当に参考までです。

nengetu単月での検索(7万件ぐらい)
　前：Completed in 277404ms (View: 34, DB: 142744)
　後：Completed in 154913ms (View: 29, DB: 27970)
nengetu複数月での検索（20万件ぐらい）
　前：Completed in 353752ms (View: 67, DB: 21555)
　後：Completed in 411954ms (View: 139, DB: 66896)
単月のデータ一括登録（3万件ぐらい）
　前：Completed in 2016712ms (DB: 205944)
　後：Completed in 2131911ms (DB: 161670)

単月の検索はかなり早くなった感じです。
他は、それほどでもないのですがもっとデータがあれば違う結果になりそうな気がしています。