最強の楽譜作成ソフトは？

Sibelius vs MuseScore

いきなりですが，MuseScore最強すぎます。これが無料なんて信じられないくらい。

自分は普段，Sibeliusっていう値段のクソ高い楽譜作成ソフトを使っています。 ですがこのソフト，インストールに50GBの容量が必要なんですよね。 1TBの容量があるメインマシンならともかく，サブのMacBook Air 128GBに入れたらPCの容量半分持っていかれます。これは避けたい。笑

そこで代替を探していてMuseScoreを試してみたら，これで十分では？ってなってしまったわけです。 そこで今回は，Sibelius vs MuseScoreっていうテーマで，各項目ごとに優劣をつけていきたいと思います。

値段

いわずもがなMuseScoreの圧勝。 Sibeliusは５万円。MuseScoreは無料。

容量

これもMuseScoreの圧勝。 Sibeliusは音にこだわった50GBのサンプル音源！！とか言っているけどPCの空き容量考えたら邪魔で仕方ないです。 しかも音もあまり良くないという。

プレイバックの音

Sibeliusが音源に容量を50GB使っているにもかかわらず，引き分け。 Windows機で比較したらSibeliusの勝ちなんですが，自分はMacユーザーなので音源の良さに優劣付けられるほどの差がないんですよね。 MacはPCに初期搭載の音源が割と良いので。

Sibeliusは50GBも容量を使ってこの音ってことを考えれると容量的にはSibeliusの負けですが，Sibeliusは装飾音符の音が入る位置を選べます。 Museは選べないので，お互い一勝一敗ってことで引き分けにしました。

ていうか音の良さならNotionが一番だと思います。ぼったくりのクソ楽譜作成ソフトだと思ってますけどね。音を別に高い金額出して購入しないと行けないので，ソフト自体は安いんですが結局ぼったくられます。笑
それならSibeliusにvsti足していい音源別で買うよっていう。

楽譜入力

MuseScoreの圧勝。 どちらもMIDI鍵盤からの入力に対応していますが，MuseScoreは入力した音符の長さをPCのキーボードで変えられます。 Sibeliusでは入力する音符の長さを変えるたびにマウス移動してぽちぽちしないといけなかったのが，MuseScoreではキーボードのQボタンとWボタン押すだけ。 これはやばい。作業効率爆上がりです。

あと臨時記号についても作業効率が全然違います。 Sibeliusはマウスでぽちぽちしないといけないけれど，MuseScoreなら入力してから上下ボタンで臨時記号付けられます。

Sibeliusでも上下キーで音符移動できるんですが，いわゆる臨時記号のつかないスケール上の音に勝手に当てはめてくれます。 それが便利なときもあるのですが，臨時記号をマウス使わないと入力できない不便が圧倒的なのでいらない機能です。笑

安定性

互角。MuseScoreのほうが圧倒的に落ちやすいけれど，Sibeliusの方が全体的に重いです。

楽譜の綺麗さ

唯一，Sibeliusの圧勝。 一応商用の楽譜印刷に使えるソフトなわけで，印刷した場合の楽譜の綺麗さは圧倒的にSibeliusが上。 とくにリハーサルマークはMuseScoreはひどいかなって思う。 自分の場合は，普段はMuseScoreで書いて，最後の清書だけはSibeliusに頼るって使い方をしています。

MuseScoreが綺麗な楽譜を印刷できるようになったら，Sibeliusの存在意義が本当になくなるわけで，先行きが不安ですね。 まぁ，有料のソフトに全項目でMuseScoreが互角になってしまったら，謎の圧力がかかってMuseScoreが公開禁止になるかもしれませんが。笑

というわけでこれまでの結果を表にまとめてみました。

--	Sibelius	Musescore
値段	5万円	無料
ソフトの容量	50GB	0.2GB
音質	普通	普通
楽譜入力	可	良い
安定性	重い	不安定
楽譜の綺麗さ	綺麗	普通

感想

三勝一敗一分でMuseScoreの勝ちでした。

