オープンデータで作った観光系サービス

新コロナウィルスで経済やら色々ダメになりつつある現状が心配ですね。

さて私は以前書いたようにオープンデータでなんとかサービスを作ってよしんば生計を立てれれば良いと考えています。
現在無職で貯金を切り崩して生活しつつ開発をしているという状況です(まだ持つとは言え苦しい...)。
khondalit.hatenablog.com

という状況で作成したのがこのPeriploosというサービスです。2月の半ばにリリースしたので1ヶ月ちょっと経過した計算になります。
www.periploos.net

Periploosとは?

Periploosはオープンデータの観光情報やそれに類するデータを収集し検索できるようにしたサービスです。
旅行、観光、お出かけがターゲットとなります。
当面はデータベースを充実させて、ユーザが増えればユーザ向けの機能を増やしていきたいと考えています。


テーマ選択の理由ですが、オープンデータをいくつか見て回り、自分の既存の技術知識と合わせてリリースまでの可能性、継続した開発の可能性を考えた結果です。
ただ、問題は構想から開発を始めたのは去年末ぐらいでしたが、公開した時期辺りには例の新コロナウィルス問題で特に観光業の落ち込みが激しい状況になったのが残念です。


また、前回投稿したマスターデータの販売サービス(Fuzina)も継続しますが、こちらともいずれ連携を取っていきたいと考えています。
khondalit.hatenablog.com

データによっては、Periploosで集めたデータを販売するのもありでしょうし、その逆にマスターデータをPeriploos側に取り込むという事もあり得るでしょう。
サービス同士がデータで連携し成長するというのも目標としています。
とは言え一人ですのでどこまで出来るかは不明ですが...

技術構成

Periploosはリリースを早く回していきたいので、自分にとって楽な技術構成を取りました。

  • サーバはHerokuを採用。AWS等は個人での管理が大変ですので
  • FrameworkはRailsを採用。2020年の現代では最新では無いもののとりあえず作るという場合ではまあ普通の選択と言って良いでしょう
  • DatabaseはPostgreSQL。まあ無難に選択です。jsonb等の機能の利用も視野に入れています。
  • 位置情報周り。これはデータとしてはQuadkeyを選択。地図表示ですがGoogle Mapと言いたい所ですがコストの関係でLeafletにしました。個人開発者には有り難いです

- Quadkeyについて拙い記事ですが公開しています Fuzina | Quadkeyで範囲検索を行う

オープンデータ

オープンデータの有用性は皮肉にも今問題となっている新コロナウィルス問題で技術に興味が無い方にも知られてきています。
特に東京都が公開しているサービスは有名です。オープンデータとOSSによって開発が進んでいます。
stopcovid19.metro.tokyo.lg.jp


さて、使い方次第だとこの様に便利なオープンデータですが、欲しい情報がほしい形で簡単に取得できるわけではありません。
今回開発していて一番難しいのはこのデータ取得部分です。

上記の新型コロナウイルス感染症対策サイトも東京都のデータだけしか見れません。できれば全都道府県のデータを1サービスで見たいなぁと思いますが、管理が東京都なので無理なのでしょう。
Periploosでも同じ問題があり、観光データも各都道府県や各市区町村レベルでの公開となっており収集だけでも一苦労です。データフォーマットがそれぞれで異なり、欲しいデータが無いこともしばしばです。

Periploosを見てもらえれば分かりますが、画像データ、説明文が無いデータも多々有ります。これは元のデータが名称と住所だけとか位置情報があればまだ良い方という悲惨な状況だからです。
これらの対策は個人ではどうしようも無いため、現状様々なオープンなデータを探していますが存在しない、またはあっても非常に扱いづらくコード化が難しいといった状況が続いています。悩ましい...

できれば行政の方にはコードからアクセスしやすく画像やテキスト等の情報が多いオープンデータの公開を期待しています。


そろそろ転職も考えないとなぁ

マスターデータを取り扱うサービスをはじめました

さて、色々あって退職して、3ヶ月ほど経過しました。
仕事はしておらず収入がなく辛い日々ではありますが個人でサービスをリリースしました。これで食べていければ嬉しいなぁ。

