2015/12/06

艦これのSSを撮影するPythonスクリプト書いた。

タイトルの通り。
いままでTwitter等でSSを公開するとき、プリントスクリーンでスクリーンショットを撮り、それをペイントに貼り付けてトリミングしていた。
だがいちいちそれをやるのは面倒くさい、ということでpythonで一発でやれるようにしようや、というのが動機になる。

以下コード。

# coding:utf-8
# Project_SS

from  StringIO  import  StringIO
import win32clipboard as cb
from PIL.BmpImagePlugin  import  DibImageFile
import sys

cb.OpenClipboard()
if not cb.IsClipboardFormatAvailable(cb.CF_DIB):
    print u'クリップボードに画像がありません。'
    sys.exit()
imgData = cb.GetClipboardData(cb.CF_DIB)
imgFile = StringIO(imgData)
img = DibImageFile(imgFile)
box= (560, 187, 1360, 667) #ブラウザの画面中艦これ部分の座標の指定。解像度によるのかな?
output_img = img.crop(box)
output_img.save('[保存する画像のパス。任意で指定。]','JPEG')

まずはこちらを参考にさせていただき、クリップボードの画像を取得するコードを書いてみた。ところが「from BmpImagePlugin import DibImageFile」の部分でエラーが出る。Pythonで何か書こうとするとimportでまず躓くのは仕様か。

というわけでGoogle先生を使って探索するとこちらを発見。どうやら「PIL.」をつければいいらしい。

更にプリントスクリーンによるスクリーンショット(つまり画面全体)から艦これ部分をトリミングすべく、検索。そしてここにたどり着いたので、組み合わせてみる。
艦これ部分の座標取得のためにMPP Utilityを使った。これはコード内にコメントで書いたように、解像度によって違うのかもしれない。もし上のコードでうまくいかなければ、MPP Utilityで艦これ部分の左上(x1,y1)、右下の座標(x2,y2)を取得し、box=(x1,y1, x2,y2)と指定すればOKだ。

今後の発展方向としては、取得した艦これ部分の画像をmatplotlibか何かで表示して、更に一部分だけをトリミングできるようにする、とかできたらいいなあ、と思っている。
ただし、思っているだけでやるとは言っていない。使ってみてそういう機能が欲しいと思えばやるし、思わなければやらない。予想だが、多分やらないんだろう。

2015/11/30

「火星カレー」に行ってきた。

前々から行きたかった池袋のカレー屋「火星カレー」に行ってきた。横浜から池袋は遠い。他に用事がないとなかなか池袋まで顔を出そうとはなりにくい。横浜というのは中途半端になんでもできてしまうから、私のような引きこもり気質の人間はなかなか多摩川を渡らなくなってしまう。

さて、この「火星カレー」を何で知ったかというと、オーナーが「ぼくのなつやすみ」の開発者だからだ。知っただけで行きたいとは思わないが、なかなか個性的なカレーということで興味を持った。カレーの肉に鹿や馬、カンガルーなんかも選べる。

残念ながら私は外食時に飯を撮影する趣味はあまりないので、肝心のカレーの画像はない。「火星カレー」と、目の前にある機械で調べれば色々と情報が出てくるだろう。加えて更に残念なことに、料理に詳しいわけでもないのでその詳細について語ることもできない。これもまた目の前の機械で調べていただければと思う。

何が言いたかったかというと、おいしいからオススメです、ということと、また池袋近くまで行くことがあれば行ってみようかな、ということだ。

2015/11/24

緩やかに死んでいく田舎の鉄道路線

JR北海道の来春80本減便方針 沿線自治体 現状維持、望む声強く

JR北海道は来年3月のダイヤ改正で普通列車約80本を減便(区間短縮を含む)する方針で、対象列車の沿線自治体に利用状況などを説明し、理解を求めている。大幅な減便となる路線の沿線では現状維持を求める声が強い一方で、「やむを得ない」と諦めも広がりつつある。減便と引き換えに、JRに地元の観光振興への協力を求める“条件闘争”の動きも出始めている。

(中略)

減便に対する自治体からの反発は強い。「地方の足を守るのがJRの役割。(減便は)絶対反対だ」。空知管内新十津川町の熊田義信町長はこう語気を強め、JRの姿勢を批判した。同町は、札沼線の終着駅の新十津川駅を観光振興に生かしていく考えだったが、同駅発着の列車が現在の1日3往復から1往復に減ることが伝えられ、戸惑いを隠さない。

JR北海道の来春80本減便方針 沿線自治体 現状維持、望む声強く

いよいよJR北海道の合理化が本格的に始まろうとしている。本業で赤字を垂れ流しつつもなあなあでここまできたわけだが、事故が多発したことでついに赤字の元凶にメスが入れられることになったようだ。遅すぎる、と言えばそれまでなのではあるが。減便の他にも一部の駅の廃止、無人化、廃線など、これからどんどん合理化は進んでいくだろう。私が以前住んでいた場所の近く(北海道基準)の駅も、無人駅になるんだとか。(元地元民から言うとあの駅、駅員いたんだ…というのが正直な感想ではある。)

「減便しまーす」、と言われるとその地域はだいたい反対する。それが自然だとも思うが、よく考えると反対の理由は一体何なのだろうか。新十津川町の町長は「地元の足」と言う。じゃあどれくらいの人が使ってるんだよ、と調べると学園都市線の北海道医療大学以北の輸送密度は2013年度で81人だという。いくら周辺自治体の人口が少ないからと言ってもこの値で「地元の足」というのは無理があるだろう。ついでに言わせてもらうと、学園都市線の末端部沿線は周辺住民が日常的に使うような施設もあまりない。せいぜい高校がいくつかあるくらいだったはずだ。高齢者が使う病院も学園都市線沿線にはなく、並行する函館本線沿線に多少ある程度だ。だいたい、地元の足として路線を守れ、と言う割に観光振興に活かしたいという時点で、地元の足それ単体として路線を成立させられないことを自ら白状しているようなものだろう。

学園都市線といえば、私が小学生の頃から「廃止されそう」と言われ続けてきた。それでも、711系がしぶとく近年まで現役だったように、どう考えても(文字通り小学生が見ても)儲かっていなさそうな路線は今日も運行を続けている。それもだいたい「地域の足」の名の下である。だがよく考えるとおかしい、JR北海道は最早国鉄ではなく、民間企業だからだ。こう言うと、だいたい「JRは民間企業とはいえども、鉄道という社会インフラを維持する責任が~」などという話になる。現実的にJR北の株主は独法だし、それも一理あるといえば一理ある。その「責任」のもとにあぐらをかきつづけ、赤字だけどまあなんとか路線は存続するんだろうと楽観していた周辺自治体の考えは甘かったと言わざるをえない。JR北海道自身がその責任を自負するのはいいが、それを赤字垂れ流し地域が主張するのは、ちとおこがましいと言わざるをえないだろう。

これまで見逃されていたのにここにきて廃止になるのは、一連の不祥事の余波というのもそうだが、車両の老朽化も関わっているようだ。鉄道車両は高い。既存の赤字路線の設備、車両を保守するだけならまだしも、新たな投資をして車両を投入するのは現実的ではない。JR東日本だったら儲かっている首都圏に新車を投入してその玉突きでボロを田舎に回しただろうが、残念ながらJR北海道が儲かっている路線で、地方でも使えるディーゼル車はほとんど走っていない。詰みである。

繰り返しになるが、自治体の読みが甘かった。車両はその辺に勝手に生えてくるようなものではない。そのことを考慮に入れず、今までなんとかなっていたからこれからもどうにかなるだろうと高をくくり、いざどうやら危うくなってきたぞと認識したときに(そもそもその時点では危うくなってきたどころか最早虫の息なのではあるが)慌てて「観光資源として活かそうと思っていたのに!」なんて言うのは、おもちゃを片付けるのを先延ばしにして母親に怒られるガキと大差ない。

観光といえば、廃止報道があって「秘境駅を観光資源にしようと思ってたのに!」と言っていた小幌駅だが、あちらは豊浦町がその維持費を負担することで存続できないか模索しているらしい。(「秘境駅」小幌駅 管理費10年で3千万円 豊浦町にJR見通し)10年間で3000万円。歳入の半分を地方交付税交付金で賄う地方の自治体が果たして払える額なのか。豊浦町は鉄道ファンの寄付やふるさと納税で賄えないか考えているようだ。確かに、この手のことに関して鉄道ファンは金払いが良い。廃車となった車両の保存に寄付を募ったら平気で数百万円集まったりする。

ただ、廃車の保存であれば最初にまとまったお金が必要になり、その後は保守管理に少々掛かる程度で済むが、小幌駅を存続させようとするなら、毎十年3000万円必要になる。最初はどうにかなっても、その後どうにかできる保証はない、というか無理そう。更に言うと、小幌駅を存続させたとして、鉄道ファンがその秘境っぷりを見に訪れたとして、十中八九豊浦町の経済には何の利益ももたらさない。彼らは鉄道で秘境駅を訪れ、そして鉄道で帰っていくだけだからだ。じゃあ駅でグッズ販売でもする?それ、「秘境駅」に対する冒涜じゃないですかね。

こうなってくるともう、何のために「観光資源」として駅を残そうとしているのか意味がわからない。寄付を募って足が出た部分は町民の税金でなんとかするんだろうか。でもそれは町の経済にメリットはほぼ無いし、秘境駅たる小幌駅は新十津川町のように「地元の足」ともならない。周りは樹海、家はないからだ。ちなみに道路もない。

「何のために駅を残したいのか」「何のために鉄道路線を残したいのか」、その問いに対する答えは何なのか。「地元の足」?利用者ほとんどいませんけど。「観光資源」?ほとんどメリットなさそうなんですが…

もう、ただの意地にしか見えない。「おらが村に鉄道を」の精神である。そのためにJR北海道に尻拭いさせ続けた結果が今の状況である。それでも数少ない利用者のために残すべき、という論理は国鉄ならどうにかなったかもしれないが、JRに対しては弱い。各所で言われるように、国鉄の分割民営化の時点で(そして北海道を単独で分割した時点で)この未来は確定していたとしか言いようが無い。

数少ない利用者の交通の便を確保しようとするなら、誰かしらがその尻拭いをしなければならない。ただそれをJRに押し付けることはもうできないし、間違っているだろう。ほんとうに必要なら自治体でコミュニティバスでも運行すればいい話なのだ。

そしてこれは笑い事ではない、明日は我が身だ。日本全体で人口は減り続け、首都圏でさえ未来の鉄道需要は減少しているはず。いざ廃止されそうになって大騒ぎするなんて愚かな真似をすることのないよう、やれることはさっさとやり始めたほうが良い。

2015/11/03

試される以前に広すぎた大地

北海道新幹線の時短効果は
函館市民が鉄道を利用して東京まで行く場合、現在は特急列車と東北新幹線を乗り継いで5時間半から6時間程度かかる。北海道新幹線新函館北斗~東京間は最速4時間程度となるが、函館~新函館北斗間はアクセス列車で約17分かかる見込みのため、これを合わせた函館駅から東京駅までの所要時間は4時間半程度と推測される。これにより、北海道新幹線開業による函館~東京間の時短効果は1時間から1時間半程度になるとみられる。
北海道新幹線利用で新函館北斗~東京間2万2,690円、函館市民の"生の声"は?

東京→新函館北斗、4時間!w

盛り上がってるところすまんのだが、普通に時間かかりすぎだろうと思うのは私だけだろうか。時短効果は一時間半くらいで、北陸新幹線(東京→金沢)と同じくらいだが、元が4時間近いところから1時間半減って2時間半になった北陸新幹線、元が5時間半だったのが4時間になる北海道新幹線、時短効果をパーセンテージで見ればその差が明らかになってしまう。

時短効果を考えるとき、その効用は単純な線形にはならないということにまず気づく。北陸新幹線だと、開業によって金沢日帰りが射程に入る時間になった。宿泊を余儀なくされていた状態が、日帰りを視野に入れられるようになる、この効果は大きい。一方東京函館4時間半、往復9時間では日帰りは厳しい。函館山にも登れないだろう(そもそも昼間登る人はそういなさそうではある)。結局日帰りできないなら、(東京の立場に立てば)1時間半程度の時短は焼け石に水である。

前ブログで、北海道の鉄道網は全て札幌に集結しているという記事を書いたことがあった。何が言いたいかというと(現実的に東京から釧路に行く時に札幌まで鉄道でやってきて、そこから更に鉄道で釧路を目指すなんてことはあり得ないだろうということはさておき)、結局函館延伸では何の意味もないということである。札幌まで伸ばさないと意味が無い、というか、札幌延伸も意味があるのか怪しいが、函館で止めるよりは遥かにマシと言いたい。現状、新函館北斗まで4時間で行けたとして、新函館北斗から札幌には既存の特急で3時間は掛かる。東北新幹線の始発を6時として、それが新函館北斗まで直通する最速タイプの列車だとしても、札幌に着くのは13時になる。札幌でラーメンを食おうと意気込んでいても途中で腹が減って駅弁でも食っているレベルである。

これが札幌まで延伸したとして、どれくらい時短効果があるのか。ちょっと検索したが「ガチれば札幌まで3時間台も余裕」みたいな噴飯物の夢物語を語っていた頃の記事ばかりヒットしてディスプレイが米粒だらけになってしまった。いろいろ計算するのも面倒なのでしないが、函館まで4時間かかる予測が出ている現状、札幌まで延びてもそう時短効果は生まれないのではなかろうか。上述の「ガチれば」も、青函トンネルというボトルネックを解消し、かつ函館以北を限りなく直線的にすればワンチャンあるかもしれないが、そう簡単にいかないだろう。そもそも青函トンネルをどうにかできてない結果が函館4時間なのである。

何が言いたいかというと、北海道は広い、ということだ。だからこそ新千歳羽田線はドル箱路線と言われ、そして道内都市間移動で普通に航空機を利用するビジネスマンが一定数いるという現状を生むのである。新幹線程度じゃどうにもできないくらい広いのである。新幹線開業直後はまあいいが、その後利用者数がどの程度になるのかが恐ろしい。鍵を握るのは函館日帰りが可能になる東北からの観光、あるいはその逆だろう。

(というか、「新函館」か「函館北斗」か「北斗函館」で揉めまくった挙句「新函館北斗」とかいうわけのわからない駅名にまとめ上げるレベルの北の大地に新幹線はまだ早いんじゃないでしょうか…)なお在来線は遅すぎた模様

2015/10/08

FIFA16をプレイして思う、サッカーゲームの在り方

FIFA 16 (北米版)が昨日ようやく届いた。去年も北米版を購入し、その時はアソビットシティの通販で頼んだのだが、今年はアソビットの改修だかなんだかで取り扱いがなく、プレイアジアで頼んだ。アソビットは確か発売日当日か翌日には手元に届いたように思うが、プレアジは香港からということを差し引いても発送までに掛かる時間が長く、結局日本版発売前日の昨日まで到着がもつれ込んだ。

体験版からやっていて感じていたことではあるが、わたしはどちらかというとFIFA15のほうが楽しめた。某掲示板のスレッドを見ると好評のほうが多く、その理由としては「FIFA15はゴリ押しのドリブルが強すぎて萎える。その点FIFA16はパスを受ける向きを考えて~(中略) しっかり崩さないとゴールが決まらないけど、そこがリアルで良い。」というものが見られた。

わたしはむしろ、どちらかというと「ゲームなんだから、多少殴り合いのバカ試合になったほうが爽快感があっていい」という立場なのだ。いかにもにわかサッカーファンだろう。ただ、前述の「リアルさ」を追求する意見を頭から否定する気はない。むしろ、この論点はサッカーゲームというか、スポーツゲームの在り方という重要なトピックに関するものだと思う。

ゲームは疑いなく、リアルさの追求に向かって進んでいる。グラフィック然り、操作然りである。FIFA16はここにきて、ゲーム性というか、試合展開そのもののリアルさが追求されたとも言える。FIFA15では特にディフェンスのAIがガバガバすぎて数分間の試合でさえバカ試合になることが多々あった。それに対する、あんなにするするドリブルで抜けたりスルーパスが簡単に通るわけもなかろう、という意見も理解できる。そしてそういう声が大きかったからか、FIFA16はディフェンスのAIが強化され、ドリブルで抜くのは難しくなり、スルーパスは簡単にカットされるようになった。

そもそも、サッカーの試合を見ればわかるが、パスやドリブルでガッツリ崩してシュートまで持ち込む展開というのはそうは見られない。だいたい序盤は両チームともポゼッションを重視しつつパスを前に入れては戻し、入れては戻し、クロスを放り込んでみたりしながら試合が進んでいく。そして1点目はだいたい、クロスやらFKやらDFの不用意なロスト、強引さ漂うミドルシュートやそのこぼれ球への反応だったりする。そして失点した方は前がかりになり、先制したチームは有利に試合を進めていくわけだ。

こうして考えると、FIFA16はめちゃくちゃリアルな展開といえると思う。ここまでCPUと何度かやったが、得点の決まり方は放り込んでみたらうまくCFが押しこんだり、ダイブっぽい転びによるPKだったり、適当に蹴ってみたミドルだったりする。そして、スコアレスドローの試合のほうが多かった。

