backstage

合唱音源の新着情報の舞台裏

合唱音源の新着情報をWebサイト化する

合唱音源の新着情報.com を作りましたので、その技術的な背景を書き残しておきます。

概要

かつて、 twitterの合唱音源の新着情報 の投稿を自動化するためにアプリケーションを開発しました。

s2terminal.hatenablog.com

今回はこの記事の続きで、これからさらに3ヶ月をかけてフロントとなるWebサイトを作りました。

開発環境について

環境とエディタの変遷

Vim(CentOS6) → RubyMine(Windows8.1) → NetBeans(Windows8.1) → SublimeText(Windows8.1) → Atom(MacOSX) → VisualStudioCode(MacOSX)

環境をコロコロ変えすぎだと思います。

色々あって結局はMacのローカルにRailsサーバを立てて、Git対応テキストエディタで直接編集という形に落ち着きました。 VisualStudioCode(ベータ版)を使っているのは宗教上の理由ですが、Sublime/Atom/VS Codeはどれも一長一短だと思います。VS Codeはこの3つの中で最も低機能なせいか、体感的には最も軽いです。

SublimeとVS Codeについてはユーザ設定をGitHubに上げました。(大した設定はしていませんが...)

ソースコード管理

バージョン管理には終始gitを使っています。 開発当初はプロダクション用のアプリケーションサーバをそのままリポジトリサーバにしていましたが、現在はGitHubの有料会員になったのでそのプライベートリポジトリを使うことにしました。

ついでに、タスク管理にもGitHubのIssue/Milestoneを使いました。 コミットをpushするとAjaxでブラウザ上のissueが勝手にクローズするのが衝撃でした。

参考:プロジェクト管理ツールとしてのgithub « 合同会社フィヨルド

システムの裏側について

オレオレSSL

前回の記事でもRailsAdminによるバックエンド画面を導入しましたが、すべてhttp通信だったのでログインが必要な箇所はhttpsに対応させました。 正規の証明書である必要ないので、いわゆるオレオレSSL(正式名称が分かりません)を用意しました。

気をつけるべき点としては ファイアウォールで443番を開けておく という事ですね。 何度言われても忘れます...

deploy

相変わらずcapistranoは使っていません(なんとなく面倒くさそう...)

前回記事の時点でdeployは毎回まごころを込めてコマンド手打ちでしたが、今回さすがにシェルスクリプトファイル化してリポジトリに含めました。(それぐらい最初からやるべきでは...)

このスクリプトをcrontabに仕込んで定期実行させて「これで継続的インテグレーション実現や!◯enkinsなんて要らんかったんや!」と言い張っています。 しかしテストが無いので、勝手にdeployして勝手に落ちて以来crontabはやめてスクリプト実行は手動にしました。 やはりさっさとcapistranoを導入するべきだと思います。

なおdeploy中はSCSSのコンパイルやデータベースマイグレーション等のため正常に表示できなくなる上、そもそもMicrosoft Azure VM A0(最弱)インスタンスではサーバ負荷的にレスポンスを返すのも厳しくなります。 そこでturnoutというgemを導入し、deploy中はメンテナンス画面を表示して503を返すようにしました。

turnout Railsでサクッとメンテナンス画面を表示 - 酒と泪とRubyとRailsと

デザインについて

方針

コンサートの動画を埋め込むことが多くなると想定していたので、高級感あるコンサートホールのやわらかい照明をイメージして配色しました。

具体的にはこんな感じです:三井住友海上しらかわホール

実際のコードを出すとこんな感じです。こういったテーマカラーを_define.scssというファイルに定義しておいて、各所から呼び出して使いました。

$color_accent: #933;
$color_dark: #555;
$color_light: #ccc;

この配色のカラーコードだけは1年前からずっと変更していません。 逆に言うと、それ以外はコロコロ変わりました。

フラットデザイン+レスポンシブデザイン

