2017年4月23日日曜日

10万PV突破

初めての投稿から3年弱、皆様に支えられてつい最近10万PVを突破いたしました。
ありがとうございます。
趣味でやっているプログラミング関係のことを中心にしたブログですので、かなり不定期の更新になっています。下手したら更新が数か月開くこともザラでした。

ですが、最近はだいたい1日当たり100~200PVほどいただいているようです。1か月にしてだいたい4500PV程度。更新頻度が低く、しかも自分の備忘録としての側面が強いブログにしてはかなりPVが大きなほうだと思います。

参考までに、ここ1か月のPVランキングを示すと

1位WPFのScrollViewerやScrollBarのスクロール位置を同期させる2015/01/16339PV
2位ポケモン「サファイア」の時計を復活させる2016/01/22308PV
3位プロキシ設定とレジストリ2015/11/09231PV
4位WPFでタスクトレイ常駐型アプリを作る2015/11/12195PV
5位非同期処理とAggregateException2014/10/15167PV

てな具合です。

ScrollViewerの記事はここのところずーっと首位です。これがヒットするとは思っていませんでしたが、実はそれなりに需要があった記事なんですかね。
2位のポケモンのソフトのRTCをいじる記事は、最近PVをどんどん上げています。たぶん、近いうちにScrollViewerの記事を抜くのではないかなと思います(週単位でランキングを作るとすでに抜かれています)。記事を書いた当時はまだ任天堂はGBAソフトの電池の交換をやってくれていましたが、今はもうそのサービスは終了したそうなので、復活させるなら否が応でも自分でどうにかしなきゃいけないという背景もあるのかもしれません。
プロキシの記事は、自分がネットにソフトを初めて公開した件にかかわる話ですので、PVを伸ばしてくれていることはとても嬉しいです。

てな具合で、今後もぼちぼち自分のペースでブログを書いていこうと思います。
今後ともよろしくお願いいたします。

2017年4月22日土曜日

Visual Studio 2017でXamarin.Forms入門

「申し訳ないがJavaはNG」

この言葉を座右の銘に置く私としては、常にAndroidアプリ開発は戦いです。
AndroidはJava開発が最も基本で、C#で開発するにはXamarinなどの環境が必要です。

Xamarinは昔は有料だったうえ、ドキュメンテーションも少なく非常にとっつきにくいものでした。しかし、Visual Studio 2015にはオプションでXamarinをインストールできるようになり、ついに2016年にはMicrosoftに買収され、Visual Studio 2017ではモバイル開発の中核に置かれるようになりました。

というわけで、私もXamarin初心者ですが、VS2017もインストールしたことだし本格的にいじってみようと思います。

Visual Studio 2017のインストール時にXamarin関係のオプションを選択してインストールすると、プロジェクトテンプレートにXamarin.Formsが現れます。
そうするとテンプレートの選択が出てきます。
空のアプリを選択してOKを押します。
そして、プロジェクトをビルドして実行すると…
見事にエミュレーター上でAndroidアプリが動きました。

しかし、このプロジェクトテンプレートには問題が1つあります。
上の画像にも書きましたが、最初のページに相当する「MainPage.xaml」がどのプロジェクトにも含まれていません。
そのため、Visual Studioがコードの依存関係等を理解できずに、IntelliSenseがほとんど働きません。編集しているとコードのいたるところに参照が解決できずに波線が引かれます。とても鬱陶しいです。

この解決には苦労しましたが、とりあえず次のようにやるとできるようです。

まずは、ソリューションにXamarin.Forms用のPCL(Portable Class Library)を追加します。
次は各プラットフォームのプロジェクトでこのプロジェクトへの参照を追加します。
さっき追加したプロジェクトに適当なMainPage.xamlを作ります。
このテンプレートには、XAMLだけでなくコードビハインドにも余計なコードが書いてあるので注意してください。コードビハインドで架空のViewModelクラス(ContentPageViewModel)をインスタンス化しようとしてくるのでコンパイルエラーが出ます。
public partial class App : Application
{
    public App ()
    {
        InitializeComponent();

        //MainPage = new XamarinFormsTest.MainPage();
        MainPage = new XamarinFormsTest.PCL.Views.MainPage();
    }

    protected override void OnStart ()
    {
        // Handle when your app starts
    }

