概要

React ,node.js版で
IndexedDBのCRUD作成となります
dexieライブラリで、IndexedDB操作して。
ブラウザ内に保存する形で。使用を想定しています

環境

react
react-dom
react-router-dom
dexie

画面

・リスト

・編集

参考のコード

https://github.com/kuc-arc-f/react_cms1_1crud

---

実装など、React Component

・Create
https://github.com/kuc-arc-f/react_cms1_1crud/blob/master/src/component/Task/Create.js

・index
https://github.com/kuc-arc-f/react_cms1_1crud/blob/master/src/component/Task/Index.js

・edit/delete
https://github.com/kuc-arc-f/react_cms1_1crud/blob/master/src/component/Task/Edit.js

---

Node.js で終了時のクリーンアップ処理を書こうとすると、 exit イベントか beforeExit イベントの2択になる。 exit だと非同期処理が書けないので、事実上 beforeExit の1択…と思って使ってみたらちょっとだけハマったのでメモ。

process.on('beforeExit', (code) => {
  console.log('Delayed');
  setTimeout(() => {
    console.log('Process beforeExit event with code: ', code);
  }, 1000);
});

process.on('exit', (code) => {
  console.log('Process exit event with code: ', code);
});

console.log('This message is displayed first.');

こんな感じの検証コードを書いて実行したら、 beforeExit の部分がこんな感じで延々実行されて止まらなくなった。

This message is displayed first.
Delayed
(1秒ウェイト)
Process beforeExit event with code:  0
Delayed
(1秒ウェイト)
Process beforeExit event with code:  0
Delayed
(1秒ウェイト)
Process beforeExit event with code:  0
Delayed
(1秒ウェイト)
...

どうも beforeExit の中で非同期処理を書くと、そこで「イベントループが空ではなくなった」ということで beforeExit 発火前の状態に戻ってしまうらしい。ぐぬぬ。

仕方ないので、1回だけしか実行されないようにガードしてみた。

let isBeforeExitAlreadyFired = false;

process.on('beforeExit', (code) => {
  // beforeExit を1回しか実行させないためのガード条件
  if (isBeforeExitAlreadyFired) {
    return;
  }
  isBeforeExitAlreadyFired = true;

  console.log('Delayed');
  setTimeout(() => {
    console.log('Process beforeExit event with code: ', code);
  }, 1000);
});

process.on('exit', (code) => {
  console.log('Process exit event with code: ', code);
});

console.log('This message is displayed first.');

This message is displayed first.
Delayed
Process beforeExit event with code:  0
Process exit event with code:  0

めでたしめでたし。

参考

• Node.js Documentation
• Process on beforeExit doesn't work correctly? ここを見る限り、この beforeExit の振る舞いは v0.x の頃から変わっていないらしい。あまり使われていないのだろうか…。

Performance aspect of Deno vs. Node

この記事に関して

Performance aspect of Deno vs. Nodeを翻訳しました。
また、私のブログからの転載です

Deno対Nodeのパフォーマンスについて

パフォーマンスが良いことは、素晴らしいことです。

数日前、Craig Mortenの投稿What Is The Best Deno Web Framework?「DenoのWebフレームワークで最適なものは何か？」を読みました。すべてのDenoフレームワークの概要を示し、それらのすべての側面を比較します。あなたがそれについて読んでいないなら、私はあなたがそうすることを強く勧めます。

クレイグの投稿によると、「パフォーマンス」セクションは魅力的です。彼の環境では、Deno HTTPモジュールはNode HTTPモジュールとほとんど同じ（さらにはそれ以上）という結果でした。これは単なる "Hello Deno！"を試すだけのパフォーマンステストですが、この結果に驚きました。

しかし、私はそれがほとんどの場合に当てはまらないことを知っていました。なぜならDeno HTTPモジュールはTypescriptで記述されているためです。型チェックは開発の楽しさをもたらしますが、コンパイラー時間により多くのリソースがかかるため、パフォーマンスに悪影響を及ぼします。
（Oghenovo UsiwomaとJonathan Beaumont がコメントで指摘してくれてありがとう）

しかし、私は以前にそれをテストしたことがあり、彼と同じ結果を得たことはありません。より強力なマシンでテストを実行するとどうなるかを確認したいと思います。

• 環境：

  • CPU：i5-9600KF @ 3.7GHz
  • RAM：16GB DDR4 2133MHz
  • OS：Windows 10
  • ベンチマークツール： autocannon