やっぱりMuseScoreは強いですね。 無料の楽譜作成ソフトのなかで唯一有料のものと互角に戦えます。 ほかの無料楽譜作成ソフトのScoreCloudとかFinale notepadとか試しましたが，酷い有様でした。

音質に関しては，より良いプレイバックを求めるのなら，生演奏かDTM寄りのソフト（Cubaseとかね）を使うかのどちらかだと思います。 少なくとも現時点では，楽譜作成ソフトのプレイバックはどれも使えた物ではない，というのが正直な感想ですね。

結論として，5万円のSibeliusと互角の能力をもって，かつ無料のMuseScoreはすごすぎると思います。 みんなMuseScoreを使おう！って感じの記事でした。

1000円前後のオリーブオイルを勝手にランキング

勝手にオリーブオイルランキング付けします。 今回対象とするのは250mlで1000円前後のオリーブオイル。

今回比較するのはこの5銘柄だ！

左から順番に，

• 成城石井 有機オリーブオイル
• soramitu 山のオリーバ
• 同 海のオリーバ
• 同 プレミアオーガニック
• alce nelo Dolce

って感じです。

soramituが3銘柄もあってすいません...笑

というわけで比較

素人が勝手に好きなオリーブオイルを順位付けしているだけなので，信じたことによる責任は一切負えません。笑
詰められた時期とかによっても味なんて全然変わってくると思うので，参考程度でよろしくお願いします。

・成城石井

我らが愛する成城石井から。
コクがすごく強いけれども，それが美味しさを殺してないっていうのがすごいなーと思います。
ただコクが強いので，もこみちみたいにドバドバかけるのは向いてなさそう。
スペイン産。

・山のオリーバ

コクが強いので使いどころが限られそうですが，そこそこおいしい。
ただ雑味がすごいあるので積極的には使いたくない感じ。

海と味が全然違うのが面白いですよね。プラシーボか？
ギリシャ産。

・海のオリーバ

いやこれはダメでしょう。 苦みがヤバい。のに美味しさがない。
サイゼリヤのオリーブオイルと良い勝負では？って感じ。薬みたいな味がする。
これもギリシャ。

・プレミアオーガニック

プレミアオーガニックと銘打っているだけあって，おいしいと思います。
味にそんなに特徴がなくて，soramituの他のオリーブオイルの進化系って感じ。
海山と比べて雑味がないので，割と好印象です。
これもギリシャ産。

・アルチェネロ Dolce

有機エキストラバージンオリーブオイル。 原産国はイタリア。

とても雑味がない味です。ピュアというか，尖ってるところがない。
ていうか普通においしい。どんな料理にも合いそう。

アルチェネロのホームページによれば，酸度の平均が0.3~0.4らしいです。 しっかりエキストラバージンオリーブオイルの条件を満たしていますね。
soramituとかはホームページにもこの辺の表記が一切なかったのでその辺どうなの？

というわけでランキング

Dolce > 成城石井 > プレミアオーガニック > 山 >（常用できるか否かの壁）> 海 > サイゼ
って感じですかね。

アルチェネロのDolceがやっぱり一番おいしいと思います。この中では。
サイゼリアのオリーブオイルは，ご自由にお取りくださいにもかかわらずちゃんと美味しいっていうのがすごいと思います。コスパ部門では一位ですね。

Boscoの1200円くらいのやつも今度買う予定なので，色々このページに書き足して行く予定です。

PythonとRuby，始めるならどっち？

2016年の今だからこそ。

昔だったらスクリプト言語やり始めたい場合はPythonかRubyの好きな方を選べって感じでした。 でも現在では，好きな方を選べって返答はたぶん間違いになると思います。 じゃあどっちを選べば良いのかってお話。

どうしてこんな記事を書くのか

自分はRubyが好きです。でもPythonも使ってます。 そのうえで，世の中のPythonとRubyの比較記事ってどちらかに偏ったものが多いな，と思うわけです。

