Node.js関連のことを調べてみた2020年03月17日

NFCシールを活用して自動打刻ツールを(個人的に)作ってみた話

# はじめに

今回はNFCシールを使用して会社の自動打刻システムを、完全に自分用で作ります!

# 要件定義

## なぜつくるか?

現在､弊社の勤怠は､エクセルで管理されています｡
実際の打刻フローとしては､

1. 出社したら出社時刻をエクセル開いて手動で打刻
2. 保存
3. 退社するときに退社時刻をエクセル開いて手動で打刻
4. 保存

｡｡｡
**毎日エクセルポチポチするの面倒すぎる!!!!!!!!!**

作業自体も面倒なのに､何日か打刻を忘れるとまあ面倒臭いことになります｡

せっかくIT企業にいるんだからいろいろスマートにやりたい…
ということで､今回の自動打刻システムの開発を決意しました｡

## どう作るか?

今回開発する自動打刻システムでは､NFCシールを活用していきます｡

処理の流れとしては､

1. NFCシールにスマホをかざして専用のWEBサイトを表示する
2. WEBサイトから自動打刻システムにリクエストを投げる
3. 打刻する

といった感じにしようかと思います｡

NFCシールにスマホかざすのとリクエストを投げるところにWEBサイト表示をは

2020年から始めるAzure Cosmos DB – JavaScript SDK (SQL API)を見てみる (Part.1)


# この記事について

本記事は、2020年3月6日 (米国時間) にて、Azure Cosmos DB に新しく Free Tier (無償利用枠) が登場したことに伴い、改めて Azure Cosmos DB を色々と触っていく試みの 3 回目です。
今回は、[前回記事][PrevLink1] にて作成した CRUD アプリ内で使用している **Microsoft Azure Cosmos JavaScript SDK** について見ていきたいと思います。

– [Microsoft Azure Cosmos JavaScript SDK][npm]
– [Azure/azure-cosmos-js][GitHub1] \(old\)
– [Azure/azure-sdk-for-js][GitHub2]

[PrevLink1]:https://qiita.com/ymasaoka/items/0b0b72635

mockyでリクエストの内容をレスポンスに反映しようとしてハマったメモ。

