Logical Rabbit.

さくらのVPS

備忘

開発作業環境について考えをまとめてみる 2015。

開発作業スペース 兼 プライベートgitリポジトリを新規確保したいのだけど、有料プランでいくつか選択肢があるのでどれにするか検討した次第。

この手のものは定期的に再検討しないと状況が変わってきたりすることと、今後開発業務の副業を本格化していく見込みで、作業スタイルを見直す必要があるため。

目的・用途

  1. 開発作業スペース
    • やりっぱなしにできると便利 = 常時稼働
    • (常時稼働の場合)そこそこ安心感のある自動バックアップ体制
    • とはいえきちんと作業してまめにリポジトリへcommitすれば、作業の区切りで初期化しても問題ないはず
  2. git リポジトリ
    • 常時稼働
    • そこそこ安心感のある自動バックアップ体制
  3. リリース前テスト環境
    • 開発作業スペースから独立したクリーンな環境が望ましい
    • VMで構築して都度初期化したほうが確実かも = VM稼働環境が必要

候補とその利点・欠点

候補 利点 欠点
レンタルサーバー(VPS or クラウド or 物理) 開発環境+gitリポジトリ (初期費用合わせて)1000円くらい/月
自宅サーバー 開発環境+gitリポジトリ+VM稼働環境 初期費用大きい、電気代かかる
githubの有料プラン 比較的安価 開発環境は置けない
Amazon EC2 開発環境+リリース前テスト環境。使わないとき止めておけば安価? EC2止めてもEBS料金は発生。連続稼働だとやはり高め。

試算

2コア、メモリ2GB、50GB ディスク程度を目安とする。1ドル=123円として計算。

候補 試算 備考
さくらのVPS 初期費用1500円+900円/月 2コア、メモリ1GB、HDD 100GB
ConoHa 900円/月 2コア、メモリ1GB、SSD 50GB
GMO VPS クラウド 初期費用4000円+934円/月 3コア、メモリ2GB、HDD 100GB
自宅サーバー 2,000円/月 ハードウェアはあるので電気代
github有料プラン(micro) $7/月 ≒ 861円/月 開発環境は別に必要
Amazon EC2 ( EC2常時稼働 ) $23.04/月 ≒ 2,833円/月 t2.micro + 50GB HDD EBS
Amazon EC2 ( EBSを永続 ) $4/月 ≒ 492円/月 50GB HDD、別途開発環境使用時にはEC2の代金もかかる
Amazon EC2 ( S3にアーカイブ ) $4.75/月 ≒ 585円/月 50GBで計算しているが実際にはもっと少なくなるはず

まとめ (まとまらない)

やっぱりVPSを借りてしまった方が楽か、はたまたそれほど頻繁には使用しないと見越してEC2でやるか、といったところか。しかし頻繁に使用しないなら自宅サーバーで良い気もしてくる。電気代2000円/月は多めに見積もっているので、実際はもっと少ないはずだし。EC2で始めて結局連続稼働時間が長くなったりすると負け確定になる。

リリース前テスト環境は頻繁・長時間使用するものではないはずなので、EC2環境で良いと思う。

技術習得というところから考えると、敢えてEC2+github有料プランというところ。金額的な面で現実的なのはConoHa VPS + github有料プランあたりと結論づけたい。

結局

EC2で毎回初期化・運用環境を整えたほうが検証がやりやすいので、小規模な確認作業はEC2でやるようになってきた。後はいかに手早くかつ手をかけずに必要な環境を整えるか、というところだけど、なんかそういう技術は既にあった気がしている。今のところ手動でも数分で終わるセットアップなので、手を出すには大仰すぎるけど。

2015/07/13 23:56:53 Linux

PHPでライブラリパスを一時追加したい

PHPではrequire_once()は絶対パスを使ったほうがいいらしい。が、取り込んだライブラリ内で別のライブラリをrequireしてる場合、やっぱりinclude_pathをいじっておかないとダメよね、という時のお話。

素直にやるならphp.iniを書くのだけど、これだとインストールされてるPHPの標準的なinclude_path + 自分専用のinclude_pathにできない気がする。追加したいんですがあたしゃ。

<? php
$myLibPath = dirname( __FILE__ ).'/lib/';
ini_set( 'include_path', $myLibPath.':'.ini_get( 'include_path' ) );

