とあるプロダーツプレイヤーの徒然日記

とあるプロダーツプレイヤーが徒然なるままによしなし事をそこはかとなく書きつくろいます

Githubでレポジトリ移動（ブランチとwikiの移動）

その他

概要

githubでいろんな事情でレポジトリを移し変えないと行けないときってあると思いますが、 そんなときにやる作業（ブランチとwikiの移動）についてまとめてみます。

ブランチの移動

  • 必要なブランチをひとまずすべてローカルに持ってくる
  • remoteのurlを確認する
$ git remote -v
origin  git@github.com:sample/repository_a.git (fetch)
origin  git@github.com:sample/repository_a.git (push)
  • remoteのurlを削除
$ git remote remove origin
# remoteをもう一度確認すると何もない
$ git remote -v
$ git remote add origin git@github.com:sample/repository_b.git
# remoteをもう一度確認するとremoteのurlが変わっている
$ git remote -v
origin  git@github.com:sample/repository_b.git (fetch)
origin  git@github.com:sample/repository_b.git (push)
  • defaultとするブランチから順番にpushしていく
$ git push origin develop
$ git push origin master
・・・

wikiの移動

  • そもそもwikiをcloneしてくる
# wikiって下記のような（レポジトリ）.wiki.gitにあるって知ってました？
$ git clone git@github.com:sample/repository_a.wiki.git
$ cd repository_a.wiki
  • githubの新しいrepositoryでwikiをcreateする
  • ブランチと同じようにoriginのurlの向き先を変更する
$ git remote remove origin
# wikiを指定してやる
$ git remote add origin git@github.com:sample/repository_b.wiki.git
  • remoteのブランチを上書きする
# 不本意ながらもforce pushを使う
$ git push origin master -f

おわりに

bitbucket ↔ github間の移行も同じようにできるの？ どなたか教えていただけると。

issueの移行も同じノリで（レポジトリ）.issue.gitとかってできたりするの？

今度やってみよう。

PC用とスマートフォン用のRspecを書き分ける

Ruby on Rails

概要

今時のwebサイトってPC用とスマートフォン用にUI作り分ける感じですよね？

ジョブメドレーでもjpmobile/jpmobile · GitHubを使って、PC用とスマートフォン用の画面を作り分けている。

そんな時に、featureテストを書くとしたら画面要素がそれぞれ違うので、テスト別々に書く必要がありますよね？

設定も含めて、どうやってPC用とスマートフォン用のテストをかき分けるかというお話です。

前提

  • gem 'jpmobile'を入れていること
  • include Jpmobile::ViewSelectorを読み込んでること
  • PC用とスマートフォン用のテンプレートを用意していること

Rspecの設定

まずは、スマートフォン用画面へ切り替えるため、user agentを偽装する関数を用意する

# spec/features/sample_spec.rb
module FeatureHelpers
  def switch_to_mobile
    user_agent = 'Mozilla/5.0 (iPhone; CPU iPhone OS 8_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko)'
    user_agent += ' CriOS/38.0.2125.67 Mobile/12B411 Safari/600.1.4'
    page.driver.header('User-Agent', user_agent)
  end
end

これをrails_helperで読み込む（featureテストなのでtypeをfeatureにする）

  # spec/features/sample_spec.rb
  config.include FeatureSpecHelpers, type: :feature

肝心のfeatureテストの書き方

# spec/features/sample_spec.rb
require 'rails_helper'

RSpec.feature 'サンプルページ', type: :feature do
  context 'PC用' do
    it 'トップページ' do
      visit '/'
      expect(page).to have_content 'PC'
    end
  end
  context 'スマートフォン用' do
    before(:each) do
      switch_to_mobile
    end
    it 'トップページ' do
      visit '/'
      expect(page).to have_content 'スマートフォンー'
    end
  end
end

まとめ

下記のQiita記事のように他にも方法はあるっぽいが、 自分としては上記の方法が一番しっくりきたので、これで。

Rspecでjpmobileを利用したスマートフォンサイトのコントローラのテストをする方法 - Qiita

"新しい自分に生まれ変わる「やめる」習慣"を読んで

ライフハック

概要

