スタートは今日のTechCrunchの記事になると思う。

TechCrunch:Twitter以来久々の大物やみつきニューフェース:Turntable.fm

実際に使ってみました。面白いサービスではあると思う。面白いだけの消費するだけのサービスだとも思う。(もちろん今後の展開にもよるけれど)

国内での紹介とルール

ホームページのネタ帳:夜作業のWeb制作も楽しくなるturntable（ターンテーブル）が今、熱い

こういう中途半端な紹介はいけない。末尾に著作権ポリシーについて書いているけど、どうせならしっかり書くべきだと思う。

Turntable.fmのコピーライトポリシーはここ。

ざっくり簡単に説明すれば、DMCA(デジタルミレニアム著作権法)に基づいて、コンテンツの著作権侵害には対処しますよ、という説明です。いわゆる”Notice and Take Down”に基づいて適切に処理しますよ！と書いてある。

違法なコンテンツ、要は適法にライセンスされていないコンテンツがあったら配信できないようにするよ！使えないようにするよ！というもの。日本国内であればプロバイダ責任制限法がこれと同種の働きをしています。

このルールの元々の意義は、サービス提供者に必要以上の責任を負わせないことが目的。

例えばYoutubeでユーザがアニメ動画をアップしてサービス提供者がそれを確実に監視できるのか？
できないなら発覚した時点で削除すれば責任はない。ざっくりと説明するならこんな感じ。

裏返せば、発覚しなければ削除されないしそこは無法地帯になる。

バランス

日本の大手レコード会社発の楽曲をアップして流している人が何人か居たけれど、それはライセンス的にアウトのはずだ。
(この辺はTurntable.fmがライセンスの管理をどうやっているのか？という点で変わってくる。少なくとも原盤権的には今のところ(ry )

Turntable.fmのサービス自体が悪い！という意味ではなくて、それを使用する人、それを使用できる環境がまずい場合があるっていう説明が適当になると思う。

他者の権利を侵害する蓋然性が高いコンテンツを発信される可能性が高いサービスが台頭してくるなら、
私たちはソニー・ボノ法を否定することもできないし、
これからの国内における著作権保護期間延長の議論を真正面から否定出来ない気さえする。

コンテンツの財産権が削られるならその分保護期間を長くする必要がある、と言われたら私たちはどう反論すべきだろうか？

この蓋然性が高いかの判断をする機関が必要なのかもしれない。公正取引委員会ならぬ公正コンテンツ取引委員会的な何かが。
(そんなもんができて適切に運用されるのか、というと頭がいたい)

誤解の無いように書いておくけど、私自身は著作権の保護期間がこれ以上長くなるのは何1ついい事がないと思っている。
財産権云々もあるけれど、権利自体の安定的な運用の観点からも既に長すぎる。

考えなければならないこと

ルールについて考えなければならない。文書化するなら法律かもしれないし新しい条約かもしれない。
コンテンツの提供者が食っていける程度の環境は維持しなければならないし、新しい世代に対してはコンテンツ利用の自由度を維持したバランスをもっと考えなければならない。

恐ろしいことに1度決定されたバランスはなかなか覆らないもので、決めてしまえばそのまま継続される可能性が高い。

Creative Commonsの登場から10年。

もっと新しいバランスが必要なのかもしれない。
音楽は私たちの文化だと思う。でもその曲は誰かの財産であって、誰かの明日の飯の種であることを忘れてはいけない。

追記

Turbtable.fmが採用しているらしいストリーミングカタログの提供企業medianetのコンテンツ提供パートナーがハンパなかったです。調べてから書くべきだった。

メジャーがそろっている！！http://www.mndigital.com/about-us/content-partners.html

恐らくは、当blogで初めての担当案件紹介になります。
クライアント様はGetting Better。

何それ？と言う方に説明するには、
下北沢を中心に展開されるRock Partyです。

Count Down JapanやRockin’ Japan FESでもDJを務める片平実主催のPartyです。

案件内容は、心機一点のリニューアル。
デザインはGetting Betterの中の人によるもので、主に実装とデザインの調整をしています。

サイトはこちら。
http://getting1996.com/

音楽Partyのお仕事と言うことで、とても楽しい作業ではありましたが、
当方とデザイナーさんとの生活時間のズレ、
さらには、デザイン部分をご担当していただき、内部設計自体はこちら、という都合上、
長い時間をかけたプロジェクトと相成りました。

みなさん、毎週月末土曜日、下北沢で会いましょう。

今日も音楽が素敵であることに感謝する。

Google Mapsは日頃から重宝しています。
お出かけの前にストリートビューと併せて使用すれば、道に迷うこともなし。
（それでも道に迷うのはきっと・・・私が方向音痴だからか！！）

さて、Google MapsといえばJavascriptでゴリゴリ動いてくれます。
しかし、JSを使用するが為、携帯電話では使えません。ん？先日発表されたDoCoMoの最新機種ならいけるのかも。

そこで、Google static maps APIの登場です。

APIの詳細については、すべてリンク先に書いてあるので割愛して、早速試してみます。

今回は、吉祥寺駅を中心にして作業を行います。
吉祥寺駅の緯度、経度は「35.702811, 139.579804」になります。

それでは1つずつ確認しながら作ります。
基本のURLは以下の通り。

http://maps.google.com/staticmap?

1.中央（center）の設定
centerに、地図の中央となる緯度経度を記述します。
前述の通り吉祥寺駅の緯度経度は「35.702811, 139.579804」なので、カンマ区切りでそのまま記述。

http://maps.google.com/staticmap?center=35.702811,139.579804

2.ズームレベル（zoom）の設定
zoomを使って、地図の拡大率を設定します。zoom=0の場合には地球全体が表示されます。
まずは適当に15で設定chrome://scribefire/content/scribefire.xul

http://maps.google.com/staticmap?center=35.702811,139.579804
&zoom=15

3.地図寸法(size)の設定
地図の大きさを設定します。
大きさは「横幅×縦」の順で記述。今回は適当に400×400で。

http://maps.google.com/staticmap?center=35.702811,139.579804
&zoom=15
&size=400x400

4.画像のフォーマット（format）[省略可]
出力する画像ファイルの種類を選択します。
デフォルトではgifが選択されます。gifで問題ないので省略します。

5.マップタイプの設定（maptype）

• roadmap(通常出力)
• mobile(携帯電話向け出力)
• satellite(航空写真)
• terrain (地図や植生)
• hybrid(航空写真と通常出力)

今回は、roadmapを選択。

http://maps.google.com/staticmap?center=35.702811, 139.579804
&zoom=15&size=400x400
&maptype=roadmap

6.マーカー(markers)の定義
目印の設定です。まずは中心となる吉祥寺駅（「35.702811, 139.579804」)。

