bit sized

ビジュアライジング・データ

ビジュアライジング・データ ―Processingによる情報視覚化手法

を読んで「何か身近に数字を絵にして試せるものはないかなー」と思っていたのですが、自分が使用しているオンラインバンクでCSVで取引履歴が取得できたので、Processingで試してみました。











とりあえず、入金/出金（振込とか）を色分けして正方形の面積で金額の大きさを表しているだけなのですが、正方形どうしが重なり合わないようにしたり、以外と面倒な事をやっています。作ってみると、何をしたいのか若干分からなくなってますね。。。コード書く前にもうちょっと考えときゃよかった。次は時系列表示にしてみよかな。。

Visual Account

定期的にチェックするサイトについて、

もっとも多かったのは「4～5」で33.8％（112人）、それに次ぐのは「2～3」で32.6％（108人）と、2～5で6割以上という結果であった。11以上のサイトをチェックする回答者は、12.1％（40人）であった。

さらにそのチェックの仕方であるが、「お気に入り」からサイトチェック9割以上、RSS リーダー派は0.6％らしい。

なぜRSSリーダーは使われないか？

こうした結果について、30秒くらい考えた。なぜRSSリーダーは使われないのか？

1. 閲覧するサイトの量が少ない
2. 質的に目新しいものではない

閲覧するサイトの量が少ない

現時点で、何かしら動機や興味によって一日１００を超えるようなサイトをチェックする人は少ないだろう。仕事で猛烈に情報収集をする必要があるなど、なにかブートストラップ的なものがなければ、RSSリーダーを使用しようとはしないのではないのか？

質的に目新しいものではない

RSSリーダーの恩恵を受けている人にとっては、膨大なサイトをフォルダやタグを用いて整理できたり、新しい情報を順に（リニアに）消化できるという機能は、それなしではネットサーフィン（という言葉はあんまり好きではないが）が苦痛になってしまうだろう。

が、

多くの人にとっては、Webサービスを必要とするのは、「新しい機能」や「新しいコンテンツ（デザインも含めて）」 である。典型例で言えば、オンラインショッピングや動画配信、また有名人のブログやSNSなどだろう。

RSSリーダーはこうした機能やコンテンツベースのソリューションではなく、膨大な「量」をこなすためのソリューションだ。

別に全ての人が毎日膨大な情報を吸収する必要があるとは思えないが、すごくメタ（ボリックではない）なレベルでは、量から質への転化というか、多くの情報を吸収するということは新しい時代の価値観の形成するベースであるような気がする（それを共有することも）。

RSSリーダーの使用率が低いのは前々から知っていたが、社内での会話からIT業界の中でも使っている人が少ないことに愕然とした今日このごろでした。

素人の投資信託で書いたように、先月から4分散で投信の自動積立を始めたのだが、

「自動積立日って何日にすればよいのだろう？」 と思っていたら、

金融の世紀というブログで、投資信託の積立日というというエントリがあった。

上記で使っているデータが2003年からのものだったので、投信の設定日から今月までもうちょっと詳しく調べてみた。（ちなみに自分がkabu.comで買っているトピックスオープンで調べた）

具体的な期間は、投信の設定日の１９９０年3月-2008年2月

これを見ると、

• 11-14日あたり
• 22-25日 あたり

が積立日としてねらい目のように思える。

もっと確実に言えそうなのは、「月初と月末は（比較的）高い」

まあ安い高いといっても、最大0.7-0.8%の差をどう見るかという事でしょうが、この差が信託報酬より大きくなっているのも事実…

ちなみに、なぜか知らないけど自分は13日に設定していた（まぐれ？）

題名からして、ハウツー本っぽいと思う人が多いだろう。

一言で言えば、

「決断する（判断する）」するための判断材料

をケーススタディを用いて、シンプルに分かりやすく説明している。

朝11時までメールは読むな! 「後悔しない決断」の技術 (講談社BIZ)

決断や判断を下すために必要な情報とはいったい何だろうか？

本書は極めて簡潔に、下記の 3つを説明しているのではないだろうか。

• 決断する事の性質
• 決断する側の性質
• 決断する際の方法論

まず、決断をする側の人間にはいろいろなバイアス（先入観）がある。それを認識する事から始まる。

• 結果によって決断を評価してしまうバイアス
• 継続性のバイアス(=今まで続いてきた事は今後も絶対変わらないと思ってしまう)
• 自信過剰のバイアス(=突き詰めてみると、自分の専門分野でもよく知らない事は多い)
• 人に対する評価の傾向(=対比誤差-自分にない能力を持っていると過剰評価してしまう、など)
• 道具のバイアス(=自分の使える能力だけで問題解決しようとする)

