2019年7月の記事一覧

クロスブラウザに対応したE2Eテスト環境の技術選定

ハコベルの中村です。

みなさんのチームではE2Eテストをやってますか?このブログでも紹介した通り、印刷サービスの開発チームでもE2Eの記事が出たばかりですが、ハコベルコネクトの開発チームでも同時期にE2Eテストを構築しました。(事業部も違えば、プロダクトのフェーズも違うので、力をいれたいポイントが異なっていて、読み比べするのも面白いと思いますので是非両方読んでいただけると!)

ハコベルコネクトの関心としては主にこれらの点でした。

  • 物流業界の幅広いお客様に使って頂くために、IE11などのブラウザでも使えるようにチェックする必要があるが、時間がかかってしまう
  • 機能追加・変更の影響範囲チェック漏れでバグが出にくくしたい
  • フロントエンドのテストとしてブラックボックステストをしたい

この課題を軽減するためにE2Eテスト環境の構築をスタートしました。TestCafe + Browserstack という組み合わせを選択しました。今回の記事ではどのような基準で選定したのか、組み合わせて使用する際に必要な設定を紹介してみます。

 

続きを読む

オンラインデザインのPHPからRailsへのリプレイス

こんにちは。サーバサイドエンジニアを担当している新卒のカグラです。

今回はオンラインデザインのRailsへのシステムリプレイスについて紹介します。

オンラインデザインとPHP

ラクスルでは、入稿データを無料でデザインできるサービス「オンラインデザイン」を提供しており、たくさんのお客さんに使ってもらっています。

オンラインデザインは、数年前にPHPで作られたアプリケーションです。そのため当時のレガシーな設計や、今後のスケールを考えた時に複数人でパフォーマンス高く運用するのが難しそうな設計が多くあったため、現在PHPの完全廃止とRailsへのリプレイスを進めています。

スムーズに開発を進めるために

オンラインデザインの多くのプロセスは、ajaxを使った非同期処理で作られており、現在50個ぐらいのAPIがあります。呼び出し元のフロントもjQueryを使った複雑な処理が多い状態でした。
使ってくれているお客さんがいる中で、サーバーサイドとフロントエンドとの複雑な処理を一緒に移行してしまうと、デザインのデータ内容の互換性などで思わぬ障害を招いてしまう危険性が高くなるため、一度に両方を修正するのではなく、まずサーバーサイドのロジック部分をRailsのAPIとして開発し、PHPから呼び出すようなプロセスにしました。

このように進めていますす。

① 元の状態

② PHPのAPIロジックがRailsのAPIに置きかわった状態

③ リプレイス完了状態

今RailsのAPIの開発はほとんど終わりました。開発当初ほぼ一人でPHPの立ち上げを行っていたこともあり、複数人での長期運用には向いていない設計となっていたため、今回開発中に作業コンフリクトなどいくつかの問題が起こりました。例えば、PHPを一部修正して、一般的なRailsのAPI呼び出し処理手順をまとめたAbstractクラスを作ってextendするようにして回避したりしました。
また、万一RailsのAPIレスポンスに問題があった時などに、元のPHPの処理にfallbackすることができるようにもしています。
以下のようになります。

abstract class CallApi  {
    abstract function internalApi($params, $endpoint);
    abstract function checkFallback($response);
}

class DesignService extends CallApi {
    function internalApi($params, $endpoint) {
        ...........
        return checkFallback($response);
    }
 
    function checkFallback($response){
        return $response.error
    }
}


$response = DesignService->internalApi($params);
if $response.error {
   fallBack();
}

function fallBack (){
   //fallbackした処理
    .........
}

 

英語でstand-up meetingは社内で唯一

オンラインデザインチームは国際化が進んでいて、日本人よりもアジア諸国からきたメンバーのほうが多いです。そしてベトナムのチームと一緒に開発しながら、英語でコミュニケーションを取ることを楽しんでいます。自分も外国人として、英語であろうと日本語であろうと母語ではないので、時々難しい感じがするんですが、これまで自信のなかった英語のレベルも時間が経つにつれて上がってきた上に、それぞれの文化に触れて積極的にコミュニケーションを取れることはとても楽しいです。

まとめ

Welcome to join our global team!

Rails Girls Saigon 1st 開催レポート


システムエンジニアの泉田史杏です。
ラクスルは7/20にベトナムホーチミンにて第一回Rails Girls Saigonのスポンサーとして参加しました。

