熊本へ支援物資届けた時に感じたことと、ボランティア心得的なまとめ

まさかまたはてなダイアリーを使う日が来ようとはね。。。
熊本へ支援物資届けた後、つらつらとツイートしたのをここにまとめます。

https://twitter.com/n_shinchan/status/721958724835745792
https://twitter.com/n_shinchan/status/721946075490201600
https://twitter.com/n_shinchan/status/721938807252094977
https://twitter.com/n_shinchan/status/721939422099283969
https://twitter.com/n_shinchan/status/721930828138225665
https://twitter.com/n_shinchan/status/721927139386208256
https://twitter.com/n_shinchan/status/721926108640256001
https://twitter.com/n_shinchan/status/721925093165694976
https://twitter.com/n_shinchan/status/721923504166162432
https://twitter.com/n_shinchan/status/721922060927131648
https://twitter.com/n_shinchan/status/721920639456555012
https://twitter.com/n_shinchan/status/721919708333625344

電子書籍が安くなると言う幻想は捨てろ!!!!

お久しぶり過ぎて涙が出ます。
近況としては、絵が描けない。絵師さん捕まらない。と言う事で電卓でも作ってみるか。と作って、タッチしか対応してなかったのをキーボードにも対応中にVSがOS巻き込んでフリーズ。ソース含め、データが吹っ飛び、ふて腐れてました。

まあ、それは置いておいて、最近、Yahooニュースに電子書籍の話題が上がりまして、あんまりにも安くしろ!100円にしろ!と言う声が多すぎて、ついついエキサイトしてしまいました。

さて、この記事を見る方はどうなんでしょうね。100円はともかく、少しは安くなると思っている方は多いのでは無いでしょうか?
最近は、ポイント付いたり、時々半額セールしてたりと、賢く買えば割と安くなってるハズなんですけどね・・・。

でも、それは出版社と喧嘩にならない範囲で、電子書籍ストアの企業努力の賜と言えるでしょう。

今日は、日本における電子書籍が、紙の書籍に比べて大きく値を下げる事は有り得ないと言う根拠を書いてみようと思います。

まず、当たり前の事ですが、出版社の主な収入源は紙の書籍の売上です。
では、電子書籍の方が売上が増えれば、電子書籍は安くなるのか?
いいえ、そんな事はありません。

電子書籍の方が、紙の書籍より10倍100倍1000倍の売上を上げようとも、出版社は紙の書籍を販売し続ます。(断言)
そもそも、電子書籍が紙の売り上げを超えないように調整するはずです。

その理由は、取次(だったかな?)の存在です。
ネットだか本だかで調べた限りでは、出版業界と言うのは、

出版社→取次→書店

と言う構造になっていて、取次のお陰で、全国に本を送る事が出来るらしいのですが、その際、出版社は取次から「前払い」で出版する本の代金を受け取るらしいのです。
そして、売れ残りが出ると、お金を返さなければならないのですが、お金が無い時には、さらに沢山の本を出版し、受け取った現金の中から、お金を返しているそうで、今の出版社は、それの繰り返しで本という名の借金が膨らんでしまっている状態なのだそうです。

もう、ここまで来ると、出版業界にとって、本は疑似通貨です。
ここで、出版社における電子書籍と紙の書籍の立場の違いが、くっきりと浮かび上がってきます。

電子書籍は疑似通貨になり得ませんが、紙の書籍は疑似通貨たり得るのです。

お金が無い時に、お金として使える。
出版社にとって、紙の本は、本であり、商品であり、クレジットカード。あるいはローンカードの様な存在なのです。

そのような便利な存在の紙の書籍を、出版社がそう簡単に手放すはずはありません。

この出版業界の「前払い」は、出版社と著者の間にもあるらしく、ある程度の売上予測をし、それに基づいて一定の額を著者に支払っているらしいのです。

そして、売れれば追加で支払い、売れなかったら、損失は出版社で吸収しているようです。

実に著者を守ったシステムですが、その代わりに著者へ支払われる著作権料はリスク吸収分も含めて少なめになっているものと思われます。
(10%とどこかで読んだ気がしますし、便利グッズ発明した人は20%とも30%とも言われますので、半分くらいはリスク吸収用に減らされているのかも知れません)

しかし、その事実があったとしても、常にヒットを生み出せる作家は少ないので、著者の多くは安定的な収入の得られる、従来の出版社との二人三脚を止める事は出来ないでしょう。

出版社は紙の書籍の売り上げが落ちたら困る。どころか、紙の書籍で赤字が出た際の補填分に回すための小遣い稼ぎとしてしか見ておらず、電子書籍のシェアは「ほどほど」が彼らにとっては理想的であろう事が伺えます。
そして現在、アマゾンから価格決定権を勝ち取り、電子書籍を提供するしないも出版社次第。
概ね、出版社の狙い通りに推移しているように見受けられます。

