Hugoへの移行失敗

  • 投稿日:
  • by
  • カテゴリ:

このブログはMovableTypeを使っている。そろそろ限界かと思い、最近評判がよさそうなHugoへの移行を試みた。

MovableTypeからHugoへの移行

MovableType2Hugoは、mysqlのデータベースからMovableTypeのデータを取り出してHugoの形式で出力してくれる。

私はレンタルサーバを使っているので、まずはレンタルサーバのデータベースをローカルPCのmysqlにコピー。 それからMovableType2Hugoを実行した。

残念ながら日本語をうまく処理できないらしく、出力結果は「???」だらけ。

MovableTypeからJekyllへの移行

次に、Jekyllを介してHugoに移行することを考えた。 前項で作ったmysqlのデータベースに対し、JekyllImportを実行。

結果はやはり「???」だらけ。

MovableTypeからWordPressへの移行

MovableTypeからの脱出口として三番目に考えたのはWordPress。 レンタルサーバにWordPressをインストールし、MovableTypeからのインポートを行うプラグインをインストール。 MovableTypeからエクスポートしたデータを問題なくインポートできた。

WordPressからHugoへの移行

WordPressのプラグインとしてWordPress to Hugo Exporterをインストールし、有効化。

"Parse error: syntax error, unexpected T_STRING"というエラーが出て有効化できなかった。WordPressのバージョンとプラグインのバージョンが合っていなかったためか。

WordPress to Jekyll Exporterも同じエラーでダメだった。

WordPressからJekyllへの移行

ローカルPCのmysqlデータベースに対してJekyllImportを実行してみたら、これはうまくいった。

JekyllからHugoへの移行

Hugoのimportコマンドを使い、成功。 MovableType -> WordPress -> Jekyll -> Hugoというルートでようやく移行できた。

コメント?

しかし、ここまで来て大きな問題に気づいた。コメントが移行できていない。 移行したファイルにはコメントが入っているが、これを表示してくれるHugoのテーマがなさそうだ。 そもそもHugoは(Jekyllも)静的ファイルを出力するものなので、コメントはデフォルトではdisqusになっている。移行したコメントをdisqusのシステムに載せるのは無理なので、記事の一部としてコメントを表示するよう、テンプレートを書き換えなければならない。

テーマ

Hugoのテーマはたくさんあるが、好みにあうものが見つからなかった。 トップページに最近の記事が数個表示されるタイプは、各記事の一部がHTMLが無視された状態で表示されるものばかり。記事の全体をきちんと表示してくれるものがほしい。自力でなんとかするしかなさそうだ。

断念

結局、Hugoへの移行はいったん諦めることにした。コメントやテーマの問題は、Hugoの人気が拡大すれば解決するかもしれない。もう少し様子を見てみようかと思う。

Gambarumeter v0.4リリース

  • 投稿日:
  • by
  • カテゴリ:

ランナー向けAndroidアプリのGambarumeterを久々にバージョンアップした。

今回のリリースで、スマートフォンのアプリで記録を確認できるようになった。スマートウォッチでのGPSの計測もほぼ正確になった。

前回のリリースは2015年3月なので、1年半空いてしまったことになる。 Moto 360 SportでのGPSの精度がどうしても上がらず、解決に時間がかかってしまったこと、クローズドソースのアプリに昨年半年ほど時間をとられたことが大きな原因だ。

まだ解決すべき問題は多く、ランナー向けのGPSアプリとしてGarminに対抗できるものにはなっていない。しかしAndroidアプリとしては、競合するRuntasticRunkeeperよりこちらのほうが優れている面もある。地道に改善していきたい。

Gambarumeterリリース

  • 投稿日:
  • by
  • カテゴリ:

GambarumeterをGoogle Playでリリースした。

Android Wear搭載スマートウォッチで動作し、心拍数、歩数、距離を計測する。
モトローラのMoto 360では心拍数と歩数、ソニーのSmartWatch 3 SWR50では距離と歩数を計測できる。