例えば。 Rubyが好きだからPythonにもmap使わせたり(あまり使わない)，Pythonが好きだからRubyにもfor文使わせたり(まず使わない)，そんな例ばかりです。 そんな書き方してたら自分の好きな言語が使いやすいに決まってるじゃないかっていう例を出しているので。

そういうわけであくまで中立を保ってる自分がこういう記事を書いてみたいな，と思ったわけです。

というわけで本題

どっちの言語からやるのが良いか？の返答として，やりたい内容に依る ってことを強く伝えたいです。

自分が両方の言語を使う際は，内容によってはっきりと使い分けています。 例えばWeb系。これは絶対Ruby。 対して機械学習系。これは絶対Python。

RubyでもPythonでもできることはRubyで，PythonでしかできないことをPythonでやってるって感じですかね。
どっちでもできる内容なら，日本語で書かれたWebサイトとかたくさんあるRubyを選ぶので。
そんな感じで使い分けをしています。

Rubyが得意とする分野

Rubyの産みの親が日本人のかたなので，日本語のドキュメントの多さ ではPythonを上回っていると思います。 最新の情報をかなり速い段階で追って行けるっていうのはありがたいです。英語も読めるけど日本語の方が格段に理解が速いので。

元祖WebフレームワークであるRailsが強いので，Web系は今でもRubyが強い印象。 RubyはPythonに比べて遊びの分野で強い印象があります。

Pythonが得意とする分野

主に学術分野です。この分野ではもはやPyhton一強なのではってぐらいPythonが強いです。 数値処理がなんでも高速でできるnumpy，化学計算用のライブラリが詰まったscipy，グラフ描写にmatplotlib，自然言語処理にNLTK，統計処理や機械学習にscikit-learnと学術系ライブラリの豊富さではほか言語の追随を許さないレベル。
Googleが出したDeep learning用のライブラリ(Tensorflow)もPythonですしね。この分野でのPythonの浸透力はかなりのものだと思います。

ていうか学術分野以外でもRubyと同レベルのライブラリが揃ってます。ライブラリの豊富さでは(Rubyも豊富ですが)Rubyを越えている感じ。ただ日本語のドキュメントが少ない。

Python2だと日本語操作で泥沼にはまるって経験を何度もしたので，自然言語処理とかはPython3を使いましょう。RubyでできるならRubyでも。

ランキングから両者を比較

というわけで主要なプログラミング言語ランキング。 こちらのサイトから引用させていただきました。

	IEEE	TIOBE	Devpost	GitHub	RedMonk
1位	Java	Java	HTML/CSS	JavaScript	JavaScript
2位	C	C	JavaScript	Java	Java
3位	C++	C++	Python	Ruby	PHP
4位	Python	C#	Java	PHP	Python
5位	C#	Python	C / C++	Python	C#
6位	R	Objective-C	PHP	CSS	C++
7位	PHP	PHP	Objective-C	C++	Ruby
8位	JavaScript	Visual Basic .NET	C#	C#	CSS
9位	Ruby	JavaScript	Swift	C	C
10位	Matlab	Perl	JSON	HTML	Objective-C

Pythonは常に3位から5位をキープ。対してRubyはGithubでは3位だけれどもTIOBEではランク外だったり。大抵10位前後にいるイメージ。 Pythonは強いだけあるなぁって感じですね。ていうか自分もCとかJavaとか速い言語書けるようになるべきなのかって少し思ってしまう

Python一択では

ここまで見てると日本語ドキュメントがなくても困らない程度に英語が読めるなら正直Python一択なのでは... って感じになってしまうのでRuby好きの自分としてはRubyの株も上げておきたい

Rubyの良いところ

Rubyは「ストレスなくプログラミングを楽しむこと」 を重視して作られた言語だそうです。 ストレスなくプログラムが組める，これめっちゃ重要なポイントじゃないですかね。

Pythonだとエラー取れなくてこのやろうみたいな感じでプログラム組んでますが，Rubyだとエラーに引っかかることがかなり少ないです。 やってる内容もPythonの学術関係の方が難しいことが多いのでPythonのほうがエラー取れなくて当たり前だと思うんですけど，それでもやっぱりRubyのほうが日本人の自分にとっては楽に感じます。