• ベンチマークスクリプト：

  • "Hello World!" deno server
  • "Hello World!" node server 最初に結果を見てみましょう：

100同時接続

名前	バージョン	AVGリクエスト/秒
node.http	12.16.3	47969.2
deno.http	1.0.0	47376
deno.http	1.1.0	46953.7
node.http	14.2.0	44409

なんと！全体的にDenoはNodeを優っているように見えます！（少なくともNodeバージョン14.2.0の場合）。

ただし、このベンチマークは、100の同時接続数に基づいてautocannon http://localhost:3000/ -c100のコマンドで実行しているため、中小規模のサーバーには多すぎます。そこで、もう一度試してみます。今回-c10は、10の同時接続で要求を送信し続けるてみます。

10同時接続

名前	バージョン	AVGリクエスト/秒
node.http	12.16.3	49926.69
node.http	14.2.0	45345.33
deno.http	1.1.0	34806.79
deno.http	1.0.0	34742.37

今回は、Nodeの勝利です。2つの間には大きな違いがあり、ノードはデノよりも毎秒約10Kを超えるリクエストを持っています。

しかし、これは新しい質問をもたらします：

同時接続数が重要なのはなぜですか？

同時接続とは、別の接続と同時に発生する接続のことです。

あるユーザーがHTMLページのリクエストを送信し、5ミリ秒後に、

別のユーザーがcssファイルのリクエストを送信したとします。

しかしこれは同時接続とは見なされません。

同時接続数を計算する方法

例えば、アプリに100人のアクティブユーザーがいるとします。これらのユーザーを1時間追跡し、各ユーザーが1時間に60回のクリックを行っていることを分かったとします。これはサーバーでの合計リクエスト数が6000であり、各リクエストには平均で2秒かかるとします（これは非常に低速です）。これは、3600秒（1時間）で、12000秒のアクティブな接続であり、同時接続数は3.33になります（12000/3600 = 3.33）。

• Q. もしサーバーが1秒以内に各リクエストを処理できるほど強力な場合はどうでしょう?

• A. 同時数はさらに少なくして、1.7未満です。

• Q. 1000人のアクティブユーザーはどうですか？

• A. 同時接続数は33.3

• Q. 100の同時接続はやりすぎでは？

• A. そのとおり！3000人以上のアクティブユーザーにサービスを提供するエンタープライズレベルのアプリケーションを構築する場合を除きます。（上記のシナリオにおいては）

NodeまたはDeno、どちらの方がパフォーマンスが良いか教えていただけますか？

そうは言っても、10個の同時接続の結果は実際にはより意味があり、Nodeはパフォーマンスラウンドで勝利します。

-c100のテストではDenoの方がパフォーマンスが優れていますが、これは、トラフィック量の多いネットワークの場合であり、NodeよりもDenoの方が優れていることを意味しています。それは素晴らしいことです。私が見てきたことから、Denoはまだ若く、現時点ではまだ本番環境に対応していないため、企業はデノよりも大量のトラフィックを処理するためにJavaまたは他のよく知られた実績のある言語を好むでしょう。しかし、Denoコミュニティの誰もがそれを実現させています?。

最後に一点申し上げたいと思います。開発コミュニティにとって、パフォーマンスは成功の鍵ではありません。PythonとPHPを見てください。それらはNodeとDeno よりもかなり遅く実行されます。なぜ、それらは人気なのでしょうか？その理由はエコシステムと人です！

追加トピック

Googleが1秒あたり75,000以上のクエリを処理することを検討してください。
サーバーは、1秒あたりこの量のリクエスト（> 40K）を処理できますか？

Node.js

% npm i socket.io

  server = app.listen(port);
  var socket = require('socket.io');
    io = socket(server); // ①
    io.on('connection', (socket) => { // ②
      const usr = Object.keys(io.sockets.sockets).length
      console.log("Hi Server")
      console.log(usr)
      socket.on('SEND_MESSAGE', function(data){ // ③
        io.emit('RECEIVE_MESSAGE', data); // ④
      })
    });

React

% sudo yarn add socket.io socket.io-client 

  import socketIOClient from 'socket.io-client'
    const socket = socketIOClient(`${API_URL}`,{transports: ['websocket']});
    socket.on('connection', (socket) => { 
      console.log("Hi client");
      console.log(socket);
    });

日本発のオープンソース receiptline でレシート印刷に少しずつトライしています。
今回は、前回のレシートプリンターと変換 API を使ってアプリを作ります。

