verbalize

文章書く練習…。

Fashion Shop Mapというwebサービスをつくった

タイトルの通りwebサービス作りました。またしてもGoogle Mapを使ってしまった。

www.fashion-shop-map.com

サービス概要

今回作ったものは、ファッションのショップの位置情報を検索することができるサービスです。これを使うことで、複数のショップの位置を同時に地図にプロットして見ることができます。

ユーザーの操作はとてもシンプルで、検索したいショップと都道府県を選択してボタンを押すと、選択された都道府県内にある店舗が地図上にマッピングされます。

機能としてはシングルページのwebサイトに近いくらいシンプルです。現在は主にセレクトショップを取り扱っており、以下のようなショップが登録されています。

ロゴ 名前 ロゴ 名前
f:id:bonhito:20161124230822p:plain BEAMS f:id:bonhito:20161124230835p:plain UNITED ARROWS
f:id:bonhito:20161125005139p:plain UNITED ARROWS BEAUTY&YOUTH f:id:bonhito:20161124230852p:plain UNITED ARROWS green label relaxing
f:id:bonhito:20161125005211p:plain URBAN RESEARCH f:id:bonhito:20161125005216p:plain URBAN RESEARCH DOORS
f:id:bonhito:20161125005220p:plain SHIPS f:id:bonhito:20161125005311p:plain EDIFICE
f:id:bonhito:20161125005319p:plain 417 EDIFICE f:id:bonhito:20161125005224p:plain JOURNAL STANDARD
f:id:bonhito:20161125005228p:plain coen f:id:bonhito:20161125005233p:plain A.P.C.
f:id:bonhito:20161125005237p:plain BShop f:id:bonhito:20161125005242p:plain SENSE OF PLACE by URBAN RESEARCH
f:id:bonhito:20161125005246p:plain HARE f:id:bonhito:20161125005252p:plain RAGEBLUE
f:id:bonhito:20161125005257p:plain GLOBAL WORK f:id:bonhito:20161125005345p:plain FREAK'S STORE

モチベーション

まず服が好きなので、それに関わるサービスを作りたいなと思っていました。

一番コアな動機としては、いろんなショップがどこにあるのかもっと手軽に見たい!と普段から感じていたことでした。私が服を見ようと思ったら、まず一覧性のあるWebで見て、その後チェックした服を実際に見に行きたいなと思うのですが、大体

「よっしゃ、週末服見に行こう。できれば1か所でビームスユナイテッドアローズとアーバンリサーチは見たいよな」

という流れ(あくまで例ですが)になります。しかしこの時、現状だとそれらのショップがどこにあるのか、Google Mapや各ショップの公式ページを見て一つずつ探さななければなりません。

この体験からGoogle MapはAND検索に弱いなと感じ、ファッションに特化した地図を作ろうと思いました。これはサイトのaboutページにも簡単に書いています。

最後にもう一つ理由があり、比較的取り扱うエンティティがシンプルだったことがあります。フレームワークを使って動的なアプリケーションを作るのはほとんど初めてだったので、DB設計が難しそうなSNSなどは考えていませんでした。

開発の話

このサービスはRuby on RailsGoogle Map、Bootstrap、jQueryを用いて作成しました。デプロイはherokuなのでスリープしてしまうと最初のページ読み込みが遅いです。

制作を始めてから現在までおよそ2ヵ月くらい経過しています。後ほど触れますが時間をかけてすぎてしまったのは反省点の一つです。

流れとしてはまず、9月末にRubyRailsに同時に入門しました。Railsおすすめのチュートリアル集で紹介されているものの内、短めのものを4つくらいこなすとすぐに流れがつかめました。夏のインターンMVCの考え方をつかんでいたのも良かったなと思っています。

その後この開発に着手し、毎日1〜3コミットずつくらいのペースで進めていきました。

サーバーサイド