その上で、決断する事項がどういう性質のものかを見極める必要がある。

発注時など評価シートやマトリックスを使用して、目的に合った評価基準を作成する場面もあれば、実は判断の内容ではなく判断するまでに掛かった時間の方が重要な決断もある。

そして、決断を下すための方法や注意事項を状況に合わせて、説明している。

• フレームワーク(SWOT分析、３C分析など)を使った
• ワーストシナリオを作成する
• 「決断をしない」という決断
• ブレーンストーミング
• 決断する時間

フレームワークの使い方など各項目についての説明は触り程度だが、心理学とビジネススキルの組み合わせ具合が巧妙な良書だと思う。

本書の引用より

If the only tool you have is a hammer,you tend to see every problem as a nail.
もしあなたが持っている唯一の道具が金づちなら、あなたは全ての問題を釘として見るようになる

- Abraham Maslow -

金づち以外のツールも持っておこう

実家に戻ると、大量のドキュメンタリー番組が録画されている。

今年は仕事納めが少し早かった事もあって、今日(28日)に戻ってきたので
チラホラとチェックしていたのだが、下記は面白かった

“背伸びが、人を育てる” – 校長:荒瀬 克己 | プロフェッショナル仕事の流儀
http://www.nhk.or.jp/professional/backnumber/071016/index.html

奇跡と呼ばれた学校―国公立大合格者30倍のひみつ
荒瀬 克己(著)

壁を越える技術
西谷 昇二 (著)

一昔前までは、京都の公立高校の評判はいいものではなかった。

国公立大学が私立大学よりもいいかどうかは別として、公立高校の進学成績の指標としては国公立大学の合格者数が使われる事が多い。

• 関西では、関東に比べて（合格難易度でみたとき）上位校は国公立大学の方が多い

• 経済的負担の少ない国公立大学の方が公立高校の進学先として馴染む

• 入試の科目数が多いので、総合的な学力という面で評価しやすい

など理由は様々だろうが 、「堀川の奇跡」と呼ばれている上記のドキュメンタリーの現場では、国公立大学への合格者を6人から180人にまで押し上げた。

私も京都大学のパラダイスと頭に名のつく学部に通っていたが、当時確かに京都の公立高校出身の京大生というのは、地元なのに数としては圧倒的に少なかった（私立では洛南が多かった気がする) 。

総合選抜制（受験生が進学先高校をえらんで受験するのではなく、試験の成績と居住地によって進学先を振り分けられる）の弊害や 、進学塾など周りに合格するためのノウハウが少ない（大阪に比べるとですが）など、環境的な要因が大きいのかと思っていた。

しかし、堀川高校で行われた改革は、そうした制度的な見直し（専門学科を開設し、優秀な生徒を集める）もさる事ながら、その中身はもっと根本的でエキサイティングな事だった。

探求学科では、生徒の「知りたい」を喚起し、それを深堀りしていく方法論（データ分析、論理の把握、構築など）を提供し、自らの研究テーマを設定し発表することまで要求する。

自分の好きな事から初めると、自分の知らない事に対するする謙虚な興味が湧いてきて、「自然に」他の教科にも 主体性を持って取り組んでいるようだ。

また、こうした「知りたい」を基礎とした教育の一番の肝は、同時に生徒に対して、「自分は何者で、何をして生きていきたいか」という簡素だが難解な問題を提起する事によって、モチベーション（=動機）を発見させるという事ではないだろうか。

勉強、特に受験勉強というのは、理不尽なものである。

「なぜ受験勉強をしなければならないのですか？」

という単純な問いに対して、私自身、生徒としても先生（塾講師や家庭教師ですが）としても納得のいく答えを聞いた事がない。一番重要なのは、生徒がその先にあるものを自分で感じ取る事だろう。あとは適切な方法論と、情報があればよい。

堀川高校の成功に対して、「専門学科を設置して偏差値の高い子供を集めたから当然」という話もあるようだが、それに応えられる教育を提供する（というより一緒に作っていくという印象だったが）のも大変な努力が必要だったとだろうし、優秀な人材を集める事自体なんの非もない。他の公立が真似できない部分もあるが、多いに参考にできるのではないか？

自分の夢を語り、自分の好きな事に邁進する高校生が増えてくれるのは「百利あって一害なし」だと思うのだが．．．

すごいエントリだなっと思ったので、日本語にしてみた。SaaSというとイニシャルコストが安いとかセキュリティやサーバー管理の手間が省けるといったユーザーの視点からの議論が多いけれども、Web開発者から見た本質とはこういう事なのだと思う。

