Hatena::ブログ(Diary)

logging.info(self)

2011-12-19

セイコガニのゆで方

| 22:45 | セイコガニのゆで方を含むブックマーク

初めて技術とはまったく関係の無いネタの気がする。

先週の休日にせり人となった中学からの友人にせいこがにのゆで方を教えてもらったのでメモ。

セイコガニとは?

まずセイコガニって何って人が多いと思うので前置き。

セイコガニはズワイガニとか松葉ガニと呼ばれるカニのメス。

ズワイガニは足の身がメインだけどセイコは卵や中のカニ味噌がメイン。

私の地元である福井ではセイコ、石川では香箱ガニと呼ばれている(他にもローカルな読み方があると思うけど知ってるのはこの2つ

福井、石川は時期になるとスーパーで売ってるのを見たことがあるけど、他は多分ネットでの販売とかにないと売ってないと思う。

福井ではゆでた状態で売ってるのが一般的。


ゆでる準備

すいません、写真ありません。

  1. 大きめの鍋にカニが十分浸かる程度の3-4%の食塩水作り沸騰させる

カニの方

すいません、写真あr(ry

  1. 10分程真水につけて動かないのを確認する。
    • ここで生きている状態だとゆでる時に暴れて自分の足をちぎるという恐ろしい事をするらしい
  2. まずはカニの殻についた泥をたわしで軽くこすって落とす。
  3. 卵(外子)の部分は流れない程度の弱めの流水で洗う
    • この時流水で卵がふわっとするようにすると茹で上がったときの見た目と食べる時の食感がよくなるらしい

ゆでる

  1. 20-25分程度ゆでる
    • 念の為動けないぐらいの重さの落し蓋をする(足を引きちぎらないようにする為
    • 茹でる時間は殻の厚さが厚いほど長く茹でるらしいがぶっちゃけ分からん
    • 目安としては泥が大量に付いていると砂地に生息していた物なので殻が薄いらしいが大量ってどれくらいよ...
    • 迷ったら長めにゆでとけとのこと

食す

熱いうちに召し上がれ

2011-10-18

Pythonのリストにおける処理パフォーマンス

| 23:03 | Pythonのリストにおける処理パフォーマンス を含むブックマーク

twitterのTLをふと見たら@さんが

とつぶやいていた。

個人的には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とマシンのスペック


Python:2.7.2(MacPortsインストールしたもの)

OS:Mac OS X 10.7.2

CPU:Core i7 2.0GHz(MBP15 early2011下位モデル)

Memory: 8GB


実行結果は

10.2765209675
17.9944810867
23.7831270695

となり、早い順にリスト内包表記, map, imapとなりました。

最初はmap()の方が早いんじゃないかと思ってたけどmap()はそんなに早くなく、

むしろリスト内包表記の方が1.8倍の速度出てます。

リスト内包表記が早い理由については、@さんが解説されている記事に詳しく載っています。

DSAS開発者の部屋:Pythonの内包表記はなぜ速い?


結論

個人的にはmap()関数の方が可読性は高いと思います。

その一方でリスト内包表記はやっぱりよいパフォーマンスでとりあえずこっち使っとけばそれなりのパフォーマンスが出ます。

以上の点を踏まえてケースバイケースで対応する方が良さそうです。

2011/10/19追記

@さんからいただいたコメントにあるコードに合わせてみたところ結果が変わったので追記。

コードは少し端折ってます。

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()という順になりました。

早くなってる理由はリストの要素数が分かってるから最初からその要素数に合わせて領域を拡張しなくてもいいようにしてるとかそんな理由でしょうか?

kk6kk6 2011/10/19 02:23 思ったよりパフォーマンスに差がでるんですね。
それと、imap_filter関数に関しては

list(imap(lambda x: x if x > 0 else 0, data))

とするとちょっとだけ速くなりました。それでもmap関数よりも遅いですが。

aroma_blackaroma_black 2011/10/19 23:09 コメントいただいた内容を更新しました。
私の環境だとmap()関数より早くなりだいぶマシになりました。

t2y-1979t2y-1979 2011/11/03 19:52 ピュア Python の関数だと、リスト内包表記の方が速いようです。組み込み関数を使うと、map の方が速い結果が出るかもしれません。

以下の最適化のところでも少し触れています。
http://gihyo.jp/news/report/01/europython2011/0002

aroma_blackaroma_black 2011/11/05 13:43 EuroPythonの記事の該当コード実行してみたところ、確かに組み込み関数だとmapの方が早い結果になりました。
組み込み関数となると使える場面は限られてしまいますが、リスト内包表記との使い分けの基準は明確に分けれそうですね。

2011-09-26

kyoto.pyハンズオン参加してきた

| 23:54 | kyoto.pyハンズオン参加してきたを含むブックマーク

なんか関西圏Python関連の勉強会にいろいろ出てたらチューターの指名を頂いたので、Pythonにおけるテスト駆動開発について話してきました。

今回のハンズオンでは他に

がありました。正直チューターやらずにPyramidハンズオン参加したかった。


TDDPythonのテストモジュール(doctest, unittest)どっち重点的にやるかっていうのは最後まで悩んだんですが、

Pythonのテストモジュールが重点的になってしまって、TDDの内容もgdgdになってしまいどっちかにすべきだったかなあと反省しています。

私としてはdoctestとunittestをどう連携させてうまく使うかというのを説明したったのですが、上手く伝わったかどうかは非常に不安。

ここで使った資料については後日公開します。


あとLTやりましたがあまりにも突発なため資料とかが用意できず。

内容はRubyのテスティングフレームワークの充実っぷりは以前から嫉妬するほど羨ましかったので、探したらletuceというcucumberライクなBDDフレームワークがあって日本語が使えるようにしましたよと宣伝してきました。

他の参加者のレポート

kyoto.py Pythonハンズオン開催しました - 何気に大変

PyOpenCLハンズオン報告 - likr’s labo

追記:資料公開

資料以下に公開しました。

忘れていて遅れました。すみません。

http://aroma_black.bitbucket.org/kyotopy201109/

2011-07-30

Bazaarの部第1回反省会会場

| 22:45 | 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

分散型バージョン管理システム勉強会@京都参加してきた

| 23:48 | 分散型バージョン管理システム勉強会@京都参加してきたを含むブックマーク

@ さんが主催された分散型バージョン管理システム勉強会に参加してきました。

gitはこれからforkしてゴニョゴニョするのに最低限の知識は必要になるだろうし、Mercurialはイマイチ覚えきれてないし、ハンズオン形式ということで参加。

git

gitは@さんが講師を担当されて基本的なところをまどマギのネタが盛り込まれたスライドで説明。

6月に行われたPython京都勉強会でアニメネタは受けなかったにもかかわらずあえてそれで突っ込んだ勇気は素晴らしいと思いました。

gitはlettuce(BDDフレームワークPython版Cucumber)で機能拡張を行った時にすこし覚えたもののまだまだ不慣れだなとわかりました。

Bazaar

gitが早く終わったので急遽講師をやりますって返事してしまったんですが、Bazaar全然理解してなかったということが露呈してしまいました。

正直酷すぎたと思うので当日言うべきだった事をこのブログにでも書いていこうかと思います。

とりあえず新規でVCS使う場合はBazaar縛りにしよう。

Mercurial

講師は@さん。基本的な事はほぼ網羅されていたかと思います。

Webで勉強会用に公開しているから実際にcloneして操作してみたりと実際の運用っぽい感じが出ていて完成度が高かった。

あと便利な拡張機能の紹介で知らなかった拡張としてrecordがありました。

これは部分的にコミットするツールのようで(cherry pickのコミットバージョンのような感じ)使いようによっては結構強力なツールになりそうだと思いました。

LT

LTは@さんと@さん@さんの3名。

@さんはgitのコミットフックを使ってJenkinsを動かすデモをされていました。コミットフックを使って何かするというのはいろいろ使われてるので今後参考にしたいです。

@さんはMercurialのコミットフックの紹介。Mercurialは内部・外部フックとわかれていて内部フックはPythonで拡張できるという話が興味深かったです。

@さんは勉強会前日にTwitterのTLで盛り上がった「女性が参加しやすいIT勉強会」をテーマにされていて、「参加しやすい勉強会がないなら自分で主催すればいいじゃない」的なノリがすごく面白かったです。

その他気づいた事

当日のUst名古屋gitの貴公子@さんが見ていたらしく、ところどころTwitter経由で補足しておられました。

Mercurialはこうしているけどgitではこうしている、と対比しながらの補足で自分がMercurial使いだった事もあり大変参考になりました。

補足ありがとうございました。

Bazaarの部反省会会場

ということで今週中にまず補足の1回目を書きますです。