本サービスは一見、位置を検索したいショップ毎にGoogle Mapで検索をかけ、結果を重ねただけのように見えますが、実際にはちゃんとデータを集めてDBに収め、そこから引っ張ってプロットしています。その理由としては、

  • そもそも店舗の情報を集める適当なAPIはない

  • ユーザーの検索のたびにGoogle Map APIを使うとすぐに制限を食らってしまう

  • Google Map自体の検索を使ってしまうと取り出したい・表示したい情報をコントロールできない

などがありました(若干うろ覚え)。なので、とにかくショップの店舗情報を集めるべく一つずつ公式ショップからスクレイピングすることにしました。

今gitのcommit logを確認すると、作り始めてからチュートリアルで学んだことをこれに当てはめながら開発を進め、サイトのシステム的な部分に関してはDBの設計と合わせても10/6に終わっていました。スクレイピングのやり方もそのあたりで並行して学びました。

なのでこれ以降はフロントエンドの開発と並行して毎日少しずつスクレイピングし、取扱ショップを増やしていきました。

フロントエンド

サーバーサイドが一段落ついてから画面の実装に取り掛かりました。試作時点での画面はこんな感じで全くデザインが当たっていませんでした(サービス名すらも違う)。

f:id:bonhito:20161125002121p:plain

そして現在のこの画面になるまでにおそらく約1ヶ月くらいはかかったと思います。まぁちょうどその頃から開発にかける時間も少なくなってしまったのも一つ原因なのですが。

f:id:bonhito:20161122160642p:plain

当初はモノクロな検索画面と地図表示画面の2つしか作っていませんでしたが、そこからBootstrapを導入し、検索条件部のドロップダウン・検索条件ラベル・地図表示画面を実装し、そのあと地図の横のリストや当サイトについてのページ、お問い合わせのページなどを作りました。このあたりではまだサーバーサイドからもらう情報が足りなかったりして、サーバーサイドのコーディングのやり直しだとか、DB設計のやり直し(カラムの追加)とかもあり手戻りが多かった気がします。

そして、シェアボタンとGoogle Analyticsなども付けました。デザインの改良はその都度その都度行いました。振り返ってみると、なにか新しいものを追加する度にcssの調整が必要だったり、jsを書かなければいけなかったり、小さなバグを潰したりと大変でした。また、最後になってから付け焼刃的にレスポンシブデザインを実装したり、前回のエントリで書いたようにロゴの使用の問題にぶつかったり、使っていた画像が実は改変禁止の素材だったりと、もうとにかく自分でバグを作り込むケースが非常に多く目立ちました

今回の開発を通じてもっともっと知識を付けなければなぁと思いました。それにしてもフロントエンド地獄って感じでした。まじで時間食われた…笑

インフラ

簡単で無料なのでherokuにしました。ルートドメインが使えないとは知らずにドメインを取得してしまい悲しい気持ちになりました。

できればシェルログインできるサーバーを借りてちゃんとデプロイしたいのですが、railsアプリはWEBrickなるwebサーバを使っておりなんだかめんどくさそうだったのでとりあえずまたの機会にしました。

振り返り

発見

  • フロントエンドは大変

    自分の実力不足でもありますが、シンプルだからと高を括って設計などをまったくせずに着手してしまったのが原因。振り返ると、機能やページを追加する度にスタイルが崩れたり、違うデバイスでサービスを使ってみて初めておかしい所に気づいたりと、fixのコミットが頻繁に入っていました。現在もなおモバイルに対するデザイン方法がわからない上、Chrome以外のブラウザでテストしたりもしていないので、フロントエンド開発自体に対する理解を深める必要があると感じました。

  • プロトタイプは仕様や設計を明確にする上で効果的

    今回プロトタイプを1つ作ってから開発を始めたのですが、これは純粋に良かったです。ただプロトタイプをどの程度の粒度(大きさ、正確さ)で作るべきか、あるいはどのような点に注目しながら作るべきなのかが明確でなく、設計のブラッシュアップが十分に行われませんでした。

  • MVPで公開した方が良い

    よく言われている(?)かとは思いますが、MVP(Minimum Viable Product: 必要最低限機能)で公開したほうが良いなと思いました。ただ、ユーザーが初めてサービスを目にした時にあの機能この機能があれば素通りせずに止まってくれるのでは無いかと考えてしまうので難しい。これについてもリーンに関わる書籍などを読んで意図するところをきちんと理解したい。

  • CRUDの内のREAD操作のみをユーザーに提供するサービスは、セキュリティ的に比較的楽

    不安ではありますが、とりあえずセンシティブな情報はあまりないので大丈夫かなと思っています。

