減量します
ちょっと最近太り過ぎています。あまりにもやばいので減量をしたいと思います。有言実行にするためにブログで宣言しておきます。
手法についてはにぽたん氏の記事に大きく影響を受けています。
現在値＆目標値
体重71.55kg/体脂肪率26.3%
↓
体重57.00kg/体脂肪率15%
目標体脂肪率はてきとーなので計測はしますがとりあえずこれをターゲットにした施策はしません。
目標体重57kgは高校生の頃の体重で、当時と身長は変わっていない(170cm)ので健康に減量できるであろう目安として採用しました。僕はモテたいとかオシャレな服を着たいとかで減量するわけではなく、あくまで健康のためなので不健康な痩身は本末転倒です。14.55kg減となるので、結構アグレッシブな目標値ですが、にぽたん氏の記事に感銘を受けたので大胆な目標値を採用しました。
方針
- 不健康な手法は採用しません
- 明確に非科学的な手法は採用しません
不健康な手法とは、絶食とか、極端に偏った食事のみを摂るようなものです。明確に非科学的な方法を採用しないとは、例えば「ゲルマニウム」のようなワードが含まれているような、概ね疑似科学とか単なるバズ、デマみたいなものは採用しないということです。ようはテレビで紹介されていた◯◯のような手法は一切採用しません。
施策
- 酒を飲まない
- 毎日体重と体脂肪を記録する
- 食事制限はしない
- 会社への行き帰りは歩く/その他なるべく運動する
- 水を1日2リットル飲む
酒を飲まないのは、おそらく酒ののみすぎが太り過ぎの主原因であると考えられるタメです。しばらく断酒します>各位
体重と体脂肪率は毎日計測します。これは「計測するだけダイエット」というやつです。つまりはPDCAサイクルを短くするということで、高カロリーな食事を控えたり運動したり歩いたりするモチベーションになります。1日100gの減量を目標にしていきます。
極端な絶食や拒食はもちろん、食事制限は基本的にはしません。ただし、計測するだけダイエットの範囲内で、栄養バランスがよく熱量(カロリー)の少ない食事を食べたいと思う限りにおいて、バランスのとれた食事をとります。したがって極端に高カロリーであったり、極端にバランスの偏った食事(マクド◯ルドとか？)はとらないことになるでしょう。もともと間食もしないですし、甘いものも好きではない上に週の1/3くらいは自炊しているので結構楽です。
結局減量というのは、摂取-消費を赤字にするしかないので運動します。昨日計測してみましたが、私の環境では会社まで歩くことにすると概ね1日7000歩くらい歩くことになります。これは継続して、＋αなにがしかの運動をします。走るとか。
水は、非常にオカルトちっくなのですが、にぽたん氏の記事で紹介されていたのと、テレプシコーラという漫画で小太りな登場人物が体質改善手法としてやっていたなあというのを思い出したので試してみます。科学的根拠があるかよく分からないのですが、水の場合、ダイエットグッズを売りたい業者によるバズということはなさそうなので試しに程度にやってみます。
#kindlejp AmazonがKindleを無料で配る理由 またはiPad vs Kindleという構図が誤っているのはなぜか。
ミクロ経済学的な分析で、「何が起きるのか」を予想するのはそれほど難しくはない。難しいのは「それはいつ起きるのか？」だ。
勝ち負けは存在するけどデバイスとしての良し悪しとかそういうレベルじゃない。
Amazonはコンテンツが売れりゃあいいんだから、本当は端末はなんでもいいし、Kindleなんか無料で配りたいんだよ。
Appleはデバイスが売れりゃあいいんだから、本当はコンテンツはなんでもいいし、音楽やアプリや本なんて無料で配りたいんだよ。
いずれAmazonはKindleを無料で配るだろうと予想していたが、これほど早いとは思わなかった。Amazon.comのプライム会員向けにKindleを無料で提供することにしたらしい。
こうなるのだと予想することは難しくはない。電子書籍リーダーと電子書籍コンテンツはお互いに非常にわかりやすい補完財だからだ。補完財について知りたい人はジョエルスポルスキーからの手紙でも読むといい。もっと詳しく知りたい人はミクロ経済学の良質な教科書
Amazonは電子書籍コンテンツの流通を牛耳ることで利益を得たいのだ。そのためには電子書籍リーダーは安ければ安い方ほどいい。またコンテンツとプラットフォームは鶏と卵の関係で、十分たくさんのユーザがいなければコンテンツホルダはそこにコンテンツを流通させたいなどとは思うはずはなく、十分たくさんのコンテンツがなければユーザはそのプラットフォームを選択したいと思うはずはない。だから、Amazonが出版社とハードな交渉をする一方で、究極的にはエントリモデルのKindleを無料で配りたくなるのは必然なのだ。
そして一方でAmazonは電子書籍リーダー市場を独占する必要はない。それがAmazonフォーマットの書籍を読める限りにおいて、消費者が多様な電子書籍リーダーを選択できることはAmazonにとって望ましいのだ。KindleのEインクのディスプレイは書籍を読むには非常によいものなのだが、それを貧相だと感じるヤッピーがいるのも事実で、そういう人たちがiPadのようなハイエンドの端末を選択できることはベゾズにとって望むところに違いない。
逆にiPadを売りたいジョブズとしては究極的には出版社が窒息しない程度にコンテンツが安い方がいい。しかしAmazonへの牽制球として、iBooksストアでは出版社が価格を決めていいことにしてしまった。本来はコンテンツをコモディティにしてしまいたかったはずが、価格決定権を手放してしまったのだ。一方でベゾズの方はというとKindleを無料にしてしまった。ここからジョブズがどういう手にでるのか。これは難しい。
おそらくベゾズが最も嫌がる戦術は、iPadからKindleを締め出すこと、つまりKindle for iPhoneやKindle for iPadをAppストアから追い出すことだが、それは一方でiPadの魅力を削ぐ結果になる。Appleにとってはコンテンツで儲ける必要はないので、iPad上で読めるコンテンツの選択肢が豊富な方が良いのだ。他にありそうなのは、電子書籍リーダーという文脈をone of themにしてしまうことだ。ジョブズ：「Kindleだって？本を読むだけの端末だろ？それよりこの新型iPadを見てくれ！信じられないくらい画期的だ！音楽も、Webも、動画を見るのにも最高の端末だ。もちろんAmazonの本を読むのにもKindleよりもずっと素晴らしい。だがそもそも人々は本など読まないだろう？」とか。
もうわかったと思うが、ガジェットとしてのiPad vs Kindleなどという戦いは存在しないのだ。Apple vs Amazonという戦いは存在する。それは、端末とコンテンツが、互いに互いをコモディティにしようという戦いだ。どちらが勝つのか？現時点では僕には分からない。
Kindle DXで漫画を読むとどうなるか？ 実験してみた #kindlejp
昨日の記事でKindleの容量制限について触れた。うめ先生に、作品のSSや動作画像をブログに載せてよいかTwitterで聞いていたのだが、以下の通り快諾いただいたので、比較画像を載せてみる。
@ume_nanminchamp うめ先生、Kindle DXで漫画を表示するとどうなるか？的なブログ記事を書こうと思っています。青空ファインダーロックのKindleストア版と高解像度な画像版のSSおよび動作しているKindleを撮影した画像を私のブログにのせていいでしょうか？
@ajiyoshi 基本OKです。似るなり焼くなり。ただウチのデータはグレースケールなので、手持ちの単行本をscansnapする場合は、元データがモノクロ網点化されてるのでやや印象が違うかも。
元データは、Kindleストアで売っているもののスクリーンショットと、うめ先生がkindle・iPad比較で掲載されていた画像ファイルの、Kindle DX版(63.4kB)とiPad版(403.96kB)をKindleに保存して表示させたものである。全体像およびコマのアップの撮影はiPhone3GSのカメラで行った。スクリーンショットはKindle標準機能(Alt+Shift+g)である。
なお、Amazonが入稿データからKindle形式への変換を行っているらしい。たぶんここで画像が劣化していると思われる。Kindleストア版の青空ファインダーロックは26p 1.4Mである。1pあたり平均で53kBほどになるが、63.4kBのものより圧倒的に品質が劣る。それどころかKindle2用の34kBよりも見づらい。どんな無駄なことをしているのだろうか。何をしているか、詳しい仕様を公開して欲しいと思う。
以下、画像。クリックで原寸表示。(©うめ)
| Kindleストア | DX版 | iPad版 | |
|---|---|---|---|
| 全体 |  |
 |
 |
