vivit 開発部はナレッジ・ドキュメントが豊富

はじめに

こんにちは!開発部マネージャーをしている井島です。
開発部では以下で紹介されているように、強みとして「ナレッジ・ドキュメントが豊富」も挙げられています。

vivit.hatenablog.com

今回は、実際にどんなドキュメントがあるか少し紹介していきたいと思います。

vivitはドキュメントのツールとしてDocBaseを主に使っており、必要に応じてGoogleのドキュメント、スプレッドシート、スライドも使っています。

開発部 全般的な資料

各画像はDocBaseの画面になります。

f:id:ijimakenta:20220116003431p:plain

開発部全体、各プロダクト開発チーム毎の振り返り資料で、主にKPT(Keep, Problem, Try) の内容になります。
「エンジニアランチ委員会」は、開発部内でコミュニケーションを活発化させる動きがあり、その資料になります。

f:id:ijimakenta:20220116003504p:plain

ここから各チームやプロダクトの資料ページに飛べるようになっています。
設計書などもこの先から飛べるようになっています。

f:id:ijimakenta:20220116003725p:plain

開発部ではクウォーター毎にキックオフMTGを行っています。
会社、各事業の情報共有や今後の方針、開発部レベルでのKPT実施など行っています。

f:id:ijimakenta:20220116003740p:plain

コードレビューについてのナレッジ、ルールを記載しています。
各チームでコードレビューのやり方があるのですが、チーム内だけのナレッジで留めず、全体に共有していけたらと思っています。

f:id:ijimakenta:20220116003756p:plain

遅刻、休み、リモートするときなどの方法のまとめになります。

f:id:ijimakenta:20220116003837p:plain

開発部では障害に対して、ポストモーテムを作成しています。
2020年からポストモーテムを書く活動を初めて、現時点では29件まで増えました。毎回きちんと根本対応まで行っており、それが功を奏しているのか、同じ問題は発生していません!

また、ナレッジを収集する活動もあります。
Slack にスタンプすると、特定チャンネルに投稿されるようになっています。まだ日々の開発で発見したナレッジを体系的にまとめる仕組みは整えられて居ませんが、収集だけは行っています。 2022年1月からは、溜まってきたナレッジを共有していく会を開催していく予定です!

f:id:ijimakenta:20220116003855p:plain

開発部内で行った勉強会、輪読会の資料になります。皆さんの満足度が高かったものは以下でした!

おわりに

vivit 開発部は決して分からないことは自分で調べろ という文化ではありません!!
常に情報共有し、メンバーが相互に助け合っている組織です。vivit のValue 「Give and Give」です!

最後に、vivit では一緒に働いてくれる仲間を募集中です。
気になったことがあれば、是非、お気軽に話を聞きに来てください!

【新卒】
www.wantedly.com

【中途】
www.wantedly.com www.wantedly.com

【2022年1月】最近のvivit開発部の特徴は?

はじめに

こんにちは、技術開発部 事業横断チーム ひよっこデータエンジニアの多田です。

前回の記事を書いてから一月ほどでしょうか。
前回は自称データエンジニアでしたが、今はひよっこデータエンジニアをしています。 vivit.hatenablog.com

最近分かったのですが、弊社の選考に進まれる方は結構このブログを見てくれるようです。
そのため、今後vivitに興味を持ってくれたエンジニアの方々に少しでもvivit開発部の特徴・雰囲気が伝わればいいなと思い、定量にそれを解説してみます。

ということで、以下の項目を部内でアンケートを取ってみました。
せっかくなので業務委託の方にもご回答頂いてます。
回答率は90%ほどです。
(ご回答いただいた皆様、ご協力ありがとうございます 🙇‍♂️)

vivit開発部の特徴

スキルマップ

下記を基準にvivitで使われているスキル(言語・FW・ミドルウェア・各種ツール)の習熟度を皆さんにスコアリングしてもらいました。

3:得意
2:業務上こまらない
1:部分的に理解している
0:無

ベテランの人ほどあまり3: 得意をつける事がなく、この画像を思い出しました…(参考)

f:id:tadavivit:20220113195546p:plain
チョットデキル????

それはさておき、スキルの数が80を超えてしまったため、ワードクラウドで可視化してみました。
文字が大きいほど、そのスキルを得意としてる人が多いという事です。

f:id:tadavivit:20220113192716p:plain
スキルマップのワードクラウド

