画像を投稿した後にレポートを出す

レポート

自作アプリで写真を投稿後に今の集計値を確認したくてページ遷移することがあり不便だったので投稿後に集計を表示するように変えた

デプロイしてから、数日使って見ている感じストレスが減ったので実装してよかったです。　　 この前進捗状況を表示するように変えたけど、それも表示したい。

履いた靴の進捗状況を表示するようにした

靴をできるだけ均一に履くようにしていると、どれが今月履いたのかわからなくなるので、ダッシュボードに進捗を表示するように変えてみた。

進捗状況

ダッシュボードには履いてない靴を4件リストに出していたけど、後どのくらい残っているのかはわからなかったので結構不便だった。

なのでリファクタリングのついでに新機能として追加してみだけど、結構便利。

大体毎月2回はループするので、今何周目とかも追加したい。
もしは進捗バーの色変えるとか。

loadable-componentsのheroku対応

loadable-componentsを使用していて、Server side renderingをheroku環境で行う場合ビルドされるloadable-stats.jsonのパスが実行環境と違うため、chunkファイルが読み込めないという問題があります。

これはビルド時は​​­/tmp/build_[id]/​のようなテンポラリディレクトリに成果物が出力されるが、実際のファイルは/appの下に配置されるため、パスが参照できなくなる為です。

この為ローカルでは正常に動いても、heroku環境ではファイルの読み込みエラーが発生します。

import * as path from 'path';
import { ChunkExtractor } from '@loadable/server';

export const statsFile = path.resolve('./dist/loadable-stats.json');

export const nodeExtractor = new ChunkExtractor({
  statsFile
});

これを回避するには、ChunkExtractorのオプションにpublicPath、outputPathを明示的に指定します。
通常この設定はloadable-stats.jsonの指定を参照するのですが、オプションを指定してあげるとそちらを使用します。

import * as path from 'path';
import { ChunkExtractor } from '@loadable/server';

export const statsFile = path.resolve('./dist/loadable-stats.json');

export const nodeExtractor = new ChunkExtractor({
  statsFile,
  publicPath: path.resolve('./dist/'), // statsファイルのpublicPathの代わり
  outputPath: path.resolve('./dist/'), // statsファイルのoutputPathの代わり
});

こうすることで、サーバー側でchunkファイルを読み込めるようになるので、正常にレスポンスを返せるようになります。

アンクルバンド買ってみた

アンクルバンド

春夏に向けてワイドパンツを買ってみたのだけど、裾が踵の方が長くなるようなデザインでした。
パンツを履くと引き摺りそうになるので、対策としてアンクルバンドを買って見ることにしました。

アンクルバンドは自転車とかに乗るときに裾が邪魔にならないようにするバンドです。

買ったのはHUKUROのアンクルバンド、色は茶色にしてみました。
ゴムで伸縮するのでフィット間は良いです。

試しに6inchブーツで歩いてみましたが特に違和感なく歩けました。

他の色のものも買ってもいいかもしれない。

自分で運用しているアプリケーションのログイン後のダッシュボードを改善した

自分で履いた靴の記録するアプリケーションを運用していて、ずっとダッシュボードに写真の投稿ボタンしか置いていませんでした。

理由は特に表示させたい情報がなかったためです。
ログインせずとも公開している情報があるので今までは特に困ってなかったのです。

ダッシュボード

しかし、特に偏りがでない様に均等に靴を履くというライフスタイルをとっていて、どれがあまり履けていない 靴なのかを把握するのが大変という問題がありました。

回数は公開しているので見ていけばわかるんですが、靴が30足以上あるのでページを跨がないとわからなかったりして結構不便だったのです。

なのでダッシュボードに表示する様にして、レコメンドのような形が取れないか試してみました。
表示する内容は一月単位で履いている回数が低いものを4件だけ表示する様にしました。

優先順位は今月全く履いていない靴、現状履いている回数が少ない靴の順番で表示しています。

1月から１ヶ月位運用していて全く履かない靴はなくなり、最低一月に一回は履くようになりました。
また、ただ表示しているだけなので強制力もなく6割位表示されている4件以外の靴を履いても達成できました。