    protected override void OnSleep ()
    {
        // Handle when your app sleeps
    }

    protected override void OnResume ()
    {
        // Handle when your app resumes
    }
}
最後はApp.xamlのコードビハインドでMainPageのインスタンスを自分が追加してやったPCLのほうへ書き換えてやればおkです。もとあったMainPage.xamlはいらないので削除してしまってもよいでしょう。
これでMainPageをPCL上に移動することに成功しました。

PCL上にUIを置けるということは、Nugetなどを活用して適当なライブラリを入れることもできるということですので、例えばXamarin.Formsに対応しているMVVMライブラリ「Prism」を入れてみましょう。
そうすれば、ほとんどWPFと変わらずにXAML+C#でAndroidアプリを開発することができます。
このアプリでは、スライダーを 動かすとそれに追従して上に表示されている数字が変わります。「ADJUST TO 50」ボタンを押すと数字とスライダーが50の位置に移動します。
XAML+C#のデータバインディングのデモをするにはこれくらいやれば十分でしょう。

例えばコントロールの配置が「HorizontalOptions」「VerticalOptions」とかいう名前のプロパティだったりと、若干WPFと違うところもありますが、まあこれくらいならフィーリングでわかるレベルでしょう。
あとはXAMLデザイナーでリアルタイムに配置の絵が表示される機能は内容ですが、この程度ならば個人的にはまあギリギリ許容できます。

これくらいWPFの開発にそっくりだと、普段からWPFで開発している身としてはとてもありがたいですね。

というわけで、いろいろといじってみようと思います。はい。

2017年4月18日火曜日

最強のWPF MVVMインフラ「Livet」をVS2017で使う

世の中的にはWindows開発と言えばUWPとかなのかもしれませんが、まだまだレガシーなWindowsデスクトップアプリが滅びる様子はありませんよね。
そのレガシーな中でも最も近代的なプラットフォームと言えばやはりWPFで、WPFでアプリケーションを作るのならばやはりLivetは欠かせません。

Livet - ProjectHome

しかし、LivetはVS2015対応としてリリースされたver.1.3を最後に更新されておりません。
作者自身もVS2015対応版がLivet 1.xの最終リリースとする旨の発言をしており、今後はLivet2を開発すると言っています。

ugaya40/Livet2 - GitHub

しかし、現時点でLivet2のLastest commitは2015年8月。Livetの最大の武器ともいえるプロジェクトテンプレート付きのインストーラはおろか、正式リリースさえされていない状態です。このような状況ではVS2017対応は絶望的です。

そうすると、何とかして自力でLivetをVS2017にインストールしなければなりません。

さて、VS2013とVS2015がリリースされた直後も、自力でLivetのプロジェクトテンプレートを組み込んでいた漢たちはいました。

最強のWPF MVVMインフラ「Livet」をVS2013で使う
最強のWPF MVVMインフラ「Livet」をVS2015で使う

Livet自体もこの時からほとんど進んでいませんし、こちらのページで紹介されているバッチファイルをちょっと改造すればいけるでしょう。

の前に、コードスニペットを改良しておきます。
本来、その改良はVS2015対応でやるべきでした。

VS2015と同時にリリースされたC#6でnameof演算子が導入されています。この、INotifyPropertyChangedインターフェースの実装に使ってくださいと言わんばかりの機能を通知プロパティのスニペットに使わない理由は無いでしょう。
ちなみに、.NET4.5からはCallerMemberName属性を使うことで自動的に呼び出し元のプロパティ名を引数としてメソッドに引き渡す機能があるので、通知プロパティの実装にそれを使う人も多いようです(Livetももちろんそれに対応しています)。しかし、「書いてもいないものが勝手に生成される」という気持ち悪さから私はこの言語機能を使いたくないので、nameofを使ったコードを書くことにしています。