製品はWebサービスが主ですからね、やはりhtmlとREST APIを扱える人は多いですね〜
また、gitの文字が大きいのはチーム開発に慣れている人が多い証拠でしょう。
フロントエンドはReactとNext.jsのどちらかなのでTypeScriptも大きいですね。
ちなみに、バックエンドにはRailsかGoが使われているのですが、あまり目立ってはいないですね…
Goを使った製品が多いので、Goエンジニアの方、是非うちへ!すぐ活躍できます!是非!!!

エンジニア歴何年?

次にエンジニア歴を聞いてみました。

f:id:tadavivit:20220113193017p:plain
エンジニア歴何年?

若手が半分、中堅・ベテランがもう半分ですね🤔
結構良いバランスなんじゃないでしょうか?
同じぐらいの年数が一定数いるのでお互い切磋琢磨も出来るし、ベテランと若手のペアプロも多々出来る環境、という感じ。
ちなみに私は4年目なので、中堅・ベテランの方々にはいつも支えてもらっております。ありがとうございます🙇‍♂️

vivitに入社した理由は?

お次は入社理由。
一つに絞り込むのが難しいと思ったので、複数回答ありで募集してみました。

f:id:tadavivit:20220114125327p:plain
vivitに入社した理由は?(複数回答可)

やはり仕事内容のマッチングが一番多いですね。
「Goを書きたかった」とか「Reactを仕事でやってみたかった」とかよく聞きますし。

あと、ウチは正社員・業務委託関わらずビジネスサイドとの折衝が多いので、事業内容が多いのも納得です😊

そしてそして!
社員の人柄や雰囲気を気に入った方が多くて嬉しいですね!
これは開発部だけでなく、会社全体の人柄・雰囲気が良くて、という話かと。
確かに優しくて、色々教えるのが好きな人が多い印象です。

ちなみに私は福利厚生にも投票してます。
キャンプ大好きマンなので、キャンプ場・用品手当はめちゃくちゃ魅力的でした。
今も月イチの頻度で使わせて頂いております。

vivit開発部の強みは?

vivitに興味を持ってくれた方の選考材料にもなりますし、私達自身が強みを自覚しより発展させるためにも、vivit開発部の「強み」を募集してみました。

複数回答可で聞いてみた

自由回答だとバラつきが出ると思ったので、私と開発部部長で思いつく限りの選択肢を並べ、皆さんにはそこから選択してもらいました。
入社理由と同じく、一旦複数回答で聞いてみた結果…

f:id:tadavivit:20220114125402p:plain
vivit開発部の強みは?(複数回答可)

突出してるのは

  • 新規分野・技術の取り込みが活発
  • 開発環境・インフラ環境が整っている
  • 心理的安全性が高い

の3つですね。

新規分野・技術の取り込みが活発

まず1つ思いつくのが、私自身の事です。
社内にデータ分析・エンジニアリングの人材・知見がない(私自身もない)状態から、データエンジニアになったのが私です。
「コレやってみましょう/やってみたいです!」の声が通りやすい環境故に実現した事だと思っています。

他にも、マイクロサービスを構築する事が多くなったタイミングで、「↓の輪読会をしてみよう!」という声が上がり、部員の半数近くが参加し完走した事もあります。
これの凄い事は、やってみましょう!と声を挙げて下さったのが業務委託の方だった事です。
業務委託・正社員関わらず技術的関心と改善欲が高い証拠だと思います。

www.oreilly.co.jp

開発環境・インフラ環境が整っている

これに関しては、ウチのSREチームが優秀である証明ですね😊
確かに、DevOps、GitOpsで困った事がないだけでなく、日々より良くなってる印象です。
詳しくは下記2記事をお読み下さい!

vivit.hatenablog.com

vivit.hatenablog.com

心理的安全性が高い

括弧書きに書いたように、風通りが良い、発言がしやすい、ノビノビ開発できる、等の意味です。
この項目が高かった要因として、vivit開発部の下記9つのValueを部員それぞれが無意識で体現しているからだと思っています。

  1. 自分が使いたくなるサービスを作ろう
  2. KPIをチーム全員で追おう
  3. 仮説を持ち、検証できる施策を最速で打ち続けよう
  4. バグや不具合の責任はチームで負おう
  5. 事実を客観的に捉えてコトについて議論をしよう
  6. 知らないことは知らないと言おう
  7. Yes, howと言おう
  8. 意思決定のプロセスをオープンにしよう
  9. 越境しよう

全て紹介したいのですが、それはまた別の記事で…
この中で私が最も好きなValueを一つ

f:id:tadavivit:20220114155828p:plain
バグや不具合の責任はチームで負おう

9つのValueは、毎日ランダムで1つ上記スライドと共にSlackに投稿されています。

他、思い当たる節としては、1on1やメンタリング、チームビルディングに力を入れている事でしょうか。
これに関しては下記記事をご覧ください。