# これ以降にrequire()とかを書く
?>

とやっていたら最終的に取り込んだライブラリが「PEAR.phpがないぞゴルァ」と言い出してどっとはらい。だったら最初からpear使えばいいんじゃ… orz

参考サイト; [PHP]require(require_once)するときは必ず絶対パスを使いましょう

2015/07/13 23:53:25 PHP

MediaWiki:: Botのテストが失敗する件 (t/29-get_log.t)

t/18-is_blocked.t とともにエラーになる MediaWiki-Bot-5.006002 の t/29-get_log.t についての調査結果。結果は脱力感全開。

元ソースは以下。

https://github.com/MediaWiki-Bot/MediaWiki-Bot/blob/master/t/29-get_log.t

  • 実行結果として期待する内容(変更ログ)は2件を指定しているが、実行時に「limit=1」を指定しているため最新の1件しか得られない(limit=2とすると期待通りの内容が得られる)
  • 実行結果として得られるログには params という項目があるが、テストとして期待する内容には無いので不一致になる

…paramsが無いというのは、まあ仕様の変更に追いついていないのだろう、とは思うのだけど、なんでlimit=1を指定しておきながら2件の結果を期待しているんだろう…？

2015/05/19 21:57:30 Linux

MediaWiki:: Botのテストが失敗する件 (t/18-is_blocked.t)

依頼されて MediaWiki::Bot 5.006002 をインストール中なわけですが、t/18-is_blocked.tとt/29-get_log.tが自動テストに失敗する。で、まずはt/18-is_blocked.tの調査。

元ソースは以下。

https://github.com/MediaWiki-Bot/MediaWiki-Bot/blob/master/t/18-is_blocked.t

問題の箇所(line 38)は、先行する line 31で決定された$resultの評価をしており、どうやらブロックされたユーザーについてAPIで問い合わせ、「ブロックされているぞ！」という答えを期待しているらしい。

line 31; my $result = $bot->is_blocked('User:Hiwhispees');

しかし、問い合わせに行っている test.wikipedia.org には “Hiwhispees” というユーザーは見当たらず、代わりに “Hiwhispees~testwiki” がいらっしゃる。しかもブロックされて。

…こっちぢゃねぇの…？

MediaWiki::Botのソースを読んで本来呼び出していると思われるURLを特定し、APIをじかにひっぱたいて見ると、やっぱり “Hiwhispees” だと結果が空、"Hiwhispees~testwiki" だと中身がある。

で。

t/18-is_blocked.t のline 31を “Hiwhispees~testwiki” に変えて make test してみたところ、あっさり通りましたとさ。

ぐぬぬ。

2015/05/19 21:55:27 Linux

LWP::Protocol::https の upgradeが失敗する…。

問題が起きているのは、 perl v5.10.1 (*) built for x86_64-linux-thread-multi に同梱されている(たぶん。他の作業でインストールはしていない筈)無印の LWP::Protocol::https を、現時点最新の6.06にアップグレードする際。

自動テストの t/apache.t で、https://www.apache.org/ にアクセスしようとして失敗するらしく、以下のようなエラーとなる。

cpan[1]> upgrade LWP::Protocol::https
(略)
Running make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/apache.t ....... 1/5 
#   Failed test at t/apache.t line 15.

#   Failed test at t/apache.t line 18.
#                   'Can't connect to www.apache.org:443 (certificate verify failed)
# 
# LWP::Protocol::https::Socket: SSL connect attempt failed error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at /usr/local/share/perl5/LWP/Protocol/http.pm line 47.
# '
#     doesn't match '(?-xism:Apache Software Foundation)'
t/apache.t ....... 4/5 # Looks like you failed 2 tests of 5.
t/apache.t ....... Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/5 subtests 
(略)

同じOS上でwget “https://www.apache.org/”すると成功するので、OSレベルでブロックされているわけではなかった。

Google検索してみると他でもエラーが出ているようだし、何より CPAN Testers で結構エラーがでているんですが…。
CPAN Testersのレポート見るとどうやらperlバージョンにかなり依存している様子。他の記事も合わせて考えると、証明書関連のミスマッチかな、という印象も。となると実使用では環境が変わる可能性も高そう。