実はこれを作りたかった

“レジプリンター式インスタントカメラで「レシート日記」はなぜ楽しいのか？”
https://weekly.ascii.jp/elem/000/004/004/4004167/

“1枚1円の安さが正義、レシート現像のトイカメラが楽しい｜ベストバイ2019”
https://japanese.engadget.com/jp-2019-12-23-1-1-2019.html

“むしろ大人が欲しい多機能ぶり！ プリンター内蔵の子ども用カメラ「myFirst Camera Insta 2」”
https://capa.getnavi.jp/news/339006/

そうです。インスタントカメラです。
記事を読んでいるだけで楽しさが伝わってきます。

早速これを receiptline で作ります。
もちろんカメラデバイスが必要です。

インスタントカメラのコード

アプリの開発環境は何でも構わないのですが、最短コースで。
receiptline の Node.js サンプルプログラムをベースにします。

作業フォルダを作成して example/nodejs 以下をまるごとコピー。
コピーした wwwroot/index.html 書き換えます。

wwwroot/index.html

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>Instant Camera</title>
    <script type="text/javascript">
        async function initialize() {
            const video = document.querySelector('video');
            const canvas = document.querySelector('canvas');
            // video
            video.srcObject = await navigator.mediaDevices.getUserMedia({ audio: false, video: true });
            video.onclick = event => {
                // image
                canvas.getContext('2d').drawImage(video, 0, 0, canvas.width, canvas.height);
                let data = `{i:${canvas.toDataURL('image/png').slice(22)}}\n`;
                // barcode
                const now = new Date();
                const iso = new Date(now.getTime() - now.getTimezoneOffset() * 60000).toISOString();
                data += `{c:${iso.replace(/\D/g, '').slice(2, 14)};o:ean,24}|`;
                // send data
                const xhr = new XMLHttpRequest();
                xhr.open('POST', 'printer');
                xhr.setRequestHeader('Content-Type', 'text/plain; charset=utf-8');
                xhr.send(data);
            };
        }
    </script>
</head>
<body onload="initialize()">
    <video autoplay style="width: 100%;"></video>
    <canvas width="576" height="432" style="display: none;"></canvas>
</body>
</html>

20 行の JavaScript コードで出来てしまいました。

写真サイズ

576 × 432 ピクセルに固定してあります。
レシートプリンターの幅に合わせて Canvas のサイズを変更してください。

• TM-T88V (80mm)
  • 512 × 384 ピクセル
• mC-Print3 (80mm)
  • 576 × 432 ピクセル (変更不要)

<canvas width="576" height="432" style="display: none;"></canvas>

撮影日時

バーコードで撮影日時を印刷しています。
2023 年 7 月 20 日 12 時 34 分 56 秒の場合。

• データ (12 桁)
  • 23 (年)
  • 07 (月)
  • 20 (日)
  • 12 (時)
  • 34 (分)
  • 56 (秒)
• チェックデジット (1 桁)
  • 1 (自動計算)

バーコードの種類は JAN (EAN) コードです。
バーコード / QR コードリーダーアプリで読み取ることができます。

ReceiptLine

{c:230720123456;o:ean,24}|

プリント先

プリンター ID を printer に固定してあります。
印刷設定に合わせて変更することができます。

xhr.open('POST', 'printer');

印刷設定

コピーした printers.json で設定します。
使用するレシートプリンターに合わせて調整が必要です。
特にガンマ補正 gamma の値は写真の画質に影響します。

TM-T88V (80mm)

printers.json

{
    "printer": {
        "host": "192.168.1.2",
        "port": 9100,
        "cpl": 42,
        "encoding": "cp932",
        "gamma": 1.8,
        "upsideDown": false,
        "command": "escpos"
    }
}

mC-Print3 (80mm)

printers.json

{
    "printer": {
        "host": "192.168.1.3",
        "port": 9100,
        "cpl": 48,
        "encoding": "cp932",
        "gamma": 1.8,
        "upsideDown": true,
        "command": "starmbcs"
    }
}

いざ撮影！

サーバーを起動します。実行環境は Windows 10 です。

$ node start.js

起動後、http://localhost:10080 を開きます。
カメラに対するアクセス権を求められるので許可してください。

映像だけのシンプルなページです。クリックすると即時印刷します。

業務用レジプリンタ式インスタントカメラ、略して “レジカメ” 誕生です！

新たな可能性

インスタ時代の新型プリントシール機が発売されたそうです。