「今日はこれを履きたい」と「明日は表示されている4件のうちどれか履いてもいいかな」という気持ちのバランスが丁度いいのかもしれません。

Victoryのアップグレード

Victory

個人で運用しているアプリケーションでグラフライブラリのVictoryを使っていてバージョンが古くなっていたので32.3.x から35.4.xにあげてみました。
大きく仕様に変化はなかったようで、型エラーを直していくだけで対応が完了しました。

VictoryLine

線のスタイルやラベルのコールバックの仕様が変わっている様です。

• strokeDasharray が配列ではなくなっていて、型としては StringOrNumberOrCallback に変更されている。
• labels のコールバックの値がデータではなく、lineのオブジェクトになってる。

import { VictoryLine } from "victory";

const dottedLine = {
  data: {
    strokeDasharray: 1, // StringOrNumberOrCallbackになったので[1, 1] みたいなしてはできない
  }
};
const barData = [{ x: 1, y: 1 }];

// 前の様にしたければdatumに置き換える
const lineLabel = (value: { datum: { x: number; y: number; } }): number | null => {
  return (value.datum.y > 0 ? value.datum.y : null);
};

<VictoryLine style={dottedLine} data={barData} labels={lineLabel} />

VictoryChart

domainPaddingの型指定が変わった様です。

export type PaddingType = number | [number, number];
export type DomainPaddingPropType =
  | PaddingType
  | {
      x?: PaddingType;
      y?: PaddingType;
    };

値をリテラルで指定していたので、[0, 15] みたいな指定が number[] で解釈されていました。

import { VictoryChart, VictoryBar } from "victory";

const domainPadding = {
  x: [15, 15] as [number, number], // 型指定はDomainPaddingPropTypeなので
  y: [0, 15] as [number, number],
};
const barData = [{ x: 1, y; 1 }];

<VictoryChart domainPadding={domainPadding}>
  <VictoryBar data={barData} />
</VictoryChart>

VictoryAxis

grid.strokeのコールバック関数の引数が変わった様です。
strokeのコールバックはtickの値が引数になっていたので、args: CallbackArgsに置き換えました。

import { CallbackArgs } from "victory-core";
import { VictoryAxis } from "victory";

const valueTicks = [0, 5, 10, 15, 20];

const valueAxisStyle = {
  grid: {
    stroke: (args: CallbackArgs) => (args.tick === 0 ? colorTransparent : axisAndTickColor),  // 前はtick: numberだった
  },
};

<VictoryAxis dependentAxis tickValues={valueTicks} style={valueAxisStyle} />

GitHub ActionsでMongoDBのレプリカセット設定を行う

GitHub ActionsでMongoDBのレプリカセットを使用してテストを実行する方法を調べました。
docker-composeを使ってもよかったのですが、mongodb-github-actionがあったので試しに使用してみました。

パラメータとしては下記の2つのものが指定できるようです。

• MongoDBのバージョン
• レプリカセットの名前

バージョンとレプリカセットの名前しか指定できないので、接続URLにユーザー名などが指定されている場合接続できないので注意が必要です。

試したURLを載せておきます。

MONGO_URL=mongodb://localhost:27017/test?replicaSet=replset

docker-composeなどでローカルでコンテナを起動している場合はMONGO_INITDB_ROOT_USERNAME、MONGO_INITDB_ROOT_PASSWORD、MONGO_INITDB_DATABASEなどを設定ファイルで指定することが多いので、これはこれでサクッと試せるのでこれはいいかなと思いました。

ただし、レプリカセットのメンバーは1つだけなので、複数ある場合のテストがある場合は今のところ使えなさそうではあります。

最後に.github/workflows/node.js.ymlの設定を載せておきます。

name: Node.js CI

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main, develop ]

jobs:
  build:

    runs-on: ubuntu-20.04

    strategy:
      matrix:
        node-version: [14.8]
        mongodb-version: [4.2]

    steps:
    - name: Git checkout
      uses: actions/checkout@v2

    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node-version }}

    - name: Start MongoDB
      uses: supercharge/mongodb-github-action@1.3.0
      with:
        mongodb-version: ${{ matrix.mongodb-version }}
        mongodb-replica-set: replset

    - run: yarn --frozen-lockfile
    - run: yarn build
    - run: yarn test