JWT認証と流れのやわらかい解説

こんにちは。 SCOUTERフロントエンドエンジニア、現在Laravel勉強中の匠平@show60です。

弊社のプロダクトはフロントエンドをVue.js 、サーバーサイドをLaravelで実装しています。 私が携わっている新規事業のback checkでは、LaravelでAPIを実装し、フロントエンドからリクエストを送ることでアプリケーションを動作させています。

APIを実装する際に必要になるのがセキュアな認証。そこで広く使われるJWT認証について学んだことを今回お話したいと思います。

なぜ必要なのか、どのように使っているのかを焦点にやさしくお話しします。

ユーザー認証とは

ユーザー認証とは、アクセスしてきたユーザーが正当なユーザーかどうかをチェックすることです。 チェックに使用される要素としては以下のようなものがあります。

  • 知る要素
    • パスワード
  • 持つ要素
    • トークン
  • 備える要素
    • 指紋
    • 虹彩 (目)

JWTはその中にユーザー認証情報を含ませることができるため、正当なユーザーかどうかをチェックできるということですね。

余談、よくパスワードを忘れた際に、母親の旧姓やペットの名前、出身校名を聞かれますが、これらは「知る要素」に分類されますね。 とはいえ、これらは他人にも知られる情報であるため、安全ではなく推奨されていません。

実家のペットの名前がモカちゃんであるとここに書くことで、私のアカウントはもはや安全ではなくなってしまいます。

