土曜：5h

フロントのモックで詳細検索をするのにハマった
結局以下のようになった

server.get(new RegExp(`/api/v1/projects/id_*`), (req, res) => {
  let result = null
  const id = req.url.match(/[^/]+$/i)[0]
  const dbObj = Object.assign(db)
  Object.keys(dbObj).forEach((key) => {
    const detailPrj = dbObj[key].find((element) => element.id === id)
    if (detailPrj) {
      result = detailPrj
    }
  })
  res.jsonp(result)
})

整理したら割と簡単な作りだった。。。。

土曜はgoの日

システムトレードのAPIだけどせっかく作るならマイクロサービスにしたくてgRPCをインプット

RESTとgRPCの違い

RESTがリソース志向（リソースに対してHTTPメソッドで操作していく考えかた)に対してRPCはメソッド志向もしくはサービス志向

gRPCはHTTP/2を採用（RESTはHTTP/1.1）

HTTP/2はコネクションを張りっぱなし。要は速い

Protocol Buffers

protoファイルというIDL（インターフェース記述言語）を書いてコンパイラを実行すると任意の言語のサーバ／クライアント用コードを自動生成してくれる
自分でAPIインターフェースを実装したり、シリアライズされたデータのエンコード／デコード処理を書く必要がない
スキーマを最初に書く(そのためAPI仕様書が古くてフロントエンドの人たちが怒ることがなくなる）
protoファイルは静的型付け
- 各言語のコード生成時に適切な型へ変換される（C++,Java,Python,Go,Ruby,PHP,C#,Node.js,Andoroid Java,Objective-C, Dart, などに対応）

gRPCのデメリット

HTTP/2非対応である危険性（AWSのALBは非対応）←リクエストを受け付けることはできるが、バックエンドのサーバへの転送をHTTP/1で行うため
↑同様に通信経路上でHTTP/2に非対応なサービスがある場合にgRPCを使う上で問題が生じる
ブラウザの対応状況が不十分

SPAとの相性はRESTに分がある

しかし、フロントエンドとバックエンドの間にgraphQLを挟むといい感じになるようだ

graphQLも少し見てみたが、フロントエンドは複数の言語で実装されている膨大なAPIを仕様等を意識することなく呼べるようで相当なメリットがあると感じた
対してバックエンド側はメリットがよくわからなかった

日曜：5h

webstrom矩形選択：option + option押したらカーソルで選択可能
docker
volumesにapp/node_modulesを記述するのはなぜかを考えていた
- ホスト側でyarn installしていないとnode_modulesは空だからホスト側をマウントしないようにしているみたい
ただ、そうしたらIDEなどの補完が効かなくなるのではと思った。
- 解決策としてdockerコンテナの中でyarn install したものをホスト側に持ってくる手法があるらしい

castaneai.hatenablog.com

月曜

jestでエラーハンドリングテスト

it('should throw error status 400', async () => {
    store.commit('setQrCodeObj', {})
    store.commit('setAgencyCode', 'A99999999')
    store.commit('setCrewCode', '0000000000')
    // mockを用意
    mock.onPost('api/systemAdminCertify').reply(400, systemAdminCertifyResult.RESULT_NG)
    try {
      await store.dispatch('certify')
    } catch (e) {
      const error = JSON.parse(e.message)
      expect(error.errorObj.response.status).toBe(400)
    }
  })

try/catchでやったら簡単だった（errorがjsonで来るからparseしてる）

caprese

qsて何に使ってるのかわからなかったけど、オブジェクト→クエリだったりクエリ→オブジェクトに変換するやつだったんだ・・・
例えば、APIのアクセストークンの再取得をcurlでやろうとすると

curl 'https://securetoken.googleapis.com/v1/token?key=APIキー' \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data 'grant_type=refresh_token&refresh_token=既存のトークン'

で、ソースコードにすると以下のようにqsを使いオブジェクトをクエリに変換してからリクエストを投げることができる

      if (refreshToken) {
        const data = {
          grant_type: 'refresh_token',
          refresh_token: refreshToken
        }

const res = await this.axios.$request({
          method: 'POST',
          headers: {
            Authorization: '',
            'Content-Type': 'application/x-www-form-urlencoded'
          },
          data: qs.stringify(data),
          url:
            'https://securetoken.googleapis.com/v1/token?key=' +
            process.env.YOUTUBE_API_KEY
        })
}

アクセストークンとリフレッシュトークンの認識についてちょっと誤解していた

auth0.com

火曜：11h

goの日
- とりあえずリアルタイムで株価情報取得まではいったよ
- コレからはissue管理しよう
- goの静的解析ツールを試す

github.com

水曜：

スクロールについて

今日はイベント系の勉強になった
以下はtouchmoveイベントとtouchendイベントを制御してスクロール

this.scrollElement = document.getElementById('campaign-inner')
    this.scrollElement.addEventListener('touchend', (e) => {
      this.previousY = undefined
    })
    this.scrollElement.addEventListener('touchmove', (e) => {
      console.log('touchmove')
      e.preventDefault()
      if (!this.previousY) {
        this.previousY = e.touches[0].clientY
      } else {
        const moveY = e.touches[0].clientY - this.previousY
        const newY = this.scrollElement.scrollTop - moveY
        this.scrollElement.scrollTop = newY
        this.previousY = e.touches[0].clientY
        this.scrollBottom = this.scrollElement.clientHeight - this.scrollElement.scrollTop
        if (this.scrollBottom < 20) {
          this.$store.dispatch('data/condition/updateScrollValidationOfCampaign', true)
        }
      }
    }, { passsive: false })

木曜：

APIへアクセスするときのクエリーの作成
Objectの中にhoge: "hoge"みたいに入っている

const queryString = Object.keys(params)
      .map((key) => key + '=' + params[key])
      .join('&') // ②
    const query = queryString.length > 0 ? `${uri}?${queryString}` : uri

週次報告

年間（2019/8~2020/8）目標時間（業務での設計・実装含む）：3380h
今週を含む累積時間：2730h
週次目標時間：65h
週次実績時間：65h
何を得たか：flutter基礎・capreseデプロイ検討・関数型プログラミングおさらい
何が必要か：golang基礎・認証の知見・Nuxt・React・テスト手法の取得・k8s基礎
来週の目標：k8s,golang進める

自分による自分のためのブログ

6月3週

土曜：5h

土曜はgoの日

システムトレードのAPIだけどせっかく作るならマイクロサービスにしたくてgRPCをインプット

RESTとgRPCの違い

RESTがリソース志向（リソースに対してHTTPメソッドで操作していく考えかた)に対してRPCはメソッド志向もしくはサービス志向

gRPCはHTTP/2を採用（RESTはHTTP/1.1）

HTTP/2はコネクションを張りっぱなし。要は速い

Protocol Buffers

gRPCのデメリット

SPAとの相性はRESTに分がある

しかし、フロントエンドとバックエンドの間にgraphQLを挟むといい感じになるようだ

日曜：5h

docker

月曜

caprese

アクセストークンとリフレッシュトークンの認識についてちょっと誤解していた

火曜：11h

水曜：

スクロールについて

木曜：

週次報告