Wiz テックブログ

Wizは、最新のIoTやICTサービスをお客様に届ける「ITの総合商社」です。

【エンジニア社内LT会】第5回

第5回LT会レポ

今回のLT会の内容は

発表者: 3名

制限時間: 自由

テーマ: 自由

コメントツール:CommentScreen

で行いました。

それでは1つずつ発表を紹介していきます。

ブランディング戦略まとめ

1人目の方には「ブランディング戦略まとめ」という内容を発表していただきました!
現在Wizエンジニアとしてのブランディング施策として主に行なっていること。

・テックブログ運用

・LT会運用

Twitterアカウント運用

今後もブランディングに注力し、Wizの認知度、採用力を高めていきたいですね!

Consumer Driven Contractについて考える

2人目の方には「Consumer Driven Contractについて考える」について発表していただきました!
メリットとしては

・フロントエンドエンジニアが欲しいカタチでAPIを貰える

・バックエンドエンジニアはビジネスロジック側の実装に集中できるようになる

APIドキュメントが簡単に作成できる

という内容でした。

「成功循環モデル」と「組織づくり」

3人目の方には「成功循環モデル」と「組織づくり」について発表していただきました!

「関係の質、思考の質、行動の質、結果の質」の循環サイクルをうまく回し、

組織としてより成果を上げていくという内容でした。

今までのLT会はこちら~

tech.012grp.co.jp

最後に~

第5回はこのような内容でした。

LT会の内容をもっと社外へ公開できるよう目指していきたいです。

また、

Wizではエンジニアを募集中です。

興味のある方は是非覗いてみてください!↓

careers.012grp.co.jp

コーディングで天下を目指せ! − 社内チームでの取り組み −

f:id:rainymoment0616:20210607113445j:plain

こんにちは、フロントエンドの柳田です。

コロナ禍で完全リモートワークになっている中、LT会や勉強会など、Tech事業部全体で業務以外での取り組みが増えてきました。

それと同じように、事業部内の各チームでも様々な取り組みが増えてきています。

フロントエンドチームは、5月時点で4つのチーム(1チーム辺り2〜4人)で構成されていて、各チームで色々な取り組みが行われています。

今回は、私のチームでスタートしている新企画について、お話させていただこうと思います。

新卒研修のフィードバックから生まれた新企画

私のチームでは、今年度から新卒が1名配属されており、チーム全体で新人向けの技術研修を行っています。

コーディングを学んでもらうには、他人のコードにたくさん触れ、かつ自分で色んなコードをたくさん書いてもらう機会を増やしたほうがいいと考えていたのですが、その中で「先輩たちがコーディングしている様子を見せるのはどうだろう?」という話があがりました。

見せる方法は様々な方法がありますが、せっかくならみんなで楽しくコーディングの勉強がしたいという気持ちもありました。

一人が何かの課題をコーディングして、それを見ながら他のメンバーでガヤガヤ話をするのも楽しいかも…もしくは制限時間を設けてみんなで一斉にやってというのも面白いのでは…?

などとチーム内で話が盛り上がり、天下一コーディング武道会という名のリアルタイムコーディング大会が爆誕しました(名前は某アニメから拝借して、メンバーの一人が命名してくれました)。

概要

現在は、下記のような形で進めています。

  1. 軽めの課題をコーディング(15〜20分)
  2. 各メンバーのコードを見ながらディスカッション(15〜20分)

コーディングに時間を要してしまうと、メンバーが業務以外の作業に集中してしまうことになるため、課題のボリュームは、1つのコンポーネント程度に収めています(ボタンやヘッダー、フッターなど)。

時間内でコーディングを進めた後(完成していなくても、時間になったら作業はストップ)、全員のコードを見ながら、

  • どういう手順で進めていったのか
  • 他メンバーと自分の書いたコードで違うところがあった場合、どういうことを考えてコーディングを進めたのか

など、みんなでディスカッションしています。

開催の様子

コーディング課題の内容をみんなで確認している様子です。
第1回目の様子(コーディング課題の確認中)

記念すべき第1回目は、メンバーの一人が課題を作成してくれて、それを元にコーディングを進めました。

作業中は、マイクをオフにせず「え?ねぇこれ終わる?」「えーここどうやって作ろう…」など、ガヤガヤと話しながら、楽しく(半ば焦りながら)進めていました。

