あおみかんのブログ

フリーランスのIT系エンジニア。ゲーム制作スタジオ4th cluster代表。

Sunspot (RailsでSolrによる検索を動かすGem)をとりあえず日本語検索に対応する方法

日本語で割と最近っぽい情報が全然なかったので簡単にメモ。

Solr: 6.6.0 / 7.0.0

Sunspot: 2.2.7

<RAILS_APP>/solr/configsets/sunspot/conf/schema.xml の中で <fieldType name="text" から始まって </fieldType> で終わる部分を以下の内容に差し替える。

<fieldType name="text" class="solr.TextField" omitNorms="false" positionIncrementGap="100" autoGeneratePhraseQueries="false">
      <analyzer>
        <tokenizer class="solr.JapaneseTokenizerFactory" mode="search"/>
        <filter class="solr.JapaneseBaseFormFilterFactory"/>
        <filter class="solr.JapanesePartOfSpeechStopFilterFactory" tags="lang/stoptags_ja.txt" />
        <filter class="solr.CJKWidthFilterFactory"/>
        <filter class="solr.StopFilterFactory" ignoreCase="true" words="lang/stopwords_ja.txt" />
        <filter class="solr.JapaneseKatakanaStemFilterFactory" minimumLength="4"/>
        <filter class="solr.LowerCaseFilterFactory"/>
      </analyzer>
    </fieldType>

stopwords_ja.txt 及び stoptags_ja.txt は solrをapache.orgから solr-7.0.0-src.tgz みたいなファイルをダウンロードしてきて 、その中にある solr-7.0.0/solr/core/src/test-files/solr/configsets/_default/conf/lang のうち _ja.txt で終わるファイルを <RAILS_DIR>/configsets/sunspot/conf/lang の中に入れれば良いみたい。 面倒ならとりあえずそれが必要な行を削っても、それなりには動く。

これをベースにtokenizerにuserDictionaryとか入れればユーザ辞書を使った検索とかも出来るっぽい。

今あまり時間がなくて雑なメモになってますが、もしもう少し丁寧に知りたい人がいたらTwitterのメンションとか、ここへのコメントくれれば追記します。

CloudFront配下にRailsを置いたときにSSL対応するMiddleware

最近CloudFront配下にアプリケーションサーバーを置くのが徐々に流行ってる気がします。

想定する構成としては、ブラウザが直接叩くのがCloudFrontで、その直下にELB、そのさらに下に直接pumaというような形式。 nginx使わないパターンですね。 assets以下はどのみちCloudFrontでキャッシュされるから、nginxで高速化するまでもないっていうのがこの設計の思想かなと思ってます。 pumaが重くならない程度に同時接続数を制御する役割もELBがになってくれますし。

さて、ともかくそんな構成にすると、SSL対応で手間取ったのでメモ。

バージョンは以下の想定です。

  • Rails 5.1.2 (4系でも変わらないとは思います)
  • Puma 3.7

困ること

何が困るかというと、CloudFrontでSSL→HTTPに変換して、ELB以降はずっとHTTPで取り回すと、X-Forwarded-Protoヘッダが渡ってこない事です。CloudFrontは何故か独自のCloudFront-Forwarded-Protoというヘッダを渡してきます。

これによって、 force_ssl! も動かないし、そもそも post,put,patchリクエストはCSRFをブロックする機構によって弾かれてしまいます。

フロントがELBだったら問題ないんですが、ここでは最前面にCoudFrontを置く想定…。

ここで対策は2つあります。

  1. ELBにもSSL鍵を指定して、CloudFrontからELBへの通信路をSSLにする
  2. AWS内しか通らない暗号化/解除の処理がムダでは?
  3. どうにかしてCloudFront-Forwarded-ProtoをRailsから認識させる。

ここでは後者を採用しました。

やったこと

以下のRack Middlewareを用意します。

# lib/cloud-front-header.rb
class CloudFrontHeader
  def initialize(app)
    @app = app 
  end 

  def call(env) 
    cf_proto = env['HTTP_CLOUDFRONT_FORWARDED_PROTO'].to_s
    if cf_proto && cf_proto.length > 0
      env['HTTP_X_FORWARDED_PROTO'] = cf_proto
    end

    @app.call(env)
  end 
end