前回オープンデータでなんとか出来ないかなぁという投稿をしました。
khondalit.hatenablog.com

こちらにも投稿しましたがそもそも私が今までWebサービスの開発してきて不満の1つがマスターデータの入手の難しさです。
www.fuzina.com

ここで例に出しているデータは駅データですが、同じ様に欲しいデータは多々あるわけです。
例えばコンビニのデータ。賃貸のマッチングサービスですと、対象の物件の近くにコンビニがあるというのが分かるだけで生活のイメージが付きやすくなりユーザには便利でしょう。
役所、病院、警察署等の公共機関のデータがあればこれも嬉しいでしょう。
こういったデータはGoogle Mapを埋め込むだけでも見れなくは無いですが、検索システムに組み込むのは無理でしょう。

無いならいっそのこと自分が作ればよいのではと数年前から頭の中にはありましたが、仕事の忙しさ等で時間がなく、またデータの取得の難しさから手をあまり動かせずにいましたが、退職や年齢などのタイミングが重なり今回の挑戦となりました。

なんとか頑張りたいなぁ

オープンデータで個人開発が出来ないか?

すごく久しぶりのblog。

色々あって仕事を退職し今は有給消化中です。
会社には色々言いたいことがあるがまあそれはそれとして良い面も多々ありました。

振り返り

プログラマーとして社会人になり20年ほど経ち何社も経験してきて来ました。
得られたのは長時間労働と無茶な開発現場の数々、その場限りで作るだけといういい加減なビジネスばかり、安い給料、それに伴いプライベートが無く人間関係がほぼ持てず、多少なりともの病気...、言い出したら切が無くお世辞にも良い結果は得られなかった。
ただ、今回の会社ではほぼリモートワークとなり時間に余裕が持て色々仕事や人生について考えざるを得ない状況になりました。
元々幼少期の家庭環境問題もあり、色々問題はありまだまだ考えねばならない事も多いですが、私は通常の社会生活には向いていないのでは無いかと考え始めています。

また、時間がある中で個人開発をする余裕も出てきました。実際仕事の副産物としてgemを1つリリースしています(まああまり需要はないでしょうが...)。まあゆっくり開発していきます。この話は本アカで書いていくのでここでは話しないと思いますが...

個人開発

時間が取れだして来てから個人開発を行っておりオープンデータを利用して遊んでいます。実際今までは若さと体力にまかせて個人で勉強したりちょっとした開発も行ってきました。ただ年を取ると時間が無い中でなかなかそういった事も難しく明確な目標が無い物に時間や精神的なコストをつぎ込む事も困難になって来ていました。
ただ余裕が出来てくると話は別です。また仕事を通じて色々不満も出てきていました(仕事そのものへの不満とは違います)。

まだ公開していませんが例えばGeolocationなAPIを作成出来ました。位置情報と住所の相互変換が可能となっています。ただ住所の "号"(X丁目Y番地Z号の号部分) まではデータが公開されていないので番地までですが... "号" は建物自体を表すのでプライバシー問題があるようです。他には会社リストもある程度まで作成しています。

一端目指したい目標はマスターデータの充実とその提供です。そもそもの動機は今までのWebサービスでこういった欲しいデータが必要となる場面が多いのに良いデータがほぼ無いことです。
例えば賃貸物件のマッチングサービスを例に取りましょう。ユーザなら住む場所を地名でも探しますし特定の駅に近い場所とかでも探すでしょう。こういった場合住所や駅の場所とそこから物件の距離等で探せると良いでしょう。また駅も会社へのルートを考えて選択できると嬉しいですよね。こういった場合に住所の一覧、駅の住所等が必要ですしまたそれぞれの住所から位置情報を取得し距離計算が必要でしょう。

先程書いたように住所データはある程度まで公開されていますがこれらをDBに入れるとなるとそれなりの開発コストが必要ですし、地名の書き方で色々問題もあります。難しい漢字をひらがなで書いてあったりして名寄せ処理等が必要となる場合も珍しくありません。
駅データは無料で公開されているのも無くもないですが有料となると非常に高価です。年で数十万〜百万以上の値段となります。