vivit.hatenablog.com

一番の強みは?

上記複数回答だと一番の強みが分からなかったので、唯一回答でも募集してみました。

f:id:tadavivit:20220113192952p:plain
vivit開発部の1番の強みは?

結果、「心理的安全性が高い」が1位でした!!
ギスギスした人間関係にウンザリしてるそこのあなた、、、是非vivit開発部へ

どこに住んでる?

ここからは番外編です。
開発部の正社員は基本的に水金出社、月火木リモートなので、個人的にどこに住んでる人が多いのか気になった次第です。

f:id:tadavivit:20220113192918p:plain
どこに住んでる?

まあ、目黒にオフィスがありますからね。東京都内に住んでる方が多いです。

キャンプにはよく行く?

キャンプに関する事業を開発・運用・保守してる我々ですからね、キャンプ好きがどれくらいいるか気になったので聞いてみました!

f:id:tadavivit:20220113192941p:plain
キャンプにはよく行く?

「行く」が30%…だと…orz
いやいや、まあまあ…聞き方が良くなかったですね。「よく」行く?ですからね。
ここ1年、キャンプ初心者の方が多く入社されたからですね、ここから沼にハマっていくことでしょう!
実際、キャンプやったことない・初心者の方も入社後キャンプ用品を集め、気がついたら月イチでキャンプに行くようになった方は多いです。

犬派?猫派?

長年開発部内で膠着状態だった犬派?猫派?論争に終止符を打つべく、最後にこの質問を設けました…っ!
結果は…

f:id:tadavivit:20220113192930p:plain
犬派?猫派?

犬派の圧勝…っ!!!

最後に

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

選考に進まれる方に少しでも開発部の雰囲気を知ってもらおうと思い書き始めましたが、改めて自部署の特徴と魅力を再確認できて良かったです。

そういうわけで、現在vivitでは一緒に働いて下さるエンジニアを大大募集中です。
カジュアル面談もやっておりますので、ご興味あるようでしたらお気軽にどうぞ!!

【新卒採用】

www.wantedly.com

【中途: バックエンドエンジニア】

www.wantedly.com

【中途: フロントエンドエンジニア】

www.wantedly.com

リモートワークでのvivitの取り組み

技術開発部の小原です。
アウトドア用品専門買取・販売サービス、hinataリユースでバックエンドの開発を行なっています。

www.hinatareuse.jp

はじめに

新型コロナウイルス感染症の拡大に伴う出勤抑制の方策として、一部リモートワークでの業務を行なっています。

現在、技術開発部では水曜・金曜の週二日を出勤日として、それ以外はテレワークでの業務を行なっていますが、 家庭の事情や体調不良の場合は、申請することでフルリモートワークでの業務が行えるようになっています。

私としては、このご時世感染リスクを考えると、出社に伴う移動は最小限に減らしたいですし、 PCとネットワークの環境さえあれば仕事はできるだろうと思っていました。

しかし、2021年4月に発表された日本生産性本部のデータによるテレワーク実施率によると、 一度目の緊急事態宣言時の実施率が一番高く31.5%(2020年5月) その後は徐々に下がり、19.2%(2021年4月)になりました。

接客業などそもそもリモートワークができない業種もありますが、 まだまだ一般的ではないことがわかりますね。

今回は、弊社の感染対策とリモートワークについて紹介しながら、 リモートワークを導入したことで感じたこと、新たに生まれた活動をご紹介します。

テレワークが導入される

もともと、全ての部署が本社の目黒に出勤して仕事を行なっていました。

第一回目の緊急事態宣言では、全ての社員がリモートワークとなり その後は段階的に出勤する部署もありましたが、技術開発部では隔週での出勤となりました。 時差出勤を行い、満員電車を避けて出社することも可能です。

業務中は、slackでコミュニケーションをとっていますが、 各自ステータスを細かく設定するようにして、状況を共有しています。 f:id:k_marietty:20220106184008p:plain

また、普段から使用していましたが、各自timesチャンネル(分報)で、状況や困っていること、雑談などをなるべくたくさん発言するように心がけています。 困ったことがあればハドルの機能を使用し、気軽にメンバーと会話し、MTGも頻繁に行っています。

これらの活動により、リモートワークでも普段と同じように業務を遂行することができるようになりました。

社内全体での取り組み

弊社では、出社前に体温の確認を各自行っています。 各デスクには飛沫防止のアクリル版を立てました。 f:id:k_marietty:20220106171019j:plain

受付やデスク周りに消毒液も設置しました。 f:id:k_marietty:20220106171055j:plain こうした感染予防への取り組みは、slackで共有され、弊社で働く全ての人に共有されます。