というか、このライブラリをインストールする主目的の作業では、HTTPS関係ないのじゃ…？とも思えてきた。

ということで、とりあえず t/apache.t のエラーになるテスト箇所をコメントアウトして逃げることにする。

まず cpanコンソールから look でコンパイル環境に入り、テストコードを編集。

cpan[2]> look LWP::Protocol::https

元のソース から

  1. line 13～18までをコメントアウト
  2. line 11 のテスト数を 5 から 3 に変更
  3. line 13で $res を宣言しつつ使用しているので、コメントアウトによってこの変数が初出となる line 24 で宣言するよう($res →my $res)に変更

以上3つの変更を実施(以下は変更後)。

#!perl -w

use strict;
use Test::More;

use LWP::UserAgent;

my $ua = LWP::UserAgent->new();
plan skip_all => "Not online" unless $ua->is_online;

plan tests => 2;
#plan tests => 5;
#
#my $res = $ua->simple_request(HTTP::Request->new(GET => "https://www.apache.org"));
#
#ok($res->is_success);
#my $h = $res->header( 'X-Died' );
#is($h, undef, "no X-Died header");
#like($res->content, qr/Apache Software Foundation/);

# test for RT #81948
my $warn = '';
$SIG{__WARN__} = sub { $warn = shift };
$ua = LWP::UserAgent->new( ssl_opts => {verify_hostname => 0} );
my $res = $ua->simple_request(HTTP::Request->new(GET => "https://www.apache.org"));
ok($res->is_success);
is($warn, '', "no warning seen");

$res->dump(prefix => "# ");

その場でmake testしてパスできることを確認。

# make test
(略)
All tests successful.
Files=2, Tests=58,  2 wallclock secs ( 0.03 usr  0.01 sys +  0.44 cusr  0.04 csys =  0.52 CPU)
Result: PASS

cpanに戻り、改めて upgrade を実行。

cpan[3]> upgrade LWP::Protocol::https

Package namespace         installed    latest  in CPAN file
LWP::Protocol::https          undef      6.06  MSCHILLI/LWP-Protocol-https-6.06.tar.gz
1 installed module has no parsable version number
(use 'o conf show_unparsable_versions 1' to show them)
Running install for module 'LWP::Protocol::https'
Running make for M/MS/MSCHILLI/LWP-Protocol-https-6.06.tar.gz
  Has already been unwrapped into directory /root/.cpan/build/LWP-Protocol-https-6.06-sQInrv
  Has already been made
Running make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/apache.t ....... ok   
t/https_proxy.t .. 1/56 # creating cert for direct.ssl.access
# creating cert for direct.ssl.access
# creating cert for foo
# creating cert for bar
# creating cert for foo
# creating cert for foo
# creating cert for bar
# creating cert for bar
t/https_proxy.t .. ok     
All tests successful.
Files=2, Tests=58,  2 wallclock secs ( 0.03 usr  0.01 sys +  0.53 cusr  0.04 csys =  0.61 CPU)
Result: PASS
  MSCHILLI/LWP-Protocol-https-6.06.tar.gz
  /usr/bin/make test -- OK
Running make install
Prepending /root/.cpan/build/LWP-Protocol-https-6.06-sQInrv/blib/arch /root/.cpan/build/LWP-Protocol-https-6.06-sQInrv/blib/lib to PERL5LIB for 'install'
Installing /usr/local/share/perl5/LWP/Protocol/https.pm
Installing /usr/local/share/man/man3/LWP::Protocol::https.3pm
Appending installation info to /usr/lib64/perl5/perllocal.pod
  MSCHILLI/LWP-Protocol-https-6.06.tar.gz
  /usr/bin/make install  -- OK

cpan[4]>

どっとはらい。

2015/05/19 21:50:40 Linux

cpanでreadlineを使いたい場合

cpanプロンプトでうっかりカーソルキーを押してしまってコントロールコードが入るのが鬱陶しい…というかそのせいで妙な誤動作をしてしまうのが怖いので、readlineに対応できないのかとグーグルさんに伺った所以下の記事が見つかりました。

ReadLine で CPAN を便利に – はちゅにっき

Term::ReadLine::Gnu をインストールすれば幸せになれるようです。

