てくすた

ピクスタ株式会社のエンジニア・デザイナーがつづるよもやまテクニカルブログです

MFIプロジェクト エンジニアともめたあのひ・・・・その1

この記事は、PIXTA Advent Calendar 2017 21日目の記事です。

こんにちは、デザイナーの宇田川です。

グーグルが発表した、モバイルファーストインデックス(MFI)で
モバイル対応を進めているWEBサイトも多いのではないでしょうか?

PIXTAのように、to B向けのサービスだと、
PCからの利用がメインになるので、今までモバイル対応をしてこなかったのですが、

MFIの発表がされ、SEO対策の一環でモバイル対応を開始することになりました。

今回は

  • モバイル対応で検討したこと
  • モバイル専用のデザインの作成
  • 根本が覆ったあの日........(エンジニアがMFIプロジェクトにやってきた)

などをお伝えしたいと思います。

モバイル対応で検討したこと

まずは、デザイナーだけでMFIプロジェクトの検討をした内容として

  • レスポンシブで進めるか?
  • モバイル専用のページを作成して進めるか?

を検討しました。

最初でもお話したように、PIXTAではPCからの利用が圧倒的に多く
【PCのUIに影響を出さない!】が絶対条件となります。

ただし、モバイルの利用も増えてきているので
モバイルの使い勝手も考慮して進めることも視野に入れる必要がありました。

それを踏まえて

まずは、レスポンシブ、モバイル専用のメリット、デメリットを洗い出しました。

レスポンシブで進めるメリット、デメリット

【メリット】

  • 運用の工数が圧倒的に低くなる

【デメリット】

  • モバイルのUIにマッチしていない

モバイル専用のページで進めるメリット、デメリット

【メリット】

  • モバイルで使いやすいUIを提供できる
  • PCのUIに影響が出ない

【デメリット】

  • 運用工数が大幅に多くなる

これを比較したときに、明らかにまずはレスポンシブかなーと考えたのですが、

  • リリースまでにそんなに時間を割けない

という課題もあり、なおかつ、

  • PC, モバイルどちらにも適したUIを提供したい

という思いがあり、PCに影響を与えない方法を考えると

モバイル専用のページを作成した方がいいのでは?

という考えにいたりました。

これで進めるぞ!

  • モバイル専用のデザインを作る
  • 既存のPCのUIは、後々モバイルに寄せていく!
  • 新規で作るのでコードも整理できるいい機会!コードリファクタも合わせてやってしまえ!

運用がPC, モバイルと二重管理になりますが、

来年にはPIXTAサイトのPC版をモバイル専用のデザインに合わせて レスポンシブ化する予定だったので

二重管理は少しの間だけ......

コードのリファクタもできる!

我ながらいい着地と、自画自賛した2017年10月の寒い日だった!

この案を、技術推進部に提案して、色々質問責めにあいましたが..... なんとかクリア!

これで進める事になりました。

モバイル専用のデザインの作成

よし!

と気持ちを改め、デザイン作成に取りかかる事となります。

※MFIプロジェクト担当予定のエンジニアは、まだ別プロジェクトにアサインされていたため、まずはデザイナーだけでデザインを進めました

新規で作成する良い機会なので、Atomic Designを採用することにしました。

【モバイル専用デザイン】

f:id:naoki-udagawa:20171220110106j:plain

【シンボルのコンポーネント化】

f:id:naoki-udagawa:20171220110240j:plain

デザイン作成で意識したことは、 後々は、PCをモバイルに寄せていく(レスポンシブ化)を意識して作成したことです。

根本が覆ったあの日........(エンジニアがMFIプロジェクトにやってきた)

ついに、別プロジェクトを終えたエンジニア2名がMFIプロジェクトにやってきました!

そう、、あれは2017年11月初旬のことでした。

エンジニアにMFIの経緯とプロジェクトの進め方を説明して
(僕は自信満々に説明していたのをよく覚えています)

よしやるぞ!!