リモートワークで感じたこと

2点あります。 1点は、テキストコミュニケーションの難しさです。

文字に起こすことで、情報が明文化され、後から見返すことができるメリットもありますが、 対面とは違うコミュニケーションスキルが必要というデメリットがあります。

相手の顔や状況が分からないので、相手が怒っているのではないか?と思わせてしまったり、要件だけを簡潔に書きすぎて、冷たい印象をあたえてしまう場合があります。 テキストコミュニケーションでは、ただ用件を伝えるだけではなく対面で伝わる情報も伝える2つを両立したスキルが必要です。

2点目は、 一体感が感じられず寂しい気持ちになることがありました。

外出自粛、イベント中止、などなど人と話す機会が減り、 ちょっとした相談や、雑談がなくなり、自分が思ってた以上に孤独感がありました。

そこで、いろんな方法でコミュニケーションを増やし相手の状況を知ろう!という試みを開始しました。

エンジニアランチ実行委員会の誕生

技術開発部のコミュニケーション活性化を目的とした雑談会や歓送迎会を主催しました。 当初は、ランチの時間にイベントを行っていましたが会話もしたいが、食事の時間もしっかり取りたいとの要望が多くあったため、ランチ時間後の業務時間内でイベントを行うようになりました。

ジョインされたエンジニアの歓迎会を行い質問会を行ったり、事前にアンケートをとり、3.4人のグループを作り雑談会を行いました。

相手のことを知る良い機会となりました。 現在もこの取り組みは続いています。

環境を整える

デスクや椅子、キーボードなどを自分好みのものにしました。 下記の写真は、私の自宅のデスクです。

f:id:k_marietty:20220106173251j:plain アロマディフューザーでリラックスして作業できます。

自分好みに環境を自由に整えられるのは、モチベーションアップに繋がりとても良いですね。

最後に

弊社では、新型コロナウイルス感染症の拡大に伴う出勤抑制のため、リモートワークを導入しています。 また、オフィスでも感染予防のため様々な対策や共有を行っています。

リモートワークでは、直接顔が見えないため日々のコミュニケーションの積み重ねがチームの一体感とスムーズな業務につながっていきます。 業務を遂行するだけのコミュニケーションだけではなく、コミュニケーションが気軽に行える環境作りも大切にしています。

まだまだコロナ禍は続きますが、技術開発チーム一丸となって楽しく開発していきたいと思います。

アウトドア事業で共に働く仲間を募集しています。 ぜひご応募下さい!!

www.wantedly.com

React と Svelte を比べて感じたこと

フロントエンドエンジニアの氏家です。

最近、JavaScriptフレームワークであるSvelteに関する記事を多く見かけるようになりました。 僕の中で「何か新しいフレームワークが出てるなぁ」から「面白そうだし触ってみよう」という気持ちに変わったので、vivit の数多くのプロダクトで採用している React と新進気鋭な Svelte を比べてみて、何がどう違うのか体系的に学んでいこうと思います。

f:id:ijimakenta:20220116231353p:plain

そもそも Svelte とは

https://svelte.jp/ では以下のように説明されています。

Svelte はユーザーインタフェースを構築する先鋭的で新しいアプローチです。React や Vue のような 従来のフレームワークがその作業の大部分を ブラウザ で行うのに対し、 Svelte はその作業を アプリをビルドする際の コンパイル時 に行います。

Svelte は仮想 DOM による差分検出のようなテクニックを使用する代わりに、 アプリケーションの状態が変化したときに DOM を外科的に更新するコードを生成します。

Svelteコンパイラである」とも言われており、記述したコードをプレーンな (vanilla) JavaScriptコンパイルします。そのため、バンドルサイズやメモリ使用量が最低限で済み、アプリケーションのロードや実行を高速化してくれます。

React と Svelte のコードの違い

百聞は一見にしかず、 React のコードと Svelte のコードを比べてみましょう。

作成するのは<Button name="hoge" />で呼び出して使うことができる、クリックするたびにカウントされるボタンコンポーネントです。

f:id:rugk:20220106171635p:plain
レンダリングされるもの

React

まずは React のコードを書いてみます。 今回は vivit のプロダクトでも採用している、@Takepepeさんの経年劣化に耐える ReactComponent の書き方に習い記述していきます。

qiita.com

/Button.tsx

import { useState } from "react";
import styled from "styled-components";

export type ContainerProps = {
  name: string;
};

type Props = {
  className?: string;
  count: number;
  handleClick: () => void;
} & ContainerProps;