インストール要件

  • ncurses, ncurses-devel, readline, readline-devel

(Term::ReadLine::Gnuをインストールする時点でncurses、readlineは導入済みだったため、必須か否かは未確認です。が、develを入れるなら実行モジュールも入れてしまえばいいと思う)

インストール時のエラーによると、ncursesのほか libtermcap.a でも良いようです。ncurses-develはrubyコンパイル時にも使用するので、こちらを選択しました。

cpan>プロンプトはreadline対応しますが、インストール時の依存性解決で

Shall I follow them and prepend them to the queue of modules we are processing right now? [yes]

と聞いてくるあたりはやっぱりダメみたい。割とここで余計なキー入力してしまうのですが…。

インストールログ

$ sudo yum install ncurses ncurses-devel
$ sudo yum install readline readline-devel
# cpan

cpan[1]> install Term::ReadLine::Gnu
 (省略)
CPAN: File::Temp loaded ok (v0.22)
 (省略)
  CPAN.pm: Going to build H/HA/HAYASHI/Term-ReadLine-Gnu-1.26.tar.gz
 (省略)
Checking if your kit is complete...
Looks good
 (省略)
  HAYASHI/Term-ReadLine-Gnu-1.26.tar.gz
  /usr/bin/make -- OK
Running make test
 (省略)
Result: PASS
  HAYASHI/Term-ReadLine-Gnu-1.26.tar.gz
  /usr/bin/make test -- OK
 (省略)
Running make install
 (省略)
  HAYASHI/Term-ReadLine-Gnu-1.26.tar.gz
  /usr/bin/make install  -- OK
 (省略)
CPAN: Term::ReadLine::Gnu loaded ok (v1.26)
.....................
21 subroutines in Term::ReadLine redefined
2015/04/20 11:25:16 Linux

普段使っているもの (2015年編)

普段使いしているものをお買い物時の備忘の意味も込めて、まとめてみる。どうせなら定期的にやってみようかと。

お仕事的な用品でないものはさらっと流します。

PC関係

  • Logicool K360 〈キーボード)

    今はK360rになってるみたいだけど、どう違うんだろう。見た目としては、天板に謎の模様がある(うちの)、無い(K360r)くらい？

    アイソレーションタイプ、10キーもついたコンパクトめのキーボード。横幅20cm弱。大型のノートPC感覚でしょうか。Excel使ったり私用でゲームやったりする場合、10キーがあるのは重要ですね。打鍵感触もそこそこなので愛用しています。自宅と職場近くのアパート用に2個購入。

    そろそろ自宅用を買い替えたいのと、職場用にもう一つ買おうか、迷ってる。

  • Logicool M560 (マウス)

    割と標準的な形状のマウスです。左右クリックの他ホイールの左右および押し込み、中央にWindowsでアクティブウィンドウ選択になる謎ボタン、左側にWebブラウザで戻る/進むに対応したボタンが2つあります。

    私の作業スタイルとして、マウスは概ね左手になります(利き手は右)。右手は腱鞘炎気味なので、あまり使いたくないのです。なので、多ボタンタイプの場合左手でも操作しやすいことが重要。このマウスは右手用ながら左でも普通に扱えるので気に入っています。

    なお、私の場合右利きで左手操作しているため実際には「右手のふりをする左手」になっているらしく、「左利き用」の機材・設定は使いづらいです。左利きの方はそのあたり踏まえて参考にしてください。

  • Wacom Cintiq 21 UX (液晶タブレット)

    趣味絵描きゆえの装備。第一世代で40万くらいした(汗) 今の世代は20万くらい？安くなったよね…。多分絵描き以外には参考にならないと思うので割愛。画質としては、かなりパッキリして色の違いが出やすいかな。

  • LGエレクトロニクス FLATRON IPS225 (液晶モニタ)

    こちらが普段のメインモニタ。配置的にも、液晶タブレットは倒して使うため普段使いには向かないので。IPS液晶でまぁまぁ見やすいのですが、ちょっと文字がちらつく感じもする。

  • 自組立PC

    実はPentium 4のベアボーンキットのケースだけ流用していたり。メイン作業兼お絵かきPCですが、科学技術計算するわけではなく、3Dをフルに使うわけでもないのでこの程度で充分です。サーバーとしては別に組んだPCがあります。フロントパネルにUSB3.0を増設したのでデータ転送も十分な速度に。

    • ミニタワーケース
    • Core i7 4770
    • メモリ8GB
    • HDD 500GB + 1TB
    • Windows 7 Professional x64)