| コマ |  |
 |
 |
SS |  |
 |
 |
まず全体像だが、iPhoneのカメラの解像度の都合であんまり違いがわからないかもしれない。Kindle DX版の周りの余白が見てほしい。Kindleストア版は、一度縮小したものを引き伸ばしているように見える。細かい字や書き込みが潰れ気味である。
潰れ具合は全体像ではわからないかもしれないので、左上のコマの拡大画像で確認してみよう。「編集」の文字の潰れ具合や絵のディティールの潰れ具合を見て欲しい。実機で見ると、ストア版はかなり字が読みづらい。64kBに抑えていて、しかも余白が大きい(i.e. 表示される実サイズが小さい)DX版でも十分な解像度があり、しっかり漢字を識別できる。
最後にSS。意外にも？グラデーションはKindleストア版がなめらかに見える。潰れてるだけともいえるかも。DX版、iPad版はシャープに見える。
Kindle DXが届いた。 #kindlejp
雑感などを書いてみる。
個人的な用途
僕としての使い方は、
- SnapScanで自炊スキャンした漫画用のビューア
- 未翻訳、糞翻訳な技術本を原著で読む
- 技術本が今すぐほしい時にとりあえず買う
まだしばらく、Kindleストアは日本向けにサービスを開始しないと思われる。僕は英語の小説を読む趣味はない(そもそも日本語でも小説は読まない)ので、主にKindleで読むのは技術系の本と新聞、それに自炊物の漫画である。
ハードウェアについて
- 薄い
- 片手で持つと意外と重い(525g)
- 反応速度は予想通りややもっさり
- でも一度表示されてしまえば綺麗で読みやすい
まわりの人に自慢して回った数名の反応を見ると、かなりの割合が画面にタッチしようとした。そういうアフォーダンスがあるのかもしれない。でも僕は本を読むだけの目的であれば、タッチパネルである必要はないように思う。BB2Cという、iPhone向けの2chブラウザがあって、これの売りのひとつは自動スクロール機能である。これをつかってみてはじめて気づいたが、僕は本当はあんまり画面をタッチしたくない。iPhoneみたいな小さい画面で縦に長いものを読んでると四六時中スクロールしまくるわけだけど、手が邪魔で画面に死角ができるし画面が汚れて見づらくなるし、いいことはない。UIは直感的なんだけどね。
Kindle DXの重さは週刊少年ジャンプと同じくらいである。両手で持つ分には特に重さは感じないが、片手で持つとすこしずしっとくる。長時間電車内で片手で持ち続けるのは無理ではないが嫌かもしれない。座って読むなら快適だと思う。iPad(680g〜730g)などは、これの1.3倍から1.4倍くらい重いので多分座ってないと長時間使用するのは無理だと思う。しかもiPadはタッチパネルなので、ページをめくるたびに、あるいはiPad上で何かしようとする度に片手で持つことになる。たぶんiPadは通勤電車などで使用するものではなく、リビングで使うものなんだと思う。
漫画ビューアとして使えるか？
自炊(持ってる漫画や本を自分でスキャンすること)したものであればかなり鑑賞に足る。
ただし、Amazon.comの連中は漫画とか縦書き文章なんてものが存在することすら知らないのかもしれないため、いくらかの不満がある。
横置きしたときに見開きにならない
向きを自動検知して、向きに応じて縦置き/横置きのモードを切り替える(固定もできる)機能があるのだが、横置きにしたときに横幅にあわせやがるので、漫画や縦書き文章では横置きは全く使い物にならない。これを体感してみたければ、PDFやワードなどで横幅にあわせて表示してみるとよい。下へ行って上へ戻って行って戻ってを繰り返さなければならない。英語などの横書き言語では横幅に合わせれば上から下へ読めるのだが、日本語ではそのUIは駄目だ。
これはソフトウェア的に解決できる問題ではある。漫画や日本語のために、横置き時は見開き表示するモードを作ればよい。ただ、Amazon.co.jpの連中はこういうかゆいところに手が届くローカライズをしやがらないのでいまいち期待できない(例：Amazon.co.jpでゴルゴ13を全巻買おうとしてみよう！)。SDKで自分で作れということだろうか。(まあこれはAppleにも期待できないのだが。断言してもいいがiPadに見開きモードなど用意されない。)
ページあたりの容量制限
自分で確認したわけではないが、Kindleストアの本には1ページあたりの容量制限があるようだ。
現状Kindleストアで購入できるおそらく唯一の日本語漫画である青空ファインダーロックを買って読んでみたが、圧縮されていて細かい漢字が読めない。これはKindle側の解像度の問題ではない。kindle・iPad比較 - 難民チャンプにて公開されているiPad用の高画質の画像をKindleに取り込んでみたが、こちらなら素晴らしくちゃんと読める。なお、SSと動いているKindleをiPhoneのカメラで撮影した比較画像がある。Kindle DXの視認性に関する研究のために引用する必然性があるので、無断引用してもおそらく問題ないと思うのだけど、一応作者のうめ先生に公開してよいか聞いてみた。逆に面と向かって確認されるとOKとはいいづらかったりするのかもしれないけど。OKってことだったら後で比較を公開する。
こういう制限が存在するのも、Amazon.comの連中は漫画なんてものがあることをしらなくて、基本的に本なんてテキストベースだからそんなに容量いらねえだろ？ってことだと思う。したがってこれは、制限が撤廃されれば解決する問題ではあるのだが、一方でKindleはストレージ容量がそれほど大きくない。あんまりにでかい漫画をやたらと保存するとあっという間にいっぱいになる。将来に期待である。
Kindleは買いか？
すごくエキサイティングな製品ではある。これだけ未来を感じさせるガジェットを手にするのは久々だ。現状、Amazon.co.jpは早ければ注文してから半日とかで本を送ってくるが、Kindleならば注文してから読めるようになるまで1分である。圧倒的だ。
しかし何に使うかによるが、現状では英語が苦にならない人とか英語で本を読みたい人、自炊できる人にしかおすすめできないのではないかな。Kindleストア日本版が来てからでも遅くはない気がする。
Class::DBIでCoro::Mysqlを使う
最近ちょっとCoroを触っていて、Class::DBIでCoro::Mysql使いたいなと思った。
■The architecture of Coro::MySQL によると Class::DBI とかそのまま使えるとあるけど、どうやるとそのまま使えるかわからなかったのでいろいろ調べたりCoro::Mysqlのソース読んだりした。
結局どうやるとそのままCDBI使えるかわからなかった。単に Class::DBI->db_Main が返してくるDBハンドルを Coro::Mysql::unblock してやるだけではうまく動かない。手元の環境ではinsertとかはできるけどなんでか検索系が変な動きをした。あと、この手法でやる場合、Class::DBIではクラス変数としてdbhを持ってるので、結局プロセス内で1スレッドしかDBアクセスできないことになり、ちょっと僕のやりたい事とずれる。僕はスレッドごとに非同期にDBに読み書きできるようにしたい。1接続だけってのはちょっと非同期実行のうまみが少なくて切ない。接続数の上限はなにがしか管理するにせよ。
要件としては
- Coroスレッドごとに必要に応じてdbhを持ちたい
- 既存のソースを使いたいので、Class::DBIは使いたい
そんで、Class::DBIに複数接続を持たせるにはどうしたらいいか調べたら
Class::DBIで複数データベースを扱う+register_cleanup
Class::DBI::Plugin::MultiDatabases
というのが見つかった。
そしてClass::DBIのWikiの"Using multiple databases"によれば、db_Mainを上書きしてやるとよいみたいだ。ただし db_Main を上書きした場合、dbi_commit と dbi_rollback がちゃんと動かなくなるので、適切なdbhからcommit/rollbackするようにしてやらないといけないらしい。
というわけでそういうのを書いてみた。
package Class::DBI::Coro::Mysql; use strict; use warnings; use base 'Class::DBI::mysql'; use DBI; use Coro; use Coro::Mysql; use Data::Dumper; __PACKAGE__->mk_classdata('_coro_dsn_info'); __PACKAGE__->mk_classdata('_coro_dbh_hash'); sub connection { my ($class, $dsn, $user, $pass, $attr) = @_; $class->_coro_dsn_info([$dsn, $user, $pass, $attr]); $class->_coro_dbh_hash({}); } sub db_Main { my $class = shift; my $me = $Coro::current; if( my $dbh = $class->_coro_dbh_hash->{$me} ){ return $dbh if $dbh->FETCH('Active'); $dbh->disconnect; } my $dbh = Coro::Mysql::unblock(DBI->connect(@{ $class->_coro_dsn_info })); $me->on_destroy(sub { if( exists $class->_coro_dbh_hash->{$me} ){ $class->_coro_dbh_hash->{$me}->disconnect; delete $class->_coro_dbh_hash->{$me}; } }); $class->_coro_dbh_hash->{$me} = $dbh; } sub dbi_commit { my $class = shift; $class->db_Main->commit(@_); } sub dbi_rollback { my $class = shift; $class->db_Main->rollback(@_); } 1;
connection までも乗っとってしまうのはどうなんだろうとも思ったけど、結局 db_Main を乗っとるた時点で Ima::DBIが作った db_Main はアクセスされないんだから、普通の Class::DBI と同じように使えるし、connection も上書きしてしまった。
あと、なんかきちんと $dbh->disconnect を呼ばずに（Perlに回収されると？）セグメンテーションフォルトする。しょうがないので、Coro::on_destroy に disconnect を登録した。（id:malaさんが書いてた、なんかunpatchのところで死ぬ。perlのバージョンが古いからかも。
と同じ問題？）
使い方は普通の Class::DBI::mysql と同じである。
use strict; package TestDB; #普通の Class::DBI::mysql を継承するとブロックする #use base qw/Class::DBI::mysql/; use base qw/Class::DBI::Coro::Mysql/; package TestDB::Sandbox; use base qw/TestDB/; __PACKAGE__->table('sandbox'); __PACKAGE__->columns(All=>qw/id sand created_on updated_on/); __PACKAGE__->set_sql("sleep" => qq{ SELECT sleep(?) }); package Main; use Coro; use Data::Dumper; TestDB->connection( "dbi:mysql:ほげほげほげ", "ほげほげほげ", "ほげほげほげ", {AutoCommit=>0} ); async_pool { print "sleep\n"; TestDB::Sandbox->search_sleep(5); print "wake up\n"; $Coro::main->ready; }; async_pool { eval { print "insert\n"; my $s = TestDB::Sandbox->create({}); $s->set(sand=>"hogehoge"); $s->update; $s->dbi_commit; printf("inserted [%s]\n", $s->id); }; if($@){ warn $@; TestDB->dbi_rollback; } }; schedule; print "end\n";
非同期実行の場合は select sleep(5) でブロックせずに、
sleep
insert
inserted [\d+]
wake up
end
みたいになる。
Google go で遊んでみた
goで遊んでみたよ！
インストール
Installing Go
にあるとおりにすれば問題なくインストールできた。
環境変数を準備
GOROOT=$HOME/go
GOOS=linux
GOARCH=386
export GOARCH GOOS GOROOT
Mercurial（入ってなければ適宜インストールする）でソースをチェックアウト
$ hg clone -r release https://go.googlecode.com/hg/ $GOROOT
ビルド
$ cd $GOROOT/src
$ ./all.bash
試す
ざーっとドキュメントを見た感じ、C+GC+軽量プロセス的な言語。コンパイル＆リンクするとネイティブコードを吐き出す。
よーくドキュメントを見るとクロージャもあることが分かる。
package main import "fmt"; func map_array(f func(int) int, array []int) []int { num := len(array); ret := make([]int, num); for i := 0; i<num; i++ { ret[i] = f(array[i]); } return ret; } func dump(i int) int{ fmt.Printf("[%d]\n", i); return i; } func main() { array := []int{1, 2, 3}; num := 1; map_array( dump, map_array( //インラインで関数オブジェクトを作り出せる。 func(x int) int { num++; return x * num; }, array )); dump(num); }
ただ、ジェネリクスとかはなく（interfaceを使って似たようなことはできる）、総称的なコンテナとかいわゆる関数型言語的なmap関数とかを作るのはちょっと面倒。実際、組み込みのcontainer/vectorパッケージにはIntVectorとかStringVectorとかそんなパッケージがあってがっかりする。
肝はたぶん軽量プロセスじゃないかと思う。そっちはまだ触ってない。
マクロを組んで作業するのは実力ではないですか？
私の職業は一般事務（派遣）ですが少しLispがわかるのでルーチン化できるものはマクロを組んでいます。そうすることによってPHPで1時間かかる作業が1分で終わることがあります。
なので職場では「仕事が早い、仕事ができる」と評価されることがありますが先日先輩に怒られました。
内容は
- マクロを使うのはずるい
- それは実力ではない
- 仕事が早いというのは同じ環境でどれだけ間違いがなく効率よく作業ができるかだ。
- マクロを組むのはズルとしているのを同じ
と。
確かに手作業で行なえば周りの人と同じくらいの速さなので周りと同じ環境であれば（マクロを組まなければ）仕事が早いとは言えないかもしれません。
しかし業務をどう効率よくして作業をするかを考え実践するのも仕事のうちだと思うのですが私の考えは間違ってますか？入力ミスもチェックするコードを書いたので、ミスはありません。
「マクロを組んだ方が仕事が早くなるがそれが仕事ができる人には繋がらない」のでしょうか？
職場にはマクロを組めるのは私しかいません。仕事が早く終わったからって遊んでるわけではないし時間が余ればさらに効率化できないかを考えたりしています。
元ネタ：http://okwave.jp/qa5419623.html
改変箇所全然ないなｗ