const Component = ({
  name,
  className,
  count,
  handleClick,
}: Props): JSX.Element => (
  <div className={className}>
    <button className="button" onClick={handleClick}>
      {name}{count}</button>
  </div>
);

const StyledComponent = styled(Component)`
  padding: 10px;
  .button {
    color: #333;
  }
`;

export const Button = (props: ContainerProps): JSX.Element => {
  const [count, setCount] = useState(0);
  const handleClick = () => {
    setCount(count + 1);
  };
  return <StyledComponent {...props} count={count} handleClick={handleClick} />;
};

このぐらい単純だと分かりやすいですね。 それぞれの層で何が行われているかもすぐに理解することができます。

Svelte

次にこれを Svelte で書いてみます。

/Button.svelte

<script lang="ts">
  export let name: string = "";
  let count: number = 0;
  const handleClick = () => {
    count++;
  };
</script>

<div class="wrapper">
  <button class="button" on:click="{handleClick}">{name}が{count}匹</button>
</div>

<style lang="scss">
  .wrapper {
    padding: 10px;
    .button {
      color: #333;
    }
  }
</style>

コード量が React の半分になりました。 さらに、 Svelte のコードを見慣れない方でもこのコードが何をやっているか一目瞭然です。 書き方は Vue.js に似ているかもしれません。

もう少し詳しく見ていきます。

Script

<script lang="ts">
  export let name: string = "";
  let count: number = 0;
  const handleClick = () => {
    count++;
  };
</script>

ここではモジュールやコンポーネントを import したり、コンポーネントの props を定義したり、 React でいう hooks を使用したりします。 props の定義をexportと書くのは違和感があるかもしれませんが、すぐに慣れてしまいます。

コードから分かると思いますが、状態管理を単なる変数で行っているのも Svelte の特徴の一つですね。

また、 Svelte は正式に TypeScript をサポートしているので、開発体験が損なわれることもありません。

DOM

<div class="wrapper">
  <button class="button" on:click="{handleClick}">{name}が{count}匹</button>
</div>

ここでは DOM(HTML テンプレート)を定義しています。 初めからロジックや状態管理のコードが分離されているので、レイアウトのみの Stateless なレイヤーになっています。

Style

<style lang="scss">
  .wrapper {
    padding: 10px;
    .button {
      color: #333;
    }
  }
</style>

SvelteSCSS もサポートしており、 ReactStyledComponents を使用して開発していた方は同じようにスタイリングすることができます。

ここで書いたスタイルは完全にコンポーネントに閉じており、例えば以下のように、

div {
  padding: 10px;
}

と書いたとしても、親コンポーネント(や子コンポーネント)で定義されたdivタグにpadding: 10pxが適用されることはありません。

比べて感じたこと

まずはじめに感じたのは、最近のモダンなフレームワークの中では学習コストが低いということです。 私はフロントエンドエンジニアとして開発に携わる際に、様々な技術や知識を勉強しました。 特に React では JSXhooksCSS in JS などの概念を覚えるのに苦戦した記憶があります。

それに比べて Svelte は、<script>で囲まれた単純な JavaScript<style>で囲まれた単純なCSS、レイアウトをつくるHTMLのみで構成されており、状態管理の方法について覚える必要も、複雑なライブラリを導入する必要もありません。 HTML、CSSJavaScriptさえ書ければ、すぐにでも Svelte で開発できます。

もう1つ感じたのは、開発体験が抜群に良いということです。 主に以下の点が挙げられます。

特にコードの記述量を減らせる点はとても大きかったです。 Svelte 独自の記法などはあるものの、シンプルで分かりやすいため可読性が大幅に上がり、実装コストも下がります。

まとめ

ここまで ReactSvelte の違いについて書きましたが、どちらが優れいている、というわけではありません。 どちらのフレームワークにもメリット、デメリットが存在しており、プロダクトやチームで行われる技術選定によって適切なものを使用すべきだと思います。

しかし、個人的な感想としては Svelte による開発の方が、 React に比べて「分かりやすくて、楽しい」と感じました。

実際、State of JS 2020で満足度・関心のランキングで Svelte が1位を獲得しています。

2020.stateofjs.com

おわりに

vivitではまだ Svelte を使用した開発は行っておりませんが、ちょっとしたLPなどの制作であれば積極的に採用していきたいです。

また、SvelteKitが正式にリリースされればより大規模なアプリケーション開発に採用していけると思うので楽しみです。

今は逸る気持ちを抑えて、個人で Svelte 開発を楽しみたいと思います。