Moto 360には現在はメタルバンドとレザーバンドのモデルしかない。これでは走るときに使えない。
しかしFunWatchBandsでシリコン製のバンドが売られている。

Moto 360の心拍計はバッテリをあまり使わない。10時間連続で使っても70%残っている。 SWR50はGPSで距離を計測すると1時間で70%になる。使えるのは3時間程度になる。

タッチ操作はランナーにとってあまり使いやすいとは言えないので、現時点でこのデバイスはGarminの代わりにはならない。しかしスマートフォンを持って走るよりはいいだろう。

ソフトウェアの複雑性と「銀の弾丸」

ある研究会で話す機会があった。ブルックスの「銀の弾丸などない」を素材に1990年代以降のソフトウェア開発の発展を語ってみた。要旨は以下の通りで、プレゼン資料はこちら


フレデリック・ブルックスは、1975年に刊行された著書『人月の神話』において、「遅れたソフトウェアプロジェクトに人員を追加投入すると、さらに遅れる」という法則を指摘した。既存メンバーと追加メンバーとのコミュニケーションが必要になり、人員追加の効果が相殺されてしまうためだという。

また、ブルックスは1986年に「銀の弾丸などない」という論文を発表し、ソフトウェア開発の生産性を劇的に改善する方法(狼男を鎮める銀の弾丸)はない、とも主張した。ソフトウェア開発の本質は抽象的な概念構造体の構築であり、技術的な改善が入り込みにくい領域だから、という。

ソフトウェアの特性としてブルックスは複雑性・同調性・可変性・不可視性の四つを挙げる。同調性や可変性は複雑性を増加させる要因とされているので、この四つの特性は実質的には複雑性と不可視性の二つに整理できる。

ブルックスの時代から現在まで、ソフトウェア業界はどのように変化してきたか。「銀の弾丸」は登場しただろうか。

■銀の弾丸

「銀の弾丸」がこれまでに飛んできた方向は大きく三つに分類することができる。開発プロセス、プログラミング技術、インターネットである。

(1) 開発プロセス

要件定義、設計、実装、試験という開発の工程をそれぞれ一回だけ実施する伝統的なウォーターフォール型に対し、全工程を何度も繰り返すインクリメンタル型が提唱された。これによりユーザーと開発者のコミュニケーションギャップを最小化し、フタをあけてみたら期待と全くちがうものが出てきた、などといったことがないようにする。

また、Linuxの開発プロセスを観察したエリック・レイモンドは、ソースコードを公開して優秀な開発者の協力を得る、という全く新しいバザール方式を発見した。

インクリメンタル型は、ブルックスが指摘したソフトウェアの可変性への対処として、いくらか有効と言える。バザール方式は特殊な条件の下でのみ成功するので評価が難しい。

(2) プログラミング技術

技術の面でもっとも重要な変化はオブジェクト指向プログラミングが普及したことだ。プログラムが処理するデータと手続きを一体化し、オブジェクトとするオブジェクト指向プログラミングは、C++やJavaとともに1990年代後半に普及した。プログラムの構成要素の独立性が高まり、変更の影響範囲を局所化することが容易になった。

オブジェクト指向プログラミングはソフトウェアの再利用を促進する結果にもなった。とくにJavaのクラスライブラリは膨大な規模になっている。アプリケーション全体の動作を共通化するフレームワークもよく使われるようになった。以前は自前で書いていた処理をライブラリに任せることができるようになったのは大きな進歩だ。

実装や単体試験に関しては自動化が進んでいる。設計書からソースコードを生成するツールや、作成したプログラムをテストプログラムによってテストするためのライブラリなどが登場した。ソースコードを生成するツールは、ソースコードと同じ細かさで設計書を書く必要が生じるため、あまり意味がない。しかしテストの自動化はある程度有効と言える。