以上の理由で、電子書籍は、絶望的なまでに(紙の書籍以上の)シェアを伸ばす余地がありません。値段を下げる余地がありません。
残念ですが、電子書籍は紙の書籍よりも安くなると言うのは夢物語です。
今の電子書籍ストアが行っている半額セールですら、頑張っていると言えます。

電子書籍の価格について、夢を見るのは、もう止めましょう。
どうしても諦められない人は、出版社と喧嘩してでも著者が電子書籍を直接出したくなるような魅力的な市場になるように考えて行動して下さい。

ただただ安くしろ!100円にしろ!と言うだけの行動は、無駄な行動と言うだけで無く、見苦しいですし、著者の方々に対して失礼です。



2013年11月9日更新

参考にしたサイトの一つを見つけたので、URLを掲載。
一年前の記事ですが、どの程度、期待通りになったでしょうか。

特集:2012年、波乱の電子書籍 出版・書店・取次の未来は ...
http://www.hummingheads.co.jp/reports/feature/1204/120416_01.html#1


2014年1月14日更新

電子書籍が発案されて間もない時期に(それでも5年10年経ってたと思う)、ebj社長本人の手で書かれた本です。
http://www.amazon.co.jp/eBook%E6%99%82%E4%BB%A3-%E3%81%AF%E3%81%98%E3%81%BE%E3%82%8B%EF%BC%81-%E3%80%8C%E9%9B%BB%E5%AD%90%E3%81%AE%E6%9C%AC%E3%80%8D%E3%81%8C%E5%A4%89%E3%81%88%E3%82%8B%E8%AA%AD%E6%9B%B8%E9%9D%A9%E5%91%BD-%E9%88%B4%E6%9C%A8-%E9%9B%84%E4%BB%8B/dp/4806119571/ref=sr_1_14?s=books&ie=UTF8&qid=1389637695&sr=1-14&keywords=ebook+Japan%E9%9B%BB%E5%AD%90%E6%9B%B8%E7%B1%8D
現在の電子書籍事情と、何が違うのか?何が同じか?比べると、大変為になります。
と言うか、絶望します。
本質的に何も、なんにも変わってないのですよ…。
規模は拡大した。売上伸びた。リフロー型が主流になった。でも、紙の本を脅かさないよう、コントロールされている様が、この本と現状の電子書籍市場を比較すると、透けて見えます。

Haskell入門以前(Kindle版)が消える前に2冊売れてた・・・(ついでに近況報告)

誰ですか。
あんな内容の薄い本にわざわざ99円も払っちゃった人は。

自分で書いといてなんですが、99円の価値も無いですよ・・・。
(だから犠牲者が出る前に消したのに・・・)

あ、電子書籍を作るために一太郎買いました。
小説は絶対縦書きじゃ無いと嫌ですものね。

もう一つ、WinStoreアプリを作り始めたのですが、中身は出来たけど、それに使う画像を用意する方に苦労してます・・・。
PCで絵を描くのは、私には無理です。
レイヤーとかの使いどころが理解できないです。
ペンタブレット買うお金が無いです。
私の腕では、マウスを本気にさせられません。
背景が透明な画像の作り方はマスターしたので、画用紙に絵を描いてスキャン→色調整→背景を透明にする。と言う方法で頑張ってみる予定。

平行して、いつかここでバイナリファイルを扱ったお題が出せるように勉強しますが、当分は更新しないと思うので、期待はしないで下さい。

Haskell入門以前をアマゾンに出品してみた。…けど、すぐ消した。

パブーにて、無料で公開している「Haskell入門以前」ですが、アマゾンの方が読んでくれる人が多いかな?と、出版してみたのですが…。
何と、アマゾン。無料で出版出来ないんですよ。
99円以上じゃなきゃダメだそうで…。

一旦は、99円くらいだったら払ってくれる人も居るかな?文句言われないかな?と、出版してみたんですが、やっぱり、私ごときの書いた内容じゃ、99円でも高そうだったので消しちゃいました^^;
(とはいえ、90日間はアマゾンの好き勝手に出来るそうなので、まだ本当には消えてませんが…。ああぁ…orz)

まあ、でも、パブーみたいに自作のePubファイルうpしたかったら金払え!みたいなのは一切ないみたいなので、縦書きの文章を出版したいときには、パブーよりもアマゾンの方が良さそうですね。
読者数も考えれば、技術書系も、有料で売れる自信が付いた物のみ、アマゾンを優先して出した方が良さそうです。
(まあ、そんな自信はここでブログしてみた限りじゃ、大分後にならないと付きそうにありませんが…)