夜更かしとか、ダラダラしちゃう良くない習慣があるので、ちょっと新年を契機に改善しようと思ったので

新しい自分に生まれ変わる 「やめる」習慣

を読んでみた。

とりあえず、この本の内容について、自分がやってみようと思ったことをまとめてみる。

これ以上の内容が知りたければ、質問or本読んでいただければ。

実践方法

ステップ１：「悪い習慣の棚卸し」

  • 健康にとって良くない習慣とはなにか
  • 生活習慣を乱している習慣はなにか
  • 仕事における悪い習慣はなにか
  • お金面でやめたい習慣はなにか
  • ストレスになっている習慣はなにか

ステップ２：本当にやめるべきか考える

  • なぜその習慣をやめたいか
  • その習慣を放置するとどのような問題があるか
  • その習慣をやめるとどんな副作用がでそうか
  • それでもその習慣を本当にやめたいか
  • やめることで将来どのような効果があるか

ステップ３：やめることを「習慣化」させる前に押さえるべきこと

  • 1度に1つの習慣に取り組む
  • センターピン(KPI的なやつ)とボトルネックを確認する
  • 目標ではなく、習慣化させるプロセスに注目する

ステップ４：心折れないために

  • 危機感を持つ：このままではまずい！という気持ちを確認すること
  • 快感を感じる：これやめられてるおれ、かっこいい
  • 期待感を持つ：これやめられればおれは生まれ変われる！
  • 悪い習慣を新しい習慣に置き換える：タバコ吸う→コーヒー飲む
  • 最初から完璧を目指さない：習慣化は山あり谷あり

ステップ５：心折れそうなときに

  • モチベーションが上がる魔法の言葉を自分にかける
  • 悪い習慣をやめたあとの夢を描く
  • 行動メニューを具体的に決めて、機械的にこなす
  • タイマーを使って制限時間内に最大限集中する
  • ご褒美と罰を用意し、快感・危機感を上手にあおる
  • 毎日、行動を振り返る時間をとることで、成果・成長を確認する
  • 同じ辞めたい習慣を持つ仲間と切磋琢磨し、励まし合う
  • 周囲の人に宣言することで、自分を追い込む

ステップ６：そろそろ習慣化したかな？と思ったら

  • やめる習慣は何%実現できているか確認
  • うまくいってるときの要因分析
  • 挫折した時の要因分析
  • 今後の改善ポイントと、新しい目標の模索

最後に

とりあえず、明日から頑張る。

うまく早寝早起き、土日の有効活用ができるようになりたい。

そして、もっとダーツする時間を確保したい。

4時間半熟睡法のススメ

ライフハック

概要

新年、ブックオフ行って

4時間半熟睡法

を買って読んだの、それについてまとめてみた。

（そういえば、昔、澤野さんっていうイケメンな人がこの本紹介してくれてたな。。。）

背景

「睡眠時間削って、もっと早く仕事切り上げてダーツしたい！」と思ったので、 ちょっとライフハックみたいな感じで短眠法にチャレンジしてみようと思った。

実践してみる

※「 なぜ？」っていうのは実際に本読んでください

ここでは、自分が明日から実践してみようと思った項目を列挙してみます。

睡眠時間

  • 月曜日〜金曜日：4時間半
  • 土日どっちかで7時間半寝る、もう片方で6時間寝る

睡眠時間帯について

  • 午前1時から午前5時半の間寝る
  • 長く寝るときは、起床時間を変えず就寝時間を変える
  • 朝起きたら、とりあえず太陽の光を浴びる(10時までに浴びるのがいいらしい)

寝る前と寝る時について

  • 3時間前までにお酒・食事（キムチ・鍋がよい）を済ませる
  • 2時間前までに軽い運動を済ませる
  • 1時間前までにお風呂(38-40度くらいがよい)を済ませる
  • 寝る前は間接照明の使用や、ディスプレイの照明を弱くする
  • 寝るときは手足を冷やすようにする（わりかしやり方不明）

その他

  • 朝食は食べる（ダイエットではなく、朝からエネルギーを作り出すため（睡眠に何か関係あるか？あれ？））
  • 「目覚ましかけずに自然に起きるまで寝る」的なことは良くないらしい
  • 昼間眠くなったら15分の仮眠を取る