以前在籍していた会社では駅データを購入していましたが高価ですしまた位置情報がありませんでした。またサービス側の問題として何故かデータの更新作業が5年前後ほど行われておらずその手順も一切不明で、古いデータのままサービスを運用していました。
仕方なく自分が頑張り購入したデータを使用せず0から駅データのリスト化作業を行い、コマンド1つでデータの最新化を行えるようになりました。

これらは一例ですがこういったマスターデータはあらゆるサービスで必要とされていますが供給が追いついていない状況です。
まずは完璧では無いにしろオープンデータでこういった状況の打破が出来ないものかと現在データと色々集めている最中です。できればこれらを安価に楽に提供する手段を開発出来ないか、可能ならばこれで自分一人でも飯が食えるようになればと頑張っている最中です。

ということで頑張りたいなぁ

Sqale終了するので、Herokuに移行中

Sqaleが終了するということで、公開しているサービスを移行中です


とりあえず、ドメインはまだですが、http://sqale.yoseba.org/ の方は一旦移動させましたが、DBの移行がちょっと面倒なので諦めました。
https://yoseba.herokuapp.com/

Sqaleのデータ移行のなにが面倒と言えば、scpは禁止、~/.sshはreadしか権限がない、ftpコマンドすら使えないという有様。
ヘルプによるとs3で移行しろらしいのですが、Amazonとの契約はしていないし、たかがバックアップのために移行程度に契約はしたくない。
一応scriptコマンドでバックアップはしたものの、HerokuはメインのDBはPostgreSQL。もちろんMySQLも使えますがせっかくならPostgreSQLを使いたい。
ということで、データ移行は諦めました。

http://mohadana-khondalit.sqale.jp の方は、ちょと通常と違うサービスなので少し復旧まで時間ください。
GW中にはなんとかしたいですね。このapi意外と利用している人がいるので、がんばります。
あと仕事関係でシソーラス作成もしていて、落ち着いたら1から個人で作成してみるつもりだったりします。
うまく言えば良いなぁ...

静的サイトゲネレータをNanocからMiddlemanへ乗り換えました

linuxc.info

linux.infoはずーっとNanocを使ってきたわけですが、アップデートをサボっていたたらいつの間にか最新版ではまともに動作せず少し我慢をしていたのですが、
更新は続けていくのに不自由していたのでMiddlemanへ乗り換えることにしました


躊躇してみた割には結構簡単に終わりましたので、簡単にメモ程度ですが特徴を公開します。

ファイルの置き場所

Nannocは content/ 以下にhtmlファイルを置くのですが、Middlemanは source/以下となります。
また、nanocだとlayoutは layouts/ 以下となるわけですが、Middlemanは source/layaouts以下になっていたりします。
基本的にMiddlemanはコンテツに関わるものは全て source/ 以下に置くこととなります。

htmlの書き方

Nanocでは基本的にhtmlのままですが、MiddlemanはERBを採用しているのでlink_toやimage_tagなどのヘルパーが使えます。
Railsになれた人ならば非常に使いやすくなています。

また、Sitemap作成機能や、MarkdownHaml、Sass等も使えるなど、モダンな開発環境となっています。

ファイルの置き場所など細かいルールは違いますが、基本的にNanocで困っていたことが大体解決していて上位互換と捉えて問題ないかと思います。
移行作業時間はおそらく、公開まで1時間かかってないでしょう。

Rails4系からRails5へのアプデ

sqale.yoseba.org

以前リリースしたサービスですが、Rails4.2.6からRails5.0.0へのアップデートを行いましたので手順を残しておこうかと思います。
ちなみに、仕事でも現在アップデート作業を頑張っていますが、こっちは規模が違うので色々大変で難航しています。


# テストコード
可能な限りテストコードは用意しておきましょう。
サービスが大きくなればなるほどアップデート作業が大変になります。
こまめに、無理のない範囲で用意しましょう。