と声が上がると期待したところ

エンジニアの方から以外な一言が.....

エンジニア:「PCとモバイル二重管理辛くないっすか....」

な・な・なんと......

エンジニアに、メリット、デメリットの考察を伝え、この経緯でこう決めましたと伝えたところ

でも

エンジニア:「初めからレスポンシブで行けばいいんじゃないっすか?」

そ・そ・そうなんだけれども、
ちょうど、エンジニアのプロジェクトへの合流も遅くなったこともあり
リリースが伸びた経緯もあった....

ガビーーーーン

ここからエンジニアとデザイナーの長い戦いが始まるのであった

話が長くなるので、これはまた別のお・は・な・し・で。。。。

※もしも話が聞きたい方がいたらぜひPIXTAへ!!!

PIXTAではエンジニア・デザイナーの採用に力を入れておりまっす

*****

ピクスタでは、サービスを盛り上げていきたいデザイナー・エンジニアを募集しています。 recruit.pixta.co.jp

結論は、

レスポンシブで対応して、モバイルとPCの共存できるUIを後から対応すればいいんじゃない?

でまとまりましたとさ...

ここで一句

デザイナー編

デザイナー 夢を盛り込む 性格ね

エンジニア編

エンジニア タスク配分 現実派

まとめ

いかがだったでしょうか?

実はこのお話には続きがあるのです!!

(MFIプロジェクト デザイナーともめたあのひ.......その2)

明日12/22(金)に続き(エンジニア目線)が見れるので、お楽しみに!!!!!!!!!!!!!

*****

ピクスタでは、サービスを盛り上げていきたいデザイナー・エンジニアを募集しています。 recruit.pixta.co.jp

Rails5.1でのおくりびとの迎え方

この記事は、PIXTA Advent Calendar 2017 20日目の記事です。

こんにちは、三浦@yukainaです。 先日「おくりびとの迎え方
と言う記事でgemのOkuribitoを導入する手順を Rails4.2系のサンプルプロジェクトでまとめていました。
https://github.com/yukaina/sample_4_2_10

今回は、Rails5.1系のサンプルプロジェクトを用意してみましたので、
こちらで導入をしてみようと思います。 https://github.com/yukaina/sample_5_1_4

1. Gemfileにokuribito_railsを追加します。

gem 'okuribito_rails'

2. bundle install

bundle

3. Okuribito用のマイグレーションファイル等の準備をします。

bundle exec rails generate okuribito_rails:install

-次は migrate なのですが、okuribito_railsの現在のバージョン0.2.4では、 migration versioingに対応していないために、エラーになってしまいます。

$ bin/rake db:migrate
Running via Spring preloader in process 14586
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:

Directly inheriting from ActiveRecord::Migration is not supported. Please specify the Rails release the migration was written for:

  class CreateOkuribitoRailsMethodCallSituations < ActiveRecord::Migration[4.2]
    (中略)
-e:1:in `<main>'

Caused by:
StandardError: Directly inheriting from ActiveRecord::Migration is not supported. Please specify the Rails release the migration was written for:

  class CreateOkuribitoRailsMethodCallSituations < ActiveRecord::Migration[4.2]
    (中略)
-e:1:in `<main>'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)

そのため、ここでは3.で生成された2つのmigrationファイル

  • YYYYMMDDHHMMSS_create_okuribito_rails_method_call_logs.okuribito_rails.rb
  • YYYYMMDDHHMMSS_create_okuribito_rails_method_call_situations.okuribito_rails.rb を編集します。

YYYYMMDDHHMMSS_create_okuribito_rails_method_call_logs.okuribito_rails.rbを例にすると class CreateOkuribitoRailsMethodCallLogs < ActiveRecord::Migration の最後に[5.1]を追記して以下のようにします。