まとめ

とりあえず、もっとダーツしたいので、睡眠時間削ってもっと仕事がんばります。

2年目エンジニアのWebゲームとWebサービスの働き方比較

その他

概要

2年目エンジニアが、WebゲームとWebサービスでの働き方を比較してまとめてみました。

大企業と中・小企業（ユーザの多い・少ないサービス）や、プロダクト文化の差も中にはあるので、 一概にWebゲームとWebサービスの違いではない点もあるかもしれませんが、自分なりに勉強になったので書きつくろいました。

軽く経歴紹介

  • 2014年4月 新卒としてグリーに入社
    • 2014年6月よりwebゲーム開発に携わる
      • 最初はgetとpostベースの「ザ・Webゲーム」のようなコンテンツを開発（運営）していた
      • 2014年9月より、ajaxベースをふんだんに使った近代的なwebゲームを開発（運営）していた
      • 同時に新規なコンテンツも開発していた（データのスキーマ設計から）
  • 2015年7月 転職して株式会社メドレーに入社

比較

あくまでエンジニア視点で比較をしてみる。 なにか質問があればコメントしていただければ、更新しますm( )m

Webゲーム Webサービス
トラフィック量 ユーザ数の割に多い 少ない
プロダクトのエンジニア率 多い(CSが別チームというのもあった) 少ない(営業やCSが一丸となって働くから)
チーム内ユニット イベント毎に分かれていた イベントがないから、小ユニットはない
リリースタイミング イベント運用なので、イベントによって決まっている 基本的にない。開発完了したものから順次リリース
リリース時間帯 イベント等はユーザが多い時間帯（基本的に昼間）に行う 大きめのリリースはユーザが少ない深夜に行う
開発の忙しさ イベント運用のため、イベントがリリースされ始まるとしばらく作業が減る（バグ対応・分析・企画期間に入るため） イベント開始等の区切りがないため、基本常に次から次へとあることがあり忙しい
SEO対策の関連の作業 動的な内容が多いので、ない（基本的にいらない気がするが、ゲームによる？） htmlタグや、title等のメタタグも考慮して作る必要がある
外部のAPI使用に関して 基本的にゲームの機能は、ゲーム内で閉じている Google MapのAPI等外部APIを使うことが多い
ノリ どちらも変わらない。人次第 どちらも変わらない。人次第

まとめ

日常的な忙しさで言うと、リリースタイミングなどが決まっていない分、圧倒的にWebサービスの方が忙しいです。（もちろん、ゲームもやることはいくらでもあったので、最終的にはやる気次第な部分もある気がします。）

ただ、WebサービスはSEO関連の周辺技術を学べる点で、ゲームよりは技術的に幅広く開発できるのかなと個人的に思いました。

おわりに

今年はとにかく、Webサービス開発に携われ、RailsやAWS、cssの書き方について学ぶことができ、いろいろ経験できたいい年になりました。 来年もいろいろ勉強していきたいと思います。

ElasticSearchでSynonymTokenFilterを設定してみる

サーバーサイド インフラ ElasticSearch Ruby on Rails

概要・背景

最近の若者は、本田翼をばっさーとかって略すらしい。 ホンツバとかって略したくなるのは自分だけでしょうか？

どっちでもいいですが、検索エンジン的には、 本田翼も、ホンツバも、ばっさーも、同じ結果を返して欲しいですよね？ もちろん、検索システムを含むサービスの運営側としては、同じ結果を返したいですよね？

日本最大級の医療介護求人サイト | ジョブメドレーではElasticsearchを使っているので、それをうまくチューニングしたというお話。

ElasticSearchについて理解する

Elasticsearchについて無知過ぎたので、そもそもまずは概形を学ぶところからスタート。 以下は、勉強に使った一部の資料。 Elasticsearchチュートリアル - 不可視点 自分流Elasticsearch入門 - $shibayu36->blog; Elasticsearch 日本語で全文検索 その３ — Hello! Elasticsearch. — Medium

わかったこと（今回はこれだけ知っていれば、行ける）

  • データからインデックスを作成して、検索時にクエリを発行して検索する
  • アナライザーは、Toknizerでパースされ、Filterで整理される
  • アナライザーは、インデックス作成用と検索用がある