想像以上にボリュームが多く、全員コーディングを完了させることはできなかったのですが、作業途中の状況をみんなで見せ合いながら、実際やってみてどうだったか、どのようにコーディングを進めていったのかをざっくばらんにディスカッションしました。

コードレビューで完成したコードを見ることはありますが、作業途中のコードを見る機会はほぼなかったので、メンバーのコーディング手順や考え方を垣間見ることができました。

参加したメンバーの感想

  • こんなに短時間で本気出してコーディングしたのは初めてかもしれない
  • マイクオフにする余裕がないくらい焦った
  • 頭が真っ白になった…けど楽しかった!
  • 20分でできる量は限られているが、その中で「効率よく進めるにはどうすべき?」ということを考えながら進めることができた
  • 普段、完成したコードは見ても、作業途中のコードを見ることはほとんどないから、みんながどういう風にコードを書き進めていっているのかを見ることができて勉強になった

最後に

チーム内で企画してスタートした、天下一コーディング武道会。

私自身、なかなかコーディングを行う機会が減ってきていたので、こういう時間を設けて手を動かすことができたことは良い機会でした。

また、「メンバーと一緒に同じものをコーディングして、それに対してディスカッションする」ということが、純粋に楽しく有意義な時間でした。

そして何より、新卒を含めたチームのメンバーが、この企画を楽しんでくれたかつ、少しでも勉強になったと感じてくれたことを嬉しく思います。

まだ、この企画は始まったばかりなので、より有意義なものとなるように、チームでブラッシュアップしていきます。

こんな楽しい企画を行っているチームと一緒に働きませんか?

Wizではエンジニアを募集しています。興味のある方、ぜひご覧ください。

careers.012grp.co.jp

アプリ開発で使う通信の仕組み〜階層型プロトコル・TCP/IP〜【初心者向け】

こんにちは、先月新卒で入社したバックエンドエンジニアの三井です。

技術研修の中でWeb周りの技術を勉強する機会があり、その中でも「階層化されたネットワークの仕組み」についてさらに詳しく調べてみましたのでこの記事で簡単にまとめていきたいと思います。

Webアプリにおける通信の流れ


Webアプリケーションはその名の通りインターネットを経由して動かすことのできるアプリケーションです。
特に「動的なWebサイト」(見る人によって表示される内容が違うサイト) のことを指します。
多くの方はブラウザ(ChromeSafari等)からURLにアクセスして閲覧すると思いますが、大まかな仕組みとして
我々の使用する「デバイス(クライアント)」とデータやサービスシステムを管理する「サーバー」でHTTPという通信ルール(プロトコル)でやりとりをしています。

話をまとめると
WebアプリはHTTPというルールで データのやり取りをして、
ユーザの欲しい情報を表示している

ということになります。

TCP/IPとは


HTTPがWebアプリの通信規則ということが分かったところでこのルールの大元になっているTCP/IPというルールについてまとめていきたいと思います。

ネットワーク同士をつなげるにはみんなが同じ通信方法にすれば良いという考えで統一されたルールで、1974年に提案されARPANETに採用されたものです。
これがのちのインターネットとして確立しました。このルールのおかげでPC、スマホ等のデバイスに関わらずインターネットに接続できます。
TCP/IPがここまで大きく標準化した理由にもなる特徴的な考え方に「階層化」というものがあります。これはプロトコルを以下の4つの層に分けて、それぞれに通信方式が決まっています。

  • アプリケーション層
  • トランスポート層
  • インターネット層
  • ネットワークインタフェース層

この順番で上に行くほど上層(サービスに近い)、下にいくほど下層(インフラに近い)と呼ばれます。 HTTP通信はアプリケーション層での通信方式の一つです。

階層モデルのメリット


階層化をしてプロトコルを管理するメリットとして以下の二つが挙げられます。

* 開発が楽になる(機器に合わせたり、OSに合わせる必要がない!)
* 機能が一目でわかる(これはインフラレベルなのかアプリレベルなのか)

例えばアプリケーション層とトランスポート層に分けられる
メール、ファイルの送受信、Webの通信等のサービスの開発において、
その層以下のインターネット層やネットワークインタフェース層の通信を
意識する必要がないということです。