そして、 application.rb に以下の内容を足します。 他にmiddleware使ってない場合は、どこに書いても問題ないと思います。

# config/application.rb
module MyApp
  class Application < Rails::Application
    # 前略
    require './lib/cloud-front-header.rb'
    config.middleware.use CloudFrontHeader
    # 後略
  end
end

と、強引な方法ではありますが、 CloudFront-Forwarded-Proto を勝手に X-Forwarded-Proto に上書きするという荒技でどうにかしたのでした。

Rack Middleware がバグるのは鬱陶しいので、to_s等を使った防衛的なコードになってますが、気に入らない人は適宜書き換えると良いです。

あと、置き場所を考え直すと require は要らないかも知れないです。 もし良い方法あったら誰かコメントとかで教えてください。

こういう事が出来るのはRackの優れたレイヤアーキテクチャのたまものですね。

Rails5で簡単にモバイル/PCのビュー分岐を行う

最近、仕事で必要だったので。 だいたい以下の記事を元にしてるだけですが、ちょいサンプルコードなど含めて解説。

stackoverflow.com

元々は mobylette というgemを使おうとしたらRails5では(たぶん4でも?)コケちゃうので自前実装気味に済ませたって経緯がある。

想定するサービス

基本はレスポンシブだけどTOPページ等の一部の画面だけPC/モバイルでの分岐をしているようなサービス

方法

まず、以下のconcernsを作る。

# app/controllers/concerns/respond_to_mobile_requests.rb

require 'active_support/concern'

module RespondToMobileRequests
  extend ActiveSupport::Concern

  # Regexp From: https://gist.github.com/dalethedeveloper/1503252/931cc8b613aaa930ef92a4027916e6687d07feac
  MOBILE_REGEXP = /Mobile|iP(hone|od|ad)|Android|BlackBerry|IEMobile|Kindle|NetFront|Silk-Accelerated|(hpw|web)OS|Fennec|Minimo|Opera M(obi|ini)|Blazer|Dolfin|Dolphin|Skyfire|Zune/  
  included do
    before_action :variant_mobile

    def variant_mobile
      # The solution from: https://stackoverflow.com/questions/39495834/mobile-view-in-rails-5
      request.variant = :mobile if is_mobile_request?
    end

    def is_mobile_request?
      @_is_mobile_request ||= MOBILE_REGEXP.match request.user_agent
    end
  end

end

次に、描画を振り分けたいコントローラおよびそこのアクションで以下のようにする

# app/controllers/home_controller.rb

class HomeController < ApplicationController
  include RespondToMobileRequests

  def index
    if is_mobile_request?
      # モバイルの時だけの処理
    else
      # PCの時だけの処理
    end
    
    # 以下のコードでビュー振り分け
    respond_to do |format|
      format.html.mobile
      format.html
    end
  end
end

あとはビューファイルとして index.html.erb (※hamlでもslimでもご自由に)と index.html+mobile.erb を作れば、勝手にビューを振り分けてくれる。

もしCloudFrontのカスタムヘッダ( CloudFront-Is-Mobile-Viewer 等)とかを使いたければ、request.user_agentにmatchかけてる部分の代わりに request.headers['CloudFront-Is-Mobile-Viewer'] 等を見ればいいと思う。

rails + sunspot なアプリケーションの本番環境をdocker-composeでつくる

Dockerやdocker-composeの話って結構「いいよ」と目にするんですが、いざ始めようと思うとハードルが高いですよね。

僕も今日は丸一日Docker(-compose)に吸われてしまいましたが、その成果をちょっとメモしておきます。

やりたいこと

やりたいのは以下のような構成。

  • Railsが動くコンテナをDockerで作る
  • Sunspotによる検索をしたいのでsolrをDockerで動かす
  • DBはRDSを想定するのでコンテナでは作らず外部に繋ぐ

想定環境

  • Mac OSX Sierra (10.12.4)
  • Docker 17.06.1-ce
  • docker-compose 1.14.0

DBをローカル宛にする方法

まず簡単な方から。

これは、単に docker.for.mac.localhost というホスト名でホストOSが見えるようになっているので、以下のようにすればOK。