というわけで、GitHubからダウンロードしたLivet-master\Installer\Files\Snippets内のLivetProperty_NET45_CSharp.snippetは削除して、LivetProperty_NET40_CSharp.snippetをnameof演算子に書き換えておきましょう(VBも必要があればやっておくといいと思います)。
<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2008/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>Livet プロパティ</Title>
      <Shortcut>lprop</Shortcut>
      <Author>Livet Project</Author>
      <Description>プロパティを作成します</Description>
      <SnippetTypes>
        <SnippetType>Expansion</SnippetType>
      </SnippetTypes>
    </Header>
    <Snippet>
      <Imports>
        <Import>
          <Namespace>Livet</Namespace>
        </Import>
      </Imports>
      <Declarations>
        <Literal>
          <ID>type</ID>
          <ToolTip>プロパティの型</ToolTip>
          <Default>string</Default>
        </Literal>
        <Literal>
          <ID>name</ID>
          <ToolTip>プロパティ名</ToolTip>
          <Default>MyProperty</Default>
        </Literal>
      </Declarations>
      <Code Language="csharp">
<![CDATA[
#region $name$変更通知プロパティ
private $type$ _$name$;

public $type$ $name$
{
get
{ return _$name$; }
set
{ $end$
if(_$name$ == value)
return; 
_$name$ = value; 
RaisePropertyChanged(nameof($name$));
}
}
#endregion
]]>
      </Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>
最後に、上記のVS2015版のサイトのbatファイルの「2015」を「2017」に置換してから実行してやればOKです。
@echo off
cd %~d0%~p0

@echo on
echo copy snippets
xcopy /I /Y .\Files\Snippets\*_CSharp.* "%UserProfile%\Documents\Visual Studio 2017\Code Snippets\Visual C#\My Code Snippets\Livet"
xcopy /I /Y .\Files\Snippets\*_VB.* "%UserProfile%\Documents\Visual Studio 2017\Code Snippets\Visual Basic\My Code Snippets\Livet"

echo project templates
call :copy_project_template_csharp Livet_WPF4.0_CSharp
call :copy_project_template_csharp Livet_WPF4.5_CSharp

call :copy_project_template_vb Livet_WPF4.0_VB
call :copy_project_template_vb Livet_WPF4.5_VB

echo item templates
call :copy_item_template_csharp LivetInteractionMessageAction_CSharp
call :copy_item_template_csharp LivetMessage_CSharp
call :copy_item_template_csharp LivetModel_CSharp
call :copy_item_template_csharp LivetViewModel_CSharp
call :copy_item_template_csharp LivetWindow_CSharp

call :copy_item_template_vb LivetInteractionMessageAction_VB
call :copy_item_template_vb LivetMessage_VB
call :copy_item_template_vb LivetModel_VB
call :copy_item_template_vb LivetViewModel_VB
call :copy_item_template_vb LivetWindow_VB

echo simple install completed!!!
pause

:copy_project_template_csharp
xcopy /I /E /Y .\Files\Templates\%1 "%UserProfile%\Documents\Visual Studio 2017\Templates\ProjectTemplates\Visual C#\%1"
exit /b

:copy_project_template_vb
xcopy /I /E /Y .\Files\Templates\%1 "%UserProfile%\Documents\Visual Studio 2017\Templates\ProjectTemplates\Visual Basic\%1"
exit /b

:copy_item_template_csharp
xcopy /I /E /Y .\Files\Templates\%1 "%UserProfile%\Documents\Visual Studio 2017\Templates\ItemTemplates\Visual C#\%1"
exit /b

:copy_item_template_vb
xcopy /I /E /Y .\Files\Templates\%1 "%UserProfile%\Documents\Visual Studio 2017\Templates\ItemTemplates\Visual Basic\%1"
exit /b
これで見事VS2017に追加されました。めでたしめでたし。


2017年3月6日月曜日

aitendoのリチウムポリマー電池を使ってみる

お久しぶりです。

最近、ふと思い立ってリチウムポリマー電池を買ってみることにしました。
リチウムポリマー電池とは、 リチウムイオン電池の一種です。電池の電解質にポリマー高分子を使っているため、リチウムイオン電池に比べて比較的安全なようです。

リチウムイオン電池の最大の魅力と言えば、そのエネルギー密度です。ニッケル水素電池などと比べると、非常に小型軽量で高容量の電池が作れるため、最近のパソコン、スマートフォン等の持ち運び性が重要な電子機器の電池はたいていリチウムイオン電池ですよね。

しかし、リチウムイオン電池はそのエネルギー密度の大きさや電解液が可燃性などの理由から、ニッケル水素電池などに比べてかなり危険です。よく燃えます。最近ではSamsung Galaxy Note 7のバッテリー発火事故は記憶に新しいですし、そのちょっと前にはボーイング787のバッテリー発火事故なんていうのもありました。