合唱界においては先例が少ないであろうフラットデザインを使いました。 併せてレスポンシブwebデザインを採用し、あらゆるデバイスで綺麗に見えるように組んであります。

動作は下記6端末で確認しました。色々ありますがiPhoneがありません。後にGoogleAnalyticsで確認した所やはりiPhoneが4割と最も多かったので、ちゃんと検証できる端末を用意したいですね。

レスポンシブにするかどうかは迷った(実際にレスポンシブ化したのは先月)のですが、下記理由により採用しました。

  • リファレンス的な使い方メインになるので、全デバイスで極力同じビューを提供したい。
  • 導線が一直線のサイトではないので、いちいち細かい最適化はしない(だろうという希望的観測)
  • 動画再生が目的なのでFeature Phoneは対応機種に含まない。

しかし問題点もあり、例えば動画埋め込みはPCで積極採用したい反面モバイルでは減らしたいのですが、テンプレートが同じなので出し分けが難しかったりします。

Landing Page/First View

トップページはそれらしくなるように頑張りました。

f:id:s2terminal:20150506233032p:plain

サイトの説明よりも音源を聴いてもらったほうが早いと思ったので、文章よりも先にいきなり動画を埋め込んでしましました。

しかし、こういったコンテンツがページ上部に無いサイトはGoogleからは嫌われ、PageSpeed Insights 等で文句を言われたりします。SEOに悪影響が出る等の不吉なことが起こるはずなので、あまり褒められたデザインではないと思います。

Twitter Bootstrap

見る人が見れば1秒で気づくと思いますが、Twitter Bootstrap に大変お世話になりました。

合唱界でTwitter Bootstrapを知っている人は少ないと思うので、いわゆるbootstrap臭については開き直ってガンガンに使っています。 それでもトップページはまだマシなものの、下層ページはあからさまにベタベタなbootstrap。もう少し真面目にデザインしたほうが良いと思っています...

Twitter Text

Twitter Bootstrapはよく聞きますが、Twitter Textはもっと評価されるべきだと思います。 まずAutoLinkが便利。

  $('.twttr-auto-link').each(function(){
    $(this).html(twttr.txt.autoLink($(this).text()))
  });

他にも、Twitter連携を真面目に作るならぜひ使うべき機能が色々あると思います。ちゃんと読んでいないのでよく知りませんが。

作業用BGM

効率を上げるために作業用BGMは重要です。このサイトは連休中 ゼノブレイドクロス で遊ぶ時間を犠牲にして作っていたので、欲求を満たすため前作ゼノブレイドのBGMをずっと流していました。 合唱音源のサイトを作っているのに合唱曲を流さないという矛盾。

特に下記動画はローカルサーバ上での動画埋め込み検証の際にも使わせていただきました。ありがとうございました。

真面目な話をすると、この合唱音源の新着情報を何年も続けるきっかけとなった曲のひとつであるAriel Quintanaの作品集 もよく聴いていました。

個人開発はいかにモチベーションを保つかが大切だと思います。 特に、合唱音源の新着情報は(現時点ではまだ)収益が立っていないので、サーバ代などのお金を払ってでもやる意義を見出さないと開発が続きません。

  • 多くの人に素敵な合唱曲を聴いてもらう(音源を紹介する目的)
  • 合唱の好きな人が集まるメディアを作って、コンサートの集客最適化(いつかやりたい事)
  • 縮小の続く合唱市場を盛り返す(最終的な夢)

私は普段こういった事を妄想しながら、夜な夜な音源を探しています。

その後について

サイトが完成し、リリース告知をTwitterにて行いました。

これをつぶやいた瞬間、せいぜい瞬間10アクセス程度なのですがサーバの負荷が極端に高まり、Webサイトが応答不能状態になりました。 Azure A0インスタンスでは厳しいか、それともアプリケーションに何か問題があるか…まだまだやる事は多そうです。

参考文献