これはプログラミングのモチベーションを維持するのに役立つのではないでしょうか。
日本語のドキュメントが多いことも相まって，ストレスが数倍少ないように感じます(個人差があります)。

あとPythonはもとが格好いい言語なので格好良く書くことを求められるわけでそれで苦労しますが，Rubyは何も考えなくてもそこそこ美しくなる感じもGood。これは偏見かも。

Pythonはfor for for,Rubyはeach map select

Pythonはただひとつの美しいやり方があるってスタンスなのに対して，Rubyは同じことでも色々な方法でできた方が美しいって考え方です。

プログラムをちょっと比較してみます。 Pythonはfor文がかなり強くて，配列操作ならとりあえずforしとけって感じ。Python3は2よりもさらにmap系の非推奨感が増してる感あります。
対してRubyは普段for文なんか使っている人見たことなくて(必要になる場面も稀にあります)，each,map,selectみたいなメソッドを使い分ける感じです。

arr = [2, 6, 3, 8]
for x in list:
  print x
print( [x**2 for x in list] ) # => [4, 36, 9, 64]
print( [x for x in list if x>4] ) # => [6, 8]

arr = [2, 6, 3, 8]
arr.each do |x|
  print x
end
print list.map{|x| x**2} # => [4, 36, 9, 64]
print list.select{|x| x>4} # => [6, 8]

まったく同じ内容を二つの言語で書いてみましたが，決定的に違う点があるのが見つけられますかね？

Pythonは右から左，Rubyは逆

Pythonは右から左に処理が流れることが多いんですけど，Rubyは逆なんですよね。 だから自分はRubyが好きになりました。文章を書くときと同じ感覚で流れるように左から右に書いて行けるので。Pythonだと行ったり来たりして流れるように書けないので思考が中断してしまうんですよね。ここは人の好き好きだと思います。

例えば，さっきの例での比較。
listから一つずつ要素をxとして取り出して，それを一つずつ2乗するっていう処理。

#Python
 [x**2 for x in list] 
#Ruby
list.map{|x| x**2}

PythonとRubyが逆でしょ。思った通りに左から右に書けるRubyが自分には良いなぁって思います。使いやすい。

結論

まぁ結局始めるならPythonなんじゃないですかね。Pythonやっておけば他の言語が必要になることってほぼないのでは？ってくらい何でもできる印象があります。

それでもこの記事読んでてあーRuby良いかもって思った人はRubyだと思います。学術目的やる予定ないんだったらRubyだと思う。最終的にはどっちもやってしまえば良いよ。

やっぱり自分に合ってる方が良いよね，みたいな記事でした。

関連:
名大で一番リア充が入る学部はどこだ？ Project OxfordのEmotion APIを試す

Googleが出した囲碁ソフト「AlphaGo」の論文を翻訳して解説してみる。

RubyとPerl比較: MIDIを読み込んで編集する

MIDIを編集したい。

MIDIをプログラム組んで編集したいなって思ったとき，これまでは過去に英華を極めたPerlでMIDI読み込みをやってました。時代的にPerlが一番強いときにMIDIもかなり流行ったと思うので。
それをRubyでやったら超楽にできちゃったやんっていう話。

とりあえずダイナミクスを可能な限り広げるスクリプトをPerlとRubyで書いてみました。 具体的には，MIDIの内容がベロシティ60-100の間の音しかない場合，それをベロシティ1-127の範囲に広げるって感じのスクリプト。

Perlから。

#!/usr/bin/perl
use MIDI;
use MIDI::Simple;
use MIDI::Score;
use Data::Dumper;
use List::Util qw(max);
use List::Util qw(min);

local $Data::Dumper::Indent = 0;

my $midi = shift;
if( !defined($midi) ) {
  print "ABORTED!\nUsage:\n\$ perl midi.pl something.midi\ninput midi file.";
  die;
}