特に過充電は非常に危険で、上記の動画のように勢いよく火を噴きます。

過充電による発火メカニズムなどの詳しいことは省きますが、このような事故を起こさないためには充放電をしっかり管理してあげる必要があります。

というわけで、世の中にはリチウムイオン電池の充電を管理するICというのも出回っています。それを使えば、下手に自分で回路を作ったりプログラムで制御するより安全にリチウムイオン電池が扱えるでしょう。

比較的入手性の良さそうなリチウムイオン電池(リチウムポリマー電池)と充電制御モジュールは、aitendoで売っています。
上に挙げたのは300mAhの電池ですが、aitendoでは3種類(110/300/850mAh)のリチウムポリマー電池を売っているようです。

ちなみに、実際に買ってみて驚いたのですが、この電池思っていた以上にコンパクトでした。すげえ。


さて、肝心の充電制御モジュール「CHR4056-MCU1A」ですが、aitendoのサイトには具体的なことが「TP4056使用」としか書いてなくて、「過電流出力保護チップ搭載」と言うもののその具体的な型番も書いていなければ、モジュールの回路図も使い方も書いていません。さすがaitendoクオリティとでも言うところでしょうか…。せっかくですので、買ってみて回路図を起こしてみました。



たぶんこんな感じです。コンデンサの容量はわかりませんが、容量が重要なコンデンサはあまりなさそうです。

TP4056の周辺はTP4056でググるとよく出てくる感じの回路です。電源5Vとバッテリー陽極の間に入って充電電流をコントロールしてくれます。データシートを見ると詳しく書いてありますが、電圧が低いうちは定電流制御をし、電池の電圧が4.2Vに達すると定電圧制御をしてくれるようです。
定電流制御をする電流はR3で決まります。最大1Aで、その時の抵抗値は1.2kΩになります。私はUSBを想定して400mAの3kΩに取り換えました。

さて、問題の過電流出力保護についての回路です。
これには2つのチップが使われていますが、DW01というICのほうがその頭脳になります。FS8205AはただのFETです。
ただのFETではあるのですが、2つFETが、しかもドレイン同士がつながっているへんてこな回路になっています。ここでポイントになってくるのがこのFETに存在する寄生ダイオードです。DW01がOC端子をHigh(>Vth)、OD端子をLow(<Vth)出力すると、上記回路図の左側のFETがONになり、右側のFETはOFFとなります。しかし、寄生ダイオードを経由して2,3番ピンから6,7番ピンへの電流ならばは流すことができます(逆方向は無理)。すなわち、充電する方向のみへの電流を流すことができる状態になっていると言えます。
逆にOCをLow、ODをHighとした場合は放電する方向のみに電流を流せまし、両方Highにすれば両方向へ電流が流せます。もちろん両方Lowにすれば両方向電流を止められますよね。なかなか面白い回路です。

OCのみHighになった場合の電流方向

充電や放電を止めたり許可したりする方法はわかりました。では、どうやって電流を検出しているのでしょうか。
ヒントはCS端子にありました。
FETにはON抵抗がありますから、両方のFETがONになっていると仮定すると、CS端子は放電時にはGND+2×R_on×Iの電圧がかかります。この電圧を測ることで過電流を検出しているようで、GNDとの電位差が150mV以上を10ms、または1.35mVを300usで電流を遮断するように作ってあるそうです。
データシートを見るとFS8205AのR_onは20mΩ程度なので、およそ3.75Aの電流で過電流検知をしてくれる、といったところでしょうか。

ついでに、このICはVCCを測ることで過充電と過放電も監視してくれているようです。4.25Vで過充電検知、2.40Vで過放電検知をするようです。
なかなかに賢いICですね。

ちなみにですが、R5とC2の回路はリプル除去(ローパスフィルター)が目的のようです。負荷変動などで電池の出力電圧が変わっても、DW01に与える電源電圧の変化をできるだけ抑えるようにするために付けていると解釈できます。


なかなか素晴らしいモジュールだということがわかりました。
リチウムイオン電池をいじってみたければ、とりあえず電池とセットでこのモジュールを買うとよいでしょう。

