2011-12-19
セイコガニのゆで方
cooking | |
初めて技術とはまったく関係の無いネタの気がする。
先週の休日にせり人となった中学からの友人にせいこがにのゆで方を教えてもらったのでメモ。
セイコガニとは?
まずセイコガニって何って人が多いと思うので前置き。
ズワイガニは足の身がメインだけどセイコは卵や中のカニ味噌がメイン。
私の地元である福井ではセイコ、石川では香箱ガニと呼ばれている(他にもローカルな読み方があると思うけど知ってるのはこの2つ
福井、石川は時期になるとスーパーで売ってるのを見たことがあるけど、他は多分ネットでの販売とかにないと売ってないと思う。
福井ではゆでた状態で売ってるのが一般的。
ゆでる準備
すいません、写真ありません。
- 大きめの鍋にカニが十分浸かる程度の3-4%の食塩水作り沸騰させる
カニの方
すいません、写真あr(ry
- 10分程真水につけて動かないのを確認する。
- ここで生きている状態だとゆでる時に暴れて自分の足をちぎるという恐ろしい事をするらしい
- まずはカニの殻についた泥をたわしで軽くこすって落とす。
- 卵(外子)の部分は流れない程度の弱めの流水で洗う
- この時流水で卵がふわっとするようにすると茹で上がったときの見た目と食べる時の食感がよくなるらしい
ゆでる
- 20-25分程度ゆでる
- 念の為動けないぐらいの重さの落し蓋をする(足を引きちぎらないようにする為
- 茹でる時間は殻の厚さが厚いほど長く茹でるらしいがぶっちゃけ分からん
- 目安としては泥が大量に付いていると砂地に生息していた物なので殻が薄いらしいが大量ってどれくらいよ...
- 迷ったら長めにゆでとけとのこと
食す
熱いうちに召し上がれ
2011-10-18
Pythonのリストにおける処理パフォーマンス
Python | |
そういえばこういう書き方もできるけど見づらいのでmap使ったほうがいいよねぇ [(lambda x: x if x > 0 else 0)(x) for x in [5, -2, 1, 8, -13
とつぶやいていた。
個人的にはmap()関数の方が読みやすいという意見には賛成。
しかしパフォーマンスについては議論されていなかったようなので検証してみた。
とりあえずtimeit
今回はとりあえず上記にあったように整数の最小値から整数の最大値までの整数を乱数で10000個生成し、負数であったら0にして新しいリストを生成するという至って簡単な非破壊の仕様にしました。
ということで今回のパフォーマンス計測に使ったコード。
# coding:utf-8 import random import sys from timeit import Timer from itertools import imap data = [random.randint(-sys.maxint - 1, sys.maxint) for x in xrange(0, 10000)] def for_filter(): return [x if x > 0 else 0 for x in data] def map_filter(): return map(lambda x: x if x > 0 else 0, data) def imap_filter(): return [x for x in imap(lambda x: x if x > 0 else 0, data)] print Timer('for_filter()', 'from %s import data, for_filter' % __name__).timeit(10000) print Timer('map_filter()', 'from %s import data, map_filter, minus_to_zero' % __name__).timeit(10000) print Timer('imap_filter()', 'from %s import data, imap_filter, minus_to_zero' % __name__).timeit(10000)
Python:2.7.2(MacPortsでインストールしたもの)
CPU:Core i7 2.0GHz(MBP15 early2011下位モデル)
Memory: 8GB
実行結果は
10.2765209675 17.9944810867 23.7831270695
となり、早い順にリスト内包表記, map, imapとなりました。
最初はmap()の方が早いんじゃないかと思ってたけどmap()はそんなに早くなく、
むしろリスト内包表記の方が1.8倍の速度出てます。
リスト内包表記が早い理由については、@methaneさんが解説されている記事に詳しく載っています。
結論
個人的にはmap()関数の方が可読性は高いと思います。
その一方でリスト内包表記はやっぱりよいパフォーマンスでとりあえずこっち使っとけばそれなりのパフォーマンスが出ます。
以上の点を踏まえてケースバイケースで対応する方が良さそうです。
2011/10/19追記
@kk6さんからいただいたコメントにあるコードに合わせてみたところ結果が変わったので追記。
コードは少し端折ってます。
def for_filter(): return [x if x > 0 else 0 for x in data] def map_filter(): return map(lambda x: x if x > 0 else 0, data) def imap_filter(): return list(imap(lambda x: x if x > 0 else 0, data)) print Timer('for_filter()', 'from %s import data, for_filter' % __name__).timeit(10000) print Timer('map_filter()', 'from %s import data, map_filter' % __name__).timeit(10000) print Timer('imap_filter()', 'from %s import data, imap_filter' % __name__).timeit(10000)
そして結果は
10.1584570408 17.7165570259 16.8313369751
となり、リスト内包表記 > imap() > map()という順になりました。
早くなってる理由はリストの要素数が分かってるから最初からその要素数に合わせて領域を拡張しなくてもいいようにしてるとかそんな理由でしょうか?
2011-09-26
kyoto.pyハンズオン参加してきた
なんか関西圏のPython関連の勉強会にいろいろ出てたらチューターの指名を頂いたので、Pythonにおけるテスト駆動開発について話してきました。
今回のハンズオンでは他に
がありました。正直チューターやらずにPyramidのハンズオン参加したかった。
TDDとPythonのテストモジュール(doctest, unittest)どっち重点的にやるかっていうのは最後まで悩んだんですが、
Pythonのテストモジュールが重点的になってしまって、TDDの内容もgdgdになってしまいどっちかにすべきだったかなあと反省しています。
私としてはdoctestとunittestをどう連携させてうまく使うかというのを説明したったのですが、上手く伝わったかどうかは非常に不安。
ここで使った資料については後日公開します。
あとLTやりましたがあまりにも突発なため資料とかが用意できず。
内容はRubyのテスティングフレームワークの充実っぷりは以前から嫉妬するほど羨ましかったので、探したらletuceというcucumberライクなBDDフレームワークがあって日本語が使えるようにしましたよと宣伝してきました。
他の参加者のレポート
kyoto.py Pythonハンズオン開催しました - 何気に大変
追記:資料公開
資料以下に公開しました。
忘れていて遅れました。すみません。
lnial
Please資料
aroma_black
公開しました
2011-07-30
Bazaarの部第1回反省会会場
ということで書きました。
rstで書いてたら面倒になったのでSphinxで公開しようって事になって、それならデプロイが簡単なbitbucketでという事で出来たのがこちら。
http://aroma_black.bitbucket.org/bzr-memo/build/html/bzr-hanseikai01.html
BazaarならLaunchpadでやれよってツッコミはなしの方向でお願いします。
今回は5分で分かるチュートリアルをベースに知っておくと便利そうな方法を追加して書いて行きました。
しかし、5分で分かるチュートリアルはいろいろ省略されすぎな気がします。
なので第2回もする予定。
2011-07-25
分散型バージョン管理システム勉強会@京都参加してきた
@naoina さんが主催された分散型バージョン管理システム勉強会に参加してきました。
gitはこれからforkしてゴニョゴニョするのに最低限の知識は必要になるだろうし、Mercurialはイマイチ覚えきれてないし、ハンズオン形式ということで参加。
git
gitは@__papix__さんが講師を担当されて基本的なところをまどマギのネタが盛り込まれたスライドで説明。
6月に行われたPython京都勉強会でアニメネタは受けなかったにもかかわらずあえてそれで突っ込んだ勇気は素晴らしいと思いました。
gitはlettuce(BDDフレームワーク、Python版Cucumber)で機能拡張を行った時にすこし覚えたもののまだまだ不慣れだなとわかりました。
Bazaar
gitが早く終わったので急遽講師をやりますって返事してしまったんですが、Bazaar全然理解してなかったということが露呈してしまいました。
正直酷すぎたと思うので当日言うべきだった事をこのブログにでも書いていこうかと思います。
とりあえず新規でVCS使う場合はBazaar縛りにしよう。
Mercurial
講師は@naoinaさん。基本的な事はほぼ網羅されていたかと思います。
Webで勉強会用に公開しているから実際にcloneして操作してみたりと実際の運用っぽい感じが出ていて完成度が高かった。
あと便利な拡張機能の紹介で知らなかった拡張としてrecordがありました。
これは部分的にコミットするツールのようで(cherry pickのコミットバージョンのような感じ)使いようによっては結構強力なツールになりそうだと思いました。
LT
LTは@ramusaraさんと@_likrさん@naoinaさんの3名。
@ramusaraさんはgitのコミットフックを使ってJenkinsを動かすデモをされていました。コミットフックを使って何かするというのはいろいろ使われてるので今後参考にしたいです。
@_likrさんはMercurialのコミットフックの紹介。Mercurialは内部・外部フックとわかれていて内部フックはPythonで拡張できるという話が興味深かったです。
@naoinaさんは勉強会前日にTwitterのTLで盛り上がった「女性が参加しやすいIT勉強会」をテーマにされていて、「参加しやすい勉強会がないなら自分で主催すればいいじゃない」的なノリがすごく面白かったです。
その他気づいた事
当日のUstで名古屋のgitの貴公子@bleisさんが見ていたらしく、ところどころTwitter経由で補足しておられました。
Mercurialはこうしているけどgitではこうしている、と対比しながらの補足で自分がMercurial使いだった事もあり大変参考になりました。
補足ありがとうございました。
Bazaarの部反省会会場
ということで今週中にまず補足の1回目を書きますです。

それと、imap_filter関数に関しては
list(imap(lambda x: x if x > 0 else 0, data))
とするとちょっとだけ速くなりました。それでもmap関数よりも遅いですが。
私の環境だとmap()関数より早くなりだいぶマシになりました。
以下の最適化のところでも少し触れています。
http://gihyo.jp/news/report/01/europython2011/0002
組み込み関数となると使える場面は限られてしまいますが、リスト内包表記との使い分けの基準は明確に分けれそうですね。