“セガ、最新プリクラ機「fiz」でプリントシール機市場に20年ぶりの再参入”
https://weekly.ascii.jp/elem/000/004/019/4019040/

ふと思いました。これも出来るのでは！？
Canvas でキャプチャした画像を加工すればいいのです。
スタンプ押してよし、文字を入れてよし、ご当地フレームもよし。

しかも、業務用レジプリンタ式なら、このような特長もあります。

• 圧倒的低コスト！
• お財布といつも一緒！
• 盛らなくても映える！ (個人の感想です)

撮り放題にして集客するなど、プリントシール機と違うビジネスが生まれそうな予感。

これにて receiptline シリーズは一旦完結。
また何か作ったら投稿します。ではまた！

nodenvをインストール

参考 : https://github.com/nodenv/nodenv#basic-github-checkout

git clone https://github.com/nodenv/nodenv.git ~/.nodenv
cd ~/.nodenv && src/configure && make -C src

上記サイトで

2.Add ~/.nodenv/bin to your $PATH for access to the nodenv command-line utility.
    For bash:
        $ echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.bash_profile

と説明されているので、

echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.bash_profile

として、.bash_profileのファイル上で、PATHに追記します。
※WSLだと.bashrcに追記すれば行けるかもしれません。

~/.nodenv/bin/nodenv init

を実行すると、

# Load nodenv automatically by appending
# the following to ~/.bash_profile:

eval "$(nodenv init -)"

のように表示されるので、eval "$(nodenv init -)"を.bash_profileの末尾（先程のPATHの設定の次）に追記します。
※WSLだと.bashrcに追記すれば行けるかもしれません。

nodeの環境を作成、有効化

nodenv install --list

を実行すると、インストール可能なバージョンの一覧が表示されます。
数字から始まるバージョンにだけ絞る場合は、grepを使って以下のように絞ります。

nodenv install --list | grep -E "^ *[0-9]+.+$"

13.10.0
13.10.1
13.11.0

ここでは、最新のバージョンをインストール
※2020.07.24時点では、13.11.0

nodenv install 13.11.0

nodenv versions

を実行し、インストールされたバージョンが表示されることを確認します。

先程インストールしたバージョンを有効にします。

nodenv shell 13.11.0

特に何か表示されるわけではないので、

node -v

を実行し、先程有効化したバージョンが正しく表示されることを確認します。

v13.11.0

ある日の筆者
茶番⤵︎ ︎は読みたくなけりゃ飛ばしておけ

｢あれ？なんかdiscordのbotが落ちてるな……｣
｢しかもglitchでUptimerbot使って起動してる奴じゃん｣
｢あれー？前エラー治してから何もいじってないはずなんだけどなぁ｣
｢とりまエラー探すかぁ｣
(数時間後……)
「どこにもエラーがねぇぇぇぇぇぇぇ」
(知人に相談したら...)
uptimerobotはglitchからBANされて使えなくなったよ
「なんだとぉぉぉぉぉ！？」

はい。

uptimerobotが使えなくなってしまった

Discord botの動作環境として結構使われているGlitchですが、glicthはタスクを閉じてから5分くらいたつとアプリケーションは落ちてしまいます。
それの回避方法としてUptimeRobotというものがよくつかわれていました。
これは簡単に言ったらURL指定して定期的にリクエスト送る...的なやつだったはず

それが、glitch有料化が出てからから少しした後？UptimeRobotはglitchで使用できなくなってしまいました。
理由としてはglitch側が有料版を使ってほしいから...と思っての行動じゃないかと勝手に推測しています。
また、利用規約に次のような文が追加されていました。

We reserve the right to delete, suspend, or terminate your access to the Services if we determine you are circumventing our services usage limits.

翻訳は(Deepl翻訳を使用しました)

私たちは、サービス利用制限のセクション（セクションE）を更新し、次の行を含めるようにしました： '私たちは、あなたが私たちのサービスの利用制限を回避していると私たちが判断した場合、サービスへのアクセスを削除、一時停止、または終了する権利を留保します。

つまり、UptimeRbotと同じような監視ツールなどを使って5分で落ちるっていう使用を回避してると、もしかしたらglitchからBANされるよ、みたいな感じです(勝手な解釈)

これからはどうすれば

上にもあるように規約で回避が禁止されてしまったのでおとなしく課金する(有料版を使う)
それが嫌ならHerokuなどglitch以外の環境を使うかしかないのか...?