しかし、自分の回路に組み込もうとなると、モジュールをそのまま載せたのでは見栄えが悪くなりますよね。あと重要なことなのですが、このモジュールのOUT+、B+などの端子は2.54mmピッチではありません。ピンヘッダなどを付けてユニバーサル基板やブレッドボードに取り付けようと思ってた皆さん、残念でした。

そうすると、皆さんは自前でカッチョイイ充電モジュールを作ろうと考えますよね。大丈夫です、私もそう考えます。ですが、TP4056DW01はaitendoで見つかりますが、FS8205Aはなかなか扱っている場所は無さそうです。
そんなあなたに、代替としてBR8205というFETモジュールがaitendoで売っているのでオススメしておきます。FS8205Aと同じようにFETが縦に2つつながったもので、使用目的も同じく充電制御に使うためのもののようです。R_onはFS8205に比べたらほんの少しだけ高そうですが、まあ問題になるほどではないでしょう。ピン配置やパッケージが違うことにさえ注意すれば、十分に使えそうです。


最初説明した通り、リチウムイオン電池はその容量密度は非常に魅力的であるものの、扱いを誤ると発火などの危険があり、どうしても敷居が高い電池です。

今回は、aitendoの充電制御モジュールを解剖することによって、リチウムイオン電池の充放電管理の回路やICを学びました。これをうまく使いこなせば、より電子工作ライフが充実してきそうです。

2016年10月5日水曜日

ポケモンGOのポッポマラソンに必要なアメ数を計算する。

最近ブームが去りつつあるような気もするポケモンGOですが、私はいまだに楽しく遊んでいます。
しかし、トレーナーレベルが20以降になるとレベルアップに必要な経験値が非常に大きく、なかなか伸び悩んできました。


というわけで、ポケモンGOでトレーナーレベルを上げるには、効率の良い経験値稼ぎが必要です。そこで行われる方法がポッポマラソンなわけですね。
ポッポ、ビートル、キャタピーは比較的入手性がよく、また進化に必要なアメ数がとても少ないです。進化で得られる経験値は500EXPと非常に高く、また、その経験値を入手するタイミングもコントロールできるため、しあわせタマゴで経験値を倍増させている30分間に集中して進化させ、経験値を荒稼ぎするのがいわゆる「ポッポマラソン」なわけです。

しかし、しあわせタマゴは貴重なアイテムであるばかりか30分という制限時間まであり、なおかつ進化にはアニメーションが付きまとうため、最大限手際よく30分間ポケモンを進化させ続ける必要が出てきます。


アニメーションの時間はおおよそ25秒程度、操作をするのに必要な時間を加味して、30分間ではおおよそ60~70匹程度のポケモンを進化させられることができます。すなわち、70匹程度ポケモンが進化させられる状態にしたうえでポッポマラソンを開始させなければなりません。しかし、進化やポケモンを博士に送る(以下、『D進』と呼ぶこととする)ことでさらにアメを得られるため、それに必要なアメの数はそう簡単に暗算できるほどのものでもありません。もちろん進化させるのはポッポだけでないでしょうから、今、自分の手持ちの中で進化できるポケモンの数を管理するのは頭の中だけでできるようなものでもありません。

というわけで、ポッポマラソンに必要なアメ数を計算し、管理する必要が出てきます。

アメは、ポケモンを進化させることで1つ、ポケモンをD進させることで1つ手に入れることができます。すなわち、ポッポマラソン中にもどんどんアメが増えていくわけです。そのことを、Excelを使って管理してみましょう。


まず立式ですが、現在持っているアメの数を$c$、進化に必要なアメの数を$c_e$とします。進化させながらだと進化させた直後に1個アメが手に入りますから、実質進化に必要なアメの数は$c_e-1$個になります。というわけで、進化可能数$e$は
\[e=\left\lfloor\frac{c}{c_e-1}\right\rfloor\]
となります。$\lfloor\rfloor$は床関数ですね。与えた数字以下の最大の整数を返す関数です。