インターネット層以下のルールでOSや通信機器がインターネットに接続しているため、
その層以上で何かものを作る(サービスを作る)際はwebブラウザやデバイスごとに
通信方法を意識する必要はない、ということです!

まとめ


  • 現在のインターネットはTCP/IPという通信方式である
  • 大まかにサービスとインフラで通信方式を層にして分けている
  • 階層化のメリットは開発する層より下層のことは考慮せず開発できる

参考文献


「Webを支える技術」

最後に


最後までお読みいただきありがとうございました。

Wizではエンジニアとして一緒に働く仲間を絶賛募集しております。

ご興味のある方、是非ご覧下さい..!!

careers.012grp.co.jp

TestCafe v1.14.0がリリースされました

こんにちは、フロントエンドエンジニアの菅野です。

4月7日にリリースされたv.1.14.0で待望の機能が追加されました!

今回はリリースノートをもとにアップデート内容とそれに伴いTestCafeを実装しているプロジェクトのリファクタリングを行なったので、ご紹介したいと思います。

E2Eの取り組みについて書いた記事もありますので興味がありましたらそちらもぜひ。

アップデート内容

スクロールアクションの機能強化

以前のバージョンでは、ページスクロールをするためにClientFunctionを使い、画面外のDOM要素を操作する必要があったのですが、 今回のリリースで専用のスクロールアクションが導入され簡単にスクロールできるようになりました。

以前までのスクロール処理

export const scrollBottom = ClientFunction(function() {
  const elementHtml = document.documentElement
  const bottom = elementHtml.scrollHeight - elementHtml.clientHeight
  window.scroll(0, bottom)
})

ちょっとめんどくさい感じで処理を書いていました・・・

便利なメソッドがたくさんある中で「なんでスクロールはないんだろう?」と不思議に思っていたので個人的に嬉しい機能追加です!

追加されたスクロールアクションは3つ

t.scroll :要素を指定された位置にスクロールします

t.scrollBy :指定されたピクセル数だけ要素をスクロールします

t.scrollIntoView :要素をスクロールして表示します

今回は、t.scrollアクションを使い、リファクタリングを行いました。

リファクタリング後のスクロール処理

const container = Selector("footer")
await t.scroll(container, 'bottom')

これだけです!

要素内のスクロールできる高さから要素の高さを引いて(ゴニョゴニョ...)しなくても良くなり、直感的な見やすいコードになりました!

その他のt.scrollByt.scrollIntoViewの使い方はこのようになっています。

t.scrollBy

設定されたピクセル数だけターゲットをスクロールします。 例ではWebページを上に200px、右に500pxスクロールさせた場合です。

fixture`Scroll Action`
  .page('http://example.com')
test('Scroll the webpage', async t => {
  await t
    .scrollBy(500, -200)
})

t.scrollIntoView

要素をスクロールして表示します。 (使いどころがピンと来てないのですが、スクロールアニメーションがある要素に使うと良いのでしょうか?)

fixture `Scroll Actions`
  .page `http://www.example.com/`
test('Scroll element into view', async t => {
  const target = Selector('#target')
  await t
    .scrollIntoView(target)
})

おまけ

サイトもいつの間にかリニューアルされていました!

リニューアル前 リニューアル前

リニューアル後  リニューアル後

最後に

Wizではエンジニアとして一緒に働く仲間を絶賛募集しております。

ご興味のある方、是非ご覧下さい..!!

careers.012grp.co.jp

Next.jsでのDynamic Importの使い所

こんにちは、フロントエンドエンジニアの髙橋です。

最近社内でNextを採用したプロジェクトが増えつつあるなか、色々な機能に驚き、助けられている日々を過ごしております。 そんな中、今回はDynamic Importの使い所について考えてみたいと思います。

そもそもDynamic Importって??

その名の通り動的なインポートのことです! ES2020の新機能で、Nextでもサポートされています。

書き方としては、Nextが提供しているnext/dynamicからimportして下記のように使用します。

import dynamic from 'next/dynamic'

// 静的なインポート
// import StaticComponent from '../components/hello'

// 動的なインポート
const DynamicComponent = dynamic(() => import('../components/hello'))