特に良かったこと

  • 好きなテーマでサービスを作ったこと

    楽しかった。

  • こうしてある程度作りきってエントリを書いていること、それ自体

  • git使ったこと

    今回記事を書くときにも試作時点の状態にパッと戻せたり、草生やして満足感が得られました。あとherokuと連携してデプロイもできます。

    f:id:bonhito:20161125004027p:plain

  • todoリスト的なものにカンバンアプリ(Wekan — open-source kanban)を使ったこと

    一人だと効果は薄いですが、インターンで教えてもらったので見える化はせっせとやっていました。

特に悪かったところ

  • テストを書いてない

    勉強します…。

  • 著作権、素材の商用利用などをちゃんと確認していない

    わりと論外。今回は見落としがあったがいつも確認する癖をつける。曖昧な部分はある程度調べ、具体的な根拠を持って(すくなくとも個人的に)理解・解釈をする。

  • railsのデフォルトのsqliteをdbとして使っていたらデプロイでコケた

    はじめてのデプロイでデータのmysql移行とかその他config関係の設定とかで時間かかってしまいました。デプロイまで見据えた方がよい(?)

  • サービス(アイデア)は考えた時点で文書化するべき

    サービス開発している途中で、「あれ、もしかしてこれってGoogle Mapのマイマップで良くないか」とか「Google Places API使えば一発じゃないのか」とか思いついてアイデンティティが揺らぎかけた。どの当たりに差別化のポイントがあるのか整理し、文書でまとめつつ、関係する技術要素は最初に徹底的に調べるべきでした。

今後のTODO

  • 宣伝と集客

    せっかく作ったのでチャレンジする。

  • スマホ(モバイル)ページを改良する

    画面狭いと本当に難しい。モバイルファーストを最初から実践したかった。

  • 取扱いショップを増やす

    ウィメンズのショップをもっと増やしたい。あと、中には公式サイトの店舗検索がjsで動くようになっているところがあるので、seleniumを用いたjs対応のスクレイピングも挑戦したい。

  • 適当な頻度で最新の店舗情報を取得するクローラを作る

    Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

    Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

  • セレクトショップのサブブランドに対応する

    現在もいくつか対応していますが…。このあたりは難しいところです。

  • 店舗に関して提供する情報をもっとリッチに

    今のままだとGoogle Mapで単体検索した場合に比べ、提供する情報が貧相です。例えばショップのブログのurlだとか、取扱がメンズ/ウィメンズのみの店舗があったりするのでその旨をに表示するとか…。ファッションサイトに特化したなりの情報が出せると良いです。気が遠くなります。

  • 同位置のデパートのプロットを工夫する

    開発でかなりはまった要素として、同じデパートに入っている複数のショップは位置情報が全く同一で、プロットすると毎回上書きされて最後にプロットしたものしか見えなくなるというものがありました。現在はマーカーをプロットする時にすでにそこにマーカーがあれば一定幅位置を横にずらすようにしているのですが、これだと不正確な位置になってしまいます。正確かつわかりやすく表現する方法を模索したいです。

さいごに

railsに対する知識はあまり増えなかったのですが、Web開発の基本的な流れが確認できた。開発はとても楽しかった。またコードを継続的に書く習慣ができたので、これからも継続していきたい。

amzn.asia