しかし、この式では不十分です。
例えば11個アメを持っていた場合、この式では進化可能数が1になってしまいます。そうです。「実質進化に必要なアメ数」と言いましたが、進化で得るアメは、その進化では使えないですね。 その分の項が入っていませんでした。
これはどう入れるかというと、「最後の進化で得るアメによる進化可能数の上昇」を差し引いてやればいいわけです。最後の進化で得るアメによる進化可能数の上昇というとややこしいかもしれませんが、すなわち$1/c_e$です。すなわち、完成した式は
\[e=\left\lfloor\frac{c}{c_e-1}-\frac{1}{c_e}\right\rfloor\]
と書くことができます。

ただ~し、この式にはまだ1つ問題があります。$c=0$のときに、$e$がマイナスになってしまうんですね。例えば$c_e=12$とすると$e=\lfloor-0.08333...\rfloor=-1$となるわけです。ですので、まあせこいですけど絶対値を取ってから床関数にでも与えれば大丈夫でしょう。床関数の中身が負になる場合はあっても、それが-1以下になることは無いですから。
\[e=\left\lfloor\left|\frac{c}{c_e-1}-\frac{1}{c_e}\right|\right\rfloor\]
ちなみに、Windowsの多くの処理系の小数型から整数型への変換やExcelのROUNDDOWN関数では0方向への丸めとなります。すなわち、正の数に対しては床関数になりますが、負の数に対しては天井関数となるわけです。なので、そのようなもので処理する場合は、このように絶対値をわざわざとる必要はありません。


さて、この式の何がいいかというと、進化直後にD進するときの式にも簡単に転用できるからです。
進化直後にそのポケモンをD進させた場合は、進化とD進で2個アメが手に入りますから、実質進化に必要なアメの数は$c_e-2$個になります。しかし、それでは進化やD進で発生したアメをそのポケモンの進化に使えてしまうことになるので、その分を差し引いておく必要があります。まあ、ついでに負の数になっちゃう問題も込々で式を立てると
\[e_{D進}=\left\lfloor\left|\frac{c}{c_e-2}-\frac{2}{c_e}\right|\right\rfloor\]
となりますね。


「進化させたり、それをD進させたりして、それで生まれるアメをまた再び進化に使う」という考えは手続き的で、このように1つの数式で進化可能数を求めることはできません。どちらかと言えばプログラムでループを回すようなイメージになってしまいます。
ですが、このような「実質的に進化に必要なアメ数」という考え方と、その考えで起こる問題に対する修正項を加えるという考え方で1つの式にすることができ、簡単にExcel等で計算できるようになりました。


あと少しで70匹になるぞ…。

2016年9月22日木曜日

Google Driveのホスティングサービス終了によるSyntaxHighlighter周りの修正

3か月くらい前にSyntax Highlighterが正常に動作しなくなっていたため、その修正をした旨の記事を書きました。

そして、昨日久々に記事を書いて、いくつか自分の過去記事を巡回していたら

ま た 動 か な く な っ て る じ ゃ ね え か

ちきしょーめ、なんかウェブページを開くとダイアログが出てきてソースコードが正常に表示されねえぞ!
こういうことで時間を取られるのは本当に面倒ですが、正常に動作しないブログはいろいろと問題ですので原因の究明と対応が必要になってくるわけです。

いろいろ調べていると、どうもGoogle Drive側に問題があるようです。
Google ドライブでウェブページをホストする
ああ、なんということでしょう。3か月前にドヤ顔で「Bloggerがhttps以外を締め出したからSyntaxHighlighter作った人のホスティングサービスが使えなくなった!だからGoogle Driveに置くことで解決してやったぜ!」って言っていたのに、その2か月後にそのサービスが終了してしまうとは…。どうもホスティングサービスの終了は結構前から予告されていたようで、それに気づかなかった私が情弱だったようですね…。

代替サービスをいろいろ調べましたが、どうもDropboxやOneDriveなどの他のクラウドストレージサービスのホスティングサービスはイマイチのようですね。うーん…。

というわけで行きついたのがFirebaseでした。
ウェブ関係にはめっきり弱い私ですから、明らかに私の手に余りそうなサービスですが、とりあえずホスティングに関してまとまった記事がちらほら見当たりましたので、それに従って挑戦してみることにしました。