http://maps.google.com/staticmap?center=35.702811, 139.579804
&zoom=15
&size=400x400
&maptype=roadmap
&markers=35.702811,139.579804

7.API key
Google MapsのAPI KEYを記述。

http://maps.google.com/staticmap?center=35.702811, 139.579804
&zoom=15
&size=400x400
&maptype=roadmap
&markers=35.702811,139.579804
&key=API_KEY

8.位置情報取得の有無(sensor)
地図を表示するだけならfalseを設定。

http://maps.google.com/staticmap?center=35.702811,139.579804
&zoom=15
&size=400x400
&maptype=roadmap
&markers=35.702811,139.579804
&key=API_KEY
&sensor=false

他にも省略可能なパラメーターがありますが、割愛。
実際に貼りつけるURLは以下の内容になります。

<img src="http://maps.google.com/staticmap?center=35.702811,139.579804&zoom=15&size=400x400&maptype=roadmap&markers=35.702811,139.579804&key=API_KEY&sensor=false" />

無事表示。
続いて、実際に使いそうなパターンを想定してイジッてみます。

1. 地図をもう少し拡大
2. 吉祥寺駅以外にもマーカー
   →ヨドバシ吉祥寺(「35.704704,139.581618」）

<img src="http://maps.google.com/staticmap?center=35.702811,139.579804&zoom=16&size=400x400&maptype=roadmap&markers=35.702811,139.579804|35.704704,139.581618&key=API_KEY&sensor=false" />

無事に目的は達成。

尚、マーカーについては、複数指定する場合、「|」で区切ります。またオプションとして「緯度,経度,色」とすることで、マーカーの色を設定できます。2つ目の地図では、吉祥寺駅を赤、ヨドバシを青としています。

とりあえず、現状ではこんなところです。
これでMobile対応のmapもAPI対応できますね。

P.S.決して！決して！！複数のエントリに分けて書けばよかったなんて思ってないよ！！思ってないよ！！！！

SQLクエリの動作を確認する場合、特に大量のデータ処理をテストする場合にはサンプルデータを作成しなくてはなりません。
Excelを使って適当に、ランダムに作るのも手ですが、簡単なテストの場合にはちょっと面倒ですね。

そこで、何かサンプルとして使えるデータはないかと考えた時、郵便事業株式会社が提供している郵便番号データが挙げられます。
（これ以外に何かいいサンプルデータをご存じの方は教えていただけると大変助かります!!）

早速、localのMySQLにインポートしてみました!!

■郵便番号データの整形
まず、こちらの中段にある「全国版」LZHファイルをダウンロード。

現れたCSVファイルには今回使用しないデータが含まれるため、一手間かけてデータを整形します。

1. Excelで開く
2. A、B、D、E、F、J～O列を削除
3. A列の左側に列を挿入し、新しく挿入した列に1～最終列まで連番をふる
4. B列（郵便番号）のセル書式を変更（郵便番号の書式が狂う為）
   →B列を選択→右クリック>セルの書式設定>表示形式タブ>ユーザー定義＞「種類」と書かれたエリアに「0000000」を入力>OK
5. CSVファイルとして保存
6. 保存したファイルをテキストファイルで開き、文字コードをMySQLに合わせて変更(TeraPadやVimでいける)
7. 変更後のファイルを保存

以上でファイルの整形は終了です。

■DBとTableの準備
DBは適当な名前でCREATE、または既存のDBを使用します。
Tableの構造は、以下の通り。

データのテスト用なので緩く。尚、主キーはidにします。

■郵便番号データのインポート
phpMyAdmin等を使用して、郵便番号データをインポートします。

これで完了です。
ファイルを作るのが面倒な方は、こちらにファイルを置いておきます。

1人で淡々と作業するには、BGMは重要です。

中学・高校の頃は、（といっても、もう10年も前ですが）好んでラジオを聞いていました。
当時は、まだ音楽を集中的に流す番組が多かった気がします。
最近のラジオは夜中でもギャーギャーワーワーしていて好きになれません。

そんな時、BGMに使うのがJamendo。

Creative Commonsライセンスが付与された高品質な音楽が沢山あります。
日本語には対応していませんが、音楽を聴く分には問題ありません。

ストリーミングはもちろんのこと、ダウンロードして楽しむこともできます。

騒がしいラジオを聴く前に＿＿＿＿＿Jamendo!!