# やりたいこと
node.jsで動くWebAPIモックサーバーの[mocky](https://github.com/2do2go/mocky)を使って、

“`
{ “name”: “John Smith” }
“`
をPOSTリクエストしたら

“`
{
“id”: 1,
“name”: “John Smith”
}
“`
が返却され、

“`
{ “name”: “Taro Yamada” }
“`
をPOSTリクエストしたら

“`
{
“id”: 1,
“name”: “Taro Yamada”
}
“`
が返却されるように、リクエストの内容をレスポンスに反映したかったのだが、つまづいたのでメモを残す。
mockyのインストール方法、基本の使い方はGithubのREADMEを参考にしてください。

# 結論
基本の使い方は公式のREADMEといいつつ、mocky自体かなりメンテされていないみたいなので少し書き方は今風にしてる箇所もあるが基本的に一緒。

“`mock.js
const mocky = require(‘mocky’);

m

入門の次のステップに進めないVue.js学習履歴（随時更新）

# 概要
ドットインストールの「Vue.js入門」を実施してある程度Vue.jsをわかった気になった。
https://dotinstall.com/lessons/basic_vuejs_v2

しかし、実際にリリースされているVue.jsのソースを見るとさっぱりわからなかった。
このため、疑問点と調査経緯を自分のメモ目的でこの記事に残していく。

# 疑問点

## yarn run xxx
package.jsonのscriptsで定義されたxxxを実行する。

“`
“scripts”: {
“xxx”: “～～～～～～～～”,　←これを実行
“yyy”: “～～～～～～～～”,
　　　　：
　　　　：
},
“`

■yarn runのドキュメントはこちら。
https://classic.yarnpkg.com/ja/docs/cli/run

## app.use(nuxt.render)

expressのミドルウェアとしてNuxt.jsを使う。

“`
const express = require(‘express’)
const ap

Lambdaプロキシ統合でmultipartのフォームデータをパースする

ファイル添付とかmultipartで送信されてくることがあるので、そのパース方法。
busboyというライブラリを次のように使うことで実現可能。

`event`はlambda関数の入力。

“`
if (event.headers[‘content-type’] && (event.headers[‘content-type’] as string).includes(‘multipart/form-data’)) {
console.log(‘IT IS MULTIPART’);
const input: CreateMeProfileInput = {};
const busboy = new Busboy({
headers: event.headers,
defCharset: ‘utf8’
});
return new Promise((resolve, reject) => {
busboy.on(‘file’,

Browser/Node.js両対応、シンプルなHTTPクライアント”bent”

Node.jsでHTTPリクエストしたいなーと思って一番メジャーそうな [request – npm](https://www.npmjs.com/package/request) を覗いたら **deprecated** になってるじゃないですか！

代わりに、シンプルなHTTPクライアントで良いの無いかなーと調べてたら、`request`のissuesコメントにあった`bent`というクライアントに辿り着きました。

# bent
– [bent – npm](https://www.npmjs.com/package/bent)

使い方はとても簡単。

`localhost:3000`へ`GET`してレスポンスボディを文字列で受けたい場合…

“`js
const bent = require(“bent”);

const httpGet = bent(“http://localhost:3000”, “GET”, “string”);

const responseBody = httpGet(“/”);
“`

これだけ。

Node.jsでは`http`を、Br

Nodeインストール時に困った件

# エラー内容
“`
v12.16.1 is not found Can not fetch: https://nodejs.org/dist/v12.16.1/node-v12.16.1-darwin-x64.tar.gz
“`
nodebrewの安定版をインストールしようとした際に
上記のようなエラーが出た。

# 解決策
どうやら別の方法で再インストール。

“`
curl -L git.io/nodebrew | perl – setup
“`
“`
export PATH=$HOME/.nodebrew/current/bin:$PATH
“`
出てきたPATHをbash.profileに追加。

“`
open ~/.bash_profile
“`
保存して閉じ、再読み込みを行う。

“`
source ~/.bash_profile
“`

参考にしました：
[Can not fetch: とか 言われて nodebrew で node のインストールが失敗する](http://kimizuka.hatenablog.com/entry/2018/02

@kintone/rest-api-client をGitHubからインストールする

# はじめに
`@kintone/rest-api-client` の開発中の機能を、GitHubからインストールして早めに使ってみました。
一般的にNPMパッケージをGitHubからインストールするときに比べて、特殊な方法が必要だったのでメモ。

# 注意

* Webpackビルド環境がある前提です
* 開発中のを勝手に使う場合、深刻なバグがある可能性もあるので自己責任で！

# ディレクトリ構造
rest-api-clientは、Gitリポジトリとしては特殊な形をしています。

https://github.com/kintone/js-sdk
この`@kintone/js-sdk`というリポジトリ内に、サブディレクトリとして`rest-api-client`が存在します。
https://github.com/kintone/js-sdk/tree/master/packages/rest-api-client

NPMの世界では `@kintone/rest-api-client` という単独パッケージ扱いですが、Gitの世界では単なるサブディレクトリ。
（なんでこんな変な構

フロント・バックエンドサービスをコンテナ化してもGitコミット時にLefthookでテストやLint実行

### TL;DR
– フロント・バックエンドサービスをそれぞれコンテナ化、docker-composeで全てのコンテナを管理する
– monorepoで管理した際に1リポジトリとなるので気軽にGit Hookの処理ができない
– Lefthookを導入してpre-commit時にすべてのコンテナに対してLintツールを動作させるようにした

### サンプルコード
https://github.com/MegaBlackLabel/lefthook-docker-node-go-dev-sample

### 1リポジトリで開発環境を管理したい
渋川さんの記事

マイクロサービスほどじゃないけどウェブサービスを分割開発したい人向けDocker設定を集めるスレ
https://qiita.com/shibukawa/items/fd49f98736045789ffc3

を読んでフロントエンドとAPIがごっちゃになっている開発環境ヨクナイ！ってことでサービス単位でコンテナ化してvs codeのリモートコンテナ機能を使って開発環境を再構築をしていたらGitとGItHooksの扱いで躓

管理者権限のないWindowsでvue開発（サンプル付き）

コロナ禍で、在宅で、与えられたリモート環境には管理者権限がなくて、でも開発はやらないと。。
なんて状態でもvue開発するための環境構築手順です

ついでに vue の動作確認サンプルも載せときます

#手順
１．node環境の構築
２．vue-cli のインストール
３．vue プロジェクトの作成
４．vue 動作確認用サンプル

#１．node環境の構築
公式サイトから ZIP版をダウンロードしてきて、展開
環境変数を設定します
ファイルを展開して置くだけなので管理者権限は不要です

## 1.1. nodeをダウンロード
https://nodejs.org/ja/download/
Windows Binary の ZIPファイルをダウンロードです


## 1.2. nodeをインストールするフォルダの準備
ユーザ（自分）のフォルダにインス

anyenv 経由の nodenv 経由で Node.js をインストールする

## 背景

Node.jsをインストールする方法がたくさんあって迷う問題。

– [公式のインストーラ](https://nodejs.org/ja) を使う場合
– [homebrew](https://brew.sh/index_ja) 経由でインストールする場合
– [nvm](https://github.com/nvm-sh/nvm) 経由でインストールする場合
– [nodebrew](https://github.com/hokaccha/nodebrew) 経由でインストールする場合
– [ndenv](https://github.com/riywo/ndenv) 経由でインストールする場合
– [nodenv](https://github.com/nodenv/nodenv) 経由でインストールする場合
– [anyenv](https://github.com/anyenv/anyenv) 経由でインストールする場合 (当記事)

いや多すぎんだろ！！?

### 公式のインストーラ & homebrew 経由でインストールした時の問題

– 複数のNodeバ

Cloud9のNode.jsのバージョンを上げる

# はじめに

Cloud9で使用しているデフォルトのOSであるAmazon Linuxでは、Node.jsのバージョンがv10.19.0のため、2020/03/16時点で最新のv12.16.1にバージョンアップする。

# 前提条件

* AWSにサインアップしていること
* Cloud9のプロジェクトを作成していること
* 本手順ではAmazon Linuxを使用している

“`bash
cat /etc/system-release
Amazon Linux AMI release 2018.03
“`

# 手順

以下のコマンドを実行します。

“`bash
nvm install v12.16.1
nvm alias default v12.16.1
npm update -g npm
npm i -g npm
“`

Node.js、VSCode、WSLときどきPowerShell

WindowsでNode.js（Angular)を使ったフロントエンドの開発環境を整えるにあたってハマったところを残しておきます

# 開発環境

– OS: Windows 10 Home
– エディター: VSCode
– コンソール: WSL1(Ubuntu)

# VSCodeのGUIで使用するGitを変更する

同じレポジトリをWSLとVSCode両方から弄っている人は今すぐにVSCodeの設定を変更してください

でないとそのうち**どちらからも書き込みができなくなるデッドロックが発生します**

発生するタイミングは把握できませんでしたが、
VSCodeのGUIでファイルの変更を取り消す(discard changes)ときに発生する気がします


この症状が起きるたびにレポ

Node.js (TypeScript) におけるキャッシュの実装方法とその戦略

現代の Web アプリケーションにおいて、キャッシュはもはや不可欠と言っていいくらい需要な技術でしょう。アプリケーションの負荷を軽減し、ユーザーへのレスポンスを高めます。
本記事では Node.js (Typescript) を使用したバックエンド API を実装する際に、どのようなキャッシュのテクニックが使えるか解説します。

※なお、説明の簡略化のためエラーハンドリングなどは省略しています。

# Node.js を使用した非同期バッチパターンとキャッシュ機構

本章では以下の３つの実装パターンを比較し、Node.js を使用したキャッシュを実装していきます。

1. キャッシュのないサンプルアプリケーション
2. 非同期バッチ処理パターン
3. キャッシュパターン

## 1. キャッシュのないサンプルアプリケーショ

伝家のトレジャーソード（COTOHA APIでつくるルー語 LINE Bot）

# やりたいこと・経緯
– 入力した日本語文の一部をカタカナ表記の英語に変換（＝**ルー語**を生成）し返すLINE Botをつくってみる
– ルー語とは：日本語文の一部を単語単位でカタカナ表記の英語に置き換えたルー大柴さんの（流行ったのは十年以上前の）ネタ
– たとえば「言わぬがフラワー」「塵も積もればマウンテン」など
– 実はすでに[ルー語変換](https://lou5.jp/)というウェブサイトがあり、そのサイトの[開発経緯](https://e8y.net/blog/2006/12/31/p139.html)には「文章を形態素解析 → 単語を英訳 → 英語をカタカナ読みに翻訳 」していると書いてある
– 日本語文の形態素解析にはMeCabを利用しているそう。COTOHA APIを使って作ったらどうなるだろうか、という単純な思いつき

# COTOHA APIについて
– https://api.ce-cotoha.com/
– 文の形態素解析や固有表現抽出などの自然言語処理や音声処理をRESTなAPIでやってくれるAPI
– ひととおりに触ってみて、非常に精度がよく、アイディ

COTOHA APIだけでおじさんになろう

# はじめに
– 読みやすさ重視のため、本文におじさん構文は登場しません。期待された方には深くお詫び申し上げます。
– また、デモサイトやバックエンドに関することは後日別記事にしようと思います。
– 前提知識 => JavaScriptのみ（！）
– 記事中に登場するコードは、axiosとfsが動くnode環境ならコピペで実行可能です。COTOHAの気軽さをお試しください。
– 筆者は趣味でコードを書く大学生です。動けばいいやの精神が強いのですが、ITの世界に進むならこれじゃあかんやろと思っているので、コードにとどまらずいろいろご指摘くだされば幸いです。

# おじさん:wink:と一緒:kissing_heart:に考えよう:thinking:
**普通の文章を入れたらその内容がおじさん構文になったらおもしろくね？**
ということで[COTOHA API](https://api.ce-cotoha.com/)のみを使って[デモページ](https://storage.googleapis.com/vue-oji-cotoha/index.html)を作ってみました。
#

事故を出さない虎の巻

「機能は追加（修正）する」「事故も起こさない」。 「両方」やらなくっちゃあならないってのが「エンジニア」のつらいところだな。 覚悟はいいか?オレはできてる。

# 事故の定義
ここで述べる事故とは、ユーザのサービス利用を妨げる事象、サービスの信頼が失われる事象を指す。
事故足りうる事象に次のものが挙げられる。

– インフラ障害（ネットワーク障害、サーバ障害）
– DB障害（データ不整合、デッドロック）
– 脆弱性（情報漏えい、インジェクション、改ざん、不正アクセス）
– メール・SNSの誤送信
– 実装バグ（二重課金、サーバエラー、操作不能、意図しない動作）

事故足り得る前提として1つ目に規模の問題がある。10人が使ってるサービスの障害と100万人が使ってるサービスの障害を比較するのであれば、明らかに後者のほうが重大な事故である。次にサービス全体へ影響を与えた障害なのか、ごく一部のユーザにのみ影響を与えた障害なのか事故の規模を考慮する必要がある。
（あまりにも規模が小

lamda, api gateway使って、クライアントに値を返すなど

主に自分用メモ。

client->api gateway->youtube apiとかやりたい。

参考: [Amazon API Gateway とは?](https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/welcome.html)

# まずlamda, api gaytewayを触ってみる

下記を見ればだいたいわかる。
[ゼロから作りながら覚えるAPI Gateway環境構築](https://dev.classmethod.jp/cloud/aws/getting-start-api-gateway/)

lamdaでのコードをローカルで作る際にはこちらを参考にした。
https://qiita.com/toshihirock/items/d28505442526e0ae7793

# 次にapi gateway->youtube apiをやってみる
ココやる上で、手元ではうまくresponse返ってきてるが、lamdaのところではresponseがnullになってて、なんでだろうとしていた

npmパッケージ公開の手順

プログラミング歴半年の素人が書いています。

間違いのないようご自身でも良く調べた上でお願いいたします。

以下の記事を参考にさせていただきました。
https://qiita.com/TsutomuNakamura/items/f943e0490d509f128ae2

# npmにサインアップ

まずはnpmの公式サイトから、会員登録しましょう。

https://www.npmjs.com/

# npm ユーザの作成

ターミナルからユーザー情報を登録します。

“`bash
$ npm set init.author.name “Ai Uehara”
$ npm set init.author.email “ai-uehara@example.com”
$ npm set init.author.url “http://qiita.com/aiuehara”
$ npm adduser # 会員登録情報の入力
“`

# npmパッケージの作成

`npm init`を実行すると`package.json`ファイルが作成され、npmパッケージとしてディレクトリを管

Node.jsの非同期処理をPromiseから理解しようとしてみた

# はじめに

今回は、Node.jsの非同期処理について、自分の備忘録も兼ねて記事を作成しました。

私はJavaScriptの言語仕様なんかをあまり知らない状態でNode.jsを触ったせいで、非同期処理に関する部分ではまり、多くの時間を無駄にしてしまいました。

かなり初歩的な内容かもしれませんが、勉強した内容をまとめます。

# 同期処理とは？

**上から順番にプログラムが実行されていくこと**です。

「上から順番に」という言葉が適切かどうか分かりませんが、「一つ一つの処理が、一個前の処理の終了をまって処理されていく」っていう説明よりは個人的に分かりやすい気がします。

コードにすると、下記の通りです。

“`js
console.log(1);
console.log(2);
console.log(3);
console.log(4);
console.log(5);
“`

実行結果は、下記のようになります。

“`js
1
2
3
4
5
“`

# 非同期処理とは？

同期処理ではないものが非同期処理なので、**上から順番にプログラムを実行されないこと**と