というわけで、10分くらいいろいろ戦いながらやってみましたが、比較的簡単にできました。
詳細はググっていただくとして、Node.jsをインストールしてからnpmでFirebaseのクライアントをインストールし、ローカルの適当なフォルダをFirebaseのフォルダに指定した後でpublicフォルダにSyntaxHighlighter周りのファイルを入れてデプロイすれば、そのフォルダがインターネット上に公開されるようになります。そして、FirebaseのサイトからホスティングのURLを確認し、BloggerのテンプレートのURLをGoogle Driveからこちらに変更してやれば完了です。めでたくコードがハイライト表示されるようになりましたとさ。言うまでもなく、Firebaseはhttpsに対応しております。


ふぅ。また3か月後に、今度はFirebaseのサービス終了みたいなお知らせ見たら私は泣くぞ…。

2016年9月21日水曜日

RailwayMap 0.1.0

さて、ついに公開にこぎつけました。

RailwayMap ver.0.1.0

まだ粗削りですが、一応バージョン0代として公開してもいいかなということで、公開します。

鉄道地図を描きたいことって無いですか?ありますよね?
ですが、なかなかいいソフトが無いです。白地図ソフトみたいなものや、Yahoo地図のように、「鉄道路線の線が引かれただけの地図」ならありますが、任意の区間を任意の色で塗って、などといったことはなかなかできません。
例えば、地元の路線地図を描きたい、各社の鉄道ネットワークがどのようになっているのか見てみたい、乗りつぶしマップを描きたい、鉄道路線の研究をしたのでカテゴリごとに塗ってみたいなど、いろいろな鉄道地図を描きたい理由があると思います。

そんな(主に自分の)ニーズに応えるのがこのRailwayMapです。


任意の区間を任意の色、太さ、大きさで描くことができます。
路線データは国土地理院の国土数値情報からユーザー自身でダウンロードしてきてください。

国土数値情報 鉄道データ

現状最新版が2015年版のようですが、2015年版は正常に読み込めません。2014年版とはデータ形式が変わったようです。気が向いたら対応します。2014年版を使ってください。
このデータは、日本の鉄道・軌道全路線が網羅されておりますので、JR在来線、新幹線から路面電車、モノレール、ケーブルカー、トロリーバス、ガイドウェイバスまで全部描画することができます。
メニューのファイルからデータを読み込めば、私の環境ならば15秒くらいで右側にツリー構造が現れます。そして、チェックボックスをいじったり、色や太さなどをいじれば好きなように地図が描けるというわけです。

細かな注意点はZIP内のReadMeを読んでもらうとして、とりあえずQ&Aだけこちらに並べておきます。

Q1.このソフト重いんじゃない?よく固まるぞ!
A1.何十万もある点をプロットするので仕方ありません。諦めてすごいCPUやつよいGPU、でかいメモリを買ってください。それでもだめなら諦めてください。(タスクマネージャー等でこのソフトのCPU使用率が1コア分より低いにも関わらず固まる場合はバグの可能性があります)
Q2.地図の形は変えられないの?
A2.線の太さや縮尺は変えられますが、形はメルカトル図法での出力になります。モルワイデ図法や正距方位図法、ボンヌ図法などでの出力はできません。
Q3.海岸線や緯線経線、縮尺などは描き出せないの?
A3.描き出せません。鉄道路線だけです。現状、実装の優先度はかなり低いです。
Q4.地図は画像ファイルに保存できないの?
A4.できません。できたら実装したいなって思っています。今のうちはPrintScreenしてください。
Q5.一生懸命設定した路線の色や表示/非表示の設定は保存できないの?
A5.できません。できたら実装したいなって思っています。
Q6.Raiload Linesの一番末端のノードの意味がわからない。どのノードがどの区間なのよ。
A6.XMLファイルに何駅と何駅の間のデータか書いてないので、仕方なくデータのIDの順序で並べています。そのうち手は入れたいとは思っていますが、見込みは立っておりません。
Q7.駅名が辞書順で並んでるのはクソ。駅順に並び替えてくれ。
A7.僕もクソだと思いますが、駅順はXMLファイルに含まれていないのでとりあえず今のところこれで我慢してください。
Q8.同じ駅が同じ路線に重複して存在している。例えば東海道新幹線には三島駅と新大阪駅が2つある。バグでは?
A8.バグではありません。元のXMLにも2つあります。理由はよくわかりません。

てなわけで、よろしくお願いします。
現在開発段階の途中で公開したような形なので、そのうちいろいろなところを仕上げていくつもりです。モチベーションが保てるかどうかはわかりませんが。