Ruby on Railsに組み込む

今回、組み込むにあたり、「辞書は定期的にいれかえる必要がある」という要件があった。 そのため、辞書更新の度に、インデックスをすべて更新するのはコストが高いので検索時のanalyzerだけ設定することにした。

辞書ファイルの作成

辞書ファイルの書き方は、大まかに3種類ある。

Synonym Token Filterを参考に

# 下記の用に=>を使うとマッピングされ
# ばっさーと検索すると、本田翼の結果が引っかかる
# ※「ばっさー」の結果は引っかからない
ばっさー => 本田翼

# 下記のようにカンマ(,)でつなげると
# 本田翼やばっさーで、検索すると
# 本田翼とばっさーとほんつばで検索した結果がすべて出る
ばっさー,本田翼,ほんつば

# 複数指定もできる
ばっさー=>ほんつば,本田翼

# 上書き方式ではなく、追加方式
# 下記の例は ばっさー=>ほんつば,本田翼と同じ
ばっさー=>ほんつば
ばっさー=> 本田翼

※追加終わったら、elasticsearchを再起動する

Elasticsearch-inquisitorを使って、実際できているかを見る

elasticsearch-inquisitorプラグインの紹介 - @johtaniの日記 2ndで紹介されているElasticsearch-inquisitorを使い、実際に検索クエリの単語がうまく解釈されているかを確認する。 ※Elasticsearchがきちんと再起動されていることを確認する

検索側のクエリにanalyzerを指定する

Query String Queryを見るとanalyzer: The analyzer name used to analyze the query string.というのがあるので、

{
    'query_string' : {
        'default_field' : 'content',
        'default_operator': 'AND',
        'query' : 'ばっさー',
        'analyzer' : 'search_analyzer',
    }
}

これで検索できる

まとめ

  • elasticsearchで類似語検索する場合は、Synonym Token Filterを使う
  • 基本的には、filterを設定しanalyzerを書いて、elasticsearchを再起動する
  • Query String Queryを使い、analyzerを設定し検索する

以上

ruby on railsでselectのクラスが設定できない！

Ruby on Rails Slim フロントエンド

概要

railsでフォームを作りこむためにslimのコードを書いていたら、selectだけうまくクラスを設定できない。 とても困ったので、備忘録として。

アホだったので

select - リファレンス - - Railsドキュメントに載っている通り、

= f.select :prefecture_id, options_for_select(1..200), autofocus: 'true', class: 'form-control'

とやろうとしたが、生成されたコードは

<select name="sample[prefecture_id]" id="sample_prefecture_id">
  <option value="1">1</option>
・・・
  <option value="200">200</option>
</select>

えー、出来無いじゃん。と思って

= select_tag "sample[prefecture_id]", options_for_select(1..200), autofocus: 'true', class: 'form-control'

と、無理やりselect_tagを使って対応していたが、どうも気持ち悪い。。。

正解

調べた結果、広い世界には同じような人がいるらしく

Can't add class on select form helper in Rails 4 - Stack Overflow

Can'tだったらしい。 とりあえず、真似して書いてみる

= f.select :prefecture_id, options_for_select(1..200), {}, { autofocus: 'true', class: 'form-control'}

生成されたhtml

<select name="sample[prefecture_id]" id="sample_prefecture_id" autofocus="autofocus" class="form-control parsley-error" >
  <option value="1">1</option>
・・・
  <option value="200">200</option>
</select>

となり、できた！！！と喜びました。

ところで

ところで、とりあえず書いたはいいものの、下記の第三引数って何に使ってるの？と思ったので補足

selectの内部実装

= f.select :prefecture_id, options_for_select(1..200), {ここはselectのオプションpromptやinclude_blankを設定するところっぽい}, { こっちはhtmlのオプションを設定するところっぽい。idやクラスとか }

とのことでした。

まとめ

要は、内部実装見に行けということでした。

以上。

大事なことは繰り返しときます。

selectの内部実装

= f.select :prefecture_id, options_for_select(1..200), {ここはselectのオプションpromptやinclude_blankを設定するところっぽい}, { こっちはhtmlのオプションを設定するところっぽい。idやクラスとか }