vivit株式会社ではモダンな環境でアウトドア事業を成長させていくエンジニアを募集しています。 また、23卒の新卒エンジニア採用も行っていますので、詳しくは下記をご覧下さい。

www.wantedly.com

react-philosophies を読んでの所感

はじめに

フロントエンドエンジニアの関(@kur0buchi)です。

プログラマとして自分で新しくコードを書いたり、誰かの書いたコードをメンテナンスする中で「良いコードとは」を悶々と考える日々を送る中、先日 Twitter のタイムライン上で mithi/react-philosophies というリポジトリを偶然見かけました。

github.com

things I think about when I write React code.
(Reactコードを書くときに考えること。)

のイントロダクションで始まるこの文章が、普段自分が React でアプリケーションを書いてる中でぼんやりと考えていることの言語化がされていたり、また正直あまり深く考えていなかった部分に気付かされたりと、非常に興味深い内容だったので記事として紹介しようと思い立ちました。

当記事は mithi/react-philosophies を読んだ私自身の所感を述べるものになっており、翻訳記事や詳細な内容を記すものではありません、ご了承ください。

また参照元の記事の内容に関しましても、イントロダクションで

  • just guidelines and NOT rigid rules
    (単なるガイドラインであり、厳格なルールではありません)
  • a living document and will evolve over time as my experience grows
    (生きているドキュメントであり、私の経験が成長するにつれて時間とともに進化します)

とある通りですのでこの点もご留意いただければと思います。

内容について

mithi/react-philosophies の構成は以下のようになります

  1. イントロダクション
  2. 必要最低限
  3. 幸せのためのデザイン(設計)
  4. パフォーマンスのヒント
  5. テストの原則
  6. 見識を他の人と共有する

最後の章については「Pull Request であなたの考えを教えて下さい!」といった内容でした。 「ぜひこれも!」というものがあったら Contribute してみるのもいいかもしれません

以下より1章からそれぞれ感じたことをいくつかピックアップしながら述べていきます。 あっさりと触れていくので原文も是非読んでみてください。

必要最低限

この章はタイトルにもある通りごく当たり前のことがほとんどかと思います。

コンピュータはあなたより賢いと認識する

タイトルは刺激的ですが、linter や formatter、フレームワークなど活用できるものは活用しましょうということですね。

  • Typescript will make your life so much easier.
  • NextJS is an awesome framework.

その通りだと思います。

見つけたときよりも少し良くする

何かがおかしいと思ったらその場で直す、すぐ直せなくてもコメントや Issue を残す。
大掛かりなリファクタリング作業にならないようにこまめなメンテナスを重ねるのは重要に思います。

幸せのためのデザイン(設計)

この辺からやや耳の痛い文章が続きます。

バナナを持ったゴリラとジャングルではなく、バナナを渡します

この言い回しは面白くて好きです。
コンポーネントの呼び出しにはなるべくプリミティブを渡すという趣旨の話で、props で渡す情報はなるべく知識を必要としない方が良いということですね。
ただこの辺はコンポーネントの抽象度によるかもしれません。

多くの useState を使用する代わりに useReducer の使用を検討してください

長い期間で少しずつ機能を追加しているといつの間にか useState 地獄に陥っている場合があるので、良きところで useReducer の採用を検討するといいかもしれません。

パフォーマンスのヒント

パフォーマンスは恥ずかしながらなんとなくでやっている部分が否めないので読んでいて胃が痛かったです……

状態を使用されている場所にできるだけ近づけると、コードが非常に読みやすくなるだけでなく、アプリが高速になります

状態変化が散らばっているコードは非常に追いにくいので心がけたいです。

状態の参照と更新機能を分離することでコンテキストを最適化できます

これは最近も React Docs Beta で書かれていたりしているので記憶に新しいです。

beta.reactjs.org

テストの原則

フロントエンドの場合、100%のコードカバレッジは必要ありません。おそらく約70%で十分です

大事ではありますがテストの精度を求めることが目的になってしまうのは業務だと苦しいかもしれません。

Jest、React testing library、Cypress や Mock service worker を使うのが好きです

Cypress は弊社でも利用しています。

まとめ

今回は簡単なピックアップと所感を一言といった簡単な形式でお送りしたのですが、原文はもっと参考になる情報ばかりなので是非ご一読ください!

github.com

おわりに

vivit では自分なりの philosophy を持つあなたの応募もお待ちしております。

www.wantedly.com

スマート家電で作業環境を便利に楽しくする【loT】

はじめに

こんにちは、技術開発部の小原です。
アウトドア用品専門買取・販売サービス、hinataリユースでバックエンドの開発を行なっています。

www.hinatareuse.jp