function Home() {
  return (
    <div>
      <Header />
      <DynamicComponent />
      <p>HOME PAGE is here!</p>
    </div>
  )
}

export default Home

nextjs.org

どうやって使用する??

そんなDynamic Importですが、さまざまな使い方があると思います。

今回は私がよく使う2つの用途を書いていきます!

パフォーマンス改善に使用する

一つ目の用途はパフォーマンス改善です。

例えば、このようなユーザーの操作によって切り替わる要素があるとします。

 

静的インポートの場合

こちらを静的にImportするとこのように書けば表現できます。

import { useState } from 'react';
import List from '../components/List'
import ListSecondary from '../components/ListSecondary'

const IndexPage = () => {
  const [toggle, setToggle] = useState(true);
  return (
    <Layout title="Home | Next.js + TypeScript Example">
      <h1>Hello Next.js 👋</h1>
      <button onClick={() => setToggle(!toggle)}>
        Toggle Component
      </button>
      {toggle ?  <List /> : <ListSecondary />}
    </Layout>
  )
}

export default IndexPage

listlistSecondaryToggle Componentを押すことで切り替えるようにしています。

早速Light houseのスコアを見てみましょう。

シンプルなページなのに少しパフォーマンスが悪いですね… 原因はListSecondaryは初期画面に表示されないのにロード時に読み込んでしまっているためです。 (わかりやすくするためにListSecondaryはめっちゃ大きくしています…笑) ではこちらを動的にインポートすればどうなるでしょうか。

動的インポート(Dynamic Importの場合)

Dynamic Importの場合、以下のように書きます

const List = dynamic(() => import( '../components/List'))
const ListSecondary = dynamic(() => import( '../components/ListSecondary'), { loading: () => <p>loading...</p> })

const AboutPage = () => {
  const [toggle, setToggle] = useState(true);
  return (
    <Layout title="Home | Next.js + TypeScript Example">
      <h1>Hello Next.js 👋</h1>
      <button onClick={() => setToggle(!toggle)}>
        Toggle Component
      </button>
      {toggle ?  <List /> : <ListSecondary />}
    </Layout>
  )
}

挙動を確認してみましょう。

Listは最初から表示されているのに対して、ListSecondaryは最初に切り替わるとき、少しラグがあります。 (一瞬なのでかなり見えづらいですが…) これはToggle Componentを押したときにImportしているため、このような挙動になります。

ではこちらのスコアはどうでしょうか。 f:id:sotq17:20210519170107p:plain

少しスコア上がったことが確認できました!

静的にインポートしたときに比べ、Dynamic Importは初期ロード時に読み込む量を減らすことができるため、サイトスピードの向上に使用することができます。

Dynamic Importを使用することで、比較的簡単にパフォーマンスチューニングすることができます。 初期表示の際に不必要なComponentが多い場合はDynamic Importを検討してみてはいかがでしょうか。  

SSR回避に使用する

もう一つ私がよく使用する用途は、SSR回避の用途です。

Nextを使っているとこんなエラーが出てくる時はないでしょうか?? ReferenceError: alert is not defined

私は気を抜いているとよくこのように怒られてしまいます。。 NextはSSR前提で動いているので、こういったブラウザの機能を使おうとするとエラーが出てしまいます。

ちなみにこういった書き方だと、上記のようなエラーとなります

import React from 'react'

import Alert  from '../../components/Alert'
const AlertPage = () => {
  return (
    <Alert/>
  )
}
export default AlertPage


*Alertはalertの機能を持つReact Componentです。

こういうときにもDynamic Importが役に立ちます!

先程のDynamic Importの書き方に{ssr: false}というオプションを渡してあげるだけで、「このファイルはSSRしない」とNextが判断するので、エラー回避することができます。

先程のソースを変更すると、以下のようになります。

import React from 'react'
import dynamic from 'next/dynamic';

const Alert = dynamic(() => import( '../../components/Alert'),{ssr:false})
const AlertPage = () => {
  return (
    <Alert/>
  )
}
export default AlertPage

これでエラーがなくなるはずです!

参考までにソースが上がったGithubも載せておきます。

github.com

まとめ

今回はNextのDynamic Importの使い方についてご紹介しました。 今回ご紹介した用途は一部の使い方で、もっといろんなことができると思います。 こんな風に使えるよ!ってご意見あれば是非ご教示いただきたいです…!