カメラ

  • パナソニック LUMIX GM1S (ミラーレス一眼レフ)

    年明け初の大物購入、6万円也。とはいえ手持ちの不用品と積みゲームを売り払った結果、現金支払いは2000円くらいだったけど。使い込むのはこれからかな。

  • ニコン D5100 (デジタル一眼レフ)

    自分の中では「本気で撮る」場合の機材。レンズも一番豊富。

  • オリンパス E-PL2 (ミラーレス一眼)

    元々「マイクロフォーサーズのレンズが使いたい」という用途で購入したものなので、LUMIX GM1Sが使い勝手良ければ売却するかも。なんか空の青が気に入らん。赤のE(エルピー)-PL(プル)2 >謎<。

  • Rollei 35S (フィルムカメラ)

    色は黒。某作品に登場する銀色より黒のほうが気に入ったので。別に銀ボディが手に入らなかったからじゃないので。

2015/02/16 12:48:13

alternativesでslaveに指定し忘れた項目があった場合。

特にたくさんの --slave を指定していた場合、一度削除して再登録するのがめんどうくさい。

alternativesシステムの構造を調べて、手動で対策できたのでメモ。

例： ソースコードからインストールしたPostgreSQLを /usr/bin に配置したい。が、pg_ctlを --slave に含め忘れてしまい、postmasterが止まらなくなった orz

(やだなぁ、あくまで例ですよ？)

一連のコマンド群を配置した際の実行パラメータは、次のようになっていた(可読性優先のためコマンドラインオプションごとに改行しています)。

alternatives
 --install /usr/bin/postgres postgresql /usr/local/postgresql-9_3_4/bin/postgres 100
 --slave /usr/bin/postmaster postgresql-postmaster /usr/local/postgresql-9_3_4/bin/postmaster
 --slave /usr/bin/psql postgresql-psql /usr/local/postgresql-9_3_4/bin/psql
 --slave /usr/bin/pg_config postgresql-pg_config /usr/local/postgresql-9_3_4/bin/pg_config
 --slave /usr/bin/pg_dump postgresql-pg_dump /usr/local/postgresql-9_3_4/bin/pg_dump
 --slave /usr/bin/createdb postgresql-createdb /usr/local/postgresql-9_3_4/bin/createdb
 --slave /usr/bin/dropdb postgresql-dropdb /usr/local/postgresql-9_3_4/bin/dropdb
 --slave /usr/bin/initdb postgresql-initdb /usr/local/postgresql-9_3_4/bin/initdb
 --slave /usr/bin/vacuumdb postgresql-vacuumdb /usr/local/postgresql-9_3_4/bin/vacuumdb
 --slave /usr/lib64/postgresql postgresql-lib /usr/local/postgresql-9_3_4/lib

当初はねー、主に使うのはこのあたりのコマンドだけかなー、と思ってたですよ。

この場合のalternativesシステムデータの構造は次のようになっていた。

  1. /usr/bin/postgres (シンボリックリンク) は /etc/alternatives/postgresql を示す
  2. /etc/alternatives/postgresql (シンボリックリンク) は /usr/local/postgresql-9_3_4/bin/postgres (実体) を示す
  3. --slave 指定した /usr/bin/postmaster (シンボリックリンク) は /etc/alternatives/postgresql-postmaster (シンボリックリンク) を示す
  4. /etc/alternatives/postgresql-postmaster (シンボリックリンク) は /usr/local/postgresql-9_3_4/bin/postmaster (実体) を示す
  5. 以後、 --slave 指定のものは同様に /usr/bin (リンク) → /etc/alternatives/<名前> → <パス> のようになる

ここで問題なのが、 --install と --slave の関係性、リンクに指定した優先度の情報はどこに行ったのか?、という点。特に優先度の情報が見えていない。

これらは /var/lib/alternatives に --install に指定した <名前> というファイル名で保存されていた。

/var/lib/alternatives/postgresql の内容は次のようになっている。