これがこの前、結局2-1でギリギリ勝利した試合のわたしのゴールシーンである。1点目は思いの外相手の寄せが早く苦し紛れに放り込んだアーリー気味のクロスにレヴァンドフスキが反応したもの、2点目は遠目からのフリーキックだ。1点目はカウンター気味ではあるが、FIFA15のときのようなダイナミックなカウンターには到底及ばない(下に参考動画)

なるほど、リアルになってめでたしめでたし、とはならない。コレはゲームなのである。そもそも、スコアレスドローだらけの試合のサッカーゲームが面白いゲームと言える…のか?

これは「サッカーゲームをどう捉えるか」ということと関連すると思う。リアルさを重視したい人はシミュレーションとして、ゴールを決める爽快さを重視したい人は『ゲーム』として、それぞれ捉えているのだろう。この問題は今後サッカーゲームが発売され続ける中で常に問われ続ける問題なのではなかろうか。そして、それは大学受験の倍率の年ごとの振れ幅のように行ったり来たりするような気がしてならない。

余談。キャリアモードを始める前に単発の試合でFIFA16の試合展開に慣れたいなあ、と思いながら練習している。今年のキャリアモードはシャルケかバイエルンでやろうかなあ、と思っている。FIFA16は15のプレミアリーグに加え、ブンデスもかなりリアルになっているからだ。

フォーメーションはいろいろ試してはいるが、敵AIのパスカット能力が凄まじくなりビルドアップにすら苦労している現状、中盤に人数をかけられる3-5-2あたりを考えているが、3バックだと失点の可能性が増えて困っている。あとはサイドからのクロス放り込みを考えるなら4-3-3も捨てがたい。個人的には偽9番をおく4-3-3が好みである。

そしてキャリモをやるときにはミドルシュートが得意な選手を積極的に獲得して中盤に配置したいなあ、とぼんやり。

2015/09/25

映画『心が叫びたがってるんだ。』を見に行った

 アニメ「あの日見た花の名前を僕達はまだ知らない」の制作陣が結集して作った新作ということで前々から気にはなっていて、いよいよ公開されて見に行こうかと思っていたが映画館が微妙な遠さのためグズグズしていたが、ちょうど艦これがメンテで遠征に張り付く必要もなかったので雨の中見に行ってきました。

 最後に映画館に行ったのがおそらく「PLANET OF THE APES/猿の惑星」以来なので実に14年ぶりの映画館ということになる。映画って意外と高いじゃないか。こんなことなら円盤発売まで待ってレンタルすれば…などと一瞬余計なことを考えつつ着席。公開初日でもないのでさすがにガラガラだった。雨が降っていたというのもあるだろう。

 さて内容だが、映画館という環境の影響もあろうが、それを差し引いても久しぶりにアニメにのめり込んだような気がした。普段は朝飯食べつつ艦これの演習やりつつ横目でアニメを眺め、そして糞アニメの烙印を押すような毎日、正直30分ですら飽きつつ惰性で見ているアニメのほうが多いまであったが、2時間ちょっとだろうか、最初から最後まで没頭していた。
 ストーリーはベタベタの青春もので、今までならあまりの現実感のなさに鼻で笑って済ませていたかもしれないが、今回はいい話だと思った。歳取ったのかもしらん。一方でアニプレックス(SME傘下)配給ということもあってか何故か主題歌が乃木坂46だったり(普通にメインの声優の歌でよかったんだよなあ)、主人公のスマホがどうもXperiaっぽかったり(ガラケーはさすがにSO機種か確認できなかった)と、変なところでも大人の事情を察して楽しんでしまった。
 とは言ってもストーリーは手放しでいい話と言い切れるし、音楽も素晴らしいというのが感想。特に2曲を絡ませるところ(見ればわかる)は鳥肌モノだった。四月は君の嘘といい響けユーフォニアムといい、音楽が主要要素に絡んでくるアニメはハズレがないな…

 音楽が良いってことで、「心が叫びたがってるんだ。」オリジナルサウンドトラックにちょっと興味が出てきた。最近レンタルばかりだったが、久しぶりにCDを買ってみてもいいかもしれない。

 いや、ほんといい話だった。

2015/09/20

TGS2015に行ってきた

 2013、2014につづいて今年もTGSに行ってきた。

 今年は今までより本気を出し、先行入場できるサポーターズクラブチケットを購入。去年は横浜から出来る限り早く行ったものの、一般チケットだったために整理券配布列に到着するまでにPSVR(当時の呼称はMorpheus)の整理券はなくなってしまった。そして悟った。これ以上早く入場するにはサポチケを購入するしかないと。よって、今年は10時から夕方までずっと購入ガイダンスの電話に掛け続けてなんとか日曜日のサポチケをゲットしたのだった。
 というわけで今年の最重要ターゲットはPSVR。到着し入場の整理券を受け取ると400番代。入場後真っ先にソニーブースに向かうと既にPSVRの待機列には人だかりができており、並んだ直後に待機列形成が打ち切られてギリギリセーフとなった。PSVR整理券は339番だかそれくらい。朝から並んでいた人のほとんどはPSVR目当てだったと言えるのかもしれない。

 待機列に並んだはいいものの、結局試遊の予約ができたのは11時を過ぎていた。入場から2時間近く経っている。既に腰が悲鳴を上げている。去年も確か腰が痛み、待機中に使うように小さい折りたたみ椅子を買おう買おう思っていたのだが、喉元すぎればなんとやらということだろうか、別にそこまでしなくていいやと同じミスを繰り返したのだった。
 試遊の時間は12時半からだが、PSVR試遊予約の待機をしている間に他の試遊タイトルの整理券配布が軒並み終わってしまった。並べるものでも120分待ち等々、これに並ぶとPSVRの試遊に間に合わないのでサクッと昼飯を食べてPSVRの試遊まで時間を潰すことにした。

 PSVRの試遊タイトルは、一番やりたかったサマーレッスンはあっさりと埋まってしまったので初音ミクのVRライブなんとかかんとか、みたいなやつにした。PSMoveという棒状のコントローラーを持ってサイリウムのようにして使う。係のおねーさんには「周りの目を気にせず盛り上がってください」と言われたが、元々私には恥の概念など存在しないので言われるまでもないのである。一人で勝手にひじょーに盛り上がった。外から見たらさぞかし滑稽だったことだろう。
 去年はOculusでも同じようなライブを見るタイトルを体験したが、多分今回のPSVRのほうが画質が良いんじゃないか、と感じた。と言っても1年の間に記憶は薄れているし、Oculusも1年の間に進化したんだろうし、なんとも言えない。それにしても、サマーレッスンだけやたら予約終了が早かったことを考えると、PSVR試遊目当てで来た人の大半はサマーレッスン目当てだったのだろう。なら全機材サマーレッスンに回せばええやんけ、と思うがそうもいかんのでしょう、大人の世界は。
 サマーレッスンのほうは、係のおねーさんいわく例の金髪のキャラは全部英語で話しかけてくるとかなんとか。それを聞いて思ったのだが、VRを使って美少女キャラと英会話するゲームで英語の発音鍛えるとかいけるんじゃないだろうか。SiriやAndroidのアレとかCortanaとか、英語の音声認識技術は結構成熟してるように思うので案外現実的なんじゃなかろうか。と書いてて思ったがバンナム(サマーレッスン製作チーム)の技術じゃないな…

 PSVRの試遊を終え、次の目当てはGOD EATER RESURRECTION(リザレクションのスペルわからなくてググった)。ソニーブースの試遊は列形成が一時打ち切りになっていたので、バンナムブースへ。こちらもPS4列は打ち切りになっていたので、しかたなくVita版の試遊を選択。待ち時間90分と掲示されていたが、本当にそうなるのか待ち行列理論を使って計算しようとするも、公式を忘れたのと私が並び始めた直後にこちらもVita版も列形成が打ち切りになったので計算はできなかった。

 GER試遊を終えた時点で14時。閉場は17時。他の試遊に並ぶとどれも2時間は掛かる。閉場時間までいると帰りの電車が地獄になるので少々早いが撤退することにした。帰り際に豊洲駅に寄ってSHARPのシースルーディスプレイの実証実験を見てきた。

 それにしても今年のTGSは人が多い。2013・2014もすごかったが、さすがに通路で身動きが取れなくなるほどではなかった。シルバーウィークということもあってかキャリーケースを持って来ている人も結構いたように思う。
 と思って調べたが2013年のほうが多かったらしい。これも喉元すぎればなんとやら、だろう。

 とりあえず、折りたたみの椅子買おう…

2015/08/09

センスの無い私みたいな人のための「色」の選び方と使ったツール

私は美術関連のセンスがない。
正確に言うと色を選ぶセンスが無かった。小学校のスケッチでは、下書きまでは割とうまく描けていたのだが、色を塗った途端ダメになる。
いくら下書きがうまくても出来上がりがヘタクソではつまらないから、私の美術への関心は急速に萎んでいった。

「美術なんて何の役にも立たん」などと言っていたのは懐かしい思い出だが、実際のところ、「色」の知識はかなり役に立つと思う。ブログやホームページを作っていればなおさらだ。
どんなに作成を補助するツールがあっても、結局色を選んだりするのは私自身なのだ。

このブログを作った時も色で少し悩んだのだが、いい機会だと思い少し色について学んでみることにして色々調べると、ひとつものすごくわかりやすく、役に立つ資料を見つけた。
それが色彩センスのいらない配色講座だ。

「色彩センスのいらない配色」なのだから、私のようにセンスが死滅してどっかに言ってしまった人間でもやれる、ということになるし、「デザインの効果を理論的に説明」しようとしていらっしゃるそうである。
理論的。いい言葉だ。「センス悪い」の一言でぶった切ってくれた理論の欠片もない昔の同級生とは大違いである。思い出したら少しイライラしてきたぞ。絶対に許さないリストに追加してやろう。

話を戻そう。この講座をもとにしてものぐさブルーライト AppsPortalのCSSをいじることにした。