# This migration comes from okuribito_rails (originally 20161027150000)
class CreateOkuribitoRailsMethodCallLogs < ActiveRecord::Migration[5.1]
  def change
    create_table :okuribito_rails_method_call_logs do |t|
      t.integer :method_call_situation_id, null: false
      t.string :class_name, null: false
      t.string :method_symbol, null: false
      t.string :method_name, null: false
      t.text :back_trace

      t.timestamps
    end
    add_index :okuribito_rails_method_call_logs, :class_name
    add_index :okuribito_rails_method_call_logs, :method_name
  end
end

2つのmigrationファイルを編集したら続きへ行きましょう。

4. migrate

bin/rake db:migrate
$ bin/rake db:migrate
Running via Spring preloader in process 15467
== 20171217143847 CreateOkuribitoRailsMethodCallSituations: migrating =========
-- create_table(:okuribito_rails_method_call_situations)
   -> 0.0033s
-- add_index(:okuribito_rails_method_call_situations, :class_name)
   -> 0.0009s
-- add_index(:okuribito_rails_method_call_situations, :method_name)
   -> 0.0010s
== 20171217143847 CreateOkuribitoRailsMethodCallSituations: migrated (0.0054s)

== 20171217143848 CreateOkuribitoRailsMethodCallLogs: migrating ===============
-- create_table(:okuribito_rails_method_call_logs)
   -> 0.0009s
-- add_index(:okuribito_rails_method_call_logs, :class_name)
   -> 0.0006s
-- add_index(:okuribito_rails_method_call_logs, :method_name)
   -> 0.0008s
== 20171217143848 CreateOkuribitoRailsMethodCallLogs: migrated (0.0025s) ======

無事成功しましたよね! ここまでくれば、以降は同じで

5. config/okuribito.ymlを用意する。

Class名:
  - "#インスタンスメソッド"
  - ".クラスメソッド"

それでは、IdeasControllerindexアクションを監視してみましょう。 本来のおくりびとの目的は、指定したメソッドが使われていないのかを確認するため、 使われていないであろうメソッドをokuribito.ymlに記入するのですが ここでは、メソッドが実行されることでカウントアップされていることで、正常におくりびとの導入ができていることを確認することにします。

IdeasController:
  - "#index"

6. application.rbを編集

class OkuribitoSetting < Rails::Railtie
  config.after_initialize do
    okuribito = Okuribito::OkuribitoPatch.new do |method_name, obj_name, caller_info|
      # do something as you like!
    end
    okuribito.apply("config/okuribito.yml")
  end
end

以上でOkuribitoの設定は終わりです。

最後に動作の確認をしてみます。

1. Rails server起動

bin/rails s

2. Okuribitoの管理画面で監視の状態を確認。

http://localhost:3000/okuribito_rails/method_call_situations IdeasControllerindexアクションのTimes of calledのカウントが0で登録されていることが確認できます。 f:id:Yukaina:20171219162539p:plain

3. 実際にカウントされるかどうかの確認をするために、アクセスしてみます。

http://localhost:3000/ideas f:id:Yukaina:20171219162601p:plain

4. アクセスした後に、Okuribitoの管理画面で監視の状態を確認。

http://localhost:3000/okuribito_rails/method_call_situations f:id:Yukaina:20171219162745p:plain IdeasControllerindexアクションのカウントが上がっていれば成功です!


Rails5.1でも、うまく導入ができたでしょうか? 今回は、手を抜いてmigrationファイルを編集してしまいましたが、 本来であれば、okuribito_railsを改修すれば良いですよね!

テストも落ちてしまっていることですし、 近いうちに、改修したものを用意してプルリクエストをと思っています。
もちろん、そんなの待てない! って方、
どんどん先に改修してプルリクエストしていただくのも歓迎です!
https://github.com/muramurasan/okuribito_rails
にコントリビュートしてみてください!
よろしくお願いします。

2017.12.25 追記

プルリクエストを出してマージしてもらいました! \(  ̄▽ ̄)/ github.com

おくりびとにコントリビュートするのもいいですが、
PIXTAにコントリビュートしたい人を
Wanted!
recruit.pixta.co.jp