参考: [Google Online Security Blog | New Research: Some Tough Questions for ‘Security Questions’ 2015年5月] (https://security.googleblog.com/2015/05/new-research-some-tough-questions-for.html)

今回の題材であるJWTは「持つ要素」に分類されるものです。

JWTとは

JWTとはJSON Web Tokenの略です。

JSONとはJavaScript Object Notationの略で、JavaScriptのオブジェクトの構造を持ったデータフォーマット。

Tokenとはユーザーを識別するための認証情報。

つまりJWTとは、JavaScriptのオブジェクトの形をした認証情報のことです。

JWTの構成

JWTは大きく3つの要素で構成されます。

  • ヘッダー
  • クレーム情報
  • 署名

ヘッダー

この後の署名に使われている暗号化アルゴリズムや、トークンタイプなどのメタ情報が入ります。

クレーム情報

任意の情報を含ませることができ、ここにユーザー認証情報を記述します。

私の携わるbackcheckというプロダクトには、企業、候補者、推薦者、管理者と4つのユーザータイプがあります。それぞれのページを行き来できないようアクセスに制限をかけるため、このクレーム情報内にユーザータイプを表すキーを実装しています。

署名

ヘッダーに記述した暗号化アルゴリズムにより、ヘッダーとクレーム情報をBase64urlに変換したものから生成されます。

なぜJWT認証を使うのか

JWTを使うメリットは以下のようなものが挙げられます。

  • 安全
    • JWTに署名が含まれているため、改ざんがあってもチェックできるようになっている。
  • 実装のしやすさ
    • セキュアなToken発行が楽に実装できる。
  • 管理のしやすさ
    • URLに含むことができる文字で構成されているから、HTTPリクエストでの取り扱いが楽。
    • 認証に必要となる情報はすべてJWTの中に入っているため、ユーザー認証情報をサーバーで管理する必要がない。DB問い合わせを行う必要がない。

JWT認証を使えば、安全かつ管理がしやすいセキュアな認証を簡単に実装できるということですね。

サーバーサイドで行うこととフロントエンドで行うこと

サーバーサイドとフロントエンドで行うことを分類しながら、JWT認証を使用する流れを説明します。

ユーザー初回登録時

  • 【フロント】
    • ユーザー情報 (メールアドレス、パスワード等) を送信
  • 【サーバー】
    • リクエストされたユーザー情報を元にJWTでトークンを生成
    • トークンをフロントへ返す
  • 【フロント】
    • 返ってきたトークンがbase64urlでエンコードされているため、base64 に変換
    • 変換したものをLocalStorageに保存

このときトークン内のユーザー情報には、上に書いた4種類のユーザータイプ情報も含んでいます。

2回目以降のログイン・画面更新時

  • 【フロント】
    • Tokenの有無の確認
      • LocalStorageにTokenがあるかどうかを確認
        • ある場合は、HTTPヘッダに入れてサーバーにアクセスする
        • ない場合は、そのユーザータイプによって適切なページへリダイレクトさせる
  • 【フロント】
    • Tokenの有効期限の確認
      • LocalStorageにTokenがある場合、その有効期限を確認
      • 有効期限が切れている場合、サーバーに問い合わせし、Tokenを更新
  • 【サーバー】
    • Tokenの更新リクエストがきたらJWTをリフレッシュして返す(このときフロントでは、初回登録時と同じように返ってきたトークンをLocalStorageに保存します)
  • 【フロント】
    • サーバーにアクセス
      • 有効なアクセスであることがフロントで確認されたらサーバーにアクセスをします
  • 【サーバー】
    • トークンの認証を確認しデータを返す

初回登録時に発行したトークンをLocalStorageに保管しており、有効期限やユーザータイプの情報を持っているため、2回目以降のログイン・画面更新時のサーバーへのアクセスは多くても2回に抑えられています。

フロントエンドでの処理は、ユーザー情報がすべてトークン内に記述されており、JSONフォーマットなので処理もとても簡単に行えますね。

まとめ

実際にはサーバー内での処理を加えるとまだまだ言及しなくてはいけないことがありますが、流れをさっくりと説明させてもらいました。

さいごに

現在、株式会社SCOUTERでは、エンジニア、デザイナーの募集をしております。

興味のある方は、是非下記よりご応募ください!

www.wantedly.com

www.wantedly.com

www.wantedly.com

www.wantedly.com

API仕様の出力プラグインをtraitにしてみた話

みなさんこんにちは
先月よりジョインしました、 niisan-tokyo です。
今後とも宜しくお願いします。

で、今回のテーマですが、以前にkotamatが公開していた、テストを通したAPIスペックの自動生成プラグインをちょいと改造したという話です。

APIスペック自動生成ツールの改造

TL;DR

  • API仕様の自動吐き出しがクラス継承式だったので、使いにくかった
  • traitでも使えるようにした
  • 一応後方互換性を確保した

対象のリポジトリ

https://github.com/kotamat/laravel-apispec-generator

ちょっと使いにくかった

このプラグインは、使い方は容易だったのですが、一つ欠点がありました。
それは、このプラグインをベースクラスとして継承しなければならないということです。

<?php

use ApiSpec\ApiSpecTestCase;

class TestCase extends ApiSpecTestCase
{

}

APIスペックを出力する必要のないところでは、このクラスを継承したくないため、別のベースクラスを使いたくなりますが、一方で、ベースクラスでアプリで特有の設定やら便利なテスト機能を実装することがあるでしょう。
結局、普通のベーステストクラスとともに、APIスペック出力用のクラスを継承したベーステストクラスを用意するという、少々厄介なことになります。

traitにする

そこで、ベースクラスの代わりにtraitを使うという技が考えられます。
traitは使用することで、そのクラスに単純にtraitの中のコードをコピーしたのと同じ状態を作ることができます。
ApiSpecTestCaseは、実際にはいくつかのメソッドにAPI仕様を吐き出すコードを入れているだけですので、traitで十分ということになります。

traitを使う場合のAPI仕様の出力は以下のようにすると可能になります。

<?php

use ApiSpec\ApiSpecOutput;

class SomeTestCase extends TestCase
{
    use ApiSpecOutput;

    //...
    
    /**
     * @test
     */
    public function API仕様を吐き出すテスト()
    {
        $this->isExportSpec = true;
        $this->getJson('/someone/status');
    }
}

こうして、必要なときにだけ、use ApiSpecOutputすることで、ベースクラスをいじることなく、API仕様を吐き出すことができます。

後方互換性の維持

こうして、traitにしようとしたときに、すでにベースクラスで使っているところはどうなるんだという話になります。
これは、プロダクト開発において、仕様を追加する場合にも発生する問題で、後方互換性をどうするのかということです。 今回は後方互換性は残すことにします。

後方互換性の確保の方法は簡単で、要するにテストが通っていればいいということです。
API仕様出力ベースクラスはテストクラスのベースクラスなので、テストの方法が厄介でした。

https://github.com/kotamat/laravel-apispec-generator/blob/0ade044a5a8f41d54a4b872978a1c3cbb2647bc9/test/ApiSpecTestCaseTest.php

テスト自体はかなり無理矢理なコードでとにかくテストできればいいやって感じになっています。

<?php

// ... 中略

    public function createApplication()
    {
        $app = new class extends Application {
            private $acceptor;
            public function __construct($basePath = null)
            {
                //
            }
            public function setAcceptor($acceptor)
            {
                $this->acceptor = $acceptor;
            }
            public function make($class, array $param = []) {
                $mock = m::mock(FilesystemAdapter::class);
                $mock->shouldReceive('drive')->andReturn($this->acceptor);
                return $mock;
            }
        };
        $app->setAcceptor($this->acceptor);
        $this->app = $app;
    }
    protected function setUp()
    {
        $this->acceptor = new class {
            public $filename;
            public $str;
            public function put($filename, $str) {
                $this->filename = $filename;
                $this->str = $str;
            }
        };
        $this->createApplication();
    }

これがテストの前提部分ですね。
無名クラスを連発しておきながら、思い出したようにMockeryを利用したりしています。
テスト部分は上のリンクで見てください。単純にpostJsonとかを投げたら、API仕様の出力ができていることを確認しているだけです。

このテストを作った上で、ApiSpecTestCaseにあったロジックの大半をApiSpecOutputに移し、ApiSpecTestCaseApiSpecOutputを使っているだけという状態にすることができました。

まあ、ベースクラスに手を入れずに、traitだけ作ればこんな苦労はないんですが、同じコードがあるって気持ち悪いので、やってしまいしました。

まとめ

というわけで、API仕様の出力をtrait化することに成功しました。
個人的にはもうちょい改造したいところですが、ひとまずはtraitで使えるようになったというところで満足しておきましょう。
今回はこんなところです。

最後に

現在、株式会社SCOUTERでは、エンジニア、デザイナーの募集をしております。

興味のある方は、是非下記からご応募お願い致します!

www.wantedly.com

www.wantedly.com

www.wantedly.com

www.wantedly.com

Vueのライフサイクルフックまとめ

こんにちは!
株式会社SCOUTER開発部フロントエンドエンジニアの佐藤(@r_sato1201)です

弊社ではフロントエンドのフレームワークにVue.jsやNuxt.jsを採用しています。 業務中で開発をしてる際に、Vueのライフサイクルフックについて理解が乏しいまま実装していることに気がついたので 今回はVueのライフサイクルフックについてまとめたいと思います。

ライフサイクルとは?

f:id:ryonnsui1201:20190225221150p:plain:w250

ライフサイクルフックについて話す前に、まずライフサイクルについて。 Vueに触れている方なら、上の図を一度は見たことがあると思います。 ライフサイクルとは、Vueインスタンスが生成されてから削除されるまでの流れのことで、上の図はその流れを表した図です。

Vueのライフサイクルは大きく分けて以下の5つに分けられます。

① Vueインスタンスの生成
② DOMへのマウント
③ 画面の更新、リアクティブデータの変更
④ Vueインスタンスの破棄
⑤ エラー時

それでは次に、上記の分類に沿ってライフサイクルフックを紹介したいと思います。

ライフサイクルフック

ライフサイクルフックとはVueのライフサイクルにおける一連の処理の中の各タイミングで実行する関数のことをいいます。 各フック内に記述することで、任意の処理を行うことができます。

先程記述したライフサイクルの5つの分類に沿ってライフサイクルフックを説明していきます。

① Vueインスタンスの生成

実行されるフック:beforeCreate created
まずは Vueインスタンスが生成されます。この時点ではインスタンスがマウントされていないので、まだコンポーネントの内容は反映されていません。 Vueインスタンスが生成され、リアクティブデータが初期化される前にbeforeCreateが呼ばれ、リアクティブデータが初期化された後にcreatedが呼ばれます。

② DOMへのマウント

実行されるフック:beforeMount mounted 
生成された Vueインスタンスは、次にDOMにマウントされます。 マウント前にbeforeMountが呼ばれ、マウント後にmountedが呼ばれます。 したがって、DOMにアクセス可能なのはmounted以降になります。

③ 画面の更新、リアクティブデータの変更

実行されるフック:beforeUpdate updated 
Vueインスタンスdataが変更された場合や、propsで渡されているデータが親で変更された場合など、それらの値の変更のタイミングでDOMを自動的に更新し再描画します。その際に実行されるフックが上記2つです。 DOMが更新される前にbeforeUpdateが、DOMが更新された後にupdatedが呼ばれます。

④ Vue インスタンスの破棄

実行されるフック:beforeDestroy destroyed
v-ifなどの機能によりVueインスタンスが破棄された時、上記2つのフックが呼ばれます。 Vueインスタンスが破棄される直前にbeforeDestroyが呼ばれ、Vueインスタンスが破棄された直後にdestroyedが呼ばれます。

⑤ エラー時

実行されるフック:errorCaptured 任意の子孫コンポーネントからエラーをキャッチしたときに呼び出されます。 このフックは ・エラー ・エラーをトリガするVueインスタンス ・どこでエラーが捕捉されたかの文字列情報 これら3つの引数を受け取ります。 また、このフックではエラーが自分より上位に伝播するのを防ぐために、false を返すことができます。

表にしてまとめると以下のようになります。
ライフサイクルフックの一覧

フック名 説明
beforeCreate インスタンスが生成され、リアクティブデータが初期化される前
created インスタンスが生成され、リアクティブデータが初期化された後
beforeMount インスタンスがマウントされる前
mounted インスタンスがマウントされた後
beforeUpdate データが更新され、DOMに適用される前
updated データが更新され、DOMに適用される前
beforeDestroy インスタンスが破棄される直前
destroyed インスタンスが破棄された直後
errorCaptured 任意の子孫コンポーネントからエラーがキャプチャされたとき

createdとmounted

ライフサイクルフックで使用頻度が高いのはcreatedmountedだと思います。 それぞれのユースケースをまとめてみました。

created

非同期通信を使ってデータを初期化するとき

よく使われるパターンとしてAPIなどを叩いて非同期通信で取得したデータをdataに初期値として挿入する処理が挙げられると思います。 このケースでは初期化のタイミングで使うという面ではbeforeMountmountedで 非同期通信を行ってもよいのですが、DOMのマウントが行われデータを画面に反映するまでの時間を少しでも減らすためにはcreatedを使う必要があります。また、beforeCreateではリアクティブデータが初期化されていないため、dataに挿入することができません。

mounted

DOMにアクセスする必要がある場合

DOM要素にアクセスする必要がある場合や、HTML要素の高さや幅を取得する場合の初期化処理はmountedに記述するとよいでしょう。 ただし、mountedは 全ての子コンポーネントがマウントされていることを保証しないことに注意してください。Vue全体がレンダリングされた後に処理を行いときは、vm.$nextTickを使いましょう

mounted: function () {
  this.$nextTick(function () {
    // Vue全体がレンダリングされた後にのみ実行されるコード
  })
}

まとめ

Vueのライフサイクルについてまとめてみました。 今回触れなかったライフサイクルフックについても、分かりやすいユースケースなどあれば教えて頂けると幸いです!

さいごに

現在、株式会社SCOUTERでは、エンジニア、デザイナーの募集をしております。

興味のある方は、是非下記からご応募お願い致します!

www.wantedly.com

www.wantedly.com

www.wantedly.com

www.wantedly.com

参考資料

転戦1ヵ月 前と後、どうなん?

まず、誰ですか?

昨年後半よりめきめきと露出度を増やしていますが、Webエンジニアで猫好きな @jiyuujinプロフィールをご覧ください。

PHPを中心に、特にLaravelを使った制作は、2年近くと少々長め。Vue.jsとの出会いもこの時です。最近は関西を拠点としたコミュニティv-kansaiの立ち上げ、昨年年末のv-kansai Vue.js/Nuxt Meetup #1初主催をはじめ活動しています。

転職前に書いた記事はこちら!

webneko.info

慣れましたか?

慣れました。しかし、まだまだ改善の余地。

今回、リモートでお仕事を進めていますが、最大の違いは「リモート生活」です。ちなみに私個人のリモート経験は、ほぼ無いです(少なくとも、フルリモートは)。まずこの判断をしていただいたことは、今でも感謝すべきことと思います。

使えるものは使う、分報とか

その上でコミュニケーションを進めるため説明にどうしても口頭で伝えたい場合にテレビ会議で、など手段のレベルで困ったことは特にありませんでした。特に自身の意図が伝わらない、といったことにならないようにするため、Slackの「分報」を最大限活用している。前職にも似たようなものが存在、使う上で困ることはありませんでした。ですがあくまで口頭の補助的な役割で使っていたため、当時と位置付けが異なりその点で手こずった。

聞くこと、存在感を示すことを心がけ

また自分自身から他メンバーに対して「聞く」、「わからないことがあったら聞く」ことができなかった。前職から染み付いていることだが、実質一人で管理画面周りを廻していた環境で自身でやり切ること。このようにやり切ることはもちろん重要だが前職と違って、既に熟知されている方もいらっしゃる現状、聞いた方が早いのも事実。自身から声を上げていかないといけないことを改めて痛感させられました。このような試行錯誤を経ながらも成長していければ、確実に慣れてくるだろうと思っています。

その他、「前」と「後」

ステークホルダーの多さ

言ってもこれに尽きると思いました。今までゲームユーザーを筆頭に、社内でのCS、プランナーと言った限られた職種の人たちに対してのみ、想定すれば良かった世界。極端なことを言うと利益は、基本的にゲームユーザーに対してのみ考慮すれば良かったのが、エージェント企業や求職者、その採用企業までと立場がとにかく多いと感じました。

工程管理

先述の通り実質一人で廻していた環境もあり、今回初耳だった「スプリントプランニング」。プランニングでどのように設計をこなし、実装を進めていくかということ。これをしっかりと行うためには、事前の知識として仕様をおおまかに把握していないと中々できない部分もあり、これからだなぁと思っています。

開発環境・使用技術

基本的に大きな違いは存在しません。強いて言うならフロントエンド周りNode.jsの管理で、NodebrewからNodeenvに変わったこと、NpmからYarnに変わったことなど。

外出機会の量

想定の範囲内でしたが毎日4000歩(5km)は歩いていた日々が一切無くなる訳で、意識していないと不健康の塊になるのは必至です。汗笑 どちらかと言うと関西では不活性な部類に入る勉強会やコミュニティ活動を平日晩に充実、もっと交流を深められればと思っています。v-kansaiもそのうちの一つ。

最後に、

SCOUTERではエンジニア、デザイナーともに募集しております! 新規事業、絶賛グロース中の事業ともにLaravel, Vue.jsで開発しておりますので、 興味のある方はお声がけください!

www.wantedly.com

www.wantedly.com

www.wantedly.com

外部パッケージを修正したあと確認するまでのコストの削減

こんにちはSCOUTERでエンジニアをしているhirokinishizawaです。

弊社ではVue製のUIコンポーネント集をはじめいくつか外部パッケージ化をしています。以前まで外部パッケージの開発を行う際に変更したら外部パッケージを毎回ビルドし直して、その外部パッケージを使用しているアプリケーションに反映をさせていました。少しの変更でも再ビルドを行い反映をするという作業が入るため、外部パッケージの大きめなアップデートをするときにはとてもじゃないですが面倒臭すぎてやってられませんでした。なので今回差分ビルドを行い確認するまでのコストを削減するようにしたのでその話をしていこうかと思います。

どのような問題があったのか

冒頭でも説明したのですが、外部パッケージを修正したあとローカル環境で確認コストが高いというのが開発メンバー内で挙げられた課題でした。実際パッケージを修正してからアプリケーションに反映をするまでに下記を実行していました。

外部パッケージを修正
↓
外部パッケージを再ビルド(yarn dist{webpack --progress --config build/webpack.base.conf.js})
↓
アプリケーションに修正を反映させるためにビルドしたファイルをrsyncでコピーする
↓
アプリケーションで反映完了を待つ

これを少しでも修正する度に行っていました。

外部パッケージの再ビルドに時間がかかるためコストが高いというのもあるのですが、弊社で開発をしているSARDINEというサービスではadminを含め3つのステークホルダーが存在しているため、それぞれに反映させるのがとても面倒臭いというのが今回差分ビルドやyarn linkを出来るようにする起因となりました。

なぜ外部パッケージを作成したのか

上記でも同じことを言いましたが弊社で開発をしているSARDINEというサービスには3つのステークホルダーが存在します。

それぞれユーザーの種類は違いますがいくつか共通な画面があります。なので共通部分のコンポーネントをパッケージ化することによってコードを1箇所にまとめることができるため、修正を加えるレポジトリが1つで済むようになり、同じドメイン領域に関するコードがまとまっているためどのような処理が行われているのかを見通しやすくなるため作成しました。

yarn link + 差分ビルドするための方法

変更自体はほとんどありません。 外部パッケージで差分ビルドできるようにするために外部パッケージのpackage.jsonにscriptsを追加。

"watch": "webpack --progress --config build/webpack.base.conf.js --watch"

これでyarn watchでパッケージの差分ビルドを行えるようになります。

次にwebpackの設定を変更しないと外部パッケージでyarn link で貼ったシンボリックリンクの解決に失敗しアプリケーション側で参照できないため、resolve.symlinks を false に変更します。

以上で準備完了です。各リポジトリ1,2行ぐらいですねw

最後にターミナルでの実行方法を書いて終わりにしたいと思います。

外部パッケージでyarn link
↓
外部パッケージでyarn watch
↓
アプリケーションでyarn link <package-name>
↓
アプリケーションをビルド

実行したあとは外部パッケージを修正しターミナルでパッケージのyarn watchとアプリケーション側のビルドが動いているのを確認できれば完了です。

余計なコストを減らして爆速で開発をしていきましょう!

最後に

SCOUTER社では一緒に働く仲間を募集しています! 興味のある方は下記からご応募いただくか、弊社CTOまでご連絡ください!

www.wantedly.com

www.wantedly.com

www.wantedly.com

Nuxt Meetup #7 を開催しました!

総括を!

nuxt-meetup.connpass.com

nuxt-meetup-7
株式会社ピースオブケイクにて

初めまして、2/1 京都のゲーム会社ポノス・にゃんこスタジオより転戦したWeb猫こと、@jiyuujin (北村勇磨)です。今回のミートアップは、株式会社ピースオブケイクさんで開催されました。移転したばかりの素敵なオフィス、素晴らしい環境でございました。改めて場所提供のほどありがとうございます。

スポンサーLTでは、CTO @konpyuさんによる登壇。メディアプラットフォームNoteのAngularからNuxtへのリプレースについて取り上げられました。去年のVue Fes Japan 2018でも、福井烈さんの発表「note のフロントエンドを Nuxt.js で再構築した話本番運用は既に始まっている。」があったように非常に大きな話題となっています。

レガシーブラウザと向き合うNuxt.js

slides.com

面白法人カヤックのフロントエンドエンジニア、@kengotoiroさんの登壇、Lobi Web版のAngularからNuxtへリプレースをした話でした。開発中辛かったこととして、Nuxtが1系→2系の移行期にありドキュメント少なくハマったとのこと。機能拡張する場合レガシーブラウザで動くように変換するため、Polyfill.ioを使うと、nuxt.config.jsのheadに記載してあげるだけで簡単に対応できるといったTipの紹介もありました。

Nuxtを中心とした開発エコシステムと、個人開発のススメ

受託開発をメインに行っているフロントエンドエンジニア、七洋株式会社の金井淳さんの登壇。キッチン周りの解決を行うサービスsmall dish (Beta Version)の開発で、Nuxtを採用。ContentfulでModel、Fieldsを永続化データで実装。Vuexストアで献立やアイディア、いいねなど管理して、スピーディに開発している話でした。

Catch up Nuxt.js 2018.02

speakerdeck.com

最近異常に活発なNuxt.jsの活動方針について、@andoshin11さんの発表でした。nuxt-edgeを使うと、毎日ビルドされアップデートされるので、日々使ってみるのも楽しくなりますね。その他主に気になった点として、以下挙げられると思います。

  1. Universal Fetch対応、ビルトインにnode-fetch、fetch polyfill
  2. nuxt.config.jsにPromiseが入った。
  3. .nuxtignoreファイルがサポートされた。
  4. Unitテストで気軽に動作確認できるようになった。
  5. NuxtでTSサポート本格化。nuxt-tsが使えるようになった。

私自身TSサポートしか知らずでしたが、色々新しい発見があり非常に興味深い話でした。

Re:ゼロから始めるNuxt生活

speakerdeck.com

株式会社nana musicでサーバサイド中心に開発を行っている角谷さんの発表でした。音楽アプリのリプレースについての話、SEOに貧弱であったことや、Python2という今では考えられない古いバージョンを解決するため、今回Django + Nuxtを採用。Vuexは便利な反面、メンテされていないtypescript-templateを使わないと言った話でした。

Web猫ブログで問い合わせにFirestoreを採用した話

master.d15419h4sw4nyx.amplifyapp.com

自ら登壇させていただきました。去年秋より関西エリアを中心に登壇、メキメキと露出を増やしています。今回ミートアップ開催1時間前になって初めて、資料を作るという手際の悪さは反省の一つでしたが、NuxtとFirestoreを使ったスタートアップの事例、あえてVuexを採用せずに作ったことなど、参考になれば幸いです。

NuxtとTailwind.css

slides.com

急遽一人LTのキャンセルが出て、10分で作ってくれました。弊社石岡の発表、FABRIC TOKYOのリプレースした話でした。UIフレームワークにこだわった時の変更や、クラス名を考える時の辛さを払拭するため、Tailwind.cssを採用。私も機会あればこの「天才的な」CSSフレームワークを使ってみようと思います。

最後に、

SCOUTERではエンジニア、デザイナーともに募集しております! 新規事業、絶賛グロース中の事業ともにLaravel, Vue.jsで開発しておりますので、 興味のある方はお声がけください!

www.wantedly.com

www.wantedly.com

www.wantedly.com

Laravel JP Conferenceでスポンサード&IRT&登壇しました

こんにちは kotamat です。 2019/02/16に行われたLaravel JP Conferenceにてゴールドスポンサーと、IRT、登壇をさせていただきました!

f:id:kotamat:20190218112333j:plain

conference2019.laravel.jp

IRT

午前中の時間を使い、「Vue.js と Laravel の相談会」というテーマでInteractive Round Tableを開催させていただきました。

他のセッションのほうがかなり魅力的だったのか、人数的に時間を区切って相談会をするのが難しかったので、都度都度相談をするような形で相談会を行いました。。

スタート時間では、ytakeさんも参加されていました。

Laravel と Vue.jsは親和性が高く、今回の発表でもVue.jsに言及されているものも多かった印象でした。 そのためトピックとしては非常に多いため、一つのテーマで20分話すものより様々なトピックに関してお話することができ、そういった意味では良い結果になったかなと思います。

登壇

登壇した内容はこちらです。

slides.com

前回のPHPカンファレンスで話した内容と若干かぶっているところもありますが、DXの面やアーキテクチャの面等で工夫したところをご紹介させていただきました。 細かい話になると非常に長くなってしまうので、アウトラインの紹介 + Ask The Speakerの方で話をする感じのスタイルにしたのですが、早口で話ししてしまったのか結構時間余ってしまったので、もうちょっと詳しく話しても良かったかなぁと思っています。

まだまだDXの向上はする余地があると思っているため、今後もいろいろなチャレンジをして開発スピードを今後も上げていこうと思っています。

カンファレンス全体を通して

Laravel JP Conferenceは今年限りというところでしたが、セッションの内容もそれぞれ非常に面白く、どのセッションを聞きに行っても満足度が高い会だったなと思っております。 特にカンファレンスの運営メンバーのホスピタリティーが高く、これほどスポンサーに対しても登壇者に対しても参加者に対しても気配りのできるカンファレンスは珍しいなと思いました。

今年はPHP系のカンファレンスも非常に多いため、PHPユーザが今後も増えていくといいなぁと思っております。

一日中喋ったので、しばらくは休養させていただきます。

最後に

SCOUTERではエンジニア、デザイナーともに募集しております! 新規事業、絶賛グロース中の事業ともにLaravel, Vue.jsで開発しておりますので、 興味のある方はお声がけください!

www.wantedly.com

www.wantedly.com

www.wantedly.com