Ask 37signals: Installable software?

企業内部で使用できるようにアプリケーションを販売する予定はありますか？

私達がインストーラブル・ソフトウェアを販売する可能性はほとんどないでしょう。これはソフトウェアにというより、ビジネス上の観点からです。

• もし、そうすればまったく別の企業になってしまうでしょう

インストーラブル・ソフトウェアを開発、販売、配給するためには今とは根本的に異なる企業にならなければならないでしょう。今ほどアジャイル開発できなくなるだろうし、今よりハッピーではなくなるでしょう。

インストーラブル・ソフトウェアを作るとすると、多大なお金と時間を テクニカルサポートに費やし、より多くのドキュメントを作成し、開発スピードを遅らせ、そして最終的には私達のアプリケーションのカスタマーエクスペリエンスをうまくコントロールできなくなってしまうでしょう。他の企業にとってはたいした問題ではないかも知れませんが、私達にとっては大変なマイナスです。

• 「ホスティング = 開発環境と動作環境をうまく管理できる 」

ソフトウェアというものは、多様な環境でうまく動作させる事が難しいものです。
Webベースのソフトウェアでは単一の動作環境上でうまく動作するように、コードを書けばよいのです。私達はプロダクトをセットアップするのに必要なハードウェアとソフトウェアを責任をもって組み合わせればよいだけです。この意義はとてつもなく大きいものです。

• 「インストーラブル = マズい事が起こりやすい 」

デスクトップアプリケーションでも、顧客の環境にセットアップされたWebアプリケーションでも、大本となるコードは単一でしょうが（あなたがカスタムバージョンを顧客ごとに作成していない限りは）、手に負えないくらい際限なく多様な動作環境に向き合わなければならないでしょう。提供するアプリケーションのインストールやアップグレードや一般的なパフォーマンスに影響を与えるOSやサードパーティのソフトウェアやハードウェアを熟知していないと、なにかマズい事が起こった時、原因を突き止めるのが非常に難しくなってしまいます。また顧客の環境にインストールする場合、異なるバージョンのRuby,Rails,MySQLなどが存在するとますます困難です。

• 後方互換性とういう悩みの種

さらに、インストーラブル・ソフトウェアを販売すると、後方互換性にも取り組まなければなりません。最新バージョンが3.2だとします、数千人のユーザーが3.1ではなく3.0を使用していたらアップグレード手順はどうなるでしょう？そして、まだ2.9や2.9.7を使用しているユーザーについてはどうしましょう？後方互換性を維持するという事は、多分ソフトウェアのアップデートにとって最大の障害でしょう。

もちろん、ブラウザー間の相違やブラウザーのバージョンの違いといった点ではWebベースのホスティングアプリケーションも似たような問題はありますが、それはWebベースのインストーラブル・ソフトウェアでも変わりません。そういった問題はどちらにも存在するので、チャラです。

• アップデート・サイクル

最後に、Webベースのソフトウェアは顧客側の作業を必要とせず、たちどころにすべての顧客に対してアップデートを行うことができます。つまり、顧客に何の負担をかけるもなく、日次で（もしくは一日に何度も）ソフトウェアをアップデートできるということです。インストーラブル・ソフトウェアのアップデート・サイクルはたいていもっと長くなってしまいます、なぜならユーザーにアップデートを毎日ダウンロードするようお願いしなくてすむよう、リリースをまとめることの方が重要だからです。

このように言う事で、デスクトップ・アプリケーションやインストーラブル・ソフトウェアがなくなるとか、魅力がないとか言いたいのではありません。しかし、今のところWebベースのホスティング・アプリケーションという私達が好むやり方にこだわりたいと思います。

Podcast に登録している番組の数が増えてきたというのと、以前ちょっと興味を引かれた速聴なるものを試したいと思い、「じゃあ、Podcastを速聴してみよう」と企ててみました。

速聴については、簡単に言えば

「普通に話しているスピードの3-4倍以上で話を聞くと、普段の言語処理を行う際には使用されない脳の部分が活性化され、記憶力などの脳力向上に役立つ」

というものです。

どうやって、Podcastを3-4倍速で聞こうか？という部分ですが

1. Podcast再生時にipodの再生速度を変更する機能を使用する
2. Podcastに登録される前に、mp3の音声データを編集しておく(3-4倍速に変換しておく)

という2種類の方法が考えられると思いますが、1の方法では

• せいぜい20%くらいの速度変換しかできない
• オーディオブックしか再生速度を変えられない