またコンテンツの企画と当日のコーチも務めてきたので、今回はその様子をお伝えします。

ホーチミン初のRails Girls

Rails Girlsは日本含めて世界各国で行われている、女性がプログラミングに親しみ、アイデアを形にするための手助けを目的とするイベントです。ベトナムでは過去にハノイやダナンで行われていますが、ホーチミンでは初の開催となりました。

ラクスルはホーチミンにも開発チームがあるため、今回参加を決めました。

会場はメインオーガナイザーであり、ホーチミンのど真ん中、眺めも非常に素晴らしいTINYpulseさんのオフィス!このブログの写真も提供いただいています、ありがとうございます。

40人弱の参加者に対しコーチは19人。
ベトナム語が話せない、カナダやフランスの参加者も。
でも大丈夫。コンテンツは全て英語で用意しています!
コーディングは、ベトナム語と英語のグループに別れて実施しました。

準備

企画開始は約3ヶ月前(私は2ヶ月前頃から参加)。
Girls達がアプリケーションを楽しいと思える場にしたいという想いと、過去のRails Girlsのフィードバックから、以下二つを特に時間をかけて練りました。

  • ワクワクするアプリケーション
  • 環境構築の時間短縮

ワクワクするアプリケーション

Girls達が、作って楽しい、身近に感じられるウェブサイトってなんだろう?
というところから議論をはじめ、最終的にECサイトに決めました。
これは自分たちでコンテンツを全て準備する必要があるものの、それでもやりたいという多くのコーチの想いの元レビューやリハーサルを重ねながら独自に作っていきました。

仕事終わりにオフィスに集まったリハーサルの風景

開催2週間前のリハーサル。仕事終わりのオフィスにて

環境構築の時間短縮

Windowsにノウハウがあるスタッフがほぼおらず、Railsの開発に集中できなかったということが過去にはあったようです。
そこで今回は思い切って開催日を1日とし、環境はrails serverとrails consoleが、それぞれコマンド一発で立ち上がるDockerを事前にコーチ陣で準備をすることにしました。

結果、一部環境構築できなかったメンバーには、開始前にコーチがセットアップを手伝うことで大きな問題なく、アプリケーション開発に集中しながら進めることができました。

当日コーチ陣によるDockerセットアップサポート

当日コーチ陣によるDockerセットアップサポート

いざ開始!

ワークショップのメインコンテンツは3つ。

  • HTML + CSSを書いてみよう
  • 技術スタックの詰め合わせ”BentoBox”
  • RailsでECサイトの開発

 

HTML + CSSを書いてみよう

まずはWebページ作成の練習!

真っ白のindex.htmlとstyle.cssの二つのファイルから静的なページ作ります。時間は50分。

一緒にコードを見て解説やデバッグしながら、画像サイズが整ったり、バックグラウンドカラーが表示されたり、マウスオーバーで文字の色が変わったりと、だんだんできあがっていくことを楽しみました。

技術スタックの詰め合わせ”Bentobox”

弁当箱のように、技術スタックをフロントエンド、バックエンド、インフラとエリアを分けてカテゴライズしながら、アプリケーションの仕組みを学ぶゲーム。

空の弁当箱に技術スタックを書き込む

空の弁当箱の用紙に技術スタックを書き込んでいきます

私のチームでは、ラクスルの技術スタックを紹介。まず詳細は説明せず、Googleなどで5分で調べてもらいカテゴライズしてもらいました。少し難しいかなという思うものも、必ず誰かは正しくカテゴライズできていました。ラクスルでの具体的な使用例などを交えながら、紹介しました。

この後、ランチを食べていよいよRailsの開発です。

ベトナム料理のオードブル。弁当ではない。

ベトナム料理のオードブル。弁当ではない。

RailsでECサイト開発

いよいよECサイトの開発!3時間の長い時間になります。

解説をしながらも、「erb と html は何が違う?」、「json とは?」、「Gemfileって何?」、「サイトの商品の画像変えたいんだけどどうしたらいい?」など質問は盛り沢山。

独自に自分達で作ったコンテンツだからこそ、「ああ、たしかにこの説明だけだとわかんないよな…」みたいな瞬間もいくつかありました。

ペースはみんな違うのですが、グループメンバー同士でも活発に話し合いながら開発は進みました。最後はHerokuにデプロイをして完了です。

ECサイト完成イメージ

最終完成イメージ