まずメインカラーだが、私が最近好きな色「烏羽色(#180614)」をチョイス。明度も低いしちょうどよいだろう。

次にベースカラーだ。「メインカラーの明度を上げた色」を調べるために0to255を使った。「烏羽色(#180614)」の明度を上げた「#fefbfe」を使った。
明度を上げすぎてほぼ白になって意味がないような気もしたが、ベースカラーの選択肢には白もあるし、気にしないことにした。

最後にアクセントカラー。メインカラーから離れた色相とは即ち補色であるらしいから、「烏羽色(#180614)」の補色を調べることにした。
これには補色作成ツール。を使い、「#E7F9EB」が補色であることがわかったので、これをアクセントカラーとした。

さて、こうして前ブログのテンプレいじりでは死ぬほど悩んだ色選びも割とすんなりと終えることができた。ちょっとメインカラーとアクセントカラーの割合が少ない気もするが、無理に色を付ける必要もあるまい。

色彩センスのいらない配色講座の作者のまりっぺ先生は「社会に出たらデザインの話が通じなさすぎて悶絶」とおっしゃっているが、それは残念だが当然だ。
この色の話も、学校の美術では一切習っていない。結局のところ、美術の先生は生まれながらにして「センスがある」人たちであって、それを「理論として」教える力に欠けている人が多い。(美術だけでなく、実技教科はそういう人多いよね。)
ひたすらスケッチだかデッサンだかの練習をさせられても、「理論的な」アドバイスがないから「センスのない」私のような人間は上達するはずもないのだ。

だったら、せめて役に立ち、かつ理論的に教えやすそうな色の話でもしてくれたほうが遥かに有意義な教科になっただろうになあ、と思うと残念でならない。
美術という教科では「センス」を「理論」として教えるようになることを切に望むばかりだ。

2015/07/30

Venue 8 ProにWindows10をインストールした。

「Windows10を入手する」で予約したがなかなかアップデート準備完了の通知が来ないので、しびれを切らしてMS公式サイトでツールを入手してアップデートした。isoファイルをUSBやDVDに焼いたりもできるみたいだが、Win7/8.1ならこのツールで直接アップデートできて非常に便利。ただ、bitの選択などはできないので、そのあたりを弄りたい人はisoを焼く必要があるかもしれない。(環境に応じたbitのOSを勝手にインストールするのか、Win7/8.1と同じbitのものをインストールするのか不明。)

とりあえずメインのノートPCはアップデートせずに、外出時に使っているVenue8ProにWindows10を入れてみたが、起動も早いし、スタートメニューもあるしでなかなか使いやすい。
Edgeもマイクロソフト製のブラウザとは思えないサクサクさで好感が持てる(もっとも、それ以外のところがどうなのかはまだわからないが。)

ドライバ関連の異常もぱっと見では見当たらないが、しばらく探り探り使ってみたい。

2015/07/18

既存動画から『タイムラプス』を作る方法を考える。

 タイムラプス、というものをご存知だろうか。口で説明するより実際に見ていただいたほうがわかりやすいと思うので、参考動画をYoutubeで見つけてきた。

 タイムラプスの基本は「コマを落とす」ということだ。普通の映像は1/30秒なり1/24秒なりに1回画像を撮影し、それをつなぎあわせる。この撮影間隔をより長く取ることで、上の参考動画のようにスピード感のある動画を撮影することができる。

 「タイムラプス 作り方」などと検索すると、カメラを固定して一定間隔で撮影して、それをつなぎあわせて動画にする、などという記事が山ほど出てくる。
 調べているうちに気づいたのだが、「タイムラプス」という言葉はどうもひとり歩きしているようだ。本来、一定間隔で撮影した写真を動画にしたものを指すようだが、動画のコマを落とす(実質的には早送り)ものもタイムラプスと呼称している例も見られる。「タイムラプス」って、一体何なんだ。

 そんな折、Microsoft Hyperlapseなるものが登場したので、もうこれしかないと思って早速試したのだが、このソフトのウリはアクションカムなどで撮影された映像を滑らかにタイムラプスにする、というものらしい。厳密にはタイムラプスとは違うのかもしれないが、これも上記のリンク先では「タイムラプス」とされている。

 というわけで、深いことは考えずに、動画のコマを落としてタイムラプス(っぽいもの)を作ってみることにした。
 まずは動画を1コマずつ画像で出力する。みんな大好きAviUtlの連番BMP出力を使うことにした。この時ポイントがある。それはタイムラプスの特徴につながることなのだが、タイムラプスは「コマ落とし」、つまり、何コマかに1コマを取り出し、それを動画にすればいい、ということになる。要は、すべてのコマを使うのではない。何コマかに1コマだけ必要になる。よって、BMP出力する段階でコマを減らして処理時間の短縮を試みる。この時使うのはAviUtlのフレームレートの変換機能だ。これでフレームレートを1/3にすれば、3コマに1コマだけをBMPで出力することになる。

 何故早送りに編集するのではなくBMPを出力したかというと、理由は2つある。ひとつは、AviUtlは(別途プラグインを用意しなければ)最大1/3にまでしかフレームレートを落とせないから。これではタイムラプスというより、どちらかというと「カクカク」の印象を受ける。もう少しコマを落としたほうがいいと思ったからだ。そしてふたつめは、一度画像を出力することで、一定間隔の画像を動画にするという本来のタイムラプスの定義に近い編集方法を取るようになることで、タイムラプスと言い張りやすくなるからだ。
 手元にはAviUtlで出力した数千コマのBMPファイルがある。数千というと多く感じるが、それでも元動画のコマ数の1/3になっている。このうち20枚に1枚のみ取り出し、元動画比で1/60のコマ落としを行うことにする。当然、数千枚の連番画像のうち、20の倍数番目以外のものを削除すればいいのだが、それを手作業でやる気にはならない。この処理にはPythonでスクリプトを書いた。

# coding:utf-8
# Project_LAPSE


import os
import shutil

#元画像保存フォルダ入力要求
path = raw_input("連番画像保存フォルダのパスを入力してください--->".encode("shift_jis"))

#フォルダ内のファイル名(連番BMPのファイル名)をリスト(files)に代入
files = os.listdir(path)


#リストに格納されたファイル名のうち、20の倍数番目の物のみを別のリスト(outputlist)へ代入
outputlist = []
for i in range(len(files)):
    if i%20 == 0:
        outputlist.append(files[i])

#連番BMPが保存されているフォルダに「output」フォルダを作成
os.chdir(path)
os.mkdir("output")

#outputlistに格納されているファイル名の画像を取得し、outputフォルダに出力
for f in outputlist:
    print f
    src = os.path.join(path,f)
    dst = os.path.join(path,"output")
    shutil.copy(src, dst)
 ざっとこんな感じだ。Pythonは嫌いだが、色々機能があって便利なことは間違いない。嫌いだけど。

 これで、元動画の60フレームごとの画像を取得できたことになる。(もちろん、フレームレート変換とpythonでの処理の組み合わせで他のフレームごと、例えば80フレームごとの画像を取得することもできる。)
 これをつなげて動画にするのだが、AviUtlは連番画像を一括で取り込めるらしいので、この機能を使うことにする。
 今outputフォルダには「00001.bmp」「000020.bmp」…のようなファイルがあるので、これを「00001.bmp」「00002.bmp」という連番に変えなければならない。本当はPythonでその処理もすればよかったし、できないこともないのだが、面倒なのでFlexible Renamerを使ってみた。
 あとはこちらの記事の④AviUtlを使い動画に変換するの方法で動画を出力することができた。

 この方法で出来上がったのが

これ。結構気に入っている。
 しかし、少し画質が落ちているような気もする。連番BMP出力時に画質が落ちたのか、それを再度動画にしてエンコードした際に画質が落ちたのか、それともYoutubeで再エンコードされて画質が落ちたのか、どのタイミングが原因なのかわからない。もう少し色々試してみたいと思う。  折角スクリプトまで書いたし、GTAもただミッションやるだけではなくタイムラプスに丁度いい景色でも探してぶらついてみるのもいいかもしれない。

2015/07/07

FIFA16に望むこと

E3でFIFA16の情報が出てきた。まだイメージムービーといった感じだが、gamescomあたりでより詳しい情報が出てくるのではないかと思う。

昨年FIFA14をはじめて、9月にはFIFA15北米版を購入し1年近く遊んできて、面白いゲームだと思うのだが一方で不満点もいくつかある。FIFA16発売後にその点が改善されているのか自分でチェックするためのメモとして整理しておきたいと思う。

ディフェンスのAI
よく言われるがAIの動きが意味不明なことが多々ある。キャリアモード(選手)では、味方のDFがパスを出せるにも関わらず自陣でこねくり回しクリアし相手にスローインを献上することばかり。チーム全体を動かすモードではCBが釣られて出てくる。ボールホルダーにプレスを掛けるのはいいのだが、肝心なところでマークを外すのはやめてほしい。

キーパーのAI
ニアのぶち抜きに弱すぎるというのもあるのだが、逆に言うと1VS1状態でのそれ(ニア)以外のシュート反応がよすぎ。結局1VS1ではニアに流しこむか、一度ボディフェイントで横に逃げるかしかない。
一方で、エリアのギリギリ外からのミドルシュートに弱すぎる。特に敵がレジェンドCPUだと、どう考えてもミドルを決めるタイプではないような選手までそこから打ってくる。CBが釣り出されないように気をつけてエリア内を固めてもミドルがポンポン入れられるようでは意味が無い。

キャリモ(選手)、FKとPK蹴らせろ
選手モードのチャレンジ解除が、FKを全然蹴らせてくれないので進まない。リアリティのためなのかもしれないが、FKもPKもCKも、全部蹴らせてくれてもいいじゃない。ゲームなんだから。

キャリモ(選手)、複数ポジションの適正が欲しい
最初にポジションを選ぶとそこ以外に使われない。同時に複数のポジションをこなせるユーティリティープレイヤーとまではいかなくても、プレイスタイルに合わせてコンバートとかできたら面白いと思う。

Jリーグはいらないけど、日本代表を収録して欲しい
Jリーグは興味ないのでいいのだが、キャリアモードで日本人にすると、日本代表が収録されていないので代表戦に出られないのがつらい。女子サッカー収録とかする前に代表くらいカバーして欲しい。

CLのライセンス
今年もKONAMIがCLのライセンスを取ったみたいなニュースを見たので絶望的だが、「チャンピオンズカップ」ではなく「チャンピオンズリーグ」をやりたい。あのアンセムをゲーム内で聴きたいんだけどなあ…

とまあ、色々文句をつけつつも絶対FIFA16は買うので楽しみにしている。DFのAIは改善されるような話を聞いたが、逆に言うと自分が点を取りにくくなるわけで、そのバランスがどうなっているのかとても楽しみだ。

2015/06/23

Lumia 640 レビュー(2) ワードフロー入力

スマホの文字入力といえば、やはり主流は「スワイプ」だろうと思う。AndroidにせよiPhoneにせよ、ガラケーの文字入力のように同じキーを何度も叩くことなく文字を入力でき、素早い入力が可能だからだ。

実はWindowsPhoneにはその上をいく文字入力方法が存在した。まずはこの動画を見ていただきたい。(英語で何を言っているかわからないかもしれないが、映像だけで何がすごいかわかるはずだ。)

これが「ワードフロー入力」である。基本はスワイプと変わらず画面上に指を滑らせるのだが、それをQWERTY配列で行えるのが良い。
本当にこんなにスムーズに入力できるのか、こんな流れるように画面に指を滑らせたら隣のキーが反応したりしてしまうのではないか、と思いLumia640で試したのだが、かなりの精度で入力することができた。
恐らく、予測変換機能で何を入力しようとしているのかを予測していることで、正しいキーに反応しやすくなっているのだろう。

実際、

これを入力してみようとしたのだが、「Hana」がうまく反応しなかった。英語に「Hana」という単語がないからだろうと思う。

残念ながら、現状では日本語入力には対応していないようだ。Windows 10 Mobileでは日本語対応されないかなあ、と密かに期待している。
(ところで、上の動画で間違いなく「Emoji」と言っているように聞こえるのだが、いつの間に「絵文字」は英語圏でも通じるようになっていたのだろう。)

2015/06/06

Lumia 640 レビュー(1) 液晶保護フィルム

Lumia640が届いてから一週間弱(記事初稿執筆時)、色々いじっているうちに思うところがいくつか出てきたので、レビューという形で記事にしていきたいと思う。

スマートフォンやゲーム機を買ったらまずすることは何か。人によるかも知れないが、液晶保護フィルムを貼る人は多いだろう。私もPSVitaを買った時にも、SH-07Eを買った時にも液晶保護フィルムを買って、貼った。
しかし貧乏性の私は、液晶保護フィルムやらケースへの出費が地味に痛くてしかたがなかったのだ。モノによっては1000円くらいしたりする。よって、安さに惹かれて買ったMeMOPadには液晶保護フィルムを貼らなかった。今回購入した端末も、ミドルレンジ端末ということもあり、落として画面が割れたらそれまでだろうくらいに考えて、本体購入時には液晶保護フィルムを買わなかった。
しかし、到着して使ってみると、スワイプの際の指の引っ掛かりがどうも気になってしまった。今までipod touch 5G、SH-07Eとスマホ(系)端末を使ってきたが、ダントツで滑りが悪い。(SH-07Eのタッチ精度は論外なのだが、それでも滑りはいい。)
しばらく使えば指が慣れるかと思ったが、どうにもストレスがたまるので滑りが良さそうな液晶保護フィルムを買うことにした。
外に出たくないのでAmazonで物色した結果、ELECOMスマートフォン用液晶保護フィルム 汎用 エアーレス スムースタッチ光沢5.0インチ(P-50FLSAG)を購入した。
Lumia 640は日本で広く売られているわけではないので、当然専用の保護フィルムの品揃えも少ない。一応専用の物もあったが、高かったり評価が悪かったり、ちょうど良さそうなものがなく、汎用のフィルムでサイズがちょうどいいものを探すことにした。そこで見つけたのが上述のELECOMの汎用保護フィルムだ。
1つ目のポイントはサイズで、Amazonのページには61mm×103mmと表記されている(2015年5月15日現在)が、ELECOM公式サイトを見ればわかるように、正しくは64mm×112mmであり、このサイズでLumia640の液晶部分にほぼフィットする。
そして2つ目のポイントは「スムースタッチ」で、滑りを良くするために買う商品としてはよさそうだと感じたし、実際貼ったところ保護フィルム無しのときよりは滑りがよい。
汎用品ということもありそこそこ安く、サイズはぴったり滑りもいい。結構良いチョイスだったと自画自賛している。

2015/05/28

PS4の動画編集ソフト「ShareFactory」の実力と課題

スクリーンショットをTwitterやFacebookにアップロードしたり、動画をキャプチャして直接Youtubeにアップしたり、TwitchやUstreamで生放送したり。
PS4が前世代機と何が一番変わったのか、と言われたら、やはりこの「シェア機能」なのではないかと思う。

あまり話題になることがないが、シェア機能を影で支える「ShareFactory」なる編集ソフトがある。 動画をゲーム機でキャプチャできるということにも驚いたが、それを編集までできるようになるなどとPS3時代に予想した人は果たしていただろうか。

例えばこれ。

これはShareFactoryで編集したものだ。 動画の切り貼り、フェードといった基本的な機能に加え、テロップをつけることもできる。 他にも色々と機能はあり(図形を挿入できるのが、オンラインで他人のIDをマスクしたりするときに役に立ちそう)、さすがにAviUtlといったソフトのレベルにまでは達していないが、イメージ的にはWindowsムービーメーカーくらいのことはできる、といったところである。

ゲーム機での動画編集としては高いレベルにあるのだが、ひとつ不満がある。それは「2つの『動画の時間』」だ。

1つは、出力する動画の時間。どういうわけかShareFactoryは15分以内の動画しか出力できない。キャプチャーも1回最大15分なので、それと足並みを揃えているのかもしれないが、もう少し長くてもいいのではないか、と思ってしまう。

そして2つ目は、編集段階での動画の時間。「読み込める動画の最大時間」と言ったほうがわかりやすいかもしれない。ShareFactoryは編集時に合計40本かつ20分以内までしか読み込めない。これが編集上のボトルネックになっている。

というのも、一つ目で挙げたように、1回の動画キャプチャは15分まで、つまり動画ファイル一つは最長で15分だ。15分の動画ファイルが2つあり、それをShareFactoryで結合し、ひとつの動画にしようと考えてみる。しかし、2つのファイルで合計時間が30分となり、読み込むことができないのだ。最終的な出力が15分以内なので、20分読み込めればそれでいいだろうということなのかもしれないが、一度に読み込んでいらないところを削っていく、ということがしにくい。せめて、最長動画2本+α、40分くらいは読み込めるようにしていただけるとありがたいなあ、と思っている。

USBメモリ経由でPCに動画ファイルを移せるので、本格的に編集したければPCでやれ、ということなのかもしれないが、著作権的にグレーな部分が多い中で「いや、全部PS4でやれているんですよ」というのは意外と強力な“言い訳”になると感じているので、個人的にはPS4で編集を完結させたいと思っていて、それがひとつのテーマにもなっている。なかなか注目を浴びないソフトウェアだが、密かにアップデートを期待している。

2015/05/23

Google Apps Scriptによるメール自動返信botの作成(2)

同(1)では受信トレイから未読メールを取得し、それが受送信用アドレスからのメールアドレスであることを確認するとcondirmBody関数を実行するようにした。この記事はそのconfirmBody関数を作成するところから続ける。
関数名は「Body(本文)を確認する」という意味にしたく、「確認する 英語」と検索をかけて出てきたのが「confirm」だったのでそうしたのだが、よく考えたらconfirmは確認するという意味でも、どちらかというと「認める」のような意味が強いのでそぐわないようにも思うが、今さら関数名が記述される部分をすべて書き直すのも面倒なのでとりあえずメール返信botのプログラムの中ではconfirmで統一する。今後同じようなシチュエーションがあれば「check○○」にでもしようかと思う。英語って難しい。

confirmBody関数では、引数のメッセージの本文を取得しその内容を確認する。そしてその内容に応じて返信内容を決め、それに応じた関数を起動するようにする。
今回の記事では、メッセージ本文の文字列に「おはよ」が含まれていれば、それにふさわしい返信をする関数(GoodMorning関数)を起動するようにする。

function confirmBody(m){
  var body = m.getBody();
  if(body.indexOf('おはよ',0)!=-1){
    GoodMorning();
  }
}
使用した機能:getBody() - Class GmailMessage - Apps Script - Google Developers
 引数のメッセージmについて、getBodyでその本文を取得できる。ここでは変数bodyに代入している。
 そして、前回も使用したindexOf関数で「おはよ」が含まれればif文内の処理を実行し、GoodMorning関数を起動するようにしている。

function GoodMorning(){
  var to = '受送信に使うアドレス';
  var title = 'Re:';
  var body = '任意の本文';
  var opt = new Object();
  opt.name = 'botからのメールで表示される送信者名'
  opt.replyTo = 'bot用のメールアドレス';
  GmailApp.sendEmail(to,title,body,opt);
}
使用した関数:sendEmail(recipient, subject, body, options) – Class MailApp - Apps Script - Google Developers
続いてGoodMorning関数である。使用した関数はsendEmail関数で、この関数の第1引数はメールの送信先、第2引数はメールのタイトル、第3引数は本文、第4引数はオプションだ。第1~第3引数では文字通りだが、第4引数はname(送信されるメールで表記される送信者名)、replyTo(返信する際の送信先)を保持するオブジェクトだ。これらを引数としてsendEmail関数を実行すると、引数で指定した通りのメールが送信される。

そして最後に、前回記事で作成した未読メール確認関数を自動的に、一定間隔で実行するようにする。
上部のメニューからリソース→現在のプロジェクトトリガーを選択し、新しいトリガーを追加のリンクをクリック。左からconfirmUnRead、時間主導型と選択肢、残り2つのセレクトボックスで実行する間隔を選択すれば良い。
これで設定した間隔ごとに未読メールがあるか確認するようになる。

たったこれだけのコードで、しょぼいなりにメールを自動返信できるようになった。もっとも、今後返信パターンを増やした際、複数のパターンにヒットする本文がある場合どうするか、などの課題はある。
また、GoogleAppsScriptはメールだけでなく、Googleの様々なサービスにアクセスできる。ただ昔をなぞるようにメールの自動返信botを作り始めたが、もう少し実用性のあるものも作れそうだ。例えばカレンダーに接続して、予定がある日の朝にメールを送信するようにする、といったこともおそらく可能だ。今後、このbotを発展させる形で色々と機能を追加して遊んでみたい。

2015/05/18

文系な私がいかに基本情報技術者試験の勉強をしたのか

さて、平成27年度春期の基本情報技術者試験の合格発表があり、私も無事合格することができた。自己採点で多少の自信はあったが、やはり実際に結果を見てようやく安心した、といったところだ。

同じく文系で基本情報技術者試験を受けようとする人の役に少しでも立てるように、この記事では文系である私の基本情報技術者試験合格までの道のりをまとめようと思う。

もっとも、文系だからどうだ、という部分(も無いわけではないが)はほとんどないので、基本情報技術者試験に興味がある人なら誰でも参考になるように書きたい(書くとは言ってない)。

Sponsored Link

そもそも文系で基本情報技術者試験に合格できるのか

結論から言うと全然大丈夫.「情報技術者」というとテクノロジー寄りの色が強いように見えるが,必ずしもそういうわけではない.

例えば「コアコンピタンス」という言葉が出てくることがあったが,これは完全に経営学分野.他にもプロマネだのサービスマネジメントだの戦略だの,むしろ社会科学系と親和性の高い分野は存在する.

従って選択問題では基本的にそうした分野で点を稼いでいく.その上で技術よりのところでも点を取る.そもそも満点を取らないといけない試験ではないので,得意なところと苦手なところでトントンになっていれば良いわけである.

まあ,合格したから言えるって話だけどね.

使用した参考書(記事編集時最新版)まとめ

午前問題対策

私が使ったのはこれ(リンクは記事編集時最新版).正直ある程度人気のある書籍数種類の中であればどれを選んでも大差はなさそう.実際本屋で立ち読みしてフィーリングが合ったものを買えば良いと思う.

Java(午後選択)

そもそもプログラミングを学ぶきっかけにしたいと思って基本情報技術者を受けたのでJavaを選んだ.プログラミングに興味が無いなら表計算とかを選べば良いと思う.

Javaの文法的なところはこの2冊がバイブル.マジでわかりやすいのでおすすめである.プログラミングに全く触ったことのなかった私だが,この本でプログラミングの基礎の基礎を学べた.

試験のテクニック的なのはこの本を使った.

午後問題の前半の選択はどれを選ぶべきか

「プロジェクトマネジメント」「サービスマネジメント」「システム戦略」「経営戦略・企業と法務」にあたる問6、問7あたりは文系でも取っ付き易い、というよりむしろ我ら文系のテリトリーだ。理系の方々はこの分野が苦手で、積極的にこれらを捨てにかかるらしい。

4問選択なのであと2つだが、「ソフトウェア設計」(問5)は割と解きやすい。残り1つは「ハードウェア」「ソフトウェア」「データベース」「ネットワーク」から選ぶことになるが、そこはそれぞれの適正に合わせて、としか言いようがない。

データベースは少し勉強すれば得点源になるような雰囲気はあったので、余裕がある人はそれがいいかもしれない。私はデータベースにまで手を付ける余裕がなかったので、まずDBを切って、残りの問題の難しそうな問題を切る、という消去法を選んだ。

勉強期間・時間

「期間」を試験の何ヶ月前に勉強を始めたのか、という意味ならばそれは1年ということになる。ただしこれはJavaの勉強にかけた時間のほうが長い.

プログラミング言語(Java)以外の勉強を始めたのは試験の2ヶ月ほど前だ。勉強3日に2回、1回あたり2時間くらいのペースだったと思う。つまりプログラミング言語を除けば勉強時間は40時間かそこらだろう。

プログラミング言語のほうはかなり長期、数ヶ月間に渡って勉強したが、こちらは週末にそれぞれ1,2時間ずつくらいのペースだった。あまりに長期間に、散発的になりすぎて勉強時間はわからないが、上に挙げた参考書をそれぞれ1週するくらいの勉強量、ということは確かだ。

勉強方法

午前・午後ともに参考書→過去問の流れ。特に午前問題は過去試験からの流用が数多くあるので、たくさん解けば解くほどいい。


いわゆる文系でIT系に就職したい!と思っているなら,実務の役に立つかはともかくとして,自分の適性を確かめるきっかけとして,勉強をはじめるきっかけとして,そしてある程度勉強し,かつ適性があることを示す証拠として有用かなと思う.

2015/05/13

スマホサイズで、Windows8.1が動く端末

 富士通株式会社は、5月14日から開催される「富士通フォーラム 2015」で、Windows 8.1を搭載する5.54型端末を参考出展する。
 あくまで参考出展であり、実際に製品化された場合の仕様とは異なるが、参考展示機の主な仕様は、5.54型フルHD(1,920×1,080ドット)液晶ディスプレイ、CPUに"最新世代"Atomプロセッサ、メモリ2GB、ストレージに32GB eMMC、OSに英語版Windows 8.1を搭載。外部インターフェイスはmicroSDカードスロット、Micro HDMI、Micro USBなど。重さは280g。ロックフリーのSIMカードスロットを搭載し、MVNO SIMなどを使用してモバイルネットワークへの接続も可能であるという。
富士通、フルWindows 8.1搭載の5.54型スマホ型端末を開発 ~最新世代AtomとフルHD液晶搭載で280g - PC Watchより引用

結構面白そうな端末ではないだろうか。もし一般向けに発売されれば、スマホサイズでありながらフルサイズのWindowsが載るのであり、当然Flashも使えるわけで、色々捗るのは間違いないだろう。

ただし、これはWindows8.1よりは今年中には出そうなWindows10のほうが相性が良さそうな気もする。現状ではWindowsストアアプリは品揃え豊富とは言えないし、この画面サイズで解像度がHDとなるとタッチやスマホに最適化されたソフトでないと使いにくい気もする。 一方Win10ユニバーサルアプリであれば、フルサイズのWindows上でスマホアプリっぽくソフトウェアを使うことができるし、外部ディスプレイやキーボード、マウスと接続すれば普通のパソコンとして使うこともできるだろう。

一方で気になるのがWindows10のシステム要件。マイクロソフトは8インチを境界にして、8インチ以上をWindows10(for PC)、8インチ未満のものをWindows10 for Phones and tablets、と分けるようだ。
例外として業務用端末では8インチ未満の端末でもfor PCが使えるようになるものがあるのではないか、という観測もある。今回の富士通の端末も企業向けのようだし、その流れでWindows10へのアップグレードがあり得るかもしれない。

一般消費者向けにも是非スマホサイズのWindows10 for PC端末が出て欲しいのだが、果たしてどうなるか。個人的には台湾あたりのメーカーがしれっと開発しそうな気もしているが、どうなるだろう。

2015/05/11

Google Apps Scriptによるメール自動返信botの作成(1)

自分語りで一記事余計に使ってしまったため、この記事が本編となる。

前提
  • 自動返信のプログラムにはGoogle Apps Scriptを用いる。
  • 返信内容のパターンは自分で考える
  • この記事では本文に「おはよ」が含まれ、かつ特定のアドレスからのメールに対して予め決められた内容を返信するプログラムを作る
必要なもの
  • 自動返信bot用のGoogleアカウント
  • bot用とは別のメールアドレス(Gmailでなくてもよい)

さて、さっそく実際のプログラミングに移ろう。まず今回使用する「Google Apps Script」を使用できるようにする。
まずはGoogleドライブへ入り、新規→その他→「アプリを追加」を選択。検索フォームに「Google Apps Script」と入力し、検索する。恐らく一番上に出てくるであろう「Google Apps Script」の右側にある「接続」をクリック。
そしてドライブの最初の画面に戻り、再び新規→その他と進むと、「Google Apps Script」(以下、GAS)が出現しているはずである。これをクリックする。
クリックするとGASのメニューが表示されるので「空のプロジェクト」をクリックする。新しくプロジェクトが作成されるので、ここにメールの返信スクリプトを書いていくことになる。

さて、実際のプログラミングに移る前に、処理の内容を検討する。

  1. 受信トレイからメールを取得する
  2. 取得したメールが未読かを確認する
  3. 未読であればメールの差出人を確認し、自分が送ったメールアドレスか確かめる
  4. 自分が送信したものであれば、本文を読み込む
  5. 本文に、決められたパターンと合致する文言があるか(今回では「おはよ」)確認する
  6. パターンと合致した場合、そのパターンにふさわしい内容の返信メールを作成し、送信する。

これらの機能ごとに関数を作成していくことにする。

1.受信トレイからメールを取得し、未読かどうかを確認する。(confirmUnread関数)

function confirmUnRead(){
  var thds = GmailApp.getInboxThreads(0,10);
  for(var n in thds){
    var thd = thds[n];
    if(thd.isUnread()){
      thd.markRead();
      confirmFrom(thd);
    }
  }
}
基本的に文法はjavascriptに準拠している。その上でGoogleが用意した関数その他を利用していく、というスタイルになる。
var thds = GmailApp.getInboxThreads(0,10);
使用した関数:getInboxThreads(start, max) - Class GmailApp - Apps Script Google Developers 
早速Googleが用意してくれた関数を用いる。
ここでは受信トレイの最初から10番目までの「スレッド」を取得している。プログラミングではいつものことだが、一番最初のスレッドは「0番目」なので注意する。
  for(var n in thds){
    var thd = thds[n];
    if(thd.isUnread()){
      thd.markRead();
      confirmFrom(thd);
    }
  }
使用した関数:
- isUnread() - Class GmailThread - Apps Script Google Developers
- markRead() - Class GmailThread - Apps Script Google Developers  取得したのはスレッドの配列なので、そこからスレッドをひとつずつ未読かどうか確認する作業を行う。その作業では当然for文を使うが、javascriptに慣れていない私はここで一回詰まってしまった。
for(var n in thds){
 この部分なのだが、Javaでいうところの拡張for文のノリ、つまりスレッドの配列からスレッドを1つずつ取り出せるのだろうと思って書いたのだがうまく動かず、リファレンスを読むとどうも違うようで、各オブジェクトのプロパティを取り出してnに代入しているようだ。
 より具体的には「取り出したものが配列の何番目か」、というのがnに代入されているようだ。
var thd = thds[n];
 というわけで、このように書けばthds配列中のすべてのスレッドを取り出せることになる。取り出した配列はisUnread関数で未読かどうかを確認、もしそれがtrue(未読)であれば、if文内の処理(スレッドを既読にし、スレッドを引数としてconfirmFrom関数を実行)を行う。

2.取得した未読メールが自分からのメールか確認する(confirmFrom関数)
さて、そのconfirmFrom関数の内容だ。

function confirmFrom(thd){
  var msgs = thd.getMessages();
  for(m in msgs){
    var m = msgs[m];
    if(m.getFrom().indexOf('自分が送信に使うメールアドレス',0)!=-1){
        confirmBody(m);
    }      
  }
}
使用した関数:
- getMessages() - Class GmailThread - Apps Script Google Developers
- getFrom() - Class GmailMessage - Apps Script Google Developers  引数として渡されているのは「スレッド」であり、いくつかの「メッセージ」の連なりだ。よって、このスレッドからメッセージを取り出す。受信トレイからスレッドの配列を取り出したのと同様に、getMessages関数を用いてメッセージの配列を取得しmsgsに代入し、これまた同様にfor文を用い、メッセージの配列からメッセージを取り出す。
 取り出したメッセージの送信元は、getFrom関数を用いて取得する。そして更に、その送信元の文字列に自分のメールアドレスが含まれているか、indexOfを用いて検索する。indeOfはGAS特有の機能ではなく、javascript標準の関数だ。第一引数に検索する文字列、第二引数に走査を開始する位置を入れると、その検索する文字列がはじまる位置を返してくれる関数で、見つからなければ-1を返す。よって、この関数の戻り値が-1でなければ、送信元アドレスの文字列に自分のアドレスが含まれていることがわかる。
 どうしてダイレクトに
m.getFrom=="自分が送信に使うメールアドレス"
としなかったかというと、getFromで取得される送信元は、送信時に使ったメールクライアントなどによって同じアドレスでも別の送信元文字列となることがあるからだ。
具体的には、Gmailでは「(登録した送信者名)<送信に使用したメールアドレス>」の形となる。送信者名を変更したりした場合にプログラムを修正しなくて済むように、ここはindexOfを用いることにした。

取得したメッセージが自分(が送信に用いるアドレス)からのメールであるときには、メッセージを引数としてconfirmBody関数を実行するようにした。これ以降の内容については次回の記事で扱うことにする。

2015/05/10

Google Apps Scriptによるメール自動返信botの作成(プロローグ)

私には両手では数え切れないほどの黒歴史がある。そしてごく最近にもその数を増やしては、明け方に目が覚めた拍子に「うわあああああああああああ」となって布団で悶えている。
一方で、私自身は黒歴史と思わないものの、他人曰くそれは黒歴史だというものが存在する。これは私自身全く恥ずかしいと思わないので、積極的にネタにしていく。メール自動返信botもその一つだ。

あれは私が高校生の頃だったと思う。私はTwitterをフル活用してメールの自動返信botを作り、botとメールするという遊びに興じていた。うろ覚えなのだが、仕組みはこうだ。

  • Twitterアカウントを2つ用意する(自分で操作する用と、bot用)
  • bot用アカウント側で、リプライに対して適切な(そしてお粗末な)リプライを返すようなbotを設定する。
  • 操作用アカウントで、botアカウントへのリプライを送るメールアドレスを設定しアドレス帳に登録。更にリプライがきたときにメールで通知されるようにして、そのメールアドレスもアドレス帳に登録。
  • メールを用いてbotにリプライを送ると、botからリプライが返ってきて、それがメールで届くようになる。

確かこのような仕組みだった。これを自分で思いつくとも思えないので、恐らく何かしら元ネタがあったのだろうと思うが、思い出せない。妄想力が今よりも豊かだったので、ご丁寧にキャラ設定まで色々考えていた。確かに闇深いといわれたらその通りだと思う。
botを動かすためにサーバーが必要だったり、返信パターンを考えるのに飽きて、結局そのうちやめてしまった。

あれから3年以上は経ったことになる。ネットサーフィン(死語)を楽しんでいた私は、「Google Apps Script」なるものの存在を知る。これはjavascriptを用いてGoogleの様々なサービスを操作できる、というものらしい。
Googleのサービス。マップ、カレンダー、ドライブ…色々ある。あとは忘れてはいけない、Gmailだ。Gmailを直接操作したらどんなことができるんだろう…そう考えだした時、3年以上前のメールの自動返信botを思い出したのだった。
Gmailを直接操れば、Twitterを介すような面倒なルートを取る必要はない。これを使って3年前のリベンジと行こうか、と思い立った。

実は思い立ったのは半年以上前の話だ。Google Apps Scriptではjavascript(正確にはjavascript互換の言語)を用いる。その当時、まだjavascriptを使ったことがなかった私は、ひとまずjavascriptを習得することにした。
…のだが、GoogleAppsScriptそっちのけでjavascriptにハマり、結局スクフェスLP回復時間計算スクリプト、艦これ:制空値算出、文章スタイルプレビューと立て続けに作った。
仕方がない、JavaやPythonと違ってHTML+Javascriptは公開も楽だし、ボタンやらフォームやらを使って視覚的なものになるので楽しいのである。

javascriptにもだいぶ慣れ、時は来た。いよいよ3年前のリベンジを始める。
恒例の熱い自分語りで尺を取ってしまったので、本編は次記事以降とするが、Googleが用意しているAPIが充実しているので、少しjavascriptの知識があれば誰でもbotを作ることができると感じた。
メール以外の機能も利用できるので、遊び方は無限にありそうで非常に楽しみだ。

2015/05/08

VisualStudio Codeを使ってみた。

先日の「同一formの別のselectの操作」の記事で紹介した「途中で詰まったコードの例」、実はあれは記事に合わせて新しく書き起こしたコードになる。詰まった経験自体がなかったわけではなく、艦これ対空値計算スクリプトを書いている時には、formごとに関数を作らず済む方法があるのではないかと詰まったのは事実だ。
ただし、そのときのコードを保存するのを忘れていたのだ。忘れていた、というよりは、どん詰まって「あああああああああ」などと言いつつ髪を掻きむしってその時のコードをCtrl+Aで全選択肢、Deleteで消した、というのが正しいのだが。
ともかくそのときのコードは存在しない。だが記事を書くに当たり、その「詰まった」コードを掲載したかった。よって新しく「わざと詰まらせたコード」を書くことにして、先日の記事のコードなのだ。

わざわざ詰まるコードを書くというのもなかなか面倒だ。そう思い、少しでも手間を省くために先日のMicrosoft「Build」で発表されたVisualStudio Codeを試してみることにした。

この「VisualStudio Code」は様々な言語の文法確認やサジェストをしてくれるエディターで、とにかくサクサクと動く。この手のツールは以前Androidアプリを作っていた時にEclipseを使っていた。VisualStudio CodeはEclipseより機能は少ないが、それを考慮しても圧倒的に軽い。Eclipseではもっさりする私の低スペックPCでもサクサク動くのはとても気持ちがいい。
軽くコードを書くときは今後、VisualStudio Codeを使ってみようと思う。機能が少ないと言いつつ、(私は使ったことがないが)Gitとの連携もできるようだし、機会があれば試してみたい。

2015/05/05

[HTML/javascript]“同一formの別のselectの操作”を複数のformについて一つの関数で行う。

この記事は以前製作した艦これ対空値計算スクリプトを事例に書いているため、艦これを知らない人にはわかりにくい説明となっている可能性があります。
一般性をもたせた結論はこちらになりますので、すっ飛ばして読んでいただいたほうがわかりやすいかもしれません。

艦これ:制空値算出は、6隻分の対空値を計算するために6つのformを使用している。
それぞれの艦について1つずつformを使用し、艦1から6まで、それぞれ「ship1」から「ship6」までのnameが付与されている。

一方、このスクリプトに必要な機能(関数)は以下の

  • 「艦種」が選択された際に、それに応じた「艦名」をセットする→setShipvar関数
  • 「艦名」が選択された際に、それに応じた「艦載機の積載数」をセットする→setShipname関数、loadsubmit関数
  • 「艦載機」が選択された際に、それに応じた「対空値」をセットする→setAircraft関数、submitAircraft関数

3つの機能が必要だ(本当はページ読み込み時に「艦種」に「正規空母」などをセットする関数と、対空値を計算する関数もあるがそれは今回の内容とは関係ないので割愛する)。

これらの関数を6つのform分用意するのは面倒くさい。しかし、積載数は6隻分別々に用意された行列に登録しなければならない。
そしてこれは一つのform内でも同じ問題が生じる。スロットは4つあり、対空値を登録するときには当然、それに応じた行列に値を登録しなければならない。となると、スロット4つ分、関数を用意することになってしまうが、それもやはり冗長だ。

故に、ない頭を振り絞って考える。どうにかこれらの関数を一つにまとめることはできないか…。難しいのは、selectで何かが選択された時に、同一form内の別のselectの内容を変更させたい、という部分だ。具体的には、艦種で「正規空母」を選んだら艦名には「赤城改」などをセットし、「軽空母」を選んだら「鳳翔改」などをセットする、といった具合だ。別のselectの内容を変更する以上、そのselectをidなりnameなりで特定しなければならない。それをform6つ分、一つの関数で処理する、というところが難しい。
いろいろ考えて、一つの解決策を思いついた。鍵となったのはformタグでselectタグを囲んでいることであった。

formは艦ごとに用意されているから、そのnameを確認することで何隻目を選択しているのか確認することができる。具体的にはこうした。

function setShipvar(selected){
 var num = selected.selectedIndex;
 var shipvar = selected.options[num].text;
 var formobj = selected.parentNode;
 var jid = formobj.shipname.id;

 switch(shipvar){
  case '正規空母':
   //"jid"を使って正規空母が選択された時の処理を記述。jidは、この関数を起動したformにおける艦名選択のselectのid。

鍵となっているのはvar formobj = selected.parentNode; と var jid = formobj.shipname.id;だ。同時に、関数に引数を設定した。それぞれのselectタグは、何か項目を選択されたときに自分自身を引数として関数を呼び出すようにした。

例えば艦1のformで艦種「正規空母」を選んだとする。(初期段階では空欄の選択肢だが、ページ読込完了時に艦種を6つのformにまとめてセットするようにしている。)するとonChangeで設定されている関数が呼び出される。この場合、自身を引数としてsetShipvar関数が呼び出される。
関数側では渡された引数をselectedという名前で扱っている。これでひとまず、setShipvar関数で6隻分扱うことについての最初の一歩を踏み出したことになる。
selected = document.ship1.shipvar なので、選ばれた艦種は

var num = selected.selectedIndex;
var shipvar = selected.options[num].text;

で取得できる。これで「shipvar」には「正規空母」が代入されていることになる。
次なる問題は、どうやって「艦名」のselectを取得するのか、ということになる。6隻分の艦名selectに一意のidを付与すれば取得できるが、それでは関数をひとつにまとめることができない。ここを前述の「鍵」でクリアすることにした。

var formobj = selected.parentNode;
var jid = formobj.shipname.id;

ここでは「var formobj = selected.parentNode;」でselected、即ち引数として渡されたselectタグの親となるタグ、つまりformタグを取得できる。艦1のformであれば「document.ship1」に当たる部分ということだ。
次に「var jid = formobj.shipname.id;」がある。これは艦種が選択されたformの、shipnameというnameを持つselect(つまり一つ下のselect)のidをjidに代入する、という意味だ。あとはこのjidを使ってjQueryを使うなりなんなりして、selectを操作できる。
formで囲んだselectを扱う際には、「document.(form名).(select名)」と言った形で扱う。となれば、form名は一意の名前とし、同じ機能を必要とするselectの名前を同じにすると、form名を指定すれば特定のselectを取得することができ、かつ関数を一つにまとめることができる。この仕様を使って、一意のidを付与しつつ、そのidを直接指定することなく関数を設計することで、複数のformで扱える関数を作ることができた。


結論
  • 同じ操作を必要とするselectは複数のformに渡って同じnameにする。
  • selectのonChangeで関数を呼び出す際、自身を引数にする。
  • 関数側で引数のparentNode(formオブジェクト)を取得し、それを基に別のselectのnameを指定すれば、ベタでIDやnameを指定することなく複数のformに関して、一つの関数で別のselectの操作を行える。

正直言ってjavascriptでやるには不向きなものだったような気もする。

2015/05/04

Windows PhoneをドイツAmazonで買った。

ついに買ってしまった、WindowsPhone。買ったのはLumia 640 LTEだ。日本では発売されていないので、海外からの個人輸入になった。
スマホの個人輸入といえば有名なのはexpansysと1shopmobileだろう。これは香港から発送されるので比較的輸送の時間も短く、利用者も多いので安心できる。
ただし、両者ともLumia 640 LTE Dual(SIMカード2枚挿せる)は早々に発売されたのだが、Lumia 640 LTEがなかなか発売されない。私はSIMカード2枚挿しに興味はないし、Dualのほうが少し高くなるのでLumia 640 LTEの発売を待っていた。そんな中、ドイツのAmazonで割と安くLumia 640 LTEを売っているのを発見したので、購入することにした。
購入方法は「ドイツ Amazon 購入」などと検索すれば色々情報があるので、特に躓くことはなかった。アカウントは以前アメリカのAmazonで作ったものをそのまま使えたので、住所の登録などを省けたのも大きかった。日本以外のAmazonはアカウントを共有できるらしいので、今後英語圏以外のAmazonで何か購入することがあれば、アメリカのAmazonで先にアカウントを作ることをおすすめする。英語ならまだなんとかなるが、ドイツ語はさすがにわからない。

配送業者はUPS。日本の業者と同じく、追跡番号で荷物がどこにあるのかを確かめることができる。発送日は確か4月30日だった。暇人なのでしょっちゅうチェックすると、あっという間に飛行機に載せられたようだ。到着予定日は5月7日。
いや待て、遅くないか。確かに私はドイツに行ったことがないから、どれくらい時間がかかるかわからない。しかし1週間はさすがにかからないだろう。グライダーで運んでいるわけでもあるまい。
まさかと思って調べると、UPSは土日祝日の配送はしないらしく、それでGWを挟んだ7日が到着予定日になっているようだ。しかも平日も日中のみ配達らしい。学校があって受け取れないじゃないか。
こんな人のためにUPSはヤマト運輸に配送を振り替えすることができるらしい。どうせ再配達をヤマトに頼むことになるなら、と思い物は試し、問い合わせセンターに日中不在の旨を伝え、ヤマトに振り替えてもらえないか聞いてみたところ、日本到着後、ヤマト運輸に引き渡され、2日には無事手元に到着した。(ヤマトはGWも配送している。)

早速色々いじくりまわして遊んでいる。レビュー的なことは今後することにしたい。Lumia640はWindows10にアップデートできて、Win10からはアプリが移植されやすくなってアプリ不足も解消される、かもしれないし。ビッグウェーブが来ていると思っているのは、私だけじゃない、と信じたい。

2015/05/01

FC2とWordPressとわたし

※この記事は、Bloggerへの移転前のWordpress時代に書かれた記事です。

紅茶さんが、FC2からWordPressへ移動した私がFC2とWordPressについてどう思っているかに興味があるらしく、私もいつか書こうと思っていたのでいい機会だし書くことにする。
そもそも何故WordPressを選んだのか、というのも紆余曲折あったのだが、それは別の機会にしようと思う。

まずWordPressの機能面のお話だが、不満はない。素の状態では機能面でFC2より劣っているかもしれない(デフォルトではTwitter連携もできない。)ただしプラグインが凄まじく充実しているので、やりたいことはだいたいできるし、やりたくないことまでやろうと思えばできる。プラグインまで考慮にいれれば、WordPressのほうが色々やれると思う。
FC2がプラグインよりは本体でカバーする範囲が広い一方、WordPress本体はあくまでブログの基礎の「き」だけをカバーし、他はプラグインに任せるようにしているのだろうと思う。この辺は設計思想の違いだろう。

とは言っても、私はブログ自体にそれほど面白い機能は求めていない。それこそFC2くらいの機能で十分で、WordPressにもその程度のプラグインしか入れていない。ならFC2でいいじゃねえか、という指摘はごもっともである。
アクセス数を比較すれば、旧ものぐさブルーライト(FC2)は更新なしで1日10近く(7~8程度)、新ものぐさブルーライト(WordPress)は週1程度の更新で同じく1日10近く(12前後)で、大差無い。最も、FC2旧ものぐさは更新すれば当日と翌日くらいは50アクセス、多ければ100アクセスくらいは行くので、まあ影響力というか、リーチはFC2旧ものぐさのほうが長い。
 それでも何故WordPressでぬくぬくしているかと言えば、意識高いっぽい言い方をすれば、コンセプトが違うからだ。

FC2旧ものぐさは、一言で言えばオナニーだった。旧ものぐさの記事から一番のお気に入りを選べと言われればこれを選ぶくらい、個人的には会心の出来の記事だ。旧ものぐさはだいたいがメイプルプレイの絵日記で、何度も言うように何故あんなブログを1日100人も見ていたのか、書いている本人が理解できなかった。言い方を変えれば、自分が書いたブログでなければ、旧ものぐさにアクセスしようとは思わないだろう、ということだ。いっそどこかにスパム報告したいくらいだ。
一方でWordPress新ものぐさブルーライトは、「多くの人でなくても、数少ない誰かの役に立つ記事を書きたい」という動機で書いている。結果として誰の役にも立たず自己満オナニーで終わるかもしれないが、最初から自己満のつもりで書いていた旧ものぐさブルーライトとは根本的に異なる、と自分では思っている。
新ブログにはコメントがほとんどつかないが、それも別にどうでもいいと思っている。私がプログラミング関連で調べる際にお世話になったブログにコメントは全くしていないが、それでも役に立ったと感謝している。そういう存在になれるのが理想なのだ。

もっとも、この記事も属する「ものぐさなつぶやき」カテゴリはどちらかというと長文Twitter、自己満要素の強い記事の集まりなのだが、今のところカテゴリ別記事数を見れば分かる通り、プログラミング関連の記事のほうが多い。
それとアクセス解析を見て密かに喜んでいるのだが、GOD EATER 2 RAGE BURST(GE2RB)で「セルフアバカ」への検索エンジンからのアクセスが非常に多い(あくまでこのブログ内の相対的なものだが。繰り返すが、アクセス数だけ見ればFC2には及ばない)。このブログのコンセプトに合った記事になっているのではないか、と自画自賛している。

旧ブログで最後、メイプルブログについて考えた時、

 ブログの性格が「周りとの環境によって決まる」なら、メイプルブログとしてはじまったこのブログには未だメイプルブログとしての関係がベタベタと貼り付いているわけで、その意味でこのブログではメイプルブログであることをやめることはできないのかもしれない。
と書いたように、あのブログは7年間の足跡を消すことはできないし、それが悪いことだとも思っていない。ただ新しくやりたいことと合致しそうにないからWordPressへ移ってきて、そのコンセプトからしても、アクセス数が少なかろうが旧ブログに戻ることはまず無いだろうと思う。(ただし、上述のように、それがWordPressでなければいけなかったわけではない。例えば新しくFC2のアカウントを作って新ブログを作る、というのも悪くない選択肢ではあったと思う。)

2015/04/28

[ブロガー向け]文章スタイルプレビュー ver2.0

昨日公開したver1.0だが、Twitterで早速指摘を頂いた。

→XSSの脅威もあるので、<や>などをエスケープすることで対応(ver1.1)

そしてこの指摘。ごもっともである。一応言い訳をすると、段落ごとの入力を想定していて、本来しっかりとした文章ならば段落内での改行はまずないわけで…
とは言っても、ブログとレポートや論文は違うし、むしろどこで改行を入れれば見やすくなるか、というのもまた重大な問題であるから、これに対応しようじゃないか、というのが今回のver2.0である。

昨日の段階で、textareaにCSSを適用できることを発見した。故にこの仕様を使って改変することにした。

ver1.1では入力欄の文字列を取得し、1文字ずつエスケープが必要かどうかを判定し新たな文字列を作成。その文字列を結果表示欄に挿入し、結果表示欄にCSSを適用していた。
一方ver2.0では入力欄のtextareaそのものにCSSを適用することで、処理が大幅に減った上に、textareaであるためHTMLタグなどのエスケープも必要無くなり、コードも大幅にシンプルになっている。

文章スタイルプレビュー ver2.0 ソースコードは以下。


2015/04/27

[ブロガー向け]文章スタイルプレビュー ver1.0公開

ブログのデザインに関して色々試行錯誤している。デザインと言っても、色がどうとか、シャレオツさがどうとかなどは全く興味が無い。問題は、記事表示欄の横幅と、フォントサイズと、そして行間なのだ。
これらの要素は記事の読みやすさに直結する。だが、一々CSSの該当する場所をいじるのが面倒で面倒でしかたがない。そこで作ったのが文章スタイルプレビューだ。

表示領域の横幅、文字サイズ、行間の値を入力すると、それらをCSSに適応した場合の表示がどうなるのかを簡単に調べることができるようにしている。
ver1.0段階では上記3つの要素についてのみ扱っているが、今後他の要素(まあ、無いとは思うが文字の色指定したいとか)をも考慮に入れたくなったら、追加することは十分可能である。私自身使っているうちに必要に応じて追加するつもりだが、「この要素を扱えるようにしろ」という意見があればコメント欄またはTwitterで連絡をいただければ、追加したいと思っている。

2015/04/25

[javascript]複数の関数で扱う変数の宣言

艦これ・制空値計算スクリプトの制作の最後の最後で引っかかったのが表題の通り、複数の関数に渡って使用される変数をどうすればいいのかという問題だった。
具体的には以下の部分だ。

function loadsubmit(shipnum,lnum1,lnum2,lnum3,lnum4){
 switch(parseInt(shipnum)){
  case 1:
   loadArray1[0] = lnum1;
   loadArray1[1] = lnum2;
   loadArray1[2] = lnum3;
   loadArray1[3] = lnum4;
   break;
  case 2:
   loadArray2[0] = lnum1;
   loadArray2[1] = lnum2;
   loadArray2[2] = lnum3;
   loadArray2[3] = lnum4;
   break;
  case 3:
   loadArray3[0] = lnum1;
   loadArray3[1] = lnum2;
   loadArray3[2] = lnum3;
   loadArray3[3] = lnum4;
   break;
  case 4:
   loadArray4[0] = lnum1;
   loadArray4[1] = lnum2;
   loadArray4[2] = lnum3;
   loadArray4[3] = lnum4;
   break;
  case 5:
   loadArray5[0] = lnum1;
   loadArray5[1] = lnum2;
   loadArray5[2] = lnum3;
   loadArray5[3] = lnum4;
   break;
  case 6:
   loadArray6[0] = lnum1;
   loadArray6[1] = lnum2;
   loadArray6[2] = lnum3;
   loadArray6[3] = lnum4;
   break;
  default:
   break;
 }
}
function submitAircraft(shipnum,slonum,toair){
 switch(parseInt(shipnum)){
  case 1:
   toAir1[slonum-1] = toair;
   break;
  case 2:
   toAir2[slonum-1] = toair;
   break;
  case 3:
   toAir3[slonum-1] = toair;
   break;
  case 4:
   toAir4[slonum-1] = toair;
   break;
  case 5:
   toAir5[slonum-1] = toair;
   break;
  case 6:
   toAir6[slonum-1] = toair;
   break;
  default:
   break;
 }
}
function calc(){
 var result = 0;
 for(i=0; i<4; i++){
  result += Math.floor(Math.sqrt(loadArray1[i])*toAir1[i]);
  result += Math.floor(Math.sqrt(loadArray2[i])*toAir2[i]);
  result += Math.floor(Math.sqrt(loadArray3[i])*toAir3[i]);
  result += Math.floor(Math.sqrt(loadArray4[i])*toAir4[i]);
  result += Math.floor(Math.sqrt(loadArray5[i])*toAir5[i]);
  result += Math.floor(Math.sqrt(loadArray6[i])*toAir6[i]);
 }
 var ele = document.getElementById('result');
 ele.innerHTML = '対空値は'+result+'っぽい';
}

対空値は艦載機の積載数の平方根とその艦載機の対空値の積によって求めることができる。よって艦載機の積載数の行列loadArraykと艦載機の対空値を代入した行列toAirkを6隻分用意し(ともにkは艦の番号。1≦k≦6)、calc関数でそれらふたつの行列のi個目(0≦i≦3)同士を掛けて足しあわせていくことにした。
その際、当初は艦名を選択した際に実行されるsetShipname関数から、艦の番号(何隻目か、ということ)とその積載数(最大4スロット)を引数として呼び出されるloadsubmit関数内でloadArraykを、艦載機を選択した際に実行されるsetAircraft関数から、艦の番号、スロットの番号、対空値を引数として呼び出されるloadaircraft関数内でtoAirkを宣言し、代入していた。
しかしそれではcalc変数からそれら2つの行列を呼び出しても、読み込むことができなかったのだ。

そこで色々と調べた結果、変数のスコープ (JavaScript)に行き着いた。これによればjavascriptにおいてはプログラム内のどこからでも、即ち複数の別の関数から扱えるグローバル変数と、関数内で宣言し、その関数でしか扱えないローカル変数がある、ということらしい。
 つまり、先ほどの宣言の仕方では、loadArrayはloadsubmit関数、toAirはloadairctaft関数でしか扱えなくなっている、ということだ。2つとも関数内で宣言しているため、ローカル変数となっているからだ。
 その対処として、これら2つの行列をグローバル変数として宣言する必要がある。つまり、関数の外で宣言すればいいということになる。

//グローバル変数宣言
var loadArray1 = [0,0,0,0];
var loadArray2 = [0,0,0,0];
var loadArray3 = [0,0,0,0];
var loadArray4 = [0,0,0,0];
var loadArray5 = [0,0,0,0];
var loadArray6 = [0,0,0,0];
var toAir1 = [0,0,0,0];
var toAir2 = [0,0,0,0];
var toAir3 = [0,0,0,0];
var toAir4 = [0,0,0,0];
var toAir5 = [0,0,0,0];
var toAir6 = [0,0,0,0];
(後略)

上述のリンク先によれば、関数内で宣言する場合にも「var」をつけずに宣言すればグローバル変数として扱われるとの記述もあったが、プログラムの冒頭でまとめて宣言しておいたほうが、どの変数はすべての関数で扱えるのか後でわかりやすいかと思い、最初にまとめて宣言することにした。
javascriptはJavaを勉強した時とは違い、実際にスクリプトを作りつつ勉強しているのでそもそも「スコープ」という言葉を知らず、上記のリンク先に行き着くにも少し時間がかかった。
最初は一瞬、面倒な仕様だと思ったが、ローカル変数として宣言した変数は同じ名前で違う関数のローカル変数として宣言することができ、変数名に規則性を持たせることができるため、なかなか使いやすい。(このプログラムでは「selected」というローカル変数がいくつかの関数で使われている。)

まとめ

  • Javascriptの変数は、変数を扱える範囲の違いによってグローバル変数とローカル変数に分けられる。
  • 変数外で宣言するか、varをつけず宣言するグローバル変数はプログラム内どこからでも扱える。
  • 変数内で宣言するローカル変数は宣言した関数内でしか扱えない。
  • 複数の関数で扱う変数は、グローバル変数として宣言しなければならない。

2015/04/21

基本情報技術者試験を受験してきた。

一昨日(19日)、基本情報技術者試験を受けてきた。
自己採点した感じ、マークミスなければ合格してるんじゃないか、という手応えがある(フラグ)。

私は所謂文系の人間で(そもそも文系理系の区分は存在するのかという議論はここではなかったことにする。)、Googleで「基本情報技術者試験 文系」と検索すると色々エピソードがあったり、はたまた「文系でも合格できますか?」みたいな質問があったり(そんなもん人によるとしか言いようがないのだが)、文系のよる受験の情報への需要は存在するのかなあ、と思う。
合格発表は来月だが、もし合格していたら、私自身どう勉強したのか、ということについて少し書きたいなあ、と思っている。
逆にもし落ちていたら、何もなかったことにしよう。来月18日?くらいに発表だったと思うので、それを過ぎても音沙汰なければお察し、ということで。

2015/04/11

ドア、挟みし向こう側。

ここにいう「挟む」とは「指をドアに挟んだよいってええええええええ」とかではなく、「テーブルを挟んで座る。」のような意味合いでの「挟む」である。
などと注釈をつけている時点でこのタイトルは失敗だったのだなあ、とこの時点で思うのだ。

 さて、新学期も始まりこのブログも順調に更新が滞っている。どっちかというと新学期というよりは新アニメのせいで忙しさが増しているのだが、どうせ数ヶ月すれば夏休みだ。
新学期といえば、進学やら就職で新たな住処に移った人もいるだろう。私も2年前のちょうど今頃、本州に入るにはパスポートが必要などと言われる北海道から神奈川へ移り住んだのだった。

新たな住居に移るにあたりよく言われたことが、「新聞の勧誘とかめちゃくちゃたくさん来るよ!」という忠告だった。
まあ確かに、やれ洗剤だの何だのの粗品を釣餌に新聞の契約を求める勧誘があるらしいとは知っていた。だから私もどんな断り方をしようかと、持ち前の性格の悪さでウッキウキだった。
そしてあとはみんな大好きNHKだ。受信を主目的とする機器がウンタラカンタラ、色々と謳ってワンセグ機能付きケータイまで契約必須にすることでお馴染みのNHKだ。終いにはネット契約していたら契約必須にしたいらしいとの噂まである。
そんな彼らがやってくるかもしれない、そう覚悟していた。

 蓋をあけると上述二種の訪問者のうち、やってきたのはNHKだけだった。
Amazonで頼んだゲームソフトが届く予定の日、ついに鳴ったピンポンにウッキウキでドアを開けるとそこにいたのは某放送局の某さんであった。
どうしてこうも人をイライラさせる登場の仕方ができるのだろう、狙っていたとしか思えない。彼は部屋を覗き込み(1Kだから中まで見えてしまう)、ノートパソコンを指し「あれテレビですよね?」などと寝言としても程度の低い戯言をのたまったわけだが、いつから彼の世界ではテレビにキーボードが一体となった製品があったのだろう。
とにかく、それ以来NHKは来ていない。

新聞屋は音沙汰がない。よく考えると近くに新聞屋があるのかもわからない。一応朝早くに新聞配達しているのは見たことがあるから、どこかにはあるのだろうと思う。
ただし私の家に来たことはない。別に来てほしいとも思わない。大学の図書館で読めるからだ。

一方思わぬ伏兵として、しょっちゅう訪れる厄介者がいる。それはインターネットプロバイダの代理店だ。あまりにしょっちゅう訪れていい加減腹が立ってきたのでその手法をワールドワイドに晒すことにした。それがこの記事だ。
彼らはまず早口で名乗る。私も大概早口だが、それよりも早い。なんせ早口に慣れている私が聞き取れない速度で名乗る。
そして「どちら様ですか」と再度の名乗り口上を求めると聞こえないふりをして黙るのである。なるほど、難聴系勧誘員というのが最近のトレンドのようだが、現実にやられてもこちらからドアを蹴破りたいほどのストレッサーにしかならない。或いは勧誘員にすら無視されているのかもしれない。悲しい世界だ。
そんな無視にもへこたれず「どちら様ですか」と数回、壊れたラジオのように問いかけると、観念したのか再度名乗り始める。なんだ聞こえているじゃないか、許すまじ。
名乗り始めたかと思えば再度はっきりしない。どうやらNTTの代理店だか、そんなことを言っているようだ。そして「この地域のインターネットの回線の設備が更新されまして」「通信状況の確認に」などと言い始める。だがこれに騙されてはいけない。まともな更新なら更新前にお知らせするだろう。通信状況に影響するやもしれない設備更新を勝手にするはずもないのだ。
…などと偉そうなことを言っているが一度うっかりドアを開けたことがある実体験から、この時点でもうプロバイダ乗り換えの勧誘はほぼ確定。「忙しいので」とシャットアウトして問題ない。話を聞き続けてもプロバイダ乗り換えの方へ話がゆっくりと、打ち寄せては返す波のように進んでいくだけだ。
中にはしつこいのもいて、「他の方にも忙しい中対応していただいています。」などと食い下がってきたりする。嘘をつけ、他の方にも同じように足蹴にされて若干涙目なのはバレバレだぞ。
或いはその「他の方」は、小学生がいう「みんなあれを買ってもらっている」みたいな正体不明の「みんな」なのかもしれない。
それでも放置しているとピンポン連打、ドアコンコン連打、なんだこいつは。指先についたアロンアルファも真っ青のしつこさだぞ。数分間不愉快なドア越しの圧迫を続けると、彼は諦めたのか去っていった。

結論から言ってしまえば、荷物が届く予定がある時以外は居留守するのが正解だ。
ただやっかいなことに、上のNHKのときや粘着質の彼のように、Amazonから荷物が届く予定の日に限って勧誘が来たりするのである。毎度再配達してもらうわけにもいかぬし、こればかりはどうしようもない。
そのやるせなさに憤って、この記事を書いた。

2015/04/04

[Python]続・指定した文字列でフォルダを作成し、指定したURLのファイルをダウンロードし保存する。

 [Python]指定した文字列でフォルダを作成し、指定したURLのファイルをダウンロードし保存する。の最後で「使っていていくつか問題も見つけたので、自分で使う分には不都合ないが、今後修正することも考えたい。」と書いた。
その「問題」を列挙すると、

  • フォルダを作成しようとする際、既に同名フォルダがあるとエラーとなって処理を中止する。
  • フォルダを作成しようとする際、特定の文字が含まれていると「\uff5e」云々のエラーなど、文字コード関連でエラーが出ることがある。
  • そして上述2つのエラーが両方共exceptで拾われる場合があり、どちらのエラーかすぐにはわからない。

列挙する、と言いつつ実質2つしか見つけていないじゃないか!という感じだが、とりあえずこの2点について修正することにした。

 一点目の修正は簡単だ。取得したページタイトルをフォルダ名とするフォルダがあるかを確かめ、あればそのフォルダへ移動し、なければフォルダを作成するようにすればよい。
ということでこうする。

#画像保存フォルダ作成
title = title.encode('cp932')
checkedpath = os.path.join(os.getcwd(), title)
if(os.path.isdir(checkedpath)):
    print u"同名フォルダが既に存在します。"
    print u"該当フォルダにファイルを保存します。同名ファイルがある場合は上書きします。"
    os.chdir(title)
else:
    try:
        os.mkdir(title)
        os.chdir(title)
        print u"フォルダを作成しました。"
    except:
        print u"フォルダを作成できませんでした。ページタイトルを確認して下さい。"
        print u"処理を中止します。"
        sys.exit()

まずは作成しようとするフォルダのパスを os.path.join(os.getcwd(), title)で作成し、checkpathに代入。

if(os.path.isdir(checkedpath))でそのフォルダが存在するかを確認し、あればフォルダへ移動、なければ前回作った部分の処理を実行するようにした。

 これで1つ目の問題、そして3つ目の問題は解消した。この時点でエラーで終了するのは2つ目の問題、文字コード絡みの場合のみといってもいい。
文字コード絡みのエラーは二種類あるようで、ひとつはタイトルにフォルダ名として使えない文字が含まれている場合、そしてもう一つがshift_jisにエンコードできない場合のようだ。
上述の「\uff5e」云々のエラーは後者の場合のメッセージのようだ。
前者はtitleを1文字ずつチェックし、if文なりswitchなりでフォルダ名に使える文字に変換すればよさそうだ、と解決策を考えたところでとりあえず納得した。
問題は後者で、文字コード関連は未だによくわかっていないのでどうすればいいかわからなかった。

素直に「Python \uff5e」で検索すると、こちらのサイトを発見。

というわけで、
title = title.encode('shift_jis')

title = title.encode('cp932')
に代えてみたところ、このエラーを見ることはとりあえずなくなった。

# coding:utf-8
# Project_KAGA

import urllib2
import re
import os
import urllib
import sys

#対象URL入力
url = raw_input(u"URLを入力してください。--->".encode("shift_jis"))

#URLを開き、ソースを読む。
fp = urllib2.urlopen(url)
html = fp.read()
fp.close()

#画像URL格納リスト作成
rowImglist = []
imglist = []

#画像URL検索
img = re.compile("[正規表現]")
i = 0
while i >= 0:
    m = img.search(html, i)
    if m:
        rowImglist.append(html[m.start():m.end()])
        i = m.start()+1
    else:
        break
#重複削除
for i in rowImglist:
    if not i in imglist:
        imglist.append(i)

#記事タイトル取得
titlestart = re.compile("")
titleend = re.compile("")

ts = titlestart.search(html, 0)
te = titleend.search(html,ts.end())

title = html[ts.end() : te.start()]

#タイトル・画像URL出力
print title.decode('utf_8')
for imgurl in imglist:
    print imgurl

#画像保存フォルダ作成
title = title.encode('cp932')
checkedpath = os.path.join(os.getcwd(), title)
if(os.path.isdir(checkedpath)):
    print u"同名フォルダが既に存在します。"
    print u"該当フォルダにファイルを保存します。同名ファイルがある場合は上書きします。"
    os.chdir(title)
else:
    try:
        os.mkdir(title)
        os.chdir(title)
        print u"フォルダを作成しました。"
    except:
        print u"フォルダを作成できませんでした。ページタイトルを確認して下さい。"
        print u"処理を中止します。"
        sys.exit()

#画像ダウンロード
i = 1
for imgurl in imglist:
    savepath = os.path.join(os.getcwd(), os.path.basename(imgurl))
    urllib.urlretrieve(imgurl, savepath)
    print str(i)+u"枚目ダウンロード完了"
    i+=1
print u'ダウンロードが完了しました。'

とりあえずこんな形に。
現状「フォルダを作成できませんでした。ページタイトルを確認して下さい。」というメッセージが出たらまずフォルダ名に使えない文字がページタイトルにある場合だが、このメッセージが出ること自体滅多にないので、とりあえずそちらは放置で。
あとは正規表現を対象のサイトに合わせてどう書くか、というのが問題かな、と。
こればっかりは正規表現に色々触れて慣れるしかないと思った。

2015/03/29

ムーンライトながら、実際のところ

 先日の高山旅行でムーンライトながらを利用した。利用する前にいくつか気になっていた点があって、実際に利用したことでわかったことをまとめておきたい。

1.予約
他のJR券と同様、1ヶ月前10時から予約開始となる。サイバーステーション発売開始数日後に確認したときには満席となっており、当日の車内放送でも指定券は売り切れている旨が伝えられていた。しかし入手難易度は(北斗星などと比べれば)それほど難しくないと感じた。
北斗星はえきねっとで予約できないために朝からみどりの窓口に並ぶ羽目になったが、ムーンライトながらはえきねっとでの事前受付が可能。その点でも難易度は低いと感じた。
えきねっとで事前受付をしておけばほぼ間違いなく予約を取れるのではないかと思う。

2.車内の室温(春)
 ネット上でも「車内の温度はどうなっていますか」という質問がいくつか見られた。結論から言うと「脱ぎ着できるもので調整するのがよい」という教科書的回答になる。
これは外が寒く、暖房が効くと車内は暖かくなるから、ということもあるのだが、車内自体での温度変化があるからだ。
私が乗車した日は比較的寒い日だったからか、乗車時には暖房が効いて暑いくらいだった。しかし、途中で暖房が止められたのか、室温は一気に低下し今度は寒いくらいとなった。古い車両なので暖房の調整もそう細かくはいかないのだろう。夏や冬は空調をつけっぱなしになるのかもしれないが、温度が変化する春は特に脱ぎ着できるものが望ましいと思う。

3.あるといいもの(睡眠編)
 よく言われるのがアイマスクと空気枕だ。アイマスクは車内の照明が消されないので有効だった。
しかし空気枕はあってもなくても大差なかったかなあと思う。どう頑張っても熟睡はできないと思って間違いない。体勢を変えたくなることもあるし、そういうとき首元に空気枕があると逆に邪魔だった。
加えて必要だったと思うのが耳栓だ。さすがに夜中までベラベラしゃべるバカがいるとは思わなかったので持って行かなかったのだが、いた。そしてしゃべるという意図的迷惑行為がなくとも、意図せずイビキをかく人がいる。こればっかりはどうしようもないので、耳栓はあったほうがいいと思う。

4.あるといいもの(その他)
 私が乗車した時は洗面所のコンセントにタコ足でスマホが何台もつながっていたが、洗面所なので水がかかるおそれもあるし、盗まれる可能性もある。ポータブルバッテリーがあれば手元で充電できて良いと思うし、ムーンライトながらを降りた後も旅行中にバッテリー残量を気にしなくても済むのは便利だ。私はAnker Astro E4を使っている。

2015/03/28

インターネットと著作権について知っておくべきだと私が思うこと

 旧ブログで以前、「著作権について言いたいことあるからそのうち記事を書く」と言って、例の如く放置していた。
しかし今、著作権法関連で大きな動きがあってもおかしくない流れになっており、書くなら今しかないのではないかという思いが湧いてきた。だから今書く。
この記事では我々が知っておくべきなのではないか、と私が思ういくつかのトピックについて(ゲームとその動画投稿についてが主だ。)私が今まで勉強してきたことを基に書こうと思う。
私は法律を特に勉強しているわけではない(法学部の学生じゃないということ)ので、認識に誤りがあるかもしれない。もし詳しい方でそれに気づかれた方がいらっしゃれば、指摘していただけるとありがたい。

 旧ブログはメイプルストーリーについて扱ったブログで、当然読者層はメイプルストーリープレイヤーが多かった。
今では下火になったが一時期動画サイトへのメイプルプレイ動画のアップは頻繁に行われていて、「みんなで動画をアップしよう!」みたいな企画もあった。(そしてそれがこの記事の構想のきっかけでもある。)
前提条件としてメイプルストーリーを考える上でまずひとつ特筆すべき点は、メイプルストーリーの運営元であるネクソンは著作権に関して割と寛容だということだ。
ネクソンの著作権ガイドラインを見ていただければわかることだが、SS利用に対して制約が少ない。
画像一枚一枚にコピーライト入れろ、などという制約もない。
当時(00年代中盤~後半)、オフゲーが画像の公開はダメ!と少なくとも表面的にはなっていたことを考えれば(後述するが今はそうでもない。)非常に先進的であり、それがメイプルブログの勢いを加速させていたとまで言える。
こちらの体験談も参考になる。)
 だからまずメイプルプレイヤーは、自分のゲーム関連著作権に関する認識がユルユルでガバガバである可能性を考えなければならない。
メイプルの常識は他のゲームの非常識である可能性があるのだ。
それ以前に、上述のネクソンのガイドラインを見てもらえるとわかるが、実はネクソンは動画については一言も触れていない(良いともダメとも)。
「動画?1秒に30枚の画像を使ったスライドショーですけど?」と言い張れば通るのかもしれないが、ガイドラインの見方によっては動画についてはグレーと読めなくもない。
もっとも、公式で動画コンテストなんて行われているくらいだから実態としてはセーフになっているのが現状だろう。
ただし、それは暗黙の了解としてである。

 動画を作るにあたり、ゲーム外からBGMとして音楽を取ってくるというケースがあり、メイプル動画にも多かった。
その音楽の権利に関してはもうネクソンの手を離れているわけで、寛容なネクソンとは違う基準で判断される。
しかしその辺りの認識が甘いケースがあったのではないか、と私は考えている。
特に、前述の「みんなで動画アップしよう!」みたいな企画では尚更、今まで動画を作って投稿したこともない人が動画作成方法を学びアップロードしたりするわけで、著作権についての知識がない可能性もある。
そんな中で、音楽の著作権について以下のような認識を持つ人がいた。

1.動画サイトが著作権者とまとめて契約してるからアップしてもいいんでしょ?
 1-1.
 ある意味正しくて、ある意味間違っている。確かに、例えばニコニコ動画は2008年4月1日にJASRACと包括契約を結んでいる。

 日本音楽著作権協会(JASRAC)とニワンゴは2008年4月1日、ニワンゴの運営する動画投稿サイト「ニコニコ動画」におけるJASRAC管理楽曲の二次利用を包括許諾する契約を締結したと発表した。これにより、JASRACが管理する音楽著作物を使用した動画を、ニコニコ動画へ自由に投稿可能になる。

ニュース - JASRACとニコニコ動画がついに契約、楽曲の二次利用が可能に:ITproより引用(2015年3月28日アクセス)

同様の契約をニコニコ動画はイーライセンス、JRCとも結んでいる。
この部分だけ見れば、確かに著作権管理団体と包括契約を結んだニコニコ動画には音楽を自由にアップできると理解できなくもない。
しかし実は単純にそうだとは言い切れない。締結日が4月1日だから嘘です、とかいうふざけた理由ではない。
引用元の続きを読めばしっかり書いてあるのだが、長ったらしく漢字が多くて読む気にならないという人もいるだろう。
だから最初の「JASRACが管理する音楽著作物を使用した動画を、ニコニコ動画へ自由に投稿可能になる。」だけを読んでブラウザバックしてしまうと気づかない次の2つの点に気をつける必要がある。

 まず使用しようとしている楽曲が、動画サイトが契約を結んだ団体の管轄かどうかということ。
JASRACは間違いなく日本で最大の音楽著作権管理団体で、かつイーライセンスやJRCとも契約を結んでいるニコニコ動画の契約はほぼすべての楽曲をカバーしていると言っても過言ではない。
しかし、これら3つの団体のいずれにも権利の管理を委託していない権利者も少数ながら存在する。
であるから、BGMとして楽曲を使用する前に、その楽曲が、投稿しようとしている動画サイトが契約している団体が管理する曲か否かということを確かめる必要がある。例えばJASRACであればJASRACの作品データベース検索サービスで検索することができる。

 データベースでヒットしたからといって安心はできない。当該の団体が権利を管理しているというのはインタラクティブ配信の区分について管理していることを指す。上述のJASRACデータベースでは「配信」の欄が該当する。
演奏や出版についてはJASRACに委託しているが、インタラクティブ配信については管理を委託していない、という楽曲も存在するため、使用しようとする楽曲がインタラクティブ配信についても管理委託されているか確認が必要なのだ。

 1-2.
 ここまででお腹いっぱい感はあるだろう。だがまだ気をつけなければならないことは続く(笑)。
先ほどの引用元を読み進めるとこんな記述がある。

 ただし、他の動画投稿サイトと同様、市販の音楽CDの音源をそのまま二次利用することはできない。

ニュース - JASRACとニコニコ動画がついに契約、楽曲の二次利用が可能に:ITproより引用(2015年3月28日アクセス)

!?という感じだろう。音楽を自由に使用できると思ったら、CD音源はそのまま使えないときた。どういうことか。
これについてはニコニコ動画公式の音楽著作物及び音楽原盤の利用に関するガイドラインがわかりやすい。


CD音源には、楽曲の著作権とはまた別の権利が存在しており、これらを利用する場合には、全ての権利者からの許諾を取る必要があります。権利者からの必要な許諾を受けることなく、CD音源の全部、または一部を動画に利用して「ニコニコ動画」にアップロードすることは出来ません。
音楽著作物及び音楽原盤の利用に関するガイドラインより引用(2015年3月28日アクセス)

この説明は非常にわかりやすい。「楽曲の著作権とはまた別の権利」という表現がとてもわかりやすい。
そのわかりやすい説明を(かえってわかりにくく)解説すると、この権利のことを著作隣接権という。
曲とは別に、演奏や歌声や録音という曲に付随するものに与えられる権利だ。
なんのこっちゃという感じだが、ざっくり言うと著作権は楽譜、著作隣接権はそれを音楽として実際に演奏されたものに対する権利くらいに理解するとわかりやすいかもしれない。
著作隣接権はレコード会社などが保有している。

 先ほどの話と突き合わせると、例えばニコニコ動画なら、JASRAC管轄の曲を利用するのは問題ない(著作権について包括契約を結んでいるから)が、CD音源を使うには、それとは別に著作隣接権保有者との契約が必要になる、ということだ。
この部分に関する認識が非常に甘いと感じた。わかりにくいし。
上記引用元によればニコニコ動画はエイベックス、ワーナーなどと契約を結んでいるため、これらの会社が著作隣接権を持つCD音源は利用することができる。
ただし、契約のない会社が権利を持つ楽曲に関しては、CD音源を使用することはできない。JASRACなどの著作権管理団体との契約に基づいて、著作隣接権を侵害しない形(MIDIで打ち込むとか、自分たちで演奏するとか)でなら利用することができる、ということになる。

1のまとめ
使用したい楽曲が、動画サイトの契約した管理団体のインタラクティブ配信の管理に含まれているか確認しなければならない。
CD音源をそのまま利用する場合は、動画サイトが著作隣接権保有者と契約しているかどうかも確認しなければならない。

2.ボーカロイドの曲はアマチュアの人が作ってるし使ってもいいっていう雰囲気があるって聞いたけど?
 2つの点で認識が甘い。まず1つは、作者がアマチュアだろうが著作権は存在するということ。確かにアマチュアだから財産権としての性格が弱いということもあり、だからこそ「ボカロは使ってもいいという雰囲気」みたいなものが蔓延しているが、だからといって著作権フリーというわけではない。

 そしてそもそもボーカロイド界隈が単なるアマチュアの域を飛び出しているということ。
今やボーカロイド楽曲を収録したCDは大量に存在し、CDショップに行けばわかるが棚をいくつか埋めるくらいの量がある場合さえある。
CDが売られたりレンタルされてりしているということは、(同人でなければ)背後に企業が存在するということになる。
こうなってくるとただ趣味の世界だったから二次利用が許される雰囲気がある、などとは言っていられない。
場合によっては作者の手さえ離れかけている場合さえ存在する。例えばこんな事例。作者が自分の作った曲をYoutubeにアップしたら、その曲を収録しているCDの販売元が削除申請したということらしい(Twitterソースのため確度は低い)。
リンク先は「【これはひどい】」などと煽っているが、別にひどくない可能性もある。作者とCDの販売元でどのような契約が結ばれているのかがわからないからだ。
要は、作者が自分の曲の二次利用を喜ばしく思っても、(作者とCD販売元の契約次第では)それが許されない可能性もある、ということだ。

2のまとめ
ボカロだからOKは通用しない。他の楽曲と同様に考える必要がある。


以上2点が私が数年前から感じていた、動画作成の際に音楽を使うことについての誤った認識の風潮だ。
ここから先はより一般的に私が現在感じていることになるので、物好きな方以外はつまらない話になってしまうと思う。
というか、あまりに長文が過ぎてそれこそ物好きな人以外ここまで読んでいない説もある。

ここまで読んで、そして私は書いて思うのだが、正直面倒臭すぎるのだ。この文を読むことが、ということではなくて(それもそうなのだが)著作権関連の制度が、ということだ。
色々知識をつけて細心の注意を払っても、何か一つ見落とすと権利を侵害してしまう可能性もある。
しかし、メイプル動画アップしたらBGMで使った曲の権利侵害してて逮捕されました、なんてことになったら末代までの恥だが、そんな話はまず聞かない。
それはどうしてかというと、みんな大好き暗黙の了解というやつがあったからだ。

レコード会社からすればCDが売れるかどうか、ということが大事なのだろうと思う。仮にメイプル動画のBGMにCD音源の全部や一部が使われていて、それをダウンロードしてipodに入れ、これで満足だからCD買ーわない、なんて人はまずいないだろう。何が面白くてデンデンが倒されてデンデンの殻をドロップした音とともに音楽を楽しめるだろうか。だから場合によってはこの権利侵害は放置され、対処されるにしても削除されるくらいだ。
(もちろん、だから権利侵害していいとは言っていない。ただ現状としてはそうなっている、と言いたいだけだ。)

ここから、話を音楽からゲームへと移していきたい。
音楽はまるまるアップロードされるとCDの売り上げに響くかもしれないが、(メイプルのようにSSのアップについて明言されていない)ゲームのプレイ動画は売り上げ促進につながると見る向きもある。
(ただし、これを企業側が言うならまだしも、ユーザー側が声高らかに唱えるのは盗人猛々しい。某動画ユーザーに多い印象だが…)
そこで、ストーリーのムービーを含まなければOK、発売直後じゃなければOK、のような暗黙の了解でここまで綱渡りしてきたのだ。

 企業側にもやはり、宣伝になるという考えがあったから、こうしてうまいことやってきたわけだ。
「鉄拳」シリーズのプロデューサー、原田勝弘氏はTwitter上で鉄拳のプレイ動画について問われ以下のような発言をしている。

以前別件で説明しましたが、こうした著作物の配信や二次創作などは例えば権利元の法務部(や問い合わせ窓口)に正面から質問すると「厳密にはダメです」という杓子定規な回答が返ってきます。
(中略)
逆を返せば現時点の法律では著作権に関わるものは版元からケチをつけない限り違法化されません。
で、ここからは現実的にどうなのかという話ですが、
「鉄拳の場合」とあえて限定しますが、鉄拳はゲームの特性上、大会の映像配信やユーザーコミュニティの盛り上げとしての配信を「広告宣伝」と「みなして」います。
(中略)
用は、こちら(版元)のさじ加減ひとつです、というのが一般論です。
(中略)
ですので、よほどの逸脱行為がない限り、こちらから物言いをした事はありません。

原田氏のTwitLongerでの発言より抜粋(2015年3月28日アクセス)

大事そうなところを抜粋したが、偏っていたらまずいので是非抜粋元の全文を読んでいただきたい。
要は「よほどのことがなければ動画については黙認。ただその“よほどのこと”があれば対処しますよ。」ということになるだろう。
「動画アップしていいよ!」と明言しないのは、結果として悪影響を及ぼすような動画がアップされた場合に対処するカードがなくなってしまうから、ということなのかもしれない。
だから暗黙の了解でうまいことやっていきましょ、ということになる。

鉄拳は格闘ゲームなのでその傾向が特に強いと思うのだが、PS4の登場でゲーム全体で大きく流れが変わった。PS4から直接TwitchやUstreamのようなサイトで配信できたり、YoutubeやDailymotionなどにアップロードできるようになったのだ。
PlaystationExperienceなどのイベントではゲームソフト開発者がこの機能に対して好意的な発言をしたり、暗黙の了解は明言に少し近づいたとも言える。
開発側はゲームの全部または一部分に配信や動画キャプチャの禁止区間を設けることができるので、配信やキャプチャが禁止されていない部分については動画を公開してもいいという反対解釈さえ可能になる。
しかしそれでもなお、実は「明言」はされていない場合が多い。

 ユーザーは動画をアップし、メーカーはそれが宣伝になるとみなせば黙認し、悪影響だと思えば削除申請をする。
今のところ、明言なき暗黙の了解のもとにゲームの動画に関してはうまくいっていると思う。
では何故こんな長文を今まで書いてきたかというと、今後うまくいかないかもしれないからだ。

その理由はTPP。「TPP?農業の問題でしょ?」というのが多くの意見で、「いや違う、実はいちばん問題なのは保険だ」と言う人もいる。一般的には全然話題になっていないのが著作権に関する問題だ。
TPPでは知的財産についてのルールも参加国で統一しようとしていて、その議論が行われている最中なのだが、その中に著作権侵害の非親告罪化の議論がある。
親告罪というのは被害者からの告訴があってはじめて訴訟になりうる罪で、現在の著作権侵害はこれにあたり、著作権者が告訴しなければ訴訟ははじまらない。
これを非親告罪にしよう議論がTPPで行われているとされており、そしてその内実は秘密交渉なのでわからない。

 もし非親告罪となるとどうなるかというと、今までゲーム動画はメーカーとユーザーの暗黙の了解によって、よほど悪質でなければ告訴などなく穏便に済まされていたが(ゲーム動画以外にもMADなども当てはまるだろう。)、非親告罪化、すなわち被害者の告訴なくとも無関係な人間による告発や検察の告訴で訴訟がはじまるようになれば、現在の暗黙の了解によるバランスは崩れてしまう。
極端な話、気に食わないやつのアカウントを調べて、著作権侵害を見つけたら告発したろ!みたいな事例が出る可能性さえある。
Twitterなどの普及で私達は以前よりも格段に簡単に画像や動画をアップできるようになっている。
ゲーム中に面白いシーンがあってスクリーンショットをTwitterにアップしたことがある人もいると思うが、もしそのゲームのメーカーが画像のアップに関して黙認しているのが現状なら、非親告罪化がなされると刑事責任を問われる可能性さえある、ということだ。
そして前述のように著作権関連の制度は難しく、ひょっとすると気づかないうちに著作権を侵害してしまっている可能性もある。それも非親告罪化がなされれば訴訟の対象になってしまう可能性がある。

これは恐ろしいことだと思う。
だからといって「非親告罪化すんな!」などと主張しようとは特に思わない。それは官僚や政治家がアメリカと綱引きして(少なくとも、綱引きするフリをして)決めることだと思っている。主張することが無駄だとは思わないが、その主張に効果があるとも思えないからだ。
逆に私がお願いしたいのは、ゲームメーカーなどの今まで暗黙の了解を保ってきた著作権利者に対して、だ。
いくつかのゲームでは既にプレイ動画のアップを条件付きで明確に許可している。GE2RBもそう。
暗黙の了解がうまくいかなくなる可能性がある今、暗黙の了解から明言へのシフトが必要なのではないか、というのが私の考えだ。



おわりに

ここまで引用部分込みで7000字も書いたらしい。読んでくれた方には感謝。
最初はふんわり書いて終わらせるつもりだったのだが、勢いでゴガガガッと書いてこの文字数になってしまった。推敲も一応したが、いかんせん文字数が多くて見落としもあるだろうし、甘い表現もあると思うので継続的に修正したいと思う。
最初にも書いたように私は法律に関して素人なので、誤りがあれば指摘していただけると非常にありがたい。というより、もっと詳しい人にわかりやすく書いてもらいたい。


初稿:2015/03/28
加筆:2015/03/29
修正:2016/05/08

2015/03/26

2015年春 青春18きっぷで飛騨高山へ行く(1日目後半・2日目・3日目)

飛騨一ノ宮からバスで高山駅へ移動した私。「氷菓」の聖地を巡りつつ、高山市街地の観光スポットを回ることにした。
聖地巡りで参考にした地図は飛騨一ノ宮観光協会の生き雛祭特設HPにある高山市公式のマップだ。
大きいサイズの画像にたどり着くのが意外と大変なので、リンクを貼っておいた。
印刷するなりスマホやタブレットに保存するなりして持って行くと便利だと思う。
この公式マップにないシーンもあるようなので、聖地巡りをしているブログなどから情報を得て書き足すのもよいかもしれない。

マップを見ながらルートを考える。Excelのソルバーを使えば最短ルートを見つけられるなあ、などと考えてはいけない。
取りこぼしのないように、わかりやすく北側から攻めてみることにした。

というわけで最初の目的地は作中では入須家の病院があるところだ。
しかし、行ってみるとそこは更地になっていた。どうやら移転したらしい。どこかのブログでもそのような記述があったので恐らく間違いないだろう。
残念、宮川に沿って南下しようと川へ近づいたところで上の写真。万人橋という橋の名前。
どこかで、というより作中で聞いた名前だ。ただし橋の名前はそれこそ「遠まわりする雛」くらいでしか出てこないが、あれは「長久橋」と「トウジ橋」だったはず。
帰宅後調べたところ、「万人橋家」が作中で名家の一つとして挙げられていた。恐らく記憶に残っていたのはそれだろう。

宮川沿いに南下すると、不動橋が見えてきた。

バレンタイン回で出てくる橋だ。

オープニングに出てくる木橋の場所はマップによればここのはずだが、どうも工事中のようだ。
写真下部にそれらしきもの(木橋の一部?)が写っている。

弥生橋から鍛冶橋方面を眺める。これもOPの1カットの景色だ。
もう少しズームしたほうが良かったかもしれない。

これもOPのワンカット。

宮川を離れ更に南下。日枝神社まできた。
作中では初詣に来る神社として登場する。

こうして書くと氷菓の舞台ばかり見て回っているように見えるかもしれないがそんなことはなくて、高山陣屋などの有名スポットもチェックしている。
0日目から1日目にかけて、列車内の座席で変な体勢で寝ていたせいか腰がものすごく痛くなってきた。時間もちょうどよくなってきたので、この日はここで切り上げ、平湯温泉へ向かうことにした。


平湯温泉へは「奥飛騨温泉郷」の名前の通り、高山から山の奥へ向かう。だいたいバスで1時間といったところだ。
意外と距離はあって、バス代は1500円ちょっとだった。普段均一216円のバスに乗っているのでちょっとびっくりした。
乗るバスは濃飛バスの新穂高線なのだが、途中のバス停の名前でいくつか私好みのものがあった。
一番のお気に入りは「日影」バス停。「日陰」ではなく「日影」なのが気に入った。対になっているわけでもないのだろうが、「日面」というバス停もあってこちらも何故か気に入った。
平湯温泉までの道は山道ということもあり険しく、周りには雪も積もっているのだが、さすが観光地というべきか道路はしっかりと除雪され、地面が見える。
途中のスキー場にも人の姿があるところを見ると、まだスキーができるのだろうか。

そんなこんなで平湯温泉に到着。記念に一枚パチリ。
「奥飛騨温泉郷」の名の通り、「温泉郷」の雰囲気があふれるいいところだと感じた。

今回私が泊まったのは旅館だ。「おっ、リッチメンゥー!」と思うかもしれないが、何の事はない、楽天ポイントのキャンペーンに乗っかっただけだ。
遅めの時間にチェックインしたこともあり、先に食事をいただく。
少食の私には量が多かったものの、とても美味しかった。特に飛騨牛、味覚が鈍感な私でもわかるくらい美味しく、そして柔らかかったのが印象的。
食事の後は待ちに待った温泉。普段アパートではシャワーを浴びるだけで済ませるので本当に温泉が楽しみだったのだ。
浴場に行く際に気づいたのだが、この時期の平湯温泉はオフシーズンなのか、他の宿泊客が見当たらない。ひょっとすると私以外宿泊者いないまであるんじゃないか、くらいの勢いだ。
もしや、と思い大浴場に着いて中に入ると、なんと誰もいなかった。温泉貸切だ。思う存分、ゆっくり浸からせてもらった。

風呂から上がり部屋に戻り、翌日の計画を練る。当初は高山を再び観光する予定だったが、1日目だけでだいぶ回れてしまった。
宿の方は新穂高ロープウェイのほうは景色がとてもいいと言っていたため、そちらもいいかもしれない、などと布団で時刻表とスマホとにらめっこしているうちに、眠りに落ちてしまった。

2日目。部屋の内線電話のモーニングコール機能を6時にセットしていたが、目がさめたのは4時。
バイトがある日に寝坊しないよう、バイトがない日も4時に一度起きている癖は岐阜県に来ても抜けていなかった。
もう一度温泉に浸かるのもいいが、やはりというか0日目から1日目の睡眠が足りていないようで眠くて仕方ない。
6時まで二度寝することにした。

6時に起床。そういえば天気予報で今日も雪だと言っていたなあ、と思い障子を開ける。

!!?!?!?
寝てる間に真冬の北海道にでもタイムスリップしたんじゃないかとさえ思った。一晩で一気に積もってしまったようだ。
何はともあれ朝食。晩御飯では飛騨牛を食べることができたが、朝食ではこれまた飛騨高山の名物だという朴葉味噌を食した。
これは朴の葉の上に味噌を乗せて焼いて食べるものなのだが、朴の葉の香りが食欲をそそる。
食べながら考えた結果、こうして雪が降ると高山の市街地もまた違った雰囲気になるのではないかが気になったので、予定通り高山へ戻ることにした。
新穂高ロープウェイも興味があるのだが、これはまたいつかあるかもしれない機会を楽しみにしよう。
食事を終え少しのんびりし、2日目出発。

1日目と平湯温泉のバスターミナルのほぼ同じ位置で撮影した写真が上の写真。
一晩でどれだけ積もったかがわかるだろう。

2日目は氷菓の聖地巡りよりも、高山の古い町並みをメインにみることにした。
天気が悪いからか、時間帯が昨日より早いからか、古い町並みに人の姿はまばらだ。
奥に見えるのは桜山八幡宮。昨日よりも濃く雪化粧した街並みが美しい。

街並みを見ながら歩いていると、再び雪が激しくなってきた。
こうなってくると、「氷菓」で雪の印象が強く残るあの場所にまた行ってみたくなる。

故に行く。再び不動橋へ。
この場所は作中で雪とともに描かれていた印象が強いので、どうしてもこの雪が強いうちに見ておきたかったのだ。

実は平湯温泉からのバスの中で、早めの電車で高山を発ち、名古屋に寄ってみようと決めたので残り時間は2時間弱。
地図を見ると駅の反対側に小高い展望公園があるようなので行ってみることにした。

行ってみることにした、なんて軽い気持ちで行ってみたはいいが、坂が思いの外キツく大変だった。
だがその苦労の甲斐のある景色を見ることができた。
眼下に広がるのは高山市街地、奥に見えるのは奥飛騨温泉郷方面の山だろう。
あの温泉郷は未だ濃い霧や雪の中のようだ。

再び痛み始めた腰と脚に苦労しつつ高山駅へ帰還。駅は改築工事中らしく、そのせいか待合室の広さも足りていないようだ。
私は青春18きっぷを使っているので普通美濃太田行きに乗るのだが、その一本前の特急ひだ名古屋行に乗る観光客でごった返していた。
工事の結果、駅がどのように変化するのか楽しみだ。

乗車したのは美濃太田行き。美濃太田から岐阜を目指し、岐阜から東海道線で名古屋へ行くというのが一つの手だ(往路の逆方向)。
ただ、折角なので太多線で多治見へ向かい、多治見から中央線で名古屋を目指すことにした。
この中央線は東京の「真ん中通るは中央線」の中央線と同じ、というか、東京から名古屋まで結ぶ路線を中央線と言う。
遠く秋葉原でちらりと見かけるオレンジ色の電車が走る線路をずっと辿れば一組のレールでここまでつながっているというのは面白い。

名古屋駅へ到着し、とりあえず夕食へ。ひつまぶしを食べようと思ったが高い上に並んでいたので、味噌カツを食べることにした。
私は味噌カツを食べるのが初めてなのだが、思ったより味噌の味が薄くて食べやすかった。
 名古屋へ来たはいいが、名古屋で何をするかは全くのノープラン、フリースタイルだ。
とりあえず名古屋といえば名古屋城だろう、ということで名古屋城を目指してみる。

地下鉄を乗り継いで市役所駅で下車。地上に出ると遠くでは何やらタワーが発光。調べるとテレビ塔らしい。
とりあえず地図を見て、名古屋城の方へ歩いてみるが…

遠い。どうやら正門へ行くには正しい道だが、もう観覧は終わっていて中には入れない。
外から見るぶんには公園の反対側のほうがいいようだ。

というわけで無駄に公園を一周。結構な距離あったように思う。
東京では皇居の周りをランニングする人がいるように、名古屋では名古屋城の周りをランニングする人が多くいた。

地下鉄で名古屋駅方面へ戻りつつ、途中下車しテレビ塔の近くまで行ってみた。
札幌にも同じようなタワーがあったような気がする。東京タワーはスカイツリーに役目を譲ったが、名古屋でも新しいタワーは建設されるのだろうか。

最後は東海道線の新快速で岐阜へ戻り、岐阜から往路と同じようにムーンライトながらに乗車。
またしても無理な体勢で無理な睡眠を取って体の節々が痛むが、なんとか横浜へ到着。
ここで一泊四日の旅は終了だ。


旅行を終えて

色々な初体験があった。岐阜県、愛知県を通過以外で降り立ち、観光するのは初めてだし、青春18きっぷを使うのもはじめてだ。ムーンライトながらもいつかどんなものか試してみたいと思っていて、それを叶えることもできた。宿泊を伴う一人旅も初めて。
色々な発見があった。高山の観光地としての美しさもそうだし、JR東日本とJR東海のアナウンスの微妙な差異のようにどうでもいいことも、名古屋はエスカレーターの右側を空けるらしいとか、名古屋の人はみゃーみゃー言わないとか。
いい経験であり、そして楽しい旅行だった。また高山にも行ってみたいし、他の場所にも行ってみたい。今後計画だけで満足し続けるのか、それとも今回のように実際行ってみたくなる場所が出てくるのか、それはわからないけれどもしどこかに行くのなら、今回の経験も活かしてもっと楽しい旅行にしたい。

2015年春 青春18きっぷで飛騨高山へ行く(0日目・1日目前半)

※2記事に分かれた長めの文です。氷菓聖地の写真だけ見たい方はスライドショーにしてYoutubeにアップしてあるのでそちらをどうぞ。

「趣味は何ですか」という質問をされることがある。アニメ鑑賞?ビデオゲームプレイ?読書?色々ある。
趣味が合いそうな人にはアニメやゲームの話をし、適当にお茶を濁したいときは読書という。
しかしもうひとつ趣味があって、これは他人にはあまりしたことがない。それは「旅行の計画をたてること」だ。

趣味は旅行計画の作成です、なんて言っても怪訝な顔をされて終わりだろう。
旅行が趣味ならまだしも、旅行の計画を立てるのが趣味というのはあまり理解してもらえない。
時刻表を見るのが楽しい、なんて言った日には変態扱いは避けられないまである。
そもそも何故計画だけで実行に移さないのか、という疑問が出てくる。
それは結局先立つものがなかったり(或いはあっても使ってしまったり)、時間的制約があったりするからだ。
色々計画を立てて、実行したのは結局、中学2年とかそれくらいに米沢、湯沢に行ったくらいだろう。
あの旅行も土日きっぷという超お得なきっぷがあって(今はない)金銭的にどうにかなったから行けたのだ。

計画だけで満足していた私だが、とある場所に、珍しく実際に行ってみたいと思うようになった。それが飛騨高山だ。
きっかけはアニメ「氷菓」なのは間違いない。
原作が推理小説だけあって、ストーリーが面白い。京アニ作画のキャラも良い。つまり全く隙がない。
そんな「氷菓」にハマり、アニメは5周し原作まで買った。
その「氷菓」、というか「<古典部>シリーズ」の舞台が高山なのだ。

飛騨高山の人には申し訳ないが、「飛騨高山観光」という選択肢は間違いなく存在するが、(特に日本人にとって)地味なのは否めないように思う。
恥ずかしながら高山が観光地だということすら無知な私は知らなかった。
ただ「氷菓」を見て高山の存在を意識し、観光地であることを知り、色々調べるうちになんというかその…
気になりはじめた。気になり始めたところで色々好条件が重なったので、実際に行ってみようと決めた。

この記事のタイトルには「0日目」とある。これはここまでの私の隠れた趣味の話を指すのではない。
今回の旅行ではムーンライトながらという夜行快速を使う。夜に東京を出て、翌朝大垣に到着する快速列車だ。
夜移動できるので、翌日から目一杯現地で移動できるというわけだ。
この列車、かつては毎日に運行されていたが、今では繁忙期の臨時列車になってしまった。
そしてちょうどこの3月下旬に運行があった。これが上述の好条件1つ目。
更にこれが快速というのがポイントだ。快速、ということは青春18きっぷで乗車できるというわけだ。
Twitterでの反応を見ると青春18きっぷの認知度は意外と低いようだが、これは1セット5回分11,850円で販売され、1回分につき1人1日全国のJRの普通・快速が乗り放題という切符なのだ。
5回分を1人で5日にわけて使ってもいいし、5人グループで1日間で使ってもいい。
青春18、とは言っても年齢制限はない。もう少しするとあの世で青春していそうなお年寄りでも、私のように青春とはかけ離れた生活を送っている者でも、だれでも使うことができるのだ。
長距離移動する時には(普通・快速に限るが)かなりお得な切符なのだ。これも春・夏・冬の繁忙期のみ販売され、今回の旅行の期間にも利用できた。これが好条件2つ目。
話を戻すと、夜行快速ということは高山に到着する前日から乗車することになる。そういう意味での「0日目」なのだ。

目的地は飛騨高山、利用手段はムーンライトながら。これがまず確定。
加えて、折角飛騨高山までいくので温泉に入りたいと考えた。どうせなら奥飛騨温泉郷まで行きたい…
という条件で計画を立てた。
旅行の計画が好きと言ってもそれをそのまま実行することに拘りはなく、ましてや一人旅なので出たとこ勝負だと思っている。
あちこちに時間の余裕を持たせているので臨機応変にいくつもりだ。

長い長い前置きを経て、ようやく本編に入る。いよいよ旅行当日だ。

深夜の、というほど更けてはいないが夜の横浜駅にやってきた。
まずは小田原までの切符を購入。青春18きっぷを使うのに何故?と思うかもしれないが、青春18きっぷ1回分はその日のみ有効なのだ。
つまり、横浜から青春18きっぷを使ってしまうと、日付が変わる小田原までで一枚使ってしまうことになるのだ。
よって、小田原までは別に切符を買って、日付が変わる小田原から先の分から青春18きっぷを使うのである。
先日の東京上野ライン開通で電光掲示板の行き先の前に「東京上野ライン」と表示されるようになっていたが、この時間は東京以北にいく電車はないらしく、そのスペースは奇妙な空欄になっていた。

東海道線下りホームへ。案内表示には先発の平塚止まり、次発にはムーンライトながら大垣行きの表示がある。
ホームにはまだサラリーマンの姿もあったが、平塚行きが出発すると、キャリーケースを持つ旅行者の姿が多くなったように感じられた。

そして定刻通りムーンライトながらが横浜駅に入線。
車両は185系。「踊り子」に使われている車両だ。以前乗った北斗星のようにベッドがあるわけではない。
普通の昼間走っている特急と同様、座席があるのみである。
明日の朝は早い。そして旅行は明々後日まで続く。ここで疲れを溜めないように早く眠りにつきたいところだ。
 しかしそうは問屋が卸さない、近くの席のアベックがペチャクチャと騒がしい。
照明が消えないと聞いていたのでアイマスクは持ってきていたが、耳栓は忘れてしまった。
しかたがない、できるだけ意識をその会話に向けないようにして目を瞑る…

が、そう試みれば試みるほど意識は研ぎ澄まされ、耳はその会話を拾う。
小田原からまた乗ってくる人がいてそこでまた目が覚めてしまうだろうし、とりあえず小田原までは起きて我慢することにした。

小田原着。既に日付は変わり、この旅行記としては「1日目」に入っている。
この先名古屋までの間、沼津、静岡、浜松に停車するが、此処から先は深夜帯ということもあり車内放送はしないそうだ。
周りの客への配慮も呼びかけられた。これで例の2人も黙るだろう…

が、そうは問屋が卸さない。しゃべる、しゃべる、しゃべる。
しかしいい加減寝ないと明日大変なことになりそうだ。ここから岐阜到着直前までフルに寝ても5時間も寝られない。
そしてどうせフルには寝られない。途中で目が覚める。
故になんとしても眠りにつかねばならない。そこで必殺技、妄想の発動だ。
色々と妄想していると俗な外界からの感覚はシャットアウトされ、脳内世界に集中できる。そしてそのまま寝ることができる。
この特技はほんとうに有効だ。妄想の対象さえ2次元という時点で色々と極地に至ってる感はあるが…
2次元といえば、最近…
なんつってる間にスヤッスヤっすよ。脳内世界がtrue world.狂って云々、以下略。

目が覚めた。電車は止まっている。眼鏡を掛け目を凝らすと、停車中の駅は浜松。浜松ではなんと30分も停車する。
これにはおそらく2つの意味があって、まずひとつは貨物列車に追い抜かれるため。
昼間は旅客列車ばかり見るが、一方夜は貨物列車の世界だ。
その証拠に、幾度と無く貨物列車が通過していく。
そして2つ目の理由は、時間調整だろう。浜松のような時刻表に書かれている停車駅以外にもいくつかの駅で長時間停車する。
そうしないと、大垣に早く着きすぎてしまうのだろう。

浜松停車中、ということはまだ寝る時間はある。ということでもう少し寝ることにした。
例の騒がしい2人組もさすがに夢の世界のようだ。そのまま起きてこなければいいのに。

再び目が覚める。時刻は4時半。またもやどこかに停車中のようだ。
窓の外を見ても駅名標が見えない。スマホのGPS機能を使うと、そこは共和駅というところだった。
愛知県に入り、名古屋はすぐそこなのだが、名古屋駅に着くまでには1時間近くかかる。
共和駅だけでなく、熱田駅の近くでもだいぶ停車していた。これも上述の時間調整のためなのだろうか。

列車は時刻通り進み、名古屋駅を出発。20分もすれば岐阜駅に着く。
名古屋は愛知県の県庁所在地で、岐阜は岐阜の県庁所在地。
いくら快速(特急型車両を使ってかっ飛ばしているから実質特急みたいなものか)とはいえ20分で県庁所在地を結ぶとは、近すぎるのではないかとも思ったが、よく考えればさいたま・東京・横浜もすごく近かった。千葉?知らない子ですね…
関西の事情はよくわからないが、名古屋と岐阜の関係はさいたま東京横浜の関係と同じようなものだと勝手に思っておくことにした。

岐阜駅についた。乗り換える高山本線の列車まで時間があるので外に出てみることにした。
左奥に見えるのは織田信長の像。人はまばら。案内図を見ると近くには神社がたくさんあるようだ。
1時間位余裕があるので、一番近くの神社まで歩いてみることにした。

それがここ、金神社。どういう神様を祀っているのかもわからないが、巡り合わせということでお参りする。
周りにはビルもたくさんあるのだが、その中に平然と現れる神社がある光景は面白いと思った。
駅から一番近い神社とは言えど、慣れない土地だからか地味に時間がかかってしまった。
少し早足で岐阜駅に戻る。見るとサラリーマン風の人が結構いる。どうやらここ岐阜は地域の中心都市というよりは、名古屋やひょっとすると京阪神のベッドタウンのようだ。

岐阜駅からは高山本線の普通・飛騨古川行きに乗車する。高山まで3時間ほどかかる長距離列車だ。
しかし車両はロングシート、いささか拍子抜けする。しかしその理由はすぐわかった。
この列車は高山の先、飛騨古川まで長距離を走るが、もっと手前、美濃太田あたりまでは学生や通勤のサラリーマンで車両はいっぱいだった。
美濃太田から先は一気にローカル線の風情。沿線には瓦屋根の建物が多く見え、なんとなく昭和っぽい雰囲気を醸している。

列車は高山へ向けて飛騨川に沿って谷を進んでいく。飛騨川は緑色っぽく、とても綺麗だ。
途中にはいくつも水力発電所があった。

列車が高山駅の一駅手前、飛騨一ノ宮駅に近づくと、急に雪が強く降りだした。
予定を変更してここで下車することにした。というのも、飛騨一ノ宮駅の近くも「氷菓」の舞台となった、いわば聖地があるのだ。

ここがまず一箇所目。駅すぐ近くの臥龍桜だ。
最終話に出てくるのでとても印象に残っているが、残念ながらまだ桜の時期ではない。桜が咲くのは4月下旬からのようだ。

そして二箇所目。飛騨一宮水無神社だ。ここも最終話(遠まわりする雛)に出てくる。
実際に生き雛祭りは4月上旬に行われているらしいが、残念ながら4月に訪れることは叶わない。
いつか生き雛祭りを見ることができる日もくるのだろうか、などと思っていると雪が一段と強くなってきた。
予定通り高山駅に直行したほうがよかったのではないかという考えが頭をよぎるが、いまさら言ってもしかたがない。まずは水無神社にお参りすることにした。
そうだな、何を願おう…
じゃあちょっと俗だが、

雪、止めーーー!!!

止んだ。
これは可能性感じざるを得ない。
上の画像は作中の生き雛祭りで歩いた川沿いに近い雰囲気のところだ。作中に出てくる地図と実際の地形が結構違うので、実際のところはわからないが…

折角晴れたのでもう一度臥龍桜のところへ戻ってみる。今度は雪に遮られずよく見える。
なるほど、この桜が満開になったらさぞ綺麗だろう。生き雛祭りは4月上旬、桜の開花は4月下旬。
両方を見たいものだが、なかなか大変そうだ。

高山本線の普通は本数が少なく、しばらく(というか夕方まで)列車がないので、高山まではバスで移動することにした。
いよいよ高山市街地に到着、続きは「青春18きっぷで飛騨高山へ行く(1日目前半・2日目・3日目)」で!