$ cat /var/lib/alternatives/postgresql 
auto
/usr/bin/postgres
postgresql-postmaster
/usr/bin/postmaster
postgresql-psql
/usr/bin/psql
postgresql-pg_config
/usr/bin/pg_config
postgresql-pg_dump
/usr/bin/pg_dump
postgresql-createdb
/usr/bin/createdb
postgresql-dropdb
/usr/bin/dropdb
postgresql-initdb
/usr/bin/initdb
postgresql-vacuumdb
/usr/bin/vacuumdb
postgresql-lib
/usr/lib64/postgresql

/usr/local/postgresql-9_3_4/bin/postgres
100
/usr/local/postgresql-9_3_4/bin/postmaster
/usr/local/postgresql-9_3_4/bin/psql
/usr/local/postgresql-9_3_4/bin/pg_config
/usr/local/postgresql-9_3_4/bin/pg_dump
/usr/local/postgresql-9_3_4/bin/createdb
/usr/local/postgresql-9_3_4/bin/dropdb
/usr/local/postgresql-9_3_4/bin/initdb
/usr/local/postgresql-9_3_4/bin/vacuumdb
/usr/local/postgresql-9_3_4/lib

1行目の auto …はまあ今回無視するとして、2行目に --install で指定した<リンク>、3行目以降に --slave で指定した <リンク>と<名前>が1行ずつ列挙されている。

また、一連の列挙の後1行空けて、 --install で指定した <パス>、<優先度>、 --slave で指定した <パス> が1行ずつ列挙されている。

ということで、指定し忘れた項目(この場合 pg_ctl )を手動で追加するには、次の手順となる。

  1. /var/lib/alternatives/postgresql の上段(1行目～空行まで)の末尾に以下を追記
    postgresql-pg_ctl
/usr/local/postgresql-9_3_4/bin/pg_ctl
  2. /etc/alternatives/postgresql-pg_ctl という名前で usr/local/postgresql-9_3_4/bin/pg_ctl へのシンボリックリンクを作成
  3. /usr/bin/pg_ctl という名前で /etc/alternatives/postgresql-pg_ctl へのシンボリックリンクを作成
  4. alternatives —display postgresql で手動追加が反映されたことを確認(以下、結果)
    $ alternatives --display postgresql
postgresql -ステータスは自動です。
リンクは現在 /usr/local/postgresql-9_3_4/bin/postgres を指しています。
/usr/local/postgresql-9_3_4/bin/postgres - 優先項目 100
 スレーブ postgresql-postmaster: /usr/local/postgresql-9_3_4/bin/postmaster
 スレーブ postgresql-psql: /usr/local/postgresql-9_3_4/bin/psql
 スレーブ postgresql-pg_config: /usr/local/postgresql-9_3_4/bin/pg_config
 スレーブ postgresql-pg_dump: /usr/local/postgresql-9_3_4/bin/pg_dump
 スレーブ postgresql-createdb: /usr/local/postgresql-9_3_4/bin/createdb
 スレーブ postgresql-dropdb: /usr/local/postgresql-9_3_4/bin/dropdb
 スレーブ postgresql-initdb: /usr/local/postgresql-9_3_4/bin/initdb
 スレーブ postgresql-vacuumdb: /usr/local/postgresql-9_3_4/bin/vacuumdb
 スレーブ postgresql-lib: /usr/local/postgresql-9_3_4/lib
 スレーブ postgresql-pg_ctl: /usr/local/postgresql-9_3_4/bin/pg_ctl
現在の「最適」バージョンは /usr/local/postgresql-9_3_4/bin/postgres です。

…いやぁ、あくまで例デスよ？(汗)

2015/01/10 18:08:48 Linux

地図APIについて調べた(日本地図限定)

キャラサミ とかもあって、地図に紐づいたデータ表示とかの技術を習得しておくのが良いんじゃないかとおもい、特に日本地図の上に独自のデータをマッピングできるAPIの現状について調べてみた。

利用にあたっての要求事項

  1. 日本地図に特化、もしくは日本地図を扱いやすいこと
  2. APIの利用手続きが煩雑でないこと(オンラインサインアップが理想)
  3. JavaScriptから呼び出せること
  4. 同一コードでPCと携帯機器両方に対応できると良い
  5. できれば無料、もしくは趣味で利用することが負担にならない程度の安価