print $midi;
print "\n";
my @s;
my @channel;
my @v_ch;
my @mtrack;
my $opus = MIDI::Opus->new({ "from_file" => $midi || die });
my $i = 0;
foreach my $t ($opus->tracks) {
  if($t->events_r and @{$t->events_r}) {
    my($score_r, $ticks) = MIDI::Score::events_r_to_score_r( MIDI::Event::copy_structure( $t->events_r )); # event kara score he
    
    @notes = ();
    my $count = 0;
    while ($count < scalar(@$score_r)){
      if(${$score_r}[$count]->[0]=~/note/){
        print ${$score_r}[$count]->[5];
        print "-";
        print ${$score_r}[$count]->[4];
        print "\n";
        push(@notes,${$score_r}[$count]->[5]);
      } 
      $count ++;
    }
    my $min_note = min @notes;
    my $max_note = max @notes;

    $count = 0;
    while ($count < scalar(@$score_r)){
      if(${$score_r}[$count]->[0]=~/note/){
        ${$score_r}[$count]->[5] = 1 + int ((${$score_r}[$count]->[5] - $min_note) * (126/($max_note-$min_note)));
      } 
      $count ++;
    }
      
    my($events_r, $ticks2) = MIDI::Score::score_r_to_events_r(MIDI::Event::copy_structure( $score_r)); # score kara event he
    push @s,$events_r;
    my $x = MIDI::Track->new({ 'events' => $events_r });
    push @v_ch , $x;
    $i++;

    push @ticks, $ticks;
    if(my $time_now) {
      unshift @{$t->events_r}, ['text_event', $time_now, "_"];
    }
  } 

  else {
    DEBUG > 1 and print " * Track is eventless.  Skipping.\n";
  }
  push @out_tracks, $t;
}
push @granularities, $opus->ticks;

print $ticks[3];
my $o = MIDI::Opus->new(
{ 'format' => 1, 'ticks' => 480, 'tracks' => [ @v_ch ] } );
$o->write_to_file( 'output.mid' );

Perlだとこんな感じ。ざっと約80行。 正直Perlはわけわからないので酷い書き方してると思います。笑

これと同じ処理をRubyで書いたら。

require 'midilib'

seq = MIDI::Sequence.new()

File.open(ARGV[0], 'rb') do |file|
    seq.read(file) do |track, num_tracks, i|
        puts "read track #{i} of #{num_tracks}"
    end
end

seq.each do |track|
    notes = track.map{|event| event.velocity if MIDI::NoteEvent === event and event.note}.compact 
    track.each do |event|      
        if MIDI::NoteEvent === event and event.note
            puts event.velocity.to_s + "-" + event.note.to_s
            event.velocity = 1 + ((event.velocity - notes.min) * (126/(notes.max-notes.min))).to_i
        end
    end
end

File.open('output.midi', 'wb') { |file| seq.write(file) }

なんと20行！！びびる

Perlはよく知らないのでもっと行減らせるんだろうなーとは思ってますが，それでも4倍の差がでるのはすごいなーと思います。
まぁPerlやってる人が書いたら20行くらいに行減らせそうですけどね...

というかコードの行数とかどうでも良くて，自分にとっての分かりやすさが段違いです。

MIDIの読み込みでPerl以外の良い方法をこれまで知らなかったのでそのためだけにPerl使ってました。
が，ついにPerlともお別れの時が来たようです。

さようならPerl。君のオブジェクト指向は自分にはわけが分からないよ。

Processing vs D3.js

...ビジュアライジングしたい。

と思ったわけです。現代では直に感覚に訴えかけるようなビジュアライジングが溢れており，自分もやりたいなーと思ってしまうわけです。
そこで誰もが突き当たるのが，どうやってビジュアライズするか 問題。

ビジュアライジングっていわゆる可視化手法で，理解しづらいデータを視覚的に理解しやすい形に再構成することらしいです。
グラフ書くだけならExcelで何も問題ないのですが，やっぱり対話的に作りたいなーと思いますよね。マウスかざしたら詳細が表示されるとか。