最近、スマート家電などインターネットにつながる、いわゆる「IoT」製品が増えています。
今回は、作業環境を便利にするためにスマート家電を実際に購入した感想と curlコマンドを送り照明をON/OFFして遊んでみたいと思います。

使用するHueシリーズの紹介

今回使用したのは、Philips Hue です。

www.philips-hue.com

LED電球をHue ブリッジ接続することにより、ライトを最大50個まで接続ができ、映像・音楽・ゲームとの連動、外出先からの操作を行うことができます。
HueはIFTTT連携することでさらに便利になります。

IFTTT とは

2つのサービスを組み合わせて決められた動作を起こすサービスで、
Twitterで帰宅するとツイートしたら、エアコンをONにする」などの 他のサービスとの組み合わせによって、さらに便利に利用できるようになります。
IFTTT(イフト)は、
IF = if
T = this
T = then
T = that

もし◯◯が、◯◯であれば、◯◯を、◯◯する。の略です。 ◯に入る内容をプログラミング(設定)することで、誰でも簡単に希望の動作をさせることができます。

設定

LED電球を設置します。
照明器具がLED電球対応かどうか確認してください。

f:id:k_marietty:20211109165654p:plain
設置が終わったら、
Hueハブを電源に繋ぎ、さらに家の無線LANに接続します。 Hueハブがhttpサーバーのような役目です。

f:id:k_marietty:20211109170142p:plain
ハブはiPhoneの半分ぐらいの大きさです。
f:id:k_marietty:20211109170329p:plain

準備は以上です。

アプリをDLし、同期させるとアプリ経由で設定することができるようになります。

f:id:k_marietty:20211109171501p:plain
部屋別に、ON/OFFだけではなく色温度を調整することができます。
f:id:k_marietty:20211109171330p:plain
時間によって好みの照明に設定することもできます。
作業中は色温度を高くしてあげると、目が疲れにくくなりますし
就寝時間によって少しずつ暗くなるように設定することで睡眠の質を上げることもできます。

こんなにも簡単に設定ができます。
次に、アプリを利用せずcurlコマンドで操作してみましょう。

curlコマンドを送り制御する

Hue公式サイトからデベロッパーサイトへのリンクがあります。 APIを利用する場合は、デベロッパーアカウントを取得する必要があります。 https://developers.meethue.com/

また今回のシステムは、Hue ハブを使用したネットワークと同じネットワークにPCを接続してください。

リビングの電気をONにするコマンド

curl --insecure https://[Hue hubのIPアドレス]/api/[ユーザーネーム]/groups/1/action -X PUT -H "Content-Type: application/json" -d '{"on": true}'

他にも、パラメーターを変更することで 照明の状態を知ることができたり、明るさなども調整することができます。

まとめ

これからも、スマート家電などを利用し、自宅作業や生活を便利で楽しくしていきたいです。

vivitではアウトドア事業で共に働く仲間を募集しています。 ぜひご応募下さい。 www.wantedly.com

vivit で実際に行っている GitOps 手法について