発表〜懇親会

有志で2名から作ったアプリケーションを発表してもらった後、懇親会です。

参加者(左)に記念品を渡すオーガナイザーのNgocさん(右) Cảm ơn nhiều!

参加者(左)に記念品を渡すメインオーガナイザーのNgocさん(右) Cảm ơn nhiều!

様々なバックグラウンドの参加者と触れ合うことができました。例えば、こんな方達。

  • ITを活かせる方法を探している英語の教師
  • フランスからインターンシップと留学で来ていて、スタートアップに興味がある学生
  • 非エンジニアからフルスタックエンジニアを目指してジョブチェンジしようとしている新卒社員
  • カナダからやってきて、ベトナム現地印刷関連会社での営業

また、スポンサーとしてラクスルはサービスの紹介もさせていただき、多くの方に知ってもらうことができました。

不便なことをシステムで解決したいよね、という想いを持っている方は多かったです。

その他GitHubさん、Stack Overflowさんを始め、海外からも多くの会社にサポートしていただけ、素晴らしいイベントとなりました。

ちなみにこのうちわは、ラクスルのノベルティで作成したものでベトナムの開発チームメインで開発したアプリケーションです。

こういった活動も通して、一緒に働く仲間を増やしたり、コミュニティを広げていきたい方、ラクスルで是非一緒に盛り上げていきませんか?

既存プロダクトに最小構成でTypeScriptを導入する

こんにちは。

印刷のラクスルでフロントエンドを担当している菅野です。

現在、稼動中のとあるプロダクトへのTypeScript導入を進めています。今回は、既存プロダクトへの影響を最小限に留めつつTypeScriptを導入する手順をご紹介します。

 

TypeScriptとは

TypeScript – JavaScript that scales.

TypeScriptは、Microsoftが開発したオープンソースのプログラミング言語です。

詳細な説明は省きますが、以下のような特徴があります。

  • JavaScriptの厳密なスーパーセット(≒上位互換)
  • 省略可能な型システム
  • クラスベースのオブジェクト指向

 

TypeScript導入にあたって

今回TypeScriptを導入することで、以下のようなメリットがあります。

  • 型システムの恩恵が得られる
  • エディタの入力補完を受けられる
  • コード=ドキュメントという状況を作りやすい

 

型システムの恩恵が得られる

TypeScriptを導入する最大の理由です。

APIレスポンスの定義をDBに近づけることで、実行時エラーの危険性を大幅に減らすことが出来ます。また、ReduxやVuexで複雑になりがちな状態管理にも型を導入するメリットは大きいです。

コンパイルエラーを無くす=ランタイムエラーを無くすということを最大の目標としています。

 

エディタの入力補完を受けられる

こちらも大きなメリットとなります。

定義した変数はもちろん、Objectのプロパティ等も型込みでエディタの補完を受けられるようになるため、開発効率がアップします。

 

コード=ドキュメントという状況を作りやすい

コメント含め、コードに関するドキュメントは、書くのもメンテナンスをするのも大変です。

TypeScriptで型をしっかり書いていけば、引数の型や戻り値の型に関するドキュメントは必要なくなります。「コードが仕様を体現する」という状況を作りやすくなるわけです。

 

本記事のゴール

  • 既存プロダクトにおいて、TypeScriptで記述できるようにすること
    • .tsファイル及び.vueファイルでの<script lang="ts">を有効にする
  • 既存ロジックには影響をあたえないこと
  • 型検査は出来るようにすること

 

TypeScript導入の下準備

本手順はmizchiさんのGistを参考にさせていただいています。

導入対象プロダクトのフロントエンド構成について

JavaScript周りは以下の構成となっています。

  • Vue.js 2.5.17
  • npm 6.4.1
  • webpack 4.35.2

 

typescript, ts-loaderのinstall

webpackでバンドルするため、typescript本体に加えてts-loaderをinstallします。

npm install typescript ts-loader

 

導入時点でのバージョンは以下の通りです。

  • typescript 3.5.3
  • ts-loader 6.0.4

※ --save-devではない理由としては、フロントエンドモジュールのインストール及び本番ビルドをデプロイサーバー上で行っているためです。

 

webpack.config.jsにts-loaderの設定を追加