設計図の標準として統一モデリング言語(UML)が使われるようになり、ソフトウェアの構造や振る舞いを視覚化する手段ができた。ただ、UMLはソースコードとのズレが生じることが多いため、無駄という意見もある。

(3) インターネット

1990年代にインターネットが一般に普及したことは、ソフトウェアの世界にも決定的な変化をもたらした。ソフトウェアのソースコードは公開すべきだ、という思想に基づくフリーソフトウェア運動は、Linuxの成功とともにソフトウェア業界の大きな潮流となった。AndroidのベースがLinuxであることを考えると、現在もっとも多く使われているOSはLinuxと言える。

インターネット上には技術者のコミュニティもたくさん生まれた。近年もっとも活発なのはQ&AサイトのStack Overflowで、プログラミングに関する質問を投稿すると誰かが答えてくれる場になっている。フリーソフトとあわせて考えると、現代のプログラマーは知識と成果物をグローバルに共有していることになる。

■狼男

以上のように様々な「銀の弾丸」が登場してきたが、一方で新たな「狼男」も現れた。

コンピュータ機器は多様化し、あらゆる電化製品がソフトウェアで制御されるようになった。これをソフトウェアの側から見ると、多様な機器に対応しなければならなくなった、ということになる。パソコンだけでなくスマートフォンやタブレットでも汎用のOSが動くようになり、近いうちにウェアラブル機器も登場する。

現代のコンピュータ機器はインターネットに接続できるのが当たり前になっている。しかし、単体で動作すればよい場合と、ほかの機器と通信しなければならない場合では、ソフトウェアの複雑性はまったく異なる。

通信機能と表裏一体の関係にあるのがマルチスレッド処理だ。マルチスレッドにより、プログラムの中で複数の処理を並行して動作させる。通信機能をつけた場合、相手がいつメッセージを送ってくるか分からないため、プログラムのどこが次に実行されるのか分からない。決まった処理を順番に実行して終わり、ではない。これは現代のソフトウェアにおいて一番やっかいな問題となっている。

■まとめ

「銀の弾丸」と評価できるかどうかはともかく、ソフトウェア開発の生産性を引き上げる方法はいろいろと登場した。しかし同時に、ソフトウェアに課される問題も高度化した。結果的にはソフトウェア開発の難しさはブルックスの時代とそれほど変わっていない。


Textalkバージョンアップ

  • 投稿日:
  • by
  • カテゴリ:

聴覚障碍者向けのAndroidアプリ「Textalk」を久しぶりにバージョンアップした。

機能追加の中心は通信機能。もともとこのアプリは、音声認識か手書きでメッセージを入力して相手に見せる、という使い方を想定していた。しかし会話する双方がスマートフォンかタブレットを持っている場合、メッセージを相手のデバイスに送信できれば便利かもしれない。そう考え、いくつかの方式で通信できるようにした。

一番よさそうだったのがAndroid 4.0から導入されたWiFi P2P。デバイス同士が直接通信してネットワークを形成できる。しかし実際に使ってみるとうまく接続できないことが多い。私が書いたアプリの不具合ではなく、Android自体に含まれているアプリを使ってもうまくいかない。テスト用に買った激安のタブレットが悪いのかもしれないが、とにかく使えない。

やむをえないので普通のWiFiのネットワークでUDPのブロードキャストを使って接続できるようにした。

  • UDPで自己自身の名前をブロードキャスト
  • 受信側はブロードキャスト元のIPアドレスにTCPで接続

WiFiのテザリングでも接続できるようにした。テザリングの場合、ホストの/proc/net/arpに接続されたクライアントのIPアドレスが書き込まれるので、それを拾ってクライアントにTCPで接続することができる。

BlueToothを使うことも考えたが、ソケットがWiFiと違っていてコードが共通化できないので見送った。

ランナー向けアプリ「Hayate」がFirefox Marketplaceで公開

  • 投稿日:
  • by
  • カテゴリ:

昨年秋から開発を進めていたFirefoxOS向けアプリ「Hayate」がFirefox Marketplaceで公開された。主な機能は以下の通り。

  • GPSでランニングの経路を記録
  • 経路はGoogle MapかOpenStreetMapで表示
  • GPXファイルをインポート/エクスポート

3月上旬にMarketplaceにレビュー申請し、一ヶ月以上かかって承認された。

一回目はwebL10nContent Security Policy(CSP)に引っかかり、不承認。

FirefoxOSのソースツリーから改変されたバージョンを拾ってきて入れ替え、二度目の申請。しかし次のレビューアはCSP Violationだと言うだけで具体的な問題箇所を示さずに不承認とした。どこを修正すればいいか質問しても応答なし。

やむをえず、同じものをもう一度アップロードして再レビューしてもらうことにした。すると今度は放置。何度もメールで催促して、ようやく得られたのが「jQueryを使っているからではないか」という別のレビューアからの回答だった。jQueryを使っても問題ない、と昨年夏にレビューアが表明しており、半年で方針が変わったとも思えないので「本当か?」とつっこむと、また応答がなくなった。

さらに別のレビューアからは「jQuery単体なら使ってもよいが、DeviceStorage APIと併用するべきではない」というメールをもらった。これが公式な回答なら、jQueryかDeviceStorage APIのどちらかを捨てなければならない。すぐには信用できなかったので確認のメールを返すと、App Review Technical Leadという肩書を持つAndrew Williamsonがでてきた。jQueryとDeviceStorage APIは併用できない、という見解は間違いだったようで、ようやく承認された。

今回得られた教訓は、jQueryを使うと能力の低いレビューアに不承認とされるおそれがある、ということ。次の開発では使わないほうがよさそうだ。

Hayate coming soon!

  • 投稿日:
  • by
  • カテゴリ:

昨年秋から、FirefoxOS向けにアプリの開発を進めている。GPSを使ったランナー向けのアプリで、走った時間や距離を記録し、Google Mapでルートを表示できる。FirefoxOSがインストールされた端末が安く買えるようになったので、なにか開発しようと思って始めたものだ。数年前にAndroid向けに同様のアプリ「Tokyo Runners」を作りはじめ、途中でやめてしまっていたので、まずはそこから入ることにした。

名前は「Hayate」。「Tokyo Runners」は東京メトロが提供するandroidアプリとかぶってしまっているので、新しい名前を考えた。Geckoといえば疾風だ。

GPSの情報はGeolocation APIで取得し、データはIndexedDBに保存する。Google Mapを表示する際はGoogle Maps JavaScript APIを使う。いずれはOpenStreetMapにも対応したい。UIにはFirefoxOS専用のBuilding Blocksを使いたかったが、まだ安定していないようなのでjQuery Mobileを採用した。

FirefoxOSはまだ開発途上で、現時点ではできないこともある。

このアプリは走る時に使うので、本来はバックグラウンドで動作させたい。しかしBackground Services APIはまだ実装されていない。なにもしないと数分で勝手にアプリが終了してしまう。それでは困るので、現在はnavigator.requestWakeLockというAPIを使ってCPUを専有させ、終了しないようにしている。CPUを専有するのでバッテリを消費することになり、長時間の使用には耐えない。

テキストを読みあげてくれる機能(Text to Speech)や音声認識の機能もまだない。計画もなさそうだ。

開発するうえでちょっと不便なこととしては、アプリをPackaged Appとして作る場合にはGoogle Mapを直接使えないことがある。Google Maps JavaScript APIはmaps.googleapis.comにあるAPIを呼ぶ形で使う。Content Security Policyの制約で、アプリのUIを定義するHTMLファイルから直接呼ぶのではなく、ネット上に置いたHTMLファイルから呼ぶことにして、Packaged Appはそれをiframeの中から使うしかない。しかたがないのでGoogle Mapの部分だけをOpenShiftのサーバに置くことにした。