こんにちは。
vivit で SRE をやっている宮本(https://github.com/tatsuro-m)です!

vivit の各プロダクト(hinata media,hinata rental, hinata spot)はバッチ処理等も含めて GKEで稼働しています。

そこで今回は vivit の開発サイクルを支える GitOps についてご紹介します!
以前にも GitOps については書きましたが、変わった部分もあるので再度ご紹介します。 vivit.hatenablog.com

現在のアーキテクチャ

f:id:tatsurom:20211109115122p:plain


利用しているツールをまとめると以下のようになります。

項目 使用ツール
基盤 GKE
マニフェスト管理ツール Kustomize
CI GitHub Actions
CD ArgoCD

順番に解説していきます。
基本的にはプロダクトごとにソースコードを配置するリポジトリは分けており、GitOps のベストプラクティスに従い Kubernetes マニフェスト(Kustomize)は別リポジトリにまとめてあります。

1. ローカルで開発して GitHub に push して PR を作成する
ここは普通だと思います。
この時 CI が走り、該当ブランチの Docker イメージがビルドされ、GCR に自動的に push されます。
Docker イメージのタグには7桁にカットした git のコミットハッシュを使っています。

2. マージする前に検証環境で動作確認したい
いきなり本番にリリースするのは怖いので検証環境にデプロイします。
もちろんここでも GitOps を利用します。

1 で作成したブランチにチェックアウトして、リリースタグを作成します。 リリースタグ作成コマンドは、プロダクトリポジトリの Makefile に用意してあります。

$ make release_tag
カレントブランチは feature/hoge-hoge です。OK? 省略すると y [y|N]: y
環境> 省略するとstg [stg|prod]: stg
サービス> 省略すると全て。カンマ区切りで複数指定可 [serviceA|serviceB]: serviceA,serviceB
名前> 省略するとtatsurom: 
自動マージを有効にしますか?【注意】git tag push のタイミングで処理が自動で始まります。 省略すると N [y|N]: N
このタグでOK? stg/2021/11/09/1203-tatsurom-serviceA,serviceB  省略すると y [y|N]: y
originにPUSHしますか?> [y/N/その他リモート名]: 

作成したタグを GitHub に push すると GitHub Actions がトリガーされ、タグのパースや Docker イメージタグの書き換え、更新PRの作成などが自動で行われます。

30秒ほど待つと以下のような PR がマニフェストファイルを管理しているリポジトリで飛んできます(塗りが多くてすみません🙇)! f:id:tatsurom:20211109121914p:plain

この PR をマージすることによって ArgoCD が反応し、検証環境の pod が新しい Docker イメージでアップデートされます。

3. 動作確認後、本番環境にリリースする
PR が approve されて動作確認もOKなら master にマージします!
この時も先程と同じようにマージコミットに対して Docker イメージの build & push が実行されます。

ローカル環境で最新の master ブランチにチェックアウトして同じようにリリースタグを作成します。

$ make release_tag 
カレントブランチは main です。OK? 省略すると y [y|N]: y
環境> 省略するとstg [stg|prod]: prod
サービス> 省略すると全て。カンマ区切りで複数指定可 [serviceA,|serviceB]: serviceA,serviceB
名前> 省略するとtatsurom: 
自動マージを有効にしますか?【注意】git tag push のタイミングで処理が自動で始まります。 省略すると N [y|N]: N
このタグでOK? prod/2021/11/09/1230-tatsurom-serviceA,serviceB  省略すると y [y|N]: y
originにPUSHしますか?> [y/N/その他リモート名]: 

飛んできた PR をマージして本番リリース完了です 🎉

大まかにこのような流れで GitOps を実現していますが、どうして「常に master ブランチが本番環境にデプロイされている」という構成にしなかったのでしょうか。
タグを作ってPRをマージして。。。という作業が無くなる分、楽で効率的とも言えそうです。

次の章で考えてみます。

GitOps と CIOps の違い

ここまで当たり前に GitOps という言葉を使ってきましたが、 CIOps との違いをおさらいしてみましょう。
こちらの記事 が非常に分かりやすいです。

オペレーション方法 内容
CIOps push 型
CI ツールで CD までやってしまう
GitOps pull 型
CI と CD で別のツールを使う

CIOps は master へのマージ(アクション)に伴って自動的に環境へのデプロイが走るものです。非常にシンプルで分かりやすいです。 つまり、master へのマージをトリガーとして「常に master ブランチが本番環境にデプロイされている」という構成は CIOps だということになります。

GitOps はソースコードを master へマージしたとしても自動デプロイは行われません。マージした際に起動するのは静的解析やテスト、イメージのビルドなど「CI」の部分だけであり、CD には別に明示的なアクションを必要とします。

CIOps の問題点

  • GitHub Actions などの CI ツールにリリースまで行える大きすぎる権限を与えることになる
  • リリース後に不具合が発生してアプリケーションを前の状態に切り戻したい場合、「デプロイだけしたい」のに CI のために長く待たされる
  • 組織規模が大きくなってくると CI/CD 間の責任分界点を作りたくなるが、それができない
  • どの環境にどのイメージがデプロイされているか分かりにくい

などです。
現在の vivit では各プロダクトの担当者がリリース作業まで行っており、 SRE が管理するのは基盤のみですが、このようなデメリットは避けたいです。

「常に master ブランチが本番環境にデプロイされている」という構成にしない理由、CIOps ではなく GitOps で運用している理由は、これらのデメリットを避けるためです。

逆に GitOps のデメリットは初期構築、自動化パイプランの構築(vivit でいうタグ作成の仕組みなど)が大変ということです。
ArgoCD は素晴らしいツールですが、マネージドサービスではないので GKE 上で自前運用が必要です。もちろん性能面で問題があった時には自分たちで対応しなくてはいけません(先日も対応しました 😇)。
設定箇所も割と多いです。

個人開発や小規模で開発を始める場合には CIOps の方が適している場合も多いと思います!

さいごに

今回は vivit で行っている GitOps の紹介と、CIOps と GitOps の違いについて書いてみました。

vivit では一緒に働くエンジニアを大募集しています。
www.wantedly.com

少しでも興味を持って頂いた方は、是非カジュアル面談の応募をお待ちしております!