const config = {
  ...,
  module: {
    rules: [
      ...,
      {
        test: /\.tsx?$/,
        exclude: /node_modules/,
        use: [
          {
            loader: 'ts-loader',
            options: {
              transpileOnly: true, /* コンパイルのみで型検査を行わない */
              appendTsSuffixTo: [/\.vue$/] /* .vueファイルをTSとして読み込むようにする */
            }
          }
        ]
      },
    ]
  }
}

 

今回のポイントはtranspileOnly: trueです。このオプションを指定することにより、ts-loaderは型検査を行わなくなります

 

tsconfig.jsonの追加

プロジェクトのrootにtsconfig.jsonを追加します。

このファイルはtypescript compiler(tsc)に関する設定を記述するファイルです。

tsconfig.json · TypeScript

Compiler Options · TypeScript

基本構成はVue.js公式ドキュメントを参考にしています。

推奨構成 — Vue.js

{
  "compilerOptions": {
    "target": "es5", 
    "module": "es2015",
    "sourceMap": true,
    "importHelpers": true,
    "esModuleInterop": true,
    "moduleResolution": "node", 
    "allowSyntheticDefaultImports": true,/* import Vue from 'vue';のような形式を有効にする */
    "noImplicitThis": true, /* thisの型推論を有効にする */
    "baseUrl": "./",
    "paths": {
      "@/*": [
        "src/javascripts/*"/* '@/account/register'のようにimportできるようにする */
      ]
    }
  },
  "include": [
    "./src/javascripts/**/*.ts",
    "./src/javascripts/**/*.tsx",
    "./src/javascripts/**/*.vue"
  ],
  "exclude": [
    "node_modules"
  ]
}

この段階では "strict": trueにはせず、"noImplicitThis": trueのみに留めています。導入段階から厳しいルールを設定してしまうと、既存コードの移行が厳しくなってしまうという理由です。

 

型検査用のscriptを定義する

前述したように、ts-loaderでは型検査を行わないため、package.jsonに手動型検査用のscriptを定義します。

{
  ...,
  "scripts": {
    ...,
    "type-check": "npx tsc -p . --noEmit",
  }
}

npxでtypescript compilerを呼び出して型検査を行います。この際、--noEmitオプションを付与することで、ファイルのoutputを行わずに型検査のみを実行しています。

試しに既存の.jsファイルを.tsに書き換えて型検査を実行してみます。

 $ npm run type-check

> project@ type-check /path/to/project/frontend
> npx tsc -p . --noEmit

src/javascripts/account/register.ts:23:13 - error TS2339: Property 'name' does not exist on type 'unknown'.

23     if (elm.name == 'authenticity_token') {
               ~~~~

...


Found 39 errors.

上記のように、コンパイルエラーを検査することが出来ます。

前述したように、ts-loaderでは型検査を行っていませんので、この状態でもビルドは成功します

 

sfc.d.tsを作成する

Visual Studio Code等のエディター・IDEで .vueファイルのimportを解決するために、プロジェクト内に以下のようなファイルを追加します。(sfcはSingle File Componentの略です)

declare module '*.vue' {
  import Vue from 'vue'
  export default Vue
}

 

以上の修正は既にmasterブランチへマージされており、無事TypeScriptで開発できるようになりました。

既存ロジックの変更は行っていないため、障害等も特にありませんでした。

 

まとめ

いかがでしたでしょうか。

0→1でTypeScriptを導入することは簡単ですが、既存プロダクトに途中からTypeScriptを導入するのは心理的ハードルが高いように思えます。

本記事が、「稼動中のプロダクトにTypeScriptを導入したいけど、障害怖いしキツそうだなぁ…」といった方々の助けになれれば幸いです。

ラクスルでは、Vue.jsで新たなUIスタンダードを創るフロントエンドエンジニアを募集しています。

 

参考資料

エンドツーエンドテスト(E2Eテスト)をTestCafeとAWS CodeBuildでもっともっと手軽にする

ラクスルの@nnm_techです。

ラクスルの印刷サービスではこれまでにもE2Eテストがありましたが、この度より良いシステムを目指し再構築することになりました。 本記事ではTestCafeとAWS CodeBuildを用いたE2Eテスト刷新について紹介したいと思います。

ラクスルで運用している印刷サービスは裏側で複数のサービスが協調動作しています。 入稿サービス、発注サービス、決済サービス…外部サービスとの連携も含めるとかなりの数があります。
このような中、弊社では各サービスの変更時におけるユースケースの動作担保・リグレッション検知を目的にE2Eテストを実施しています。

続きを読む