てなるとやっぱりプログラム組まないといけないわけです。そしてプログラミングの手法に何を選ぶかってその後の効率にかなり響いてくるのでけっこう大事。

というわけで，代表的な可視化手法であるProcessingとD3.jsのどちらを選ぶか悩んでみました。とりあえずオライリー本は両方あります。比較するしかない。

Processingとは？

ご存知かなり古くからある可視化手法。MITで2001年に生まれたんだっけ？
Javaで記述します。PythonやJSもサポート。

一応processing-rubyってのがあるらしい。Rubyで書いたらprocessing用のJava吐いてくれるやつ。Rubyで書けるって聞くと飛びつきたくなります。笑

Processingのオライリー本が2008年初版なのでさすがに古さを感じます。そして書いてある内容がすごいお堅い。ていうかJavaで説明されるのがつらいなーって感じ。どうせJSかRubyでしか書かないと思うのに。

D3.jsとは？

データ・ドリブン・ドキュメントとかいうのの略語らしい。2011年ぐらいに作られたものだと思います。日本ではそれほど流行ってる印象がないですね。

記述方法はJavaScript一択。D3.js単体では図形を描写する能力すらなくて，HTMLの仕様に組み込まれた他の物(ていうかほぼSVG)を操作して図形を描写します。

D3.jsのオライリー本をProcessingのコントリビュータさんが書いているらしい。ちなみに2014年初版。書いてある内容はめちゃくちゃ面白いです。くだらないギャグが7割り増しらしい。動的型付けの欄はめちゃくちゃ笑いました。
このD3.js入門サイトの内容を大幅に改訂したもの。分量は桁違いに多いです。そして学びやすい。

両者の比較

比較ならとりあえずグーグルトレンドを参照するよね。笑 グラフを見る2013年くらいからD3.jsがProcessingを上回っている感じです。 やっぱり後発のD3.jsのほうが道具としてうまく練られてれているのでしょうか。

ツールの違いとして，Processingはセット一式なんですが，D3.jsは一つのツールのみなんですよね。
例えるなら，Processingはハサミ，のり，トンカチ，定規が揃ったツールボックス。
D3.jsはハサミだけ。あとはHTMLとかJavaScriptとかに丸投げ。この違いは結構大きいと思います。

とりあえずD3.jsを学んでみた

感想としては，良い。 Ruby好きだったら同じようにバリバリメソッドチェインしていけるから最高です。 Processingだったら数行数十行書かないといけないようなプログラムも繋げ続ければ一行で書けてしまう。もちろん見にくいので改行しますが。笑

とりあえずすべての建物を地図上に投影してみたり。東京。

D3.jsはツールの一つであるっていう立ち位置が非常にありがたいですね。Web系だったらある程度触った事あるので，そこにD3.jsっていうものを足すだけで十分なのは学習コストが非常に低くて良いです。それにWeb周りの学習にもなります。

実際自分は，ビジュアライズというよりネット上のベクター画像(SVG)操作用のライブラリとして使っている感が有ります。

ただし，一つできないことがあります。それは光るようなビジュアライズ。 光っているものをPCの画面上で実装する場合は加法混色で実装するのですが，SVGではまともに対応していません。二枚の画像を加法混色で重ねあわせることならできましたが，それ以上のことは自分の力不足かできませんでした。
多分こればかりはProcessingを使わないとできなさそうです。

つっても光らしたり3D描写したりっていうミーハーなことやりたいんだったらThree.jsとか学んだ方が近道かもしれませんが。

結局両方必要になるのでは？

まとめとして，まぁどちらの手法にも一長一短あるんだと思います。両方をある程度学んだ上で，こういうことやるならこっち，っていう選び方が出来るようになりたいなーと。

だから始めるのも自分に合った手法，自分がすんなり受け入れられそうな手法で始めるのが良いと思います。 例えば，Web周り触った事あるんだったら最初に手を出すのはD3.js一択だと思いますね。PHPやRubyでデータベース扱って，それをJSに渡して，ビジュアライジングするっていうのがシームレスにできます。
JavaやPythonの経験があるのならProcessingからってのも良いと思います。細かいところから作り込める伝統ある可視化手法ですし。