もしくは消されるの覚悟でほかの何か使って定期的にリクエスト送って5分回避を続けるか...?

Herokuは無料版だと月末動かなくなるし...

おわり

今回はglitchでUptimeRbotが使えなくなってしまったということの共有的な感じで記事を書きました。
これからどうしましょうかねぇ...

(もしかしたら抜けてるところとか間違えてるところがあるかもしれません。もしも間違えがあったらコメント等で指摘してください)

参考にしたページやサイトなど

https://glitch.com/legal (glitchの利用規約)

ある日の筆者
茶番⤵︎ ︎は読みたくなけりゃ飛ばしておけ

｢あれ？なんかdiscordのbotが落ちてるな……｣
｢しかもglitchでUptimerbot使って起動してる奴じゃん｣
｢あれー？前エラー治してから何もいじってないはずなんだけどなぁ｣
｢とりまエラー探すかぁ｣
(数時間後……)
「どこにもエラーがねぇぇぇぇぇぇぇ」
(知人に相談したら...)
uptimerobotはglitchからBANされて使えなくなったよ
「なんだとぉぉぉぉぉ！？」

はい。

uptimerobotが使えなくなってしまった

Discord botの動作環境として結構使われているGlitchですが、glicthはタスクを閉じてから5分くらいたつとアプリケーションは落ちてしまいます。
それの回避方法としてUptimeRobotというものがよくつかわれていました。
これは簡単に言ったらURL指定して定期的にリクエスト送る...的なやつだったはず

それが、glitch有料化が出てからから少しした後？UptimeRobotはglitchで使用できなくなってしまいました。
理由としてはglitch側が有料版を使ってほしいから...と思っての行動じゃないかと勝手に推測しています。
また、利用規約に次のような文が追加されていました。

We reserve the right to delete, suspend, or terminate your access to the Services if we determine you are circumventing our services usage limits.

翻訳は(Deepl翻訳を使用しました)

私たちは、サービス利用制限のセクション（セクションE）を更新し、次の行を含めるようにしました： '私たちは、あなたが私たちのサービスの利用制限を回避していると私たちが判断した場合、サービスへのアクセスを削除、一時停止、または終了する権利を留保します。

つまり、UptimeRbotと同じような監視ツールなどを使って5分で落ちるっていう使用を回避してると、もしかしたらglitchからBANされるよ、みたいな感じです(勝手な解釈)

これからはどうすれば

上にもあるように規約で回避が禁止されてしまったのでおとなしく課金する(有料版を使う)
それが嫌ならHerokuなどglitch以外の環境を使うかしかないのか...?

もしくは消されるの覚悟でほかの何か使って定期的にリクエスト送って5分回避を続けるか...?

Herokuは無料版だと月末動かなくなるし...

おわり

今回はglitchでUptimeRbotが使えなくなってしまったということの共有的な感じで記事を書きました。
これからどうしましょうかねぇ...

(もしかしたら抜けてるところとか間違えてるところがあるかもしれません。もしも間違えがあったらコメント等で指摘してください)

参考にしたページやサイトなど

https://glitch.com/legal (glitchの利用規約)

Linux もしくは Windows Subsystem for Linux のターミナルから以下のコマンドを実行し、npm と node.js をインストールする。

   sudo sed -i -e 's%http://.*.ubuntu.com%http://ftp.jaist.ac.jp/pub/Linux%g' /etc/apt/sources.list
   sudo apt update
   sudo apt upgrade
   sudo apt-get install -y nodejs
   sudo apt install npm

任意のフォルダを作成し、その中で npm init コマンドを実行し package.json を作成する。
expressのパッケージをインストールし、アプリケーションのエントリーポイントとして app.js を作成する。

   mkdir hoge
   cd hoge
   npm init
   npm i express --save

   touch app.js

package.json の中身は次の通り。npm init の実行時になされる質問で main で指定するエントリーポイントをデフォルトから app.js に変更している。

{
  "name": "hoge",
  "version": "1.0.0",
  "description": "",
  "main": "app.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Matsuoka",
  "license": "MIT",
  "dependencies": {
    "express": "^4.17.1"
  }
}

app.js の中身は次の通り。

const http = require('http');
const express = require('express');

const app = express();

app.use( function (req, res, next) {

    return res.send('こんにちは世界！');

});

let server = http.createServer(app);

server.listen('3000');

以下のコマンドで、node から app.js を実行する。

node app.js 

http://localhost:3000/ をブラウザで開く。