まったくテストコードがない場合は、重要な部分、テストコードが簡単に用意できる部分、RailsであればModelのように下位レイヤーあたりから始めるのがおすすめです。
テストコードが1つもないより、1つだけでもあるプロジェクトの方が安心感がぐっと上がります。


# Rubyのアップデート
最近のRubyでは互換性が無い修正はまずありません。
可能な限りRubyのアップデートから始めましょう。
アップデート前と後でテスト結果に変化が無いことも試しましょう。

もし、問題が発生するとすればRubyのバージョンとGemのバージョンの依存関係が多いと思います。
Gemは普段からアップデートしておき、開発が停止している場合は乗り換え先を探しましょう。
可能ならば、Gemを使わなくて済む方法を探しましょう。ちょっとした機能であれば自前で開発するのが良いです。


# Rails4系の最新版へのアップデート
自分のサービスは小さいので定期的にアップデートを行っていますが、最新になっていない場合はまずメジャーバージョンは固定しつつ最新にしましょう。
ここでもGemの依存関係に悩まされるはずです。Gemは少ないほうがバージョンアップ時に苦しまなくても済みます。

テストはもちろんテストコードを利用しましょう。

# Rails4系からRails5系へアップデート
いよいよ本題です。

私の場合は次のような手順を踏むことが多いです。

  • アップデート作業開始は大体ベータ版がリリースされたタイミング
  • リリースノートやリリース情報をチェックする
  • 新しいRails5のプロジェクトを作成する
  • 仕入れた情報と合わせつつ、現在のプロジェクトとRails5のプロジェクトを見比べる

- 例えばbin/以下に違いが出てないか? config/以下は? Gemfileは? などなど
- 現在のプロジェクトが大きい場合はRails4系の新規プロジェクトを作成して比較すれば分かりやすい

  • 違いが分かれば適時Rails5に合わせていく
  • リリースノートやRailsのログを見つつ使われなくなる機能や各種警告に対応する
  • Gemの整理


今回の追加、修正の目ぼしい箇所をいくつか上げておきます

  • app/models/application_record.rb、app/controllers/application_controller.rbがデフォルトで追加された
  • bin/以下に修正が入っている
  • config/application.rbの書き方が一部変更になっている
  • config/cable.yml、app/channels/、app/jobs/等新しい機能に対応するファイル/ディレクトリが増えている
  • 他にもpublic/apple-touch-icon*.png等の追加ファイルもある
  • Gemfileには追加や削除されたものがあるので、適時追加、削除、修正を行う

これらを試しつつ'rails s'が動けば最低限の山は超えたと言ってよいでしょう
もちろん、テストコードの結果、rakeタスクのようにテストコードが書きにくい機能の手動テスト、デザインやJSなどUI/UX周り、等など確認する部分は多々有ります。

最終的に納得する部分まで来たら、最後は覚悟を決めてリリースです。
いつでもrollback出来るように準備を忘れずに...

MeCabのWebAPIを公開してみた

仕事でmecabを使わざるを得ない機会が出てきました。
やりたいことは複合名詞の取得。

SEOを目的としたサイト内リンクの増加の為に、キーワードを増やしたいわけですが、これがどうしてもサイトがターゲットの業界でよく使われるキーワードが多く、データは毎日何万、何十万という単位での変更があるため、手動では追いつきません。
そこでMeCabでの複合名詞の自動取得というわけです。

ただ、サーバのOSのバージョンやライブラリの関係から全サーバにMeCabを入れるのが辛い状況。
そこでWebAPIなのですが、仕事用ということでどうしても独自性が出てきて汎用的ではありません。また割り込みも多く開発がどうしても遅くなりがちです。
個人的にNLP機械学習系は興味があったのですが、これを機会に個人で作ろうかと思いたち公開しました。


サイトはここです。
形態素解析 Mecab(複合名詞対応) Web版


とりあえず、以前作成した http://sqale.yoseba.org/ と同じくSqaleさんを利用します。
内容的には大したことないですし(DataBaseすら必要無い),個人でクラウド借りてサーバの管理までしたくはないので、これで十分でしょう。

ちなみに、mohadanaはMeCab->和布蕪->海苔から調べると、こういう記述がありまして、パクりました。
海苔 - Wikipedia

和銅3年(710年)に遷都した平城京には、海草類を売る「にぎめだな」(和布店)、海苔や昆布を佃煮のように加工したものを売る「もはだな」(藻葉店)という市場も存在した。

WebAPIを使ってみる

http://mohadana-khondalit.sqale.jp/api のサンプルから持ってきます。
complexオプションを付けることにより、複合名詞を推測します

$ curl -G http://mohadana-khondalit.sqale.jp/api/v1/parse --data-urlencode sentence="日本語の形態素解析" -d complex|jq
{
  "status": 200,
  "message": "Success",
  "results": [
    {
      "surface": "日本語",
      "reading": "ニホンゴ",
      "pronunciation": "ニホンゴ",
      "pos": "名詞",
      "pos_detail": [
        "一般"
      ],
      "conjugated_form": null,
      "conjugated_type": null,
      "infinitive": "日本語"
    },
    {
      "surface": "の",
      "reading": "ノ",
      "pronunciation": "ノ",
      "pos": "助詞",
      "pos_detail": [
        "連体化"
      ],
      "conjugated_form": null,
      "conjugated_type": null,
      "infinitive": "の"
    },
    {
      "surface": "形態素解析",
      "reading": "ケイタイソカイセキ",
      "pronunciation": "ケイタイソカイセキ",
      "pos": "名詞",
      "pos_detail": [
        "複合"
      ],
      "conjugated_form": "",
      "conjugated_type": null,
      "infinitive": null
    }
  ]
}

複合名詞の判定

品詞の種類で判定しています。
初めは名詞+名詞という単純なルールで実験をしていましたが、これが結構ダメなようでして色々調べた所、幾つかのパターンがあるようです。

例えば、「医療機関」。これは一般名詞の連続で、この場合は複合名詞と判定して良いようです。

$ echo 医療機関|mecab
医療    名詞,一般,*,*,*,*,医療,イリョウ,イリョー
機関    名詞,一般,*,*,*,*,機関,キカン,キカン
EOS

$ curl -G http://mohadana-khondalit.sqale.jp/api/v1/parse --data-urlencode sentence="医療機関" -d complex|jq
{
  "status": 200,
  "message": "Success",
  "results": [
    {
      "surface": "医療機関",
      "reading": "イリョウキカン",
      "pronunciation": "イリョーキカン",
      "pos": "名詞",
      "pos_detail": [
        "複合"
      ],
      "conjugated_form": "",
      "conjugated_type": null,
      "infinitive": null
    }
  ]
}

では「交通費」はどうでしょうか。
この場合は「費」が名詞ですが、接尾語のようです。逆に接頭語とかもありそですね。
この場合も複合名詞として良いでしょう。

$ echo 交通費 |mecab
交通    名詞,一般,*,*,*,*,交通,コウツウ,コーツー
費      名詞,接尾,一般,*,*,*,費,ヒ,ヒ
EOS

$ curl -G http://mohadana-khondalit.sqale.jp/api/v1/parse --data-urlencode sentence="交通費" -d complex|jq
{
  "status": 200,
  "message": "Success",
  "results": [
    {
      "surface": "交通費",
      "reading": "コウツウヒ",
      "pronunciation": "コーツーヒ",
      "pos": "名詞",
      "pos_detail": [
        "複合",
        "後接続不可"
      ],
      "conjugated_form": "",
      "conjugated_type": null,
      "infinitive": null
    }
  ]
}
||>

このように幾つかのパターンをWeb上で調べまして、複合名詞処理を行いました。
専門家ではない人間が行った処理ですので、推測が正確ではないかもしれませんが、テストをした範囲ではそれなりに動くようです。


** 今後の対応
複合名詞以外にも、複合動詞というのがあるそうですので対応を行うのも良いかもしれません。
名詞でもアニメのタイトルなど判定が難しい新語もありますので、このあたりは辞書を強化する必要があるでしょう。
また、分野によってはアスキーアートの対応が欲しい場面もあるようです。

まだまだ追加したい処理はありますので、これから対応したいと考えています。