# .env.production (抜粋)
DATABASE_URL=mysql2://root:@docker.for.mac.localhost:3306/my_app
# database.yml (抜粋)
default: &default
  adapter: mysql2
  encoding: utf8
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  timeout: 5000
  username: root
  password: ''
  socket: /tmp/mysql.sock
production:
  <<: *default
  database: my_app
  # ↓ ここが重要。他はデフォルト。
  url: <%= ENV['DATABASE_URL'] %>

この場合のDockerfile/docker-composeは後述のsolrを使う場合のから読み取って欲しい。

SolrをDockerベースで動かしつつsunspotと連携させる方法

こっちが難しかった。

先にコードを示す。

#Dockerfile
FROM ruby:2.4.1
RUN apt-get update -qq && \
  apt-get install -y build-essential libpq-dev nodejs
RUN mkdir /app
WORKDIR /app
COPY Gemfile /app/Gemfile
COPY Gemfile.lock /app/Gemfile.lock
RUN bundle config build.nokogiri --use-system-libraries && \
  bundle install -j3 --without test development --no-cache
COPY . /app

こっちは割と普通の例だと思う。 bundle install--deployment を付けるとrakeがないって怒られるようになってしまったので、つけるのやめた。

# docker-compose.yml
version: '2'
services:
  web:
    restart: always
    build: .
    env_file: .env.production
    command: "bundle exec rails s -p 3000 -b '0.0.0.0' -e production"
    volumes:
      - .:/app
    ports:
      - "3000:3000"
    depends_on:
      - solr
  solr:
    image: solr:6.6.0
    volumes:
      - ./solr/configsets/sunspot/conf:/opt/solr/server/solr/production
      - solr:/opt/solr/server/solr/production/data
    entrypoint:
      - docker-entrypoint.sh
      - solr-precreate
      - production
      - /opt/solr/server/solr/configsets/sunspot

volumes:
  solr:

何のことはなく、volumesでホストOSのディレクトリをゲストに使わせてるだけなんだけど、これが重要だった。

この状態で docker-compose build && docker-compose up -d で立ち上げた後、solrの Core というのを作るために次のコマンドを打つ

# このコマンドは打たなくてよくなった
# docker-compose exec solr bin/solr create_core -c production

↑entrypointのセクションで不要に出来ました。

solrのwebコンソールとかにらめっこしながら、とにかく開発時にsunspotが生成する schema.xmlsolrconfig.yml をdockerのsolrに認識してもらおうとしてたらこのようになった。

現状の課題

現状だと solr/configsets/sunspot/conf/core.propertiessolr/configsets/sunspot/conf/data/ にsolrのデータが生成されてしまう。 開発環境で邪魔になるという問題もあるし、本来これらはvolumeを定義してそこに保存されて欲しい。 しかし、solrのconfig類を渡す必要もあるので、いまひとつどうすればいいか分からなかった。 ……solrについては元々あまり詳しくないので、誰か補足してくれたら凄く嬉しいです。是非コメントください。

参考

以上、調べるのに割と苦戦したのでメモでした。誰かの助けになれば幸い。

ドラクエ11 ファーストインプレッション

さて、とうとう出ましたね、ドラクエ11。 ふと思った事があるので僕なりの印象を書きます。ネタバレ要素はない気がするけど、カンの良い人にとっては間接的にネタバレする要素もあるので気をつけてください。




↓以下本文






ちなみに僕はドラクエ9のみ未プレイ、他は一通りプレイ済みって感じです。クリアしてないのもちらほらありますが。

ドラクエ 11 = 10 + 1 ?

ドラクエ11をプレイして最初の感想は「ドラクエ10のゲームシステムでドラクエ1のプレイフィールを再現しようとしたのかな?」でした。 僕がPS4版でプレイしているのもありますが、ドラクエ10のシステムがベースだと感じました。3Dマップ、戦闘中に歩き回れる、戦闘フィールドが探索フィールドと一致している、以前のドラクエとは異なるターンシステム、クエストシステム、3Dムービーの入れ方…などなどです。

しかし、ドラクエ10に存在していた(M)MORPGとしての要素はなくなり、スタンドアロンなゲームになりました。ここがある種の原点回帰だなと感じ、これはどことなくドラクエ1のようだ、とも思いました。

ドラクエ 11 = 2 + 9 ?