数週間以内にアルファ版をリリースできるところまで来た。FirefoxOSは日本でも海外でも盛り上がっているとは言えない状況だが、いずれ変わると信じて取り組みたい。

もじら組フォーラムの再構築

  • 投稿日:
  • by
  • カテゴリ:

もじら組のフォーラムを全面的に再構築することにした。 基本方針は以下の通り。

  • サーバー側はnode.js/MongoDB、クライアント側はjQuery/IndexedDBで書く。つまりどちらもJavascript
  • 見た目はStack Overflowを目指す。
  • Firefox OSにも対応する。

クライアントとサーバーのあいだではJSON形式でスレッドや記事を送受信することにしたい。

  1. クライアントがサーバーにアクセス
  2. サーバーはHTMLのテンプレートを返す
  3. クライアントはテンプレートを受け取ったらスレッドや記事のデータを要求
  4. サーバーはスレッドや記事のデータをJSON形式で返す
  5. クライアントは受け取ったテンプレートとJSONをデータからHTMLファイルを作成

こんなシーケンスになる。Single-page applicationの考え方で、モバイルへの対応を考えた場合はこれが最善だと思う。

サーバー側のフレームワークとしてはExpress、クライアント側のフレームワークとしてはBackbone.jsがメジャーなので、この二つを組み合わせたい。 Backbone.jsはnode.jsのモジュールもあるので、サーバー側でも使える。Backbone.Modelは両側で共有できそうだ。

通信はAjaxを使う方法とSocket.IOを使う方法がある。Socket.IOを使えば新規投稿のリアルタイム配信が可能。A Node.js speed dilemma: AJAX or Socket.IO?を読むと、AjaxでもSocket.IOでもパフォーマンスに違いはないことが分かる。とりあえずSocket.IOを使う方向で進めたい。

一番困っているのがクライアント側のDB。IndexedDBをlawnchairを通して使うのがよさそうなのだが、lawnchairは開発がそれほど活発でなさそうなのが気になる。かといって代わりのものも見つからない。

Kmoney/mobile v0.1リリース

  • 投稿日:
  • by
  • カテゴリ:

Kmoneyのandroid版をgoogle playでリリースした

昨年の3月に始めた家計簿アプリの開発はようやく一段落。まさか1年かかるとは思っていなかった。とても片手間でできるような開発規模ではなかった。まだ完成にはほど遠いが、私個人にとっては十分なレベルに達したし、私以外に使ってくれる人がいるかどうか分からないので、これで一区切りにしたい。

KmoneyがAMOの予備審査を通過

  • 投稿日:
  • by
  • カテゴリ:

Firefoxの拡張機能として開発してきたKmoneyを正月明けにaddons.mozilla.orgに登録し、アドオンとしての審査を申請した。審査には予備審査(preliminary review)と本審査(full review)があり、私が選んだのは本審査。

その結果が昨日返ってきた。本審査は通らなかったが予備審査は通った、とのことだ。不具合が4つ指摘された。

Kmoneyは金融機関の入出金明細をインポートできるのが大きな特長だが、現在対応しているのは日本のごく一部の金融機関だ。このソフトが役立つのは日本で生活している人だけと言っていい。しかしアドオンの審査は海外の人たちが行う。その際のコミュニケーションはもちろん英語だ。ハードルが高いなあ、というのが率直な印象。Androidアプリにはこのような審査はない。ダウンロードしたユーザーのレビューが全てだ。カネのあるgoogleがすべてをユーザーに委ねているのに、弱小のmozillaがスタッフによる審査を行なっているのは不思議な気がする。

ともあれ、正月明けからはAndroid向けのKmoneyの開発を始めている。なんとか来月いっぱいには開発を終え、Firefox版とあわせてリリースしたい。

この数ヶ月、私はFirefox OSのニュースが気になってしかたがない。つい先日にはKDDIがFirefox OS搭載端末の販売を検討中というニュースが出た。Android版のあとはFirefox OS向けにKmoneyを作ってみることも考えている。