候補

  1. “日本 地図 API”でググり、さらに期間を1年以内に
  2. めぼしいものをチェック、取捨選択

10候補/5ページ目までチェックした結果、以下4つくらいしか名前が上がってこない感。各制限事項などは2014年11月21日現在のもの。

  1. Google maps API
    • APIの発行ページにGoogleアカウントでログインし、発行手続きを行う
    • アプリケーションの Maps API 使用量が使用制限を超過した場合、API キーを使用して Maps API を読み込み、追加割り当てを購入する必要がある。使用制限は地図の読み込みを1 日あたり最大 25,000 回を90日連続超過した場合。
      • 使用制限の適用は営利目的のウェブサイトの場合のみで、非営利目的の場合Googleに申請、認められれば無償で Google Maps API for Business ライセンスが供与される
    • 日本語のチュートリアルあり。APIの発行は英語のみ？
  2. Yahoo!地図 Yahoo! JavaScriptマップAPI
    • Yahoo! JAPAN IDを取得し、その後アプリケーションIDを登録
    • 1つのYahoo! JAPAN IDにつき、無料APIアプリケーションIDは10個まで、1アプリケーションIDごとに1日50000リクエストが上限
    • 非商用(対価を受ける目的でソフトウエアまたは開発ソフトウエアを自ら利用し、または第三者に利用させることを禁止)、商用ライセンスあり
    • APIのチュートリアルは日本語でソレ自体は分かりやすいのだけど、よけいな情報が多すぎて見辛い印象が。なぜ雨雲レーダーにそこまでこだわるのか。
  3. ゼンリン地図API
    • 実質的にGoogle maps APIってことでしょうか。細かい規約は違う可能性があるけど、動くシステムは同一っぽいので調査終了。
  4. MapFan API
    • 完全商用らしい。「低コスト年間48万円から」等と表記されている。そもそもサイトが法人むけだし。

予想通りと言えばそれまでだけど、やはりGoogleかYahoo!になる様子。「日本」特化というのはどちらも無しかな。どちらもアカウントはあるので、後はAPIキー発行してもらえば良いはずね。まずはこの辺りから始めてみましょうか。

2014/11/21 14:51:09 Web API

USB3.0が相性問題っぽい原因でアクセス不能になったとき。

xhci-hcd モジュールをアンロードしてからロードすれば回復するっぽい。ちぃ覚えた。

具体的には CentOS 6.5 でのお話。USB3.0 は後付けの玄人志向 USB3.0R-P2H2-PCIE。Groovyの UD-3000SA でHDDを繋いだあたりで期限を損ねてしまい、以後は他の接続実績のあるUSB HDDを接続しても認識しない状態に。

OSリセットすべし、という情報もあったけど、それは何か負けのような気がする…というか別のプロセスで長時間かかる md5sum チェックをしていたのでリセットするわけにもいかず。どーせ何かを再起動すればいけるんじゃね?　と色々あさった結論。

最初は usb_storage を再読み込みさせたけど、反応が変わらなかった。dmesgのエラーログを見ると、どうやらHUBあたりがエラーを起こしているっぽい。ていうかM/BのUSB2.0ポートは普通にUSBメモリとか認識するので、 usb_storage は悪くない、らしい。

usb_storage より下層の(ハード寄りの)部分ってなんだっけ？　と漁った結果、uhciとかohciとかそのあたりよね、と。それっぽい名前を lsmod で探したところ、 xhci-hcd が見つかった。

"xhci-hcd" の正体を確認すべくググると、正体どころか "Bug 717633 - USB3.0 harddisk not working with xhci_hcd module " なんて記事が出てきたので、内容読むまでもなくあぁこれぢゃね、等と。

再読み込みにあたり念のためアンロードしたけど、USBまわりなのでアンロードと同時にUSBキーボードとか色々使用不能に陥る可能性を危惧(作業はssh接続してたけど)。予め sudo -v で認証も突破した上で、連続実行するように仕向ける。

$ sudo modprobe -r xhci-hcd ; sudo modprobe xhci-hcd

その後 dmesg 見たら認識しなかったUSB HDDも無事認識してマウントできるようになってた。

2014/10/30 22:08:00 Linux