次に、UIが気になったので、一緒に買っておいた(というかゆうしゃの剣ボックスで買った)3DS版をプレイしてみました。 ドラクエ9のことは画面しか知らないのですが、DSシリーズ同士ということで、3DSDQ11DS9に似ていると感じました。

また、滅びた国の話を聞いたり、イヌに変身させられている人間(こっちは仲間にならないけど)を見つけたりしているうちに、DQ2っぽいシナリオのような気もしてきました。

ドラクエ11 = 今までのすべてのドラクエ

このまま例示を続けるのもアホくさいので結論に走ると、ドラクエ11は今までのドラクエ(ナンバリング)シリーズの要約というか集大成のようなものなのだと思います。 ドラクエ4と被って見える要素も沢山あります。パーティーメンバーの姉妹とか。 重ねて、ドラクエ5由来かなと思える展開も。

そんなわけで、ドラクエ11は、今までのドラクエシリーズをプレイしていればニヤリと出来るセルフオマージュが沢山あって、でもドラクエシリーズをプレイしたことがない人でも楽しめるような配慮がされていると思います。

ちなみにですが、僕は油断してサソリにやられました。今回、鍛冶がすごく楽しい。

ボス戦は「ゲームシステム」なのか「物語」なのか

ボス戦は「ゲームシステム」なのか「物語」なのかっていう話をporoLogueさんがしていて興味深かったので少し考えてみた。
みたら、とても1ツイートには収まる気配がないので、せっかくだし短めの記事にしてみる。

そもそもRPGってさ

そもそもRPGにおいて、システムと物語というのは切っても切れないものだ。
何故かというと、ここでいう(コンピュータ)RPGというのは物語を体験する遊びであるところのT-RPGをコンピュータで再現する試みなので、そもそもRPGの最初のコンセプトの時点で、物語体験型のゲームであるということだ。

しかしコンピュータRPG(以下、単にRPGと呼ぶ)も歴史が重ねられていくにつれ、その原義だけでは語れないものも増えてきた。
元々は何か意図を持って構築されたシステムが、なんとなく踏襲されているのは、珍しくない。ある程度は仕方ないとも思う。

システムと物語の協調

それでも、やはりゲーム体験において楽しいのはシステムと物語が噛み合っているものだと思う。
ザコ戦などは「修行」や「努力」的なものであるべきだし、
条件分岐的な意味での「フラグ回収」が物語構造上のフラグ(伏線)と関連しているのがよい。

じゃあボス戦って何か。

それは「苦境」あるいは「対立」に相当するものだと思う。

ミッドポイントあるいはクライマックス

いわゆる三幕構成における第二幕、特にそのミッドポイントと呼ばれる場面は、物語上重要な局面だ。ここでは「主人公の危険度が急に上がる」とされる。逆に言うとそれまでは楽勝で油断している。
あるいは、第三幕のクライマックスも超重要な場面だ。こっちは説明不要かな。

そう、第二幕ミッドポイントが中ボス、第三幕クライマックスが大ボスに相当すると考えられる。

ボス戦が何度もあるゲームが多いが、それは1つのゲームの中にこの構造が複数含まれているって事だ。

参考:

三幕構成 - Wikipedia

切っても切れない物語とシステムの関係

つまり、ボス戦は三幕構成の中でも際だって重要な2箇所をゲームシステムと重ねがけで演出するのに非常に適したイベントだということだ。
そりゃあ、多くのゲームにボス戦があるわけですよ。

余談

余談だけど、あんまりブログで紹介していないけれど、4th clusterで制作中のRPG「StarMined」がようやく形になってきた。
あんまり黙ってるから「え、お前ゲームなんか作ってたの?意外w」とか言われそう…w

科学×中学生がテーマなノベルゲーム「EVERETT EFFECT」 開発途上版 "interpretation" 公開予定

f:id:akn_ep:20160729005618j:plain

everett-effect.com

僕がシナリオとか演出とか企画全体の概ね半分くらいをやっている「EVERETT EFFECT」というゲームの開発途上版を5月6日に東京ビッグサイトで行われるコミティア120にあわせて公開します。

ノベルゲーム部公式ページ

ノベルゲーム部、という名前のコミティア部活動の一員としての出展です。

ブースは K04b Sapience です。よろしくおねがいします。