自分に合ったやり方から始めるのがやっぱり一番良いですよね。みたいな感じでした。

関連：
名大で一番リア充が入る学部はどこだ？Project Oxfordのemotional APIを試す

全国の道の傾斜マップを作った。

自転車とかで遠くへ行きたい時とか，事前に坂がきつい道とかを知っておけると良いなーって思いませんか。自分はよく思います。

でもそんな時に地図の等高線とか見ても何も役に立たないんですよね。笑

というわけで，全国の道の傾斜を表示する傾斜マップを作りました。Rubyで。

使い方

灰色ー赤色の道が傾斜がきつい道になります。水色は平坦。

きつい坂を登りたくない場合，赤色は避けてください。水色の道はかなり楽に走れます。

「場所を指定して移動」の欄に見たい場所を入力すると，そこへ自動へ移動してくれるようになっています。富士山，長野，みたいな場所を示す単語を入力してください。

スマホ等で表示した場合は現在地を取得するボタンがついています。現在地が取得できた場合，マップが自動で現在地に移動します。

注意

マップの傾斜情報が取得されている範囲ですが，一応全国表示取得しているはずです。
仕組みとしてはGoogleMapに道に色付けするAPIがなかったので，OpenStreetMapの全国の地図情報をサーバー側で持っておいてそれをGoogleMap上に表示するという結構エグいことをやっています。笑

Webサーバーが非常に非力なので，あまりアクセスが集中するとエラー吐かれたりすると思います。

回線が遅い場合でもエラーが頻発するかもしれません。 ただの個人サイトなのでお手柔らかにお願いします。

かなり要求スペック高いので，一昔前のスマホとかだときついかもしれません。推奨はiPhone5s以上，iPad Air 2以上って感じです。
もし需要があったらiOSやAndroidのネイティブアプリでも作る予定です。Webベースより数倍表示が速いだろうし。

というわけで

傾斜マップのページはこちら。->Cymap

無料運用しているため、アクセスした後起動するのに時間がかかります。
快適な自転車ライフをCymapと共に送っていただけたら幸いです。

あと名大周りってこう見ると坂がひどい...笑

画像の座標を取得するアプリ作った(Ruby+sinatra+D3.js+jQuery)

画像の一点をクリックしたら座標を取得してくれるようなそんなアプリがほしかった。

多分ドンピシャなソフトを探すより自分で作った方が速いだろう，と思ったので作りました。

RubyとHTMLを合わせても40行にも満たないミニアプリです。
画像をクリックするとその座標の位置情報をresult.txtに出力します。

require "sinatra"

get "/" do
    erb :index
end

get "/place" do
    File.open("result.text", "a") { |f| f.write params["x"]+"-"+params["y"]+"\n" }
end

__END__

@@index
<!DOCTYPE html>
<html>
<head>
   <meta charset="utf-8">
   <title></title>
   <script type="text/javascript" src="d3.js"></script>
   <script type="text/javascript" src="jquery.min.js"></script>
   <script type="text/javascript">
   var w = window.innerWidth;
   var h = window.innerHeight;
   d3.select('body').append('div').append('svg').attr({'width': w, 'height': h}).append('image')
   .attr({
       'xlink:href': "hoge.png",//表示する画像のディレクトリを指定，public/hoge.pngがhoge.png扱いされるので注意
       width: w,
       height: h,
   });
   d3.select('svg').on("click",function(){
       var x = d3.mouse(this)[0];
       var y = d3.mouse(this)[1];
       $.get("/place?x="+x+"&y="+y);
   })
   </script>
</head>
<body></body>
</html>

出力はこんな感じ。x軸の座標-y軸の座標。

283-214
323-213
346-253
411-253
446-253
512-253
577-253
639-253

使い方

使う人が果たして存在するのだろうか。Ruby環境があればgem install sinatraしてこのRubyファイル実行してください。Publicフォルダにd3.jsとjquery.min.jsを入れるの忘れずに。
取り急ぎ。