という事で、自宅にある余っているLinux+ Apacheを使用して自分用のフィードに変換(mp3 + rssを編集)して、それをPodcastに登録する事にしました（下図）

最近個人的によく聞く、新刊JPで配信している新刊のダイジェスト（火木土更新）での例。

1. rssファイルを新刊JPのサイトから取得
2. 1のファイルをparseして、各エントリのmp3ファイルをダウンロードする。
3. ダウンロードしたmp3を3-4倍速に変換。
4. 変換済みのmp3ファイルのパスを、1のrssファイルでの各エントリの ファイルとして書き換える
5. 変換済みのmp3ファイル+編集済みのrssファイルをapacheのディレクトリに配置する。
6. iTuneから、5のurlを指定してpodcastを登録する

Linuxマシンの方で必要なものは下記ですが、sox以外はデフォルトで使用できるのではないでしょうか？

• ruby
  • 本体
  • ライブラリ
    • rexml
    • open-uri
• Linuxコマンド
  • wget
  • sox (mp3編集ツール)

処理としては、上記のツールをつなぎ合わせているだけのようなものなので、
シェルでもできとおもいますが、勉強も兼ねてRubyで書いてみました。

あとは、更新日にあわせてCronに登録しておけばよいでしょう

#!/usr/bin/ruby

require 'open-uri'
require 'rexml/document'

# global variables

$feed_org = "http://www.sinkan.jp/rss.xml"       #新刊JPダイジェストのRSS

$data_dir = "/var/www/xxx/xxx/"                  #Linuxのhttpdディレクトリ

$data_dir_url = "htttp://hostname/xxx/xxx/"      #↑のurl

$username = "username"                           #新刊JPのユーザー名(メールアドレス)

$password = "password"                           #パスワード


class Feed
  def initialize(feed_path)
    @feed_path = feed_path
    @rss_file_name = @feed_path.split(/\//)[-1]

    @feed_local = $data_dir + @rss_file_name
    doc = REXML::Document.new(open(@feed_path).read)
    @rss_root = doc.root
    @feed_items = Array.new
    @rss_root.elements.to_a("/rss/channel/item").each { |i|
    @feed_items.push( FeedItem.new(i))
  }
  end

  def comp_feed_entry(org_idx,stretch_rate)
    @feed_items[org_idx].stretch_rate = stretch_rate
    @feed_items[org_idx].download_mp3($username,$password)
    @feed_items[org_idx].time_stretch
  end

  def comp_all(stretch_rate)
    for i in 0..@feed_items.size - 1
      comp_feed_entry(i,stretch_rate)
    end
    @rss_root.elements["/rss/channel/title"].text = "[" + stretch_rate.to_s + "

]" +  @rss_root.elements["/rss/channel/title"].text + "_"
  end

  def save_feed
    local_doc = File.open(@feed_local,"w")
    @rss_root.write  local_doc
  end

end

class FeedItem
  def initialize(rss_node,stretch_rate = "")
    @rss_node = rss_node
    @stretch_rate = stretch_rate
    # rss node mapping

    @title = @rss_node.elements['title']
    @mp3_path = @rss_node.elements['enclosure'].attributes['url']
    @mp3_name = @mp3_path.split(/\//)[-1]
  end

  def time_stretch
    puts @stretch_rate
    stretched_mp3_name = @mp3_name.sub(/(.+?)\.(.+)/) {|m|  $1 + "_" + @stretch_
rate.to_s + "." + $2 }
    stretched_mp3_path = $data_dir + stretched_mp3_name
    command_line ="sox " + @mp3_path + " " +stretched_mp3_path +  " stretch " + @stretch_rate.to_s
    puts command_line
    system(command_line)
    @title.text =  "[" + @stretch_rate.to_s + "]" +  @title.text
    @rss_node.elements['enclosure'].attributes['url'] = $data_dir_url + stretche
d_mp3_name
  end

  def download_mp3(un = "",pw = "")
    if File.exist?($data_dir + @mp3_name) then
      File.unlink($data_dir + @mp3_name)
    end
    if un != "" || pw != "" then
      command_line = "wget -P " + $data_dir + " --user=" + un + " --password="
+ pw + " " +  @mp3_path
    else
      command_line = "wget -P " + $data_dir + @mp3_path
    end
    system(command_line)
    @mp3_path = $data_dir + @mp3_name
  end

  attr_accessor :rss_node
  attr_accessor :title
  attr_accessor :stretch_rate
end

fd = Feed.new($feed_org)
fd.comp_all(0.3)
fd.save_feed