最後までお読み頂きありがとうございました!

最後に


Wizではエンジニアとして一緒に働く仲間を絶賛募集しております。

ご興味のある方、是非ご覧下さい..!!

careers.012grp.co.jp

REST APIとは?ざっくりと理解してみる【初心者向け】

image.png

こんにちは、バックエンドチームの中嶋です。

まだ入社して2ヶ月ほどですが、先日にWeb技術の勉強会の機会を頂き「REST API」についてLTを行ったので、簡単に内容をまとめていきたいと思います。

 

あくまで基本的な概念をざっくりと理解する、初学者向けの内容です!

それでは順番にみていきましょう〜。

まずはRESTを知る

REST APIの前にそもそも「REST」とは何かというと、「シンプルなWebシステムの設計思想」のことです。


これは「REpresentational State Transfer」
(リプレゼンテーショナル・ステイト・トランスファー

の略で、

  • Representational →具象化された
  • State →状態の
  • Transfer →転送

つまり、ざっくりと理解すると

「具体的に状態を定義した情報のやり取り」

のような意味合いになります。

これについて「RESTの4原則」というものがあり、これを満たすものを「RESTfulなシステム」と呼んだりします。

RESTの4原則とは?

このRESTの4原則は、
HTTPを設計した中心人物であるRoy Fielding氏が2000年に提唱したもので、
 ①統一インターフェース
 ②アドレス可能性
 ③接続性
 ④ステートレス性

 の4つです。

 

順番に見ていきましょう。

①統一インターフェース

統一インターフェースは、あらかじめ定義・共有された方法でやり取りされることです。
Webの場合、例えば「GET・POST・PUT・DELETE等のHTTPメソッドでやりとりするよ~」とか「やり取りするデータはJSON形式にしようね〜」といったものになります。
データの形式にはXML等もありますが、近年は軽量なJSON形式が使われることが多いです。
image.png

②アドレス可能性

アドレス可能性は、全ての情報が一意なURI(識別子)を持っていて、提供する情報をURIで表現できることです。
このURIUniformed Resource Identifierの略で、Webの場合は通常URLで与えられます。
image.png

③接続性

接続性は、やりとりされる情報にはハイパーリンクを含めることができる、というものです。
1つのリンクから別の情報にリンク(接続)することができて、RESTfulなシステム同士なら円滑に情報連携を行うことができます。

image.pngimage.pngimage.png

④ステートレス性

ステートとは「状態」のことでしたね。これがレスなので「状態がない」ということになります。
つまり、RESTでは「やりとりが1回ごとに完結する」と理解することができます。

 

これは、前のやり取りの結果に影響を受けないのでシンプルな設計にできるというメリットがあります。(セッション管理が不要など)

 

WebにおけるRESTの4原則を図にすると..

あくまでひとつの例ではありますが、こんな感じでイメージできると思います。

image.png
 ①HTTP通信で,JSON形式でやりとりするよ →統一インターフェース
 ②このURLの情報くださーい →アドレス可能性
 ハイパーリンクを含んだページをあげるよ →接続性
 ④さっきの情報をくださいと言われても〜 →ステートレス性

じゃあ本題のREST APIとは??

「REST」についてざっくりと理解したところで、本題のREST APIについて見ていきま しょう。

まずAPIとはApplication Programing Interfaceの略で、ざっくりと、「プログラムの情報をやり取りする蛇口のようなもの」と理解することができます。
image.png

そして「REST API」とは先ほどのRESTの4原則に則ったAPIのことです。

 

ちなみに..
RESTful APIREST APIは呼び方の違いで意味はほぼ同じ。
またWeb分野では単にWeb APIと呼ぶこともある。

外部APIを使うイメージ

例えばのイメージですが、天気予報サイトの外部APIを使う場合の図です。
image.png
・中央のポータルサイトが例えばYahoo!のようなサイトで、ユーザーは住んでいる地域を登録しています。
・この地域情報を天気予報のAPIサーバーに渡して、その地域の天気の情報を検索して返します。
スマホアプリなども登録情報から同様に活用されます。

 

ざっくりと、こんな感じのイメージです。

ちなみにREST以外には..?

REST以外のものとしては、2000年代初頭までは標準化として「XML-RPC」や「SOAP」というものが使われていました。
しかし形式をXMLに限定していたり仕様が複雑だったりで、あまり広く普及するには至らなかったという背景があり、現在ではSOAPに代わり今回紹介したRESTが中心になっています。

 

なお「REST」は標準化ではなくあくまで設計思想なので、この点は留意しておきたいところです。

今回のまとめ

・RESTは「RESTの4原則に沿ったシンプルな設計思想」のことで、
  ①統一インターフェース
  ②アドレス可能性
  ③接続性
  ④ステートレス性
 の4つ。
・これらに沿ったシステムを「RESTfulなシステム」という。
・「REST API」と「RESTful API」は、呼び方の違いだけと思って良い。
・「REST」はRPCやSOAPと違って「標準化」ではないが、現代の主流の設計思想である。

 参考文献

イラスト図解式 この一冊で全部わかるWeb技術の基本

以上、最後までお読み頂きありがとうございました〜!

 

Wizではエンジニアとして一緒に働く仲間を絶賛募集しております。

ご興味のある方、是非ご覧下さい..!!

https://careers.012grp.co.jp/engineer

MySQLで行うパフォーマンスチューニング

こんにちは。バックエンドエンジニアの米山です。

私個人はJava+Oracleでお仕事をする期間が長かったのですが、昔はよくOracle側のパフォーマンスチューニングを行っていました。
弊社では、まだ採用ケースは少ないのですがDBにMySQLを採用し、経年によるデータ増加に対応する場合にどうするべきか?を考えてみようと思います。

準備


まずデータ増加した(ということにする)DBを用意します。
本当は100万件・・・と言いたいところですが、時間がかかりそうなので10万件程度にしておきます。

以下のような構成で作成しました。

  • MySQLのバージョンは8(8.0.22)
  • テーブルを3つ用意する(samples,cities,join_data)
  • samplesにデータを10万件insertしておく(カラム数や中のデータは適当に散らばせる)
  • samplesにINDEXを作成(SAMPLES_IDX_01、SAMPLES_IDX_02)

今回は、データはLaravelのSeederを使って作成しました。

チューニングしてみる


準備ができたら、実行計画を取ります。
MySQLで実行計画を取る場合は「EXPLAIN」句を使います。
f:id:t-yone3:20210514180331p:plain

データ量が大したことないのですぐ返却されましたが(笑)テーブルのJOINはB(cities)->A(samples)->C(join_data)の順に結合されていること、Cへの結合はHASH JOINで行われていることなどがわかります。
INDEXもほど良く使われていますね。

Oracleではお馴染みのオプティマイザヒントですが、MySQLでも使えるようです。
試しにJOINの順番を変えてみましょう。
JOIN順番を指示するには「JOIN_ORDER」ヒントを指定します。 f:id:t-yone3:20210514180509p:plain

実行計画が変わったことが確認できました。

実務でよくあるのがINDEXヒントの導入です。
ビッグデータ且つデータの分布率が思わしくなく、INDEXを作成したのに有効に効かない時にクエリで指定してあげる、というケースが多いです。

MySQLでのINDEXヒントはOracleとは違い、FROM句の中で行います。 f:id:t-yone3:20210514180905p:plain

どうでしょうか?実行計画が変わったのがわかりますか?
USE INDEX(SAMPLES_IDX_02)を指定することで、意図的にそちらのINDEXを使用するようになりました。
但し、INDEXヒントはデータの状況や選択したINDEXによっては、逆にパフォーマンスを悪化させることもありますのでINDEXの選定と併せて、使用はご注意下さい。

最後にSQL実行時間の測定です。
実行計画を見ながら、実際にSQLが早くなったのかを確認していきます。
mysqlコマンドに-vvvオプションをつけて実行します。
f:id:t-yone3:20210514181035p:plain

今回紹介した、JOIN_ORDERとUSE INDEXを両方適用してSELECT文を実行しました。
本当に僅かですが実行時間が変わったことと思います。

プログラムコードを弄るほどではないけど、画面表示のパフォーマンスを改善したい!という時には効果的です。

最後に


Wizではエンジニアを募集しております。

興味のある方、ぜひご覧下さい。

careers.012grp.co.jp