
## intro

こんにちは、Shumpei[(@seventhseven)](https://twitter.com/seventhseven)です。

動的に要素数が変わってしまうオブジェクトの初期値をキャッシュしておきたいなんていう時、

変数化した配列に値を入れておいて、好きなときに取り出して使う方法です。


# オブジェクトをキャッシュする方法

1. オブジェクトの配列を用意する

```js
const itemArr = [
  {
    name: "mic",
    age: 16,
    gen: "male",
    params: document.getElementById("hoge")
  },
  {
    name: "drake",
    age: 20,
    gen: "male",
    params: document.getElementById("fuga")
  },
];
```

2. キャッシュ用の殻配列を用意する

```js
const cacheArr = [];
```

3. for文を回して任意の値をキャッシュ配列に入れていく

```js
function addCache(arr) {
  for (let i = 0; i < arr.length; i++) {
    cacheArr.push(arr[i].name(or age, pamars, etc...))
  }
};

addCache(itemArr);
```

もしくは。pushを使わずに、`cacheArr[cacheArr.length]`に代入していきます。

```js
function addCache(arr) {
  for (let i = 0; i < arr.length; i++) {
    cacheArr.push(arr[i].name(or age, pamars, etc...))
    cacheArr[cacheArr.length] = arr[i].name(or age, pamars, etc...);
  }
};

addCache(itemArr);
```



## 使い所

例えば初期値と現在のパラメータの比較で使えるかと思います。

スライドショーで、最初は１枚しか表示してなかったけど、

動的に増えたから矢印ボタンを表示させる…とかだと使えるかも。

## ワンポイントメモ

個人的には、最後の`addCache`としている関数は、`name`なら`addCacheInitName`などにして、

もう少し具体的な名前にします。

また、取得したいパラメータが２つ，３つくらいであれば、

それぞれパラメータ毎に分けて`addCacheInitAge`とか`addCacheInitParams`も作っておきます。

そうしておくと、それらをラップしておく関数を作っておけば修正がしやすくなります。

```js
function addInitCacheItems() {
    addCacheInitName();
    addCacheInitAge();
    addCacheInitParams();
}
```

こんな感じにまとめてあげると、関数の呼び出し順を変えることも簡単ですし、

ひとつだけ関数を消したり、あとから付け足すことも難しくないからです。

そしてこの`addInitCacheItems`関数も、例えば`initApp`みたいな一番大きい関数の１つのルーチンとして登録しておけば

取り出しやすいですね。

【JavaScript】オブジェクトの特定の値をキャッシュしておきたい


## intro

こんにちは、Shumpei[(@seventhseven)](https://twitter.com/seventhseven)です。

今回の話は、例えばタブUIを作るときなんかで使えるかもしれないです。

ラジオボタンをv-modelで捕捉しておいて、現在どのタブが選択されているかを確認します。

また、v-forで動的にリストを取得してUIを構築するときに使えるかなと考えています。


# コード

具体的にはこんな感じです。

## Vue側
```js
data: {
  choosed: ""
  list: [
    { id: 1, name: "a", val: "b" },
    { id: 2, name: "c", val: "d" }
  ]
}
```

## テンプレート側
```html
<ul>
  <li v-for="item in list" :key='item.id'>
    <input type="radio" name="sample" 
      v-model="choosed" :id="item.name" :value="a.val">
    <label :for="item.name">{{ item.val }}</label>
  </li>
</ul>
```

---

別に特別なことはしてないですが、これを作ってCSSでラジオボタンを`display:none`で消すことで

labelをタブUIを書けば完成です。

また、表示はされていないものの、ラジオボタンとlabelタグはfor属性で紐付いているので、

CSSは`radio:checked`が有効になります。

つまり、選択状態が取得できるので、選択中のスタイルも設定することが可能です。

【Vue.js】v-forで作ったリスト内のラジオボタンをv-modelでチェックする


## intro

こんにちは、Shumpei[(@seventhseven)](https://twitter.com/seventhseven)です。

今回はURLパラメータをJSで作る際、**filter**、**map**を使用するパターンを紹介します。

今まで頑張って文字列と変数を使って作っていたのですが、

先輩と開発していたときにその先輩がこう書いていて、初めて見た時、「なるほど、読みやすくてこっちがいいじゃん！」となりました。

とても気に入っている方法です。


# URLパラメータをJSのfilterとmapを使って作る

具体的にはこんな感じです。

```js
const targetUrl = '../index.html?' + [
    ['paramA', code],
    ['paramB', Config.settingA && settingAKey],
    ["paramC", Config.settingB && settingBKey && isStatus('hoge')],
    ['paramD', Config.settingC && settingCKey && fugaStatus]
].filter( function( p ) {
    return !!p[ 1 ];
} ).map( function( p ) {
    return p.map( function( v ) {
        return encodeURIComponent( v.trim() );
    } ).join( '=' );
} ).join( '&' );
```

## ざっくり解説

```js
const targetUrl = '../index.html?' + [
    ['paramA', code],
    ['paramB', Config.settingA && settingAKey],
    ["paramC", Config.settingB && settingBKey && isStatus('hoge')],
    ['paramD', Config.settingC && settingCKey && fugaStatus]
]
```

まず、取りうるパラメータを配列内配列で用意します。

また、**paramB**〜**paramD**のように条件を設定して、trueならパラメータとして有効にしたいものを設定します。

```js
.filter( function( p ) {
    return !!p[ 1 ];
} )
```

次にfilterを噛ませます。

これは最初の配列内配列の中で、各１番目の値がtrueならfilterを通ります。

つまり、パラメータとして追加されることになります。

また、値の前に`!!`をつけると真偽値を返してくれるようになります。

```js
.map( function( p ) {
    return p.map( function( v ) {
        return encodeURIComponent( v.trim() );
    } ).join( '=' );
} ).join( '&' );
```

**map**が２回使われています。

外側のmapは、filterで通ってきた配列（パラメータのペア）に対してループ処理を行います。

内側のmapは、上記で取り出された配列をキーと値をそれぞれ分解して処理を行います。

```js
p.map( function( v ) {
        return encodeURIComponent( v.trim() );
    } ).join( '=' );
```

引数vはvalueという意味です。

`encodeURIComponent`でエスケープしてセキュリティ対策を行います。

v.trim()で余計な空白を取り除きます。

そして最後にjoinで「`キー=値`」としてパラメータとして組み立てます。

```js
} ).join( '&' );
```
そして最後に内側のループで作ったパラメータのペアが複数あるので、`&`で繋いで完成です。


【JavaScript】URLパラメータをfilterとmapを使って構築する


## Intro

エンジニアに転職して丸2年が経ちました。

普段やろうやろうとしてできていなかった今年の振り返りを、

思い出せる範囲でやっていきたいと思います。

振り返る内容に関しては主に経験した技術についてと、

自分の環境の変化について出てくればそれについても書いていこうと思います。

---


# 技術について振り返る

## 業務で経験した技術

### フロントエンド

- jQuery
  - slick
- Vue.js 2.x系
  - VueCLI 3.x系
  - webpack
  - babel
- Adobe XD
- Velocity(Java)

### サーバ・バックエンド

- IIS
  - cgi
- node.js
- apache
- WordPress
- AWS
  - EC2
  - ALB
  - S3

### 開発環境

- VSCode
- eclipse
- vim
- git
  - tig

## 個人開発で経験・勉強した技術

### フロントエンド

- Vue.js 2.x系
  - Vuex
  - Nuxt.js
    - Nuxt/content
- react.js

### サーバ・バックエンド

- Firebase
  - Firestore
  - Firebase hosting
  - Firebase Cloud Function
- Netlify
- mixhost
- Docker

- PHP 7.x系
  - Laravel
- MySQL

- LINE BOT

### 開発環境

- VSCode
- git
  - tig
  - Github
- MAMP
- XAMP

---

ざっとこんな感じでした。

今年の学習計画の一つとして、

- 勉強する範囲を絞る
- なるべくJSを書く

ということを決めました。

技術の世界はとんでもなく広く、

Webだけでもデザイン、フロント、バックエンド、インフラ…と多岐にわたりますし、

自分の性格上、飽き性なので色んなものを作ってみたいと思ってしまうので、

なるべく勉強範囲を絞って絞っていこうと考えました。


## どんな一年だったか

## 業務

基本的に業務ではフロントに比重を置いた開発をやらせていただきました。

JSに関しては、Vanila.js、jQuery、Vueのどれかを使いました。

既存のサービスに組み込むペライチのページを作ったり、

プロトタイプとしてのサービス提供を行うため、フロント部分の開発に携わることが多かったです。（現在も開発しているものがあります）

メインのドメインがBtoBなので、ツールとしてのWebアプリを開発していますが、

実際使うユーザは年齢層が高いので、IE9とかでも動くことを考えなくてはいけないことも多く、

巷で流行っているキラキラWeb系自社開発とは全然違う領域にいます。

### リニューアル

Velocityで作られたPC用の画面しかないサイトについて、

CSSメインでスマホでも見られるように頑張るという案件もやりました。

自社製CMSで作られたものを解読しつつ、メディアクエリで頑張る感じなのですが、

ところどころiframeで呼び出されているコンポーネントがあり、いい経験でした。。

### 職場の雰囲気

アサインされる人間はフロント1人、バック1人か、

もしくは1案件1人で開発することがほとんどの弊社なので、

サーバを書くことはあまりないにせよ、環境構築などは聞きながらでも自分でやらないといけないことも多かったです。

続けていけば、否が応でもフルスタックになっていくような感じです。

幸い、先輩方は優しいので色々教えていただけるので、なるべくメモっています。

コロナでリモートワークしているので、気持ち的には楽な部分も大きいです。

ただ、コミュニケーションコストは高いと感じるときもあります。

慣れていない…と言われたらそうかもしれませんが、

やはり対面での会話で得られる情報とは差があると感じています。

## 個人開発

### 2020年前半

**いきなりフロントエンドではなくなるのですが…**

個人的に懇意にしている[いけしん](https://twitter.com/_ikeshin)さんの私塾でデータベースの勉強を行いました。

エンジニアになってから特に勉強会とかは興味がなくて行ったこともなく、

淡々と過ごしていたのですが、トークを聞きに行ったことがきっかけで入塾しました。

データベースについて、ほとんど知識がなかったので、

エッセンスだけでもと思い、オンラインでの参加を続けました。

子育てしながらのオンライン参加だったので、なかなか難しいところもありましたが、

データベース以外にも業界にいる肌感覚などの話が聞けたので、

自分が所属している会社とは別の面から見ることでよかったなと思っています。


また、私塾とは別でサロンもあったので参加しました。

サロン内でPHPとMySQLを使用しての予約システムのWebアプリ開発を学んでみました。

この事をきっかけに、今でも仲良くしていただいている方たちに巡り会えたので、

とてもよい経験になりました。


### 2020年中盤

主にハンズオン本などを使って、バックエンドはFirebaseを使ってのサンプルアプリや、

ちょっと試してみたいAPIを使って遊んでみることが多かったです。

また、このくらいの時期にDockerも触ってみましたが、

Docker Composeからのお試しな感じだったので、

コンテナ技術の深いところまでは全然到達はできませんでした。

前半で作ったPHPのアプリはVueとフロント部分を置き換えることができないかとか、

VueとFirebaseでSlackコピーしてみたり、

Laravelを使ってのLINE BOT作ったりしてました。


### 2020年後半

9月頃からNuxtが気になりだして、Wordpressみたいにテーマを作ってみようと思って、

プロトタイプ的に開発をはじめました。

業務や個人てもVue.jsで書いていたので、Nuxtを選択してプログレッシブフレームワークとなるものを経験することができました。

今回はcontentを使って記事を投稿するという形を取りましたので、

SSGで静的にビルドしたものを配信しています。

また。Nuxで作るとVue単体でやるよりかなり簡単にページが作れてしまうことに感動しました。

一応、自分の運用しているメディアサービスを作ってリリースまで持っていき、

順次開発を進めつつ毎日アップデートと記事の投稿を行っていたのですが、

Twitter運用の仕方が悪く、スパム判定をうけてアカウントが凍結してしまいました。

ログインはできるもののその他何もできない状態になってしまったので、

新しくアカウントを作ってはみたものの、気持ちが萎えてしまいました。。。

ただ、60記事ほど投稿したので、閉鎖は見送っています。


### 7月は入院してた

奥さんが職場復帰直後のクッソ大変なときに1週間入院してました。。。

時期的に業務でアプリを開発しているうちに、

もっと設計して作って直しやすいようにしたいという気持ちが強くなっていたので、

入院中はオブジェクト指向を学んでいました。

PCが持ち込めたので、先輩のコードを見つつ、モジュールパターンを意識してみたり、

なるべく安全にやるベーシックな方法を書いたりして手を動かしてました。

エンジニアになった頃よりはちょっと違うコードが書けるようになった気がします。



## 成果

まともに個人でリリースに至ったのは１つでした。

9月ごろから作っていた、Nuxt製のブログです。

開発自体は時間をかけてかなり力を入れていましたし、その分Nuxtを理解することができました。

中〜大規模になりそうなサービスを作るなら選択肢として今なら候補になるという意味も理解できました。

業務で一番始めに作ったWordPressのサイトも、

今であればWordPressは選ばずNuxtか、別の案を考えると思います。


## 展望

来年2021年はReact、TypeScriptをやっていこうと思います。

UdemyやBoothでいくつか教材を買っているので、それを使って勉強していきたいと思っています。

また、Twitter絡みの作りたいアプリがあります。

とりあえずAPIの申請だけ通っていますが、まだ設計などはちゃんと出来ていない状態です。

こちらはFlutterもやりたい欲があり、Webアプリで行くかスマホアプリで行くか悩んでいます。。

とにかく、まだまだ学ばなければいけないことも多いので、

来年もサービス開発もしつつ、スキルも磨きつつな1年になるかと思います。

2020年の振り返り


# ポイントの管理を行うDBの構造はどんなものがあるか

・グループM
　　↓
　・店舗マスタ
　　　↓
　　　・ポイント利用テーブル

・ユーザM

## なぜグループマスタが必要か

例
---
ワタミ（グループマスタ）
↓
→東京店
　↓
　・3/1
　・3/20
→横浜
　↓
　・3/5
　・3/6


---

## 基本的なポイントの動き

- 売上 → 加算
- ポイント消化 → 減算
- ボーナス、キャンペーン → 加算

---

ワタミ（グループマスタ）
↓
→東京店
↓
→横浜店

つぼ八（グループマスタ）
↓
→東京店
↓
→横浜店

店同士は互換性があるが、企業が異なる場合をあとであわせて管理することになったとき...

例：ワタミ→100p、つぼ八→80p

これの互換性、コンバートをしやすくするときは、店舗マスタではなく、グループマスタとして管理しておく

# 発展形

グループマスタの上に「業種マスタ」を追加してもよい

薬局グループでためたポイントを、居酒屋でポイントを使いたいなどの変更が可能

```
居酒屋→ワタミ（グループマスタ）
      ↓
      →東京店
      ↓
      →横浜店

居酒屋→つぼ八（グループマスタ）
      ↓
      →東京店
      ↓
      →横浜店

-----------------------------------

薬局→HAC（グループマスタ）
      ↓
      →東京店
      ↓
      →横浜店

薬局→スギ薬局（グループマスタ）
      ↓
      →東京店
      ↓
      →横浜店
```

ポイントのレートを意識するとき、店舗マスタにレートをもつほうが適切かも検討する

# どうやってマネタイズするか

このアプリ導入についてはQRコードで配布

**Webサイト**
持ち込み
↓
専用のQR表示
↓
使用可能（システムは使える・ポイントは貯められるけど、セキュリティ的に使うことはできない）
ーーー仮審査おわりーーー
↓
本審査
↓
OKならレート交換


---

入力部分はデータベースとは関係ないけど一番むずかしいところ。

ペイペイは手入力を許したことで勝てた

入力
- POSレジ連携
- 手入力


---

自分が何をやりたいのかから考え始める

---

- 手入力の不正を防ぐ

例：id, shop, data, pointカラム以外、ランダムな16桁の数値（可逆的なハッシュ値）

ハッシュ値はid, shop, data, pointをキーに生成し、

変更が不正なものの場合、このレコードを無効にする対策を行う

**ハッシュ値を深くすると激重になる**

---

レコード数が爆発的に多くなるのでスピードをだすときは

id | user | shop | data | point
-- | -- | -- | -- | -- |
1 | 100 | 50 | 0318 | 10000
2 | 101 | 70 | 0318 | 700
3 | 130 | 30 | 0318 | -100
4 | 100 | 50 | 0319 | -560

ind...1
user
shop
date


ind...2
user
date
shop

id | user | shop | data | hour | time | point
-- | -- | -- | -- | -- | -- | -- |
1 | 100 | 50 | 0318 | 09 | 19 | 10000
2 | 101 | 70 | 0318 | 11 | 05 | 700
3 | 130 | 30 | 0318 | 12 | 34 | -100
4 | 100 | 50 | 0319 | 18 | 30 | -560


ある日の何時から何時までの売上を管理するとかだと、時間も切り出してレコードに保存する

計算はデータベースに計算させないほうがいい場合もあるので、アプローチは考える必要がある

インデックスをはるのは最低限にする（メモリ食う）

どういう集計するかでインデックスや工夫の余地がある

---

# アンケートについて考える

## アンケートを構成するもの

- 文字入力
- 文章入力
- 選択
  - プルダウン
  - 単一選択
  - 複数選択
- 他

## テーブル構成

### アンケートテーブル
- id
- アンケート名
- 回答期限
  - 回答期限From
  - 回答期限To
- 誰が


### アンケート本体テーブル
- id
- アンケートid
- 行番号
- 設問名
- 入力方法
- プルダウンなどの場合、選ばれた選択肢


### 回答テーブル
- id
- アンケート本体id
- ユーザid
- 回答


---

DBだけで集計するのは難しいので、SQLで吐き出したデータをプログラムで集計させるほうがこの構造だといいかも



ポイント管理・アンケート管理のDB


# テーブルを小分けにする

## スケジュールデータテーブル
- id
- 日付From
- 日付To
- 用件
- 場所

## 参加者テーブル
- id
- スケジュールid
- ユーザid

## 結果テーブル

スケジュールに参加して、どんな内容だったかを記録する使い方

例：打ち合わせ

- id
- スケジュールid
- 参加者id
- 結果内容

## 参加可否テーブル
- id
- スケジュールid
- ユーザid
- 可否フラグ

---

**各テーブルは最低限の情報を持っておくことで柔軟に対応できる**

上記の例
- スケジュールidがわかれば、参加者idがとってこれる
- スケジュールidと参加者idがわかれば、参加した人間と結果がわかる


---

# 繰り返しの要件の場合

毎日、毎週、毎月、毎年、決まった日、決まった曜日などを登録させるときのテーブル構造は...

## スケジュールデータ（改）
- id
- 親id <= 追加！
- ユーザid
- 日付

## 登録の仕方

| id | 親id | ユーザid | 日付 | 用件 |
| -- | -- | -- | -- | -- |
| 1 | null | A | 3/20 | --- |
| 2 | null | B | 3/21 | --- |
| 3 | null | A | 3/24 | --- |
| 4 | 1 | A | 4/20 | 1の繰り返し |
| 5 | 1 | A | 5/20 | 1の繰り返し |
| 6 | 1 | A | 6/20 | 1の繰り返し |




カレンダー機能のDB


# 弁当宅配サービスを例にとる
​
## 考える事項
​
- 賞味期限
  - ロットナンバー（製造番号）で管理
  - 基本的にリードタイムおよび賞味期限が短いものから先に出荷する
  - 何らかの理由で賞味期限が前後したものが納品される可能性を考慮する
  - 在庫のロス（廃棄）や納品物の不良があるので、賞味期限以外の在庫が減る理由が存在する
​

​
## DBの目的
​
- ロットナンバーで追跡したい
- 製造者責任
​
---
​
## 案
- 廃棄マスタは必要か？
  - きれいにやるならあってもよいが、工数を考えて注文テーブルの届け先カラムに「廃棄」、備考に廃棄理由を書いて対応するのも一手
​
### 注文テーブル
​
| id | 注文日 | 届け日 | 商品id | 数量 | 届け先 | ロットNo. | 区分 | 備考
| -- | -- | -- | -- | -- | -- | -- | -- | -- | 
| 1 | 200314 | 200316 | 1 | 4 | hoge | 200301 | 注文 | - 
| 2 | 200315 | 200316 | 1 | 2 | 2 | - | 廃棄 | 不良  
| 1 | 200316 | 200317 | 1 | 10 | fuga | 200301,200305 | 注文 | -


```
在庫数量の関係で、使用する在庫数によってはロットNoが複数またく可能性あり
```
​
### 入庫テーブル
​

| id | 注文id | ロットNo. | 数
| -- | -- | -- | -- |
| 1 | 1 | 200301 | 10
| 2 | 1 | 200301 | 20
| 3 | 1 | 200305 | 10
| 4 | 1 | 200301 | 5​

```
ロットNo（賞味期限）が前後して入荷する可能性がある
および、賞味期限が短い方から出荷する必要がある
```
​

### 商品マスタ

| id | 品名 | カロリー | 材料
| -- | -- | -- | --
| 1 | 惣菜 | 200 | きゅうり、にんじん
| 2 | コロッケ | 430 | じゃがいも​




## 処理速度を考えなかったら
​

1. まずロットナンバー順に納品される
1. 注文データを見て出荷する
1. 在庫が増減する
​
​
---
​
- 商品マスタ

| id | 品名
| -- | --
| 1 | ハンバーグ
| 2 | カレー
| 3 | ラーメン


​
- 入庫データ（工場から倉庫）

| 日付 | 商品id | ロット | 数
| -- | -- | -- | --
| 0314 | 1 | A0314 | 100
| 0314 | 2 | B0314 | 100
| 0314 | 3 | C0314 | 100


​
- 出庫データ(注文データ)

| 日付 | 商品id | 数 | 届け先 | 届け日
| -- | -- | -- | -- | --
| 0314 | 1 | 10 | - | 0316
| 0314 | 2 | 10 | - | 0316


---


# DBについての考え方

検索、並べ替えのときに使う情報を保存する

SQLに色々とやらせる宗派と、SQLは極力シンプルにしてプログラムに色々とやらせる宗派があるが、

後者の方が良いのではないかと考えている

---

# 課題

グーグルカレンダーをベースにどんなテーブル構造なのか想像してみる

## 作成したモデル

### Dateマスタ
- id
- Year
- Month
- Date
- 曜日
- timezone
- time

### スケジュールマスタ
- id
- start_date
- end_date
- f_終日
- f_loop
- loop_genre
- location
- f_video
- f_alert1~5
- alert_timing1~5
- user
- marker
- schedule_genre
- pub_setting
- memo
- created_at
- updated_at
- deleted_at
- f_guest
- guest_id
- guest_permission
- permission_setting

### カレンダーマスタ
- id
- name
- description
- time_zone
- created_at
- updated_at
- deleted_at

### ユーザマスタ
- id
- user_name
- email
- created_at
- deleted_at

### ユーザ設定マスタ
- id
- display_space
- color
- theme
...

### スケジュールジャンルマスタ
- id
- genre_name
- created_at
- updated_at
- deleted_at

### マーカーマスタ
- id
- marker_name
- color
- creadted_at
- updated_at
- deleted_at

宅配弁当を例にとってDBを考える


# DBとしての捉え方
常に与えられた命題は念頭に、
最終的な出力形態をモデリングに反映させなくてはいけない。

物事をデータベースとして捉えられるように身に着けなくてはいけない

## モデリングについて
- DBとしてどうやって捉えているか

## 化粧品の物流についてどのようにモデリングしたらよいか
### マスタ

キーはひとつでなくてよい（業務系に限り）

- 商品マスタ
  - 品名
  - JAN
  - 商品コード
  - 単価
  - 色
  - サイズ

- 仕入先マスタ

- 出荷先マスタ


idをシステムに任す

現場では商品コード、JANコードはユニークなキーになりえない
過去の0001と現在の0001は同じ商品をさしていない場合がある

これを防ぐには商品IDをキーに使うなど、シーンによってキーを使い分ける

論理削除フラグがたってるけどidがことなるけど商品コードが同じという状況が発生する

FWに任すと上記の不整合が起こり得る

FWの癖をわかりつつ使わないといけない

同じレコードがたくさんあってステータスがそれぞれ違うというのが起こっている


### ディメンショナルモデル

商品 | カテゴリ
-- | --
id | id
名前 | 名前
カテゴリid | 

それぞれ1万件あったら

先にカテゴリを絞ってから商品マスタにぶつけてみる
という手法

**遅いけど、正しい**

---

使うRDBによって手法がそれぞれある

目的に応じて作戦を練る必要がある

---

## 例：宅急便
- 送り状番号 13桁(12 + 合計値を7で割ったあまり)
- 届け先
- 送り主
- 品名
- 取扱（割れ物・天地無用・水濡れ厳禁）
- 温度帯（常温・冷蔵・冷凍）
- 支払い方法

送り状番号は自動裁判、送り主・届け先の営業所番号をひく
郵便番号は各社のテーブルから見る
支払い方法から送り状番号の生成ロジックは変わる

---

採番について

最終の番号をもっておけば、最後の番号までいったらの処理を決めておく

※同梱か同梱できないかもフラグで持っておく必要がある

処理済みフラグを複合キーとして持っておく

---

toCで数値化できないものを数値化させる難しさ

## 実際にどう組んだら良いのか

### 化粧品の場合

セット品なのか、単品なのか

セット品はバラしていいのかだめなのか

商品マスタの他にセット品マスタを用意する

ばらしていいものは1商品扱い

バラせないものはそれを1商品扱いとする

なるべくセット品マスタをメインにシステムを組んでいく

--

機能単位でテーブルのここを見るというのは苦しい

拝殿テーブルに受注伝票の中に拝殿No、
受注伝票テーブルに拝殿と受注No


# モデリング練習

化粧品のECサイト

仕入テーブル
商品テーブル
在庫テーブル
注文テーブル
赤伝テーブル
ユーザーテーブル

クロンでやるなら5分おき注文データを見て在庫を管理する
計算する対象を限らせるように

在庫計算の難しさ

在庫 ... 100
入庫 ... 20
出庫 ... 30
ーーーーー
在庫 ... 110
棚卸 ... 107
ーーーーー
在庫 ... 107
.
.
.
みたいなことがおきる


## 在庫

親TBL
ーーーー
親id
区分 ... 売・仕・棚


子TBL
ーーーー
子id
親id
商品id
数量 + -


## カテゴリー

一般的な例

---
1,

大分類、中分類、小分類でわける

- 大分類マスタ
  - id
  - 名前

- 中分類マスタ
  - 大分類id
  - id
  - 名前

- 小分類
  - 中分類id
  - id
  - 名前

---
2,

- カテゴリーマスタ
  - id
  - 親id
  - 名前

id | 親 | 名前
 -- | -- | --
1  | 0 | a
2  | 0  | b
3  | 1  | c
4  | 3  |  d

大中小で分類するときはこれがきれいかも

共通化のメリデメ
- バグが出ても一部分直せば

--- 

ECサイトを作るときに
どんなテーブルにどんなカラムがあるのか考える

それをヤフーショッピングやアマゾン、楽天にぶつけて動くか検証する

---

商品マスタ | カテゴリマスタ | 商品カテゴリマスタ
-- | -- | --
id | id | id
名前 | カテゴリ名 | 商品id
-- | -- | カテゴリid 
--  | -- | プライオリティ 

---

1対1でも1対nにしたとき対応できるように想定したテーブルを

結局こういうこと言ってくるよねっていうことを想像しておく

きっとこういうこと言ってくる

この業種ならこういうデータを欲してくるだろうという

---

人は3秒までは待てる

だいたいSQL自体は1秒くらいで返ってくるけど

表示に時間がかかっている

---

Googleを支える技術は読んだほうがいいと思う

---

# 最終目標
2000万件分のDBデータを一覧で表示するには

DBについて


> [Gulpの設定](/tags/gulp/)

フロントエンドエンジニアのShumpei[(@seventhseven)](https://twitter.com/seventhseven)です。

今回はMAMPで作った環境下のHTMLをGulpでホットリロード（自動でブラウザを更新）させる方法を書いていきます。

MAMPは、PHP・Apache・MySQLの実行環境をクリックだけで用意できるソフトです。
PHPmyAdminもついているので、これだけで簡単に始められちゃいます。

[MAMP](https://www.mamp.info/en/mamp/)


## 状況

MAMPでPHPの実行環境を用意して、HTMLテンプレートとしてPHPを混ぜて書いています。

その際、更新したら都度Cmd + Rでブラウザ更新してたのですが、
とても面倒でしたので、Gulpのブラウザシンクによるホットリロードでそのへん解消したいと思います。

### それまでの設定

今まで知っているGulpのホットリロードの方法は以下の通り。

```js
var browserSync = require("browser-sync").create();

// Browser Sync
gulp.task("server", function(done) {
  browserSync.init({
    port: 8000,
    server: {
      baseDir: "./dist/",
      index: "./html/index.html"
    }
  });
  done();
});
```

あとはwatchで更新を監視し、defaultで"server"タスクを設定…みたいなことをしていました。

> [参照：Gulp4のシンプルセッティング](/2019/07/10/gulp-4-setting/)


### 謎だったところ

ブラウザシンクのタスクの中に、ポートを設定するところがあります。

```js
browserSync.init({
    port: 8000,  <=== これ
    server: {
      baseDir: "./dist/",
      index: "./html/index.html"
    }
```

これは、Gulpが起動したら8000番のポートでアクセスできるようになるのですが、
MAMP自身のApacheは別の80番ポートで開いています。

なので、改めてポートを追加するみたいなことができないのではないか…と思いました。

実際、Gulp側のポートをMAMPで設定しているポートと同じ番号を書いたものの、
すでにMAMPが使っているのでアクセスできず。


## MAMPでのケースはこう書く

ポートの設定は行いません。

```js
// Browser Sync
gulp.task("server", function(done) {
  browserSync.init({
    proxy: "http://localhost:80/myproject/www/",
    reloadOnRestart: true,
  });
  done();
});
```

代わりに、`proxy`を使います。

`watch`と`default`の部分は以下の通り。

```js
// watch
gulp.task("watch", function(done) {
  gulp
    .watch("./www/**/*")
    .on("change", function() {
      browserSync.reload();
    });
  done();
});


// default
gulp.task("default", gulp.parallel("server", "watch"));

```

これだけでMAMPで作った環境下のHTMLファイルは更新されたら自動でブラウザをリロードできるようになりました。


MAMPで作った環境下のHTMLをホットリロードさせる


こんばんは、Shumpei[(@seventhseven)](https://twitter.com/seventhseven)です。

今回はHTMLのフォームについての小ネタです。


## 正規表現で入力内容を制限する

例：カタカナ・ひらがなのみに制限する
```html
<label class="f_title mst" for="client_name">お名前（ひながな・カナ）</label>
<input required type="text" id="client_name" name="client_name" 
placeholder="ひらがなかカタカナで入力" value=""
pattern="[ァ-ヶー　ぁ-ゞ]*" title="全角ひらがな・カタカナで入力してください">
```

**pattern="[ァ-ヶー　ぁ-ゞ]*"**でカタカナ、ひらがな（全角スペースと全角ハイフン）が0文字以上マッチするように制限。

- ァ-ヶでカタカナ
- ぁ-ゞでひらがな
- ー　 で全角スペースと全角ハイフン

## 桁数を制限して数字のみの入力を受け付ける

例：1行のフォームで電話番号を入力させる
```html
<label class="f_title mst" for="phone_no">電話番号</label>
<input required type="tel" pattern="[\d]*" 
title="半角・ハイフンなしの数字を入力してください" id="phone_no" name="phone_no"
placeholder="012033334444（半角・ハイフンなし）" value="" minlength="11" maxlength="11">
```

**pattern="[\d]*"**で[0-9]に0文字以上マッチするように制限。

電話番号は11桁なので、**minlength="11" maxlength="11"**で最小11文字・最大11文字入力できるように制限。

## 基本的な機能に学ぶ

今回機会があってフォームを作成してたのですが、HTMLタグだけでも組み合わせれば色々とできることがわかりました。

これでメールアドレスなどの入力も正規表現での制限でエラーチェックができます。

POSTしてからバックエンド側でエラー判定を出してもいいのですが、
フロント側でPOSTする前に制限したほうがユーザビリティも高いですね。

もちろんバックエンド側もバリデーションは必須だと思いますが、
知らなかったので残しておきます。

MB.js

BLOG