ちなみに、パブーの「kindleに送る」機能よりも、アマゾンに直接うpして変換してもらった方が、インデントが崩れていませんでした。
と言うか、完ぺきでした。
(パブーの「kindleに送る」機能で「Haskell入門以前」をKindleに送ると、インデントが崩れます)

パブーの「Kindleに送る」機能で、上手く表示されない本で、どうしてもパブーの本を有料でもいいからKindleで読みたい!と言う方は、著者さんにアマゾンでも出版するようにコメントしてみてはいかがでしょう?
あんまり、そんな需要は無い気もしますが、一応。

searchコマンドをByteStringで書き直すと上手く動かない・・・

countコマンドのRuby版アルゴリズムにHaskell/Pythonも合わせてみた+メモ化に関する疑問 - しんちゃんの日記で頂いたツムジさんのByteStringを使うと速くなるというアドバイスを元に、こちらのベンチマークのコードPython vs Ruby vs Haskell(文字列検索deベンチマーク) - しんちゃんの日記もByteStringに書き換えてみたんですが…

コード

import System.Environment
import qualified Data.ByteString.Char8 as B

search _ _ empty = []
search (y,x) s ns | B.take (B.length s) ns == s = (y,x):search (y,x + 1) s (B.tail ns)
search (y,_) s ns | B.head ns == '\n' = search (y + 1,1) s (B.tail ns)
search (y,x) s ns  = search (y,x + 1) s (B.tail ns)

main = getArgs >>= \args ->
		B.readFile (args!!0) >>=
		return.search (1,1) (B.pack (args!!1)) >>= \pos ->
		putStrLn (args!!0) >>
		print pos

何故か、空リストしか返さなくなっちゃいました…orz
search関数のパターンマッチにも問題があるみたいで、

search3.hs:4:1:
    Warning: Pattern match(es) are overlapped
             In an equation for `search':
                 search (y, _) s ns = ...
                 search (y, x) s ns = ...
                 search (y, x) s ns = ...
Linking search3.exe ...

と言う警告が出ます…

何で動かないんだろう?謎だ…


2013年2月19日追記

tanakhさんのアドバイスのお蔭で動くようになりました!!

動くようになったコードはこちら!

import System.Environment
import qualified Data.ByteString.Char8 as B

search _ _ ns | B.null ns = []
search (y,x) s ns | B.take (B.length s) ns == s = (y,x):search (y,x + 1) s (B.tail ns)
search (y,_) s ns | B.head ns == '\n' = search (y + 1,1) s (B.tail ns)
search (y,x) s ns  = search (y,x + 1) s (B.tail ns)

main = getArgs >>= \args ->
		B.readFile (args!!0) >>=
		return.search (1,1) (B.pack (args!!1)) >>= \pos ->
		putStrLn (args!!0) >>
		print pos

私の環境では

>difftime search pi.dat 7777777
pi.dat
[(298906,35),(517833,1),(517833,2),(517833,3)]


1.4843963s

Python/Rubyに勝てないとコメントで書きましたが、オリジナルの方が、改めてベンチ取り直してみたら4秒とかなり遅かったので、現在の環境で今夜にでもまたベンチ取り直してみます。



2013年2月20日追記

Python vs Ruby vs Haskell(文字列検索deベンチマーク) - しんちゃんの日記をベンチ取り直して更新しましたが、Haskellが両言語に肉薄はするものの、順位は変わりませんでした…orz
通りすがりさんのコードをByteStringに直さないと勝てないかも知れません…

Haskell入門以前の内容を、微修正しました。

日本語的におかしかった個所や、再帰版reverse関数の説明が少し間違っていたので、修正加えました。
それと、ghciとrunghcは末尾最適化されないと書いてたところも、runghcはどうも末尾最適化してるっぽい事が分かったので、ghciのみと言う書き方に直しています。

まあ、再帰版reverseはお勧めしない書き方として紹介していますし、どれも本筋には影響ないのですが、一応報告までに。

Haskell入門以前 - しんちゃん | パブー

VisualStudioExpress2012 for Windows8が、不安定な件

弟夫婦が新しくPCを購入。
OSがWin8だと聞いて、「おっしゃ!姪っ子(2歳)が楽しめるアプリ作ってみるか!」と意気込んでみたのは良いのですが、試作用に適当な画像を背景とした所までは良かったのですが、その上にさらにキャラクター(予定)用のこれまた適当な画像を置いたら、まだ1行もコード書かないうちから、アプリを(デバッグでもリリースでも)実行するとOSを巻き込んでフリーズします…
(countコマンドのWinStoreアプリ版を作った時も、たまにOS巻き込んでくれてましたし…)

動く絵本的なものなら作れるかな?と思っていたのに、前途は多難そうです…

for Desktopはもうちょい安定してたと思うんだけど…

WinStoreアプリやWinRTは、新しいプラットフォームですし、不安定な所が多いみたいです。