AWS公式のサーバレスWebアプリケーションのチュートリアルをやってみた
明日参加予定のJAWS-UG愛媛のテーマが「サーバレスWebアプリケーション」で、公式のチュートリアルを題材にハンズオンやるよ、となっていたので一足先に予習してみた。
で、最終的に何ができるのかと思えばユーザーが Wild Rydes のユニコーンへの乗馬をリクエストできるシンプルなサーバーレスウェブアプリケーションらしい。
まったくもって意味がわからん。
LPの色使いからしてもこれ作ったやつ絶対○リファナキメてんだろとしか。
先日Firebaseのハンズオンが「レストランの評価アプリ」って良くも悪くも実用に徹した題材だっただけに、最初のインパクトがデカすぎるけど、粛々とやってみたので感想をば。
完走した感想
完成品の出来はサンプルでも確認できるのでそこについてはノーコメントで、チュートリアルの流れ自体は非常にいいと思った。
コードは既に出来上がっているものをコピペすればいいだけ(変更もコンソール上で作ったリソースのIDを入力するくらい)で、サーバレスアプリを構築するリソースを触ることだけに集中していれば大丈夫。
Lambdaで使うロールを作るときも、最低限のポリシーだけをアタッチするって原則を忠実に守ってるのも好感持てる。
※ちなみに一番好きなポリシーは何ですか？って聞かれたら迷わずAdministratorAccessと答える人間(個人で触る分には、ま多少はね？)。
個人的にはCognito以外はしまの時刻表作る時に触ったこともあるサービスがほとんどだったこともあって、目安時間2時間となっているところを3,40分で完走できた。
(コピペとはいえ)これだけの速さで本番稼働するアプリケーションが作れて、しかもデプロイまで済んでるってインパクトが体感できるのは素直にいい教材じゃないかと思った。
情報の古さと日本語訳の粗さが気になった
一方で↑が原因でつまずきそうなポイントが何箇所かあったので、これからやる人向けにメモ。
まずひとつ、作成したS3にバケットポリシーを適用する箇所があるんだけど、S3がアップデートされてから、デフォルトではポリシーの編集ができなくなっているので、まずはその設定を解除してやる必要があるところ。
やり方は↑の記事に書いてあるのでそれに従ってもらうとして、チュートリアル上ではこの点に一切言及がないので結構なハマりポイントになってるかと思う。
チュートリアルが書かれたのがS3がアップデートされる前っぽいので仕方ない部分はあるにせよ、そこに合わせてチュートリアルの方も改定してくれよな、とは強く思った。
それとLambdaのランタイムではNode.js 6.10が指定されてるんだけど、本家の方ではサポート終了済み。
一応8.10を選んでも動作はしてくれたけど、そこの情報知らない人だと戸惑うんじゃないかな。
その他、○○を押して..って指示する箇所がたくさんあるんだけど、そこの日本語訳が英語版の直訳なのか各サービスのアップデートに対応していないのかで読み替えが必要な箇所が多数。
それでも完走はできたからいいものの、そこに脳のリソース使うのは内容がいいだけにもったいないと感じた。
..とまあ、いろんなところで不満は感じたものの、最初に書いたとおりAWSやサーバレスアプリを初めて触る人にとってはいい勉強になると思うので、興味があったら挑戦してみて欲しい。
PythonでGoogle検索を自動化→CSVに出力するスクリプトを書いた
昨日の記事と同じようなネタ、タイトルだけど、今度はCustom Search APIとやらを叩いてみた。
実装にあたっては↓の記事をがっつり参考にさせていただいた。
やろうと思った経緯
で、作った。
どうやったか
Googleで「(島名) フェリー」で検索したら、トップに運行会社がやってるページあるいはそれに近いような結果がヒットするやろ、とガバガバな仮説を立てる。
ただ、1個1個手打ちでやるのは至極しんどいので、昨日書いたスクリプトを応用して、Pythonに検索用APIを叩いてもらうことにした。
画面の案内と参照元ページに従って検索エンジンのインスタンスやらを作成。
参照元にあるように、API叩くのに使いやすいモジュールがあるとのことなのでインストールしておく。
$ pip install google-api-python-client
細かく解説していこうとも思ったけど、細部は前回のものとほぼ変わらないのでコード全文といくつかポイントのみ。島名のリストも元サイトがよくまとまっているので今回もそのまま使わせてもらった。
#coding:utf-8 from bs4 import BeautifulSoup import re import csv # APIとの通信用 import urllib from time import sleep from googleapiclient.discovery import build soup = BeautifulSoup(open("rito.html"), "lxml") html = soup.find(class_='land-list').find_all('a') header = ['島名', 'ページ名', 'URL'] body = [] API_KEY = '自身のAPIキー' CUSTOM_SEARCH_ENGINE_ID = '検索エンジンのID' service = build("customsearch", "v1", developerKey=API_KEY) for h in html: text = re.split('[（｜）]', h.text) name = text[0] area = text[2] query = area + name #検索 sleep(1) res = service.cse().list( q=query + ' フェリー', cx=CUSTOM_SEARCH_ENGINE_ID, lr='lang_ja', num=1, start=1 ).execute() if(res['searchInformation']['totalResults'] != '0'): title = res['items'][0]['title'] url = res['items'][0]['link'] else: title = "" url = "" body.append([name, title, url]) print(name + 'の検索結果を取得') #CSVへの出力処理 with open('data.csv', 'w') as f: writer = csv.writer(f) writer.writerow(header) writer.writerows(body) print('CSVへの出力完了')
API側で(一定時間内に？)叩ける回数に制限があるので、検索する直前にsleepで間を取らせる処理を追加する必要があるのと、ヒット件数が文字列で返ってくるのに気づかなくてしばらく苦労したくらい。
で、例のごとくCSVに結果を吐き出させたので、昨日作ったものとスプレッドシート上でつなぎあわせたものがこちら。
検索条件がガバガバなので明らかにこれ違うだろってのもちらほらあるけど、まあこんなものかと。
検索結果を複数件取得→それらを順にクローリングさせて一番近そうな結果を出力するような実装も考えたけど、最終的に情報の内容は目視で確認しなきゃいけないので、そこまでやる必要もないかと思って見送り。
ただ考え方的にはアリかと思ったので、別の機会に取っておこうと思う。
Pythonで複数の住所の座標を検索→CSVに出力するスクリプトを書いてみた
しまの時刻表に必要なデータを集める中で、各島の位置情報(座標)調べるのがなかなか面倒だったんだけど、Python使ったら結構楽に解決できたのでメモしておく。
元となるデータの収集・抽出
離島経済新聞のサイトに日本の有人離島の一覧が載っているページがあるので、そちらを利用させてもらった。
内容がコロコロ変わるような性質のものではないので、ソースをコピーしてローカルに保存→そこからデータを読み出すようにした。
from bs4 import BeautifulSoup soup = BeautifulSoup(open("rito.html"), "lxml") html = soup.find(class_='land-list').find_all('a')
スクレイピングはBeautifulSoup4でさくっと。
これでサイトの凡例通りの『島名（指定地域名｜市町村名）』の部分が取り出せた。
for h in html: text = re.split('[（｜）]', h.text) # ex. text = ['中島', '忽那諸島', '松山市', ''] name = text[0] area = text[2] address = area + name
経験上Mapで島を検索する際は「市町村名＋島名」だと引っかかりやすいのでその形に。
変数textの箇所は正規表現使ってもっとキレイにしたかったんだけど、今回指定地域名は使わないのでカッコ等で区切った配列を作成→島名、市町村名の部分を抜き出して利用することにした。
Geocoding APIを叩いて位置情報を取得
住所→座標の取得はGoogle MapsのGeocoding APIから出来るっぽい。
最初はAPIキーの取得から。
Geocoding APIが含まれているのは右端の「プレイス」なのでそちらを選択。以前にサイト本体用のキーを取ったのと同じノリで「マップ」を選択して一瞬ん？ってなったのは内緒。
必要なモジュールをpipでインストールしたらAPIを呼び出せるようになる。
$ pip install googlemaps $ pip install pygeocoder
コード自体は非常にシンプルなので、コピペで簡単に使いまわしできそう。
# 関係ある部分だけ抜粋、最終的なソースは記事の後半で from pygeocoder import Geocoder import googlemaps body = [] apikey = '自分のAPIキー' gmaps = googlemaps.Client(key=apikey) for h in html: text = re.split('[（｜）]', h.text) name = text[0] area = text[2] address = area + name result = gmaps.geocode(address) if(result != []): lat = result[0]["geometry"]["location"]["lat"] lng = result[0]["geometry"]["location"]["lng"] else: lat = "" lng = "" body.append([name, area, lat, lng]) print(name + 'の位置情報を取得')
住所が検索でヒットしなかった場合は空の配列で返ってくるので、そこ避けるためにif書いたくらい。
後でCSVに出力する用に配列を置いて、取ってきたデータをぽんぽん放り込んでいく。
全部で400件くらいデータあったんだけど、だいたい1回2,3分くらいで仕上げてくれた。
CSVへの書き込み部分
教科書通り、というかどっかからのコピペなので特に言うことはなし。
header = ['島名', '地域', '緯度', '経度'] #CSVへの出力処理 with open('data.csv', 'w') as f: writer = csv.writer(f) writer.writerow(header) writer.writerows(body) print('CSVへの出力完了')
最終的な全体のコードはこんな感じ。
#coding:utf-8 from bs4 import BeautifulSoup import re import csv # Geocoding API叩く用 import urllib # Google API モジュール from pygeocoder import Geocoder import googlemaps soup = BeautifulSoup(open("rito.html"), "lxml") html = soup.find(class_='land-list').find_all('a') header = ['島名', '地域', '緯度', '経度'] body = [] apikey = '自分のAPIキーの値' gmaps = googlemaps.Client(key=apikey) for h in html: text = re.split('[（｜）]', h.text) name = text[0] area = text[2] address = area + name result = gmaps.geocode(address) if(result != []): lat = result[0]["geometry"]["location"]["lat"] lng = result[0]["geometry"]["location"]["lng"] else: lat = "" lng = "" body.append([name, area, lat, lng]) print(name + 'の位置情報を取得') #CSVへの出力処理 with open('data.csv', 'w') as f: writer = csv.writer(f) # writerオブジェクトを作成 writer.writerow(header) # ヘッダーを書き込む writer.writerows(body) # 内容を書き込む print('CSVへの出力完了')
スプレッドシートに上げておいたので、事あるごとに使うことにしよう。
感想とか
今までgeocoding APIの存在を知らなくて、本家Google Mapのサイトで得たい場所を検索→右クリックして座標をコピペをちまちまやっていたんだけど、それが一瞬で片付くようになったのは非常にありがたかった。
ただ位置情報関係でいうと、島ごとの港+そこと結ばれている本土の港の位置情報も集めなきゃいけないのがなかなかしんどいけど、今回書いたやつを一部修正して使い回すようにすればそこまで手間はかからないと思う。
これからもっと退屈なことはPythonにやらせよう。
2019/05/09追記
何の考えもなしに1回数百回API叩きまくってたら、いつの間にか請求額が結構な値段になってた。
GCPは最近登録したばっかりで、今回の請求もクレジットの範囲内でまかなえるっぽいけど、ちーと気をつけんといかんなと思った次第。
(10連休最終日)連休中に欲しくなったものリストまとめてみた
こんだけの長期連休を経て明日からはお仕事。
このまま行くと5月病まっしぐらな臭いがプンプンするので、物欲をがっつり発露させてお金稼ぎたいモードに自分を追い立てようとしてみる。
スーパーカブ
新しいバイク欲しいって話はTwitterでも小出しにしてたり、実際に会った人にも色々聞いてみたりして考えがまとまらなかったんだけど、表題通りカブ(110ccでノーマルのやつ)を買うことに決めた。
現状50cc(ビーノ)と250cc(エストレヤ)の2台持ってて、ビーノを通勤用・エストレヤをちょっと遠くへ行くとき用と使い分けているんだけど、エストレヤの方に乗る機会が少なくなっていて。
というのも、自宅アパートの駐輪スペースが狭すぎて中型バイクが置けない→会社の倉庫の空き部分に置かせてもらってるんだけど、ツーリングに行くためには「原付で10分くらいかけて」「休日に会社に行かなくてはならない」というのがなんか億劫だから。
だから「自宅アパートの狭小スペースに無理なく置けて」「50ccよりは走れて」「けどスクーターはあんまり」等々の条件を考えて、現状の2台体制→1台に移行しようと考えている。両者ともまだローンが残っているので、時期的にはその完済の目処がついたぐらいに。
あと自分の場合田舎に行く機会が多いこと考えると、あんま今風のいかついやつで乗りつけて地元の人に煙たがられるのが嫌っていうのもあったり。
長距離は辛くなるとは思うけど、そこは公共交通機関との併用で乗り切れるし、何よりバイク本体に高いお金を払って細々暮らすより、維持費の安いバイクで出費抑えて1回でも旅の回数を増やしたいってのが一番の決め手かもしれない。
とはいえ大型バイクを諦めたわけはないので、大型免許だけは近いうち(MT車を手放す前か直後くらい？)に取りに行きたい。ただ置き場所問題は依然として残るので、購入するとしたら駐輪スペースが十分ある場所への引っ越しとセットで検討かなと。
しかし松山市内でピンとくるエリアや物件が特に思い当たるわけでもないし、↓とか参考に移住..とかも真面目に考えてみても良いかもしれない。
どんな土地でも四半世紀も暮らせば飽きるわ。
バイクウェアとかグッズとか
バイクの話が出てくるとその関連グッズも欲しくなる。現状気になっているのはヘルメットと夏用のジャケット。
エストレヤに乗る時はOGKカブトのRockを使っており、シンプルな形状がクラシカルなバイクと相性いいかと思って気に入ってはいるんだけど、夏場は暑いし蒸れるし、もうちょっといいもの欲しいなとか考えていて。
ベンチレーション機能(頭のてっぺんに穴が空いてて空気を通してくれるやつ)とやらが付いているものにグレードアップするのもいいかなと。
ジャケットは本名と同じ「カドヤ」ってブランドが前から気になっていて、これくらいだと機能的にもネタ的にもおいしいかなと。
ロングツーリング行くとしたら他にも積載量増やす装備とかいろいろあるけど、まあまずはシンプルに乗って出かける機会増やしたい。
ポケットWi-Fi
正式名称がよくわからんのだけど、要は携帯用のWi-Fiルーター。
現状自宅にはOCNの光回線引いてるんだけど、外で作業したほうが集中できることもあってあまり使っていないし、外ではフリーWi-Fi使える時はそれを、それ以外はiPhoneのテザリングでネットつないでるけどどっちも不安定だし細いし。
ちょうど欲しいな、と思っていたところ調べてみたらOCNの解約月が来月・再来月となっていたのでこれを機会に乗り換えようかと。
自宅には無料で使えるケーブルのネットがあるので、大容量のもの落とす時はそっちと併用すれば特に不便はないかなと思っている。
しかしどの会社のプラン見ても、最初の○年は割引が効くのにそれが過ぎると高くなる設定の意図がよくわからない。そんくらい経ったら新しい機種が出るからそっちに乗り換えれ、ってポジティブ寄りな理由ならわからなくもないけど、そうじゃないなら長期で使う客優遇してくれりゃいいような気がするんだけどね。
通信業界の商売の仕方ってどうも不透明なところが多くて好かん。
iPhone SEが欲しくてショップ行ったのに訳のわからんタブレットとウォーターサーバーまで一緒に売りつけようとした○uは一生許さん。
新しい携帯とかタブレットとか
そのiPhone SE、3年くらい前に買ってからバッテリーがヘタり始めたので、もうそろそろ買い替えてもいいんじゃないかと思ってはいるものの、代わりに欲しいと思える端末があんまりない。
iPhoneも最近高いばっかりでこれぞ！って機能もないし、Pixel2とかに鞍替えするのもアリかな？とか思ったけど、高いっていう点ではPixelもそんなに変わらんし。
ならいっそ安いiPadとか買って、ブラウジングとかゲームとかパケット食う役割をそっちに集中させて、iPhoneの方は細々と電話+SNS専用機って使い分けするのもアリなんじゃないかとも思っている。
最近はApple Pencil対応モデルも増えてきたみたいだし、調子の悪いペンタブの代わりにお絵かきマシンにできるかも、とか考えたら悪くないかも。各SNSのアイコンも描き直したいし。
Wi-Fiルーターも合わせて使うことだし、ちょっと考えてみるか。
お金で買えるものでいったらこのくらいか。
あとはシンプルに健康(痩せた体)とお金が欲しい。
(10連休9日目)この連休中かつてない充実感を得られたので、その原因を考えてみる
タイトルどおり、この連休、これまで経験してきた連休よりも色々楽しいなあと感じるので、なんでだろうなってぼんやり考えてみた。
客観的には「途中に平日を挟まない」「改元という数十年に1回レベルのイベントがあった」こと、個人的には「前から行きたいと思っていた場所に行けた」「進めたいと思っていたことを進められた」こと等が挙げられると思うけど、
正確に言えば「やりたかったことにフォーカスできたことで、今後やりたいと思うことがどんどん増えていった」のが充実感の正体だと思っている。
課題の解決→さらに別の課題が浮き彫りになるのが面白い
この連休は「基本的に停滞していた個人開発を進める」「天気がいい日には近場でお金がかからないところに遊びに行く」と決めて臨み、その結果は過去の記事で書いてきたとおりなんだけど、その中でも色々な気付きがあった。
まず時刻表サイトについて、課題の中身は記事にしたとおりだけど、中でもこれまで興味はあるけど手が出なかった技術=スマホアプリについて、本気で勉強したいと思う動機ができたのは大きかったと思う。
スマホアプリはこれまでもやってみたいと思って何度か挑戦してみたけど、やるたびに挫折してきていて。ただそこにもう一度挑戦したくなったのは「Webアプリでは思ったとおりの操作感が実現できない」という明確な課題とか問題意識ができたからじゃないかと。
逆に特に問題意識もないまま新しい技術覚えたいなー、と思っても(自分の場合)たぶん身にはならないだろうなとも思ったので、今後はトレンドに振り回されることなく、自分の課題ドリブンで勉強していこうと改めて思えたのも収穫のひとつだと思う。
ブログをストレス無く更新できている
長いこと放置していたブログを再開したのは、単に暇つぶしと、個人的にすごいなと思ってる人たちが口をそろえて「アウトプット大事」って言ってるからというのが率直な理由。
ただスマホアプリと同様、ブログも「何回もやろうと思って何回もやめてきた」部類のやつなので、 やるからにはまず継続するためのコツを掴めたらな、とぼんやり考えてみた。
で、実際に記事を書いていく中で、記事の内容も課題ドリブン、というか事実と率直な感想ベースで書くほうが自分には合っているという気付きが得られた。
過去にブログを書こうとした時は、技術系の記事は「自分が体験した問題について抽象化して、読む人の役に立つように」意識して、旅行先について書く時は「旅先の魅力が伝わるよう、面白おかしく」などと考えていたのだけれど、
それを無理にやろうとすると上手くまとめられなくなる→書くのに時間がかかる→書くこと自体がめんどくさくなる ..というのを毎回繰り返してきた。
そこを開き直って、技術系なら「こんなことやった(事実)+ここが満足or不満(感想)」、旅行記事なら「こんなとこ行った(事実)+こう思った(感想)」だけを書くのに徹するようにしたら、以前よりはだいぶ楽に記事を更新できるようになった。
「そんな記事を量産したところで何の役に立つんだ？」と言われたら、
- そもそも誰かの役に立とうと思って書いてるわけじゃない
- あくまで自分の思考を言語化するための訓練とか
- 日々やったことの記録を単純に残したいだけ
- ↑読者には単純に「自分がこういう人間だ」というのを知ってもらいたい
..とこれまた開き直ったのでいいんじゃないかと思う。
こちとらプロブロガーじゃない、プログラマーだ。世の中に有益なもんは自然言語じゃなくプログラミング言語で提供すれば良いのだ(ﾄﾞﾔｧ
というか日々の生活のログを残していくのは単純に楽しい。まだ再開して1週間くらいしか経ってないのに既に過去記事見返すのも楽しい。
ただ記事の更新がここまで出来たのも休みで時間が有り余っていたというのが一番でかいと思うので、仕事が始まってからもこのペースを続けられるか、まあ、頑張ってみる。
(10連休8日目)北条・安居島のついでに鹿島に寄ってみた
前回津和地島に行ったことで三津浜港・高浜港から行ける松山市内の島はすべて回ったことになったんだけど、忽那諸島という括りでいうとまだ行けていない島がひとつあって。
それが今回行ってきた安居島(あいじま)。
この安居島、定期船の出ている北条港が松山市中心部から10キロほど離れたところにある..程度であればどうってことないんだが、その定期便の本数が異様に少ないのだ。
夏季期間と呼ばれる期間を除けば、基本的に本土側からの船は1日1便。
その便が安居島に着いてからは本土側に戻る便が翌朝までないので、乗った時点で一泊コースが確定する素敵なダイヤ設定となっている。
希望すれば公民館に1泊3,000円で泊まったり、宿泊施設もあったりはするのだが、ただ朝までの間わずか0.26平方キロの小さな島で何を？と考えると上級者向けであることは否めない島。
最近だと築100年・188平米6DKの大邸宅が0円で売りに出されたり、その紹介文で「秘境」とまで言われている島、ああますます興味をそそられる。 ritou-akiya.com
島好きを名乗るからには1泊程度屁でもないぜ！くらいの勢いで乗り込むべきなのだが、慢性的な金欠＆チキンな僕は、本土からの船が1便増える(=日帰りできる)第1土曜日を狙ってとりあえず様子見に徹することにしてみた。
アクセス事情からは想像もつかない別天地
上記のような事情もあって「相当な僻地みたいだし、なかなかの荒れ地なのでは..」と想像して行ってみたのだが、乗ってきた船からして内装は古臭い感じもしないし、最近リフォームしたかのようなモダンな作りの家屋もちらほらあるし、人口20人とはいっても「死にかけている」ような場所にはまったく見えなかった。
それでも集落の中を歩いてみると空き家が目立ったりするのだけれど、それもこの町の独特の雰囲気を作る「味」のような気がしてきて。
個人的には周りのどこを見渡しても同じようなデザインの家屋が立ち並ぶ分譲住宅地なんかより、この安居島の町並みのほうがずっと「生きている」感じがする。
不便極まりない場所には間違いないけど、歩いていて楽しかったのも間違いない。
灯台までの道のりはちょっとした冒険要素
とはいえただ町を歩いているだけでも仕方ない、何か見どころ的なものはないのかと探してみたところ「灯台 徒歩10分」と書かれた山道を示す看板を発見。
この山道、一応人の手が加わった階段はあるのだが、とにかく緑が多くて「自然の中を歩いてる」感がすごかった。
こういう光景を見て自然と「ジブリの世界っぽい！」って思ったんだけど、
ふと思うとそれって、こういう自然豊かな光景に触れる機会が創作物の中くらいしか無い、って暗に言ってるみたいで、実はそれってものすごく寂しいことなんじゃないのか？
..とかふと真面目なことを考えてみたり。
最近とどまることなく膨張し続ける自分の体脂肪に喝を入れる、くらいのことは出来た気がする。
あとは海でも眺めるくらい
唯一の冒険要素を消化してしまったら、あとは特にすることがない。
ちょっといいな、と思った風景を写真に収めるくらい。
車がないから波音と鳥の声くらいしか聞こえてこない。
13時35分に到着後、15時の船で戻らなければならない慌ただしいはずのスケジュールだったけど、リラックスできた度合いでいうと、今まで行ったどの島よりも高かった気がする。
からの、超お手軽観光スポット「鹿島」
安居島から戻ってきたのが3時半頃、このまま帰るには早すぎるということで、北条港近くに船の発着場がある鹿島にもついでに寄ってみることにした。
鹿島は公園扱いで人が住んではいない無人島。なので僕が興味のある「有人離島」とは別カテゴリに入るのだが、まあそこは別にどうでもいい。暇つぶしだし。
安居島へのチケットが片道860円だったのに対し、こちらは往復で210円と格安。
まあ陸地から目の前に見えてる場所に漕ぎ出すだけだからやたらぼったくられても嫌なんだけど。
鹿がいる島で鹿島、でこの船っていうストレートにも程があるこの外装。
となるとさすがに鹿を見に行かねばなるまい。
..あれ？柵の中にいる？
はるか昔、じーさんばーさんに連れられて行った時は島内に放し飼いになっていた記憶があるのだが、なんか動物園の1コーナーくらいの面積で完結してる鹿要素。
自分の記憶違いなのか、安全上の理由とかで今の形になったのかはよくわからんが、想像してたものよりだいぶ落ちる鹿体験だったことは間違いない。
鹿区画の反対側はキャンプ場になっていて、連休終盤なおかげか、想像より多くの家族連れで賑わっていた。
松山市内からもアクセスしやすく、ちょっとした自然体験が手軽にできる場所だし、リーズナブルに楽しむにはいい場所なのかもしれない。
そういうわけで丸1日アクティブに動いたら結構疲れてしまった。
残り2日、前半同様おとなしく過ごすことにしますか。
(10連休7日目)一息入れるついでに時刻表サイトの問題点について整理してみた
津和地島から帰ってきた後に、しれっとリニューアル版を本番反映していた時刻表サイト。
とりあえずローカルで検証したとおりの動作はしてくれて安心はしたものの、現時点でも問題は山積みなので、一休みついでにその整理と対策方法について考えてみた。
モバイルでの操作性が総じてうんこ
リニューアル前と同様、PWA化してモバイルでの快適性を上げようと頑張ってみたのだけれど、PWA云々とは関係ない部分で問題が結構見つかった。
まず一番大きいのは画面サイズの小さい携帯から見ると必要な情報を得るのに上下にスクロールを繰り返さなければならないところ。
Chromeのシミュレータで確認したかぎり、iPhoneで言えばPlusシリーズを除くX以前の機種は軒並みこの状態になっているので早期に改善をしたいところ。
画面を強制的にスクロールさせるか、時刻表をモーダルで表示してスクロール自体を不要にするか。後者のほうがよさそうかな？
あとそのモーダル関連で言えばこれも画面が小さい機種だと選択肢がはみ出て表示されちゃうのもマズい。
このへんは休み中になんとか対処したいな、と思ってる。
ただこれらのバグは直していく一方、スマホに関してはネイティブアプリ版の作成を頑張ってみるのもアリかなとも思っていて。
そもそも「地図上のマーカーを操作する」アイデアはReact Nativeの技術書に載ってたサンプルから着想を得たものだし、バックのAPIも既存のものをそのまま使い回せる可能性が高いので(React/React Nativeを頑張って習得すれば)実現できるんじゃないかと。
まあそのへんは機会を改めて考えてみよう。
その他気になるところ
バグではないけど気になっているのは画像の読み込みと料金表に設定がない項目の表示について。
前者については、画像の点数自体を減らしたとはいえ500KB強(2019/5/4追記:さすがに嘘、200KB前後だった)の画像が結構大量にあるので、ユーザの想定外のところでギガ食わせてたら嫌だなあと思っていて。
使用ケースとして「電波状況のよくない離島で」目的の船の時刻表を調べることを考えているので、なるべく通信量は抑えたい(となるとそもそもGoogleマップを使うことを前提にしてるのも考え直さないといけないかも)。
このへんは遅延ロード処理入れるとかして対応していこうかな。
後者はたとえば高速船など、人以外が乗せられない船(あるいは自転車までは行けるけど車バイクは無理とか)での料金表の扱いについて。
現状そういう便の場合は数字を増やしても金額が増えないようにはなっているけど、それであれば元々フォームを表示しないほうが親切ではあるよな、ということで。
リニューアル前には一応やっていたことだけど、Vuetifyに変わってから処理をどうするか迷ったとこなので、なんとか対処法検討して実現していこうかと。
時刻表データの収集・管理方法
ここまではユーザ側から見える部分についてだったけど、これは管理・運営側の問題について。
時刻表の元データの収集を自動化するのが難しいのが悩みであるとは以前の記事でも書いていたけど、これから検索対象を増やしてくとなると、やはりすべてを手動で行っていくのはなかなか無理があるなと。
今まで二の足を踏んでいたスクレイピング処理も可能な部分に関しては少しでも実装して、自身の負担を少しでも減らす努力をせんとな、とは思っている。
それと「データの正しさを担保するシステム」作りにもぼちぼち着手していく必要があるかな。
ダイヤの改正もそうだし、消費税増税に伴って運賃が改訂される可能性も今後あるわけで、そこの変化をいかに素早く察知してこっち側のデータに反映させていくかを考えていきたいところ。
いろんな会社のサイトを毎日目視で確認して、ってわけにもいかないしこのへんも何らかの形で自動化ができれば、と思っているが果たして。
収益化
..とここまで考えてみると、今までも、そしてこれからもサイトの維持・拡大には結構な手間暇がかかってくる(現に連休の半分つぶして実装してる)と予想されるわけで、そうなるとその分はお金になって返ってきて欲しいと思うのが人情ってもの。
今のところ収益につながりそうなのはPayPal.Meへのリンク = 任意の寄付ボタンだけだけど、満足な収益を得られる期待は薄いし(現に以前の2つのサイトでも使っていたけど入ってきたお金はゼロ)。
導入する可能性が高いとすれば観光に繋がる部分。たとえば時刻表の検索と同時に周辺の宿を検索できて予約サイトへ導入するとか、遠方から訪れる人を想定して空港券の.. ってのが現時点で出てるアイデア。
ただ実装方法どうするかとか、それ本当にユーザが欲しいものなのかとか、それが原因でパフォーマンス落ちちゃったらどうなのか、とかとか。
考えるべきことは色々あるけど、そこは維持費格安の個人サービス。
いろいろ試して成功したらもっと頑張るし、駄目だったらとっとと引き下がればいいだけの話。
今はただ自分もユーザもWinWinになれるシステムを考える、それだけの時間が楽しい。
あー、この連休あと10日くらい延長できんかな。
