Next.jsでSVG画像をReact Componentとして描画する

Next.js React

@svgr/webpackを利用する。

react-svgr.com

npm install @svgr/webpack --save-dev

# or use yarn

yarn add @svgr/webpack --dev

next.config.js

module.exports = {
  webpack(config) {
    config.module.rules.push({
      test: /\.svg$/,
      issuer: {
        test: /\.(js|ts)x?$/,
      },
      use: ["@svgr/webpack"],
    });

    return config;
  },
};

github.com

react-svg-loaderを利用する

github.com

npm install react-svg-loader --save-dev

# or 

yarn add react-svg-loader --dev

next.config.js

const path = require("path");

module.exports = {
  webpack(config) {
    config.module.rules.push({
      test: /\.svg$/,
      include: [path.resolve(path.resolve(), "src/images")],
      use: ["react-svg-loader"],
    });

    return config;
  },
};

個人的には@svgr/webpackのほうがスマートに見えるのでそっちを利用する。お好みで。

TerraformでAWS LambdaLayer with Python を利用する

Terraform

ほぼclassmethodさんの記事通りですが

ソースコード

github.com

$ tree
.
├── README.md
├── build-layer.sh
├── iam.tf
├── lambda
│   ├── function.zip
│   └── lib.zip
├── lambda.tf
├── provider.tf
├── requirements.txt
├── src
│   └── index.py
├── terraform.tfstate
├── terraform.tfstate.backup
└── variables.tf

DeployするLambda functionのソースコード

import os
import sys
import requests
from bs4 import BeautifulSoup


def lambda_handler(event: dict, context):
    response = requests.get("http://example.com/")
    bs = BeautifulSoup(response.text)
    return bs.title.name

lambda functionでrequestsとBeautifulSoupを使いたい。そのためにlambda layerを利用する。

Lambda Layer

見るのはlambda.tfとbuild-layer.sh

data "archive_file" "function" {
  type        = "zip"
  source_file = "./src/index.py"
  output_path = "lambda/function.zip"
}

data "archive_file" "layer" {
  type        = "zip"
  source_dir  = "./lib"
  output_path = "lambda/lib.zip"
}

resource "aws_lambda_layer_version" "layer" {
  filename         = "${data.archive_file.layer.output_path}"
  layer_name       = "lib"
  source_code_hash = "${data.archive_file.layer.output_base64sha256}"

  compatible_runtimes = ["python3.6"]
}

resource "aws_lambda_function" "example_lambda" {
  function_name = "example_lambda"

  runtime          = "python3.6"
  handler          = "index.lambda_handler"
  filename         = "${data.archive_file.function.output_path}"
  role             = "${aws_iam_role.iam_role.arn}"
  source_code_hash = "${data.archive_file.function.output_base64sha256}"
  layers           = ["${aws_lambda_layer_version.layer.arn}"]
}

肝になるのはlambda functionとlayerのsourceの参照先の違い。

lambda functionのソースコードは project/src/index.pyを利用するが、 lambda layerは lib/ を利用する。pipライブラリのinstallについてはnull_resourceを利用してterraformで完結しようとしたが、うまく出来なかったので、shellファイルで実行する。何か良い方法あれば教えてほしい

#!/usr/bin/env bash

if [ -d lib/ ]; then
  rm -rf lib/
fi

echo "bundle pypi packages"
pip install -r requirements.txt -t lib/python

find lib -type f | grep -E "(__pycache__|\.pyc|\.pyo$)" | xargs rm

pip installで lib/python を指定しているのはlambda functionからlambda layerを参照するpathを通すため。lib/packagesなどではpathが通らないので注意。 __pycache__と.pyc、pyoを削除しているが、これはpip installをしても__pycache__配下のファイルの影響で差分が発生してしまうから。

$ sh build-layer.sh
$ terraform plan
$ terraform apply

参考

Markdown文書で画像の表示にURLを使わず埋め込む

Markdown

今回から技術記事はHatenaBlogに書いていこうと思います。

忘備録

Markdownに画像を表示する場合、どうしていますか。おそらくimgurやGitHubなどに画像をアップロードしてURLを参照していると思います。

imgur.com

![airplane](https://homepages.cae.wisc.edu/~ece533/images/airplane.png)

が、機密性のある画像のURLをpublicに公開したくはないが、Markdownで書きたい場合はどうすればよいか。

A. Data URI schemeを使う

Data URI Schemeとはと言う方はWikipediaをどうぞ。

ja.wikipedia.org

何でも良いですが、画像をbase64 encodingします。

$ base64 airplane.png > airplane_base64.txt
![airplane](data:image/jpeg;base64,iVBORw0KGgoAAAANSUhEUgAAAgAAAAIACAIAAAB7GkOtAAAAB3RJTUUH0AESFgINTbbB1gAAAAlwSFlzAAC4jAAAuIwBzPa7LwAG32VJ.....)

この様に画像のURLを使わずに画像を埋め込むことが出来ました。

f:id:teitei_tk:20200425113315p:plain
markdown preview

問題点

GitHub flavored markdownではセキュリティ上に理由でbase64を利用した画像は使えません。

github.com

この点はGitHub flavoerd markdownを利用する時点である程度publicな文書だと思うのでおとなしくGitHubに画像をアップロードして使ったほうが良さそう。

ワイヤレスヘッドホン "Bose QuietComfort 35" レビュー

5年ほど前に使っていたヘッドフォンがご臨終なされました。

ついに長年使っていたヘッドフォンが壊れてしまった。南無。

使っていたのは Audio-TechnicaのATH-A900というやつを使っていました。

audio-technica アートモニターヘッドホン ATH-A900

audio-technica アートモニターヘッドホン ATH-A900

確か1万〜2万の間だったかな。そういった意味では十分にペイしたかなと思います。南無。

というわけで新しいヘッドフォンを探した。

イヤホンでも良いんですが、個人的にはヘッドフォンが良いなという事でヘッドフォンをメインに探してみました。
今回重視した点としては

  • ワイヤレスヘッドホンであること
  • 通勤時〜仕事中でなるべくシームレスに使えること
    • 通勤中はiPhone ~ 社ではMacに繋げることが出来る。
  • そこそこの音質

というわけで色々探していたら友人がBose QuietComfort 35を使っているとの事だったので、
いろいろと調べてみて、実際に店舗で視聴をして購入を決めた。

新しいヘッドホンを手に入れた。が、オタクなのでアニソンしか聞かないし、無駄感あるのは無視しておきます。

www.bose.co.jp

Bose QuietComfort 35 wireless headphones ワイヤレスノイズキャンセリングヘッドホン ブラック【国内正規品】

Bose QuietComfort 35 wireless headphones ワイヤレスノイズキャンセリングヘッドホン ブラック【国内正規品】

購入を決めた理由

ワイヤレスヘッドホンであること

これまであまり意識をしていなかったのですが、ワイヤレスヘッドホンは神。 線が無いので、仕事中席から少し離れて飲み物を取りに行く際にもつけたままなのはかなり良い。
通勤中も、仕事中もだいたいヘッドフォンをつける or 首に下げておいています。

無線LANが当たり前になっている今日このごろですが、改めてWirelessの利点を認識した。 Bluetoothが使えない端末のために有線のケーブルも入っているので、問題ない。

Nintendo SwitchはBluetoothに対応してクレメンス・・・。

iPhone ~ Macでシームレスに使えること

これに関しては想像以上に良かったです。
専用のアプリでBose Connectというアプリがある。

www.bose.co.jp

これで接続先、iPhoneへの同期、接続先を選ぶことが出来る。 Bose Connectなのか、"QuietComfort 35"だからなのかは分からないが、同時に2台まで接続が出来る。

例えばFireTvStickに繋ぎながら冴えない彼女の育て方♭を見つつ、iPhoneでFate G/Oをやるという事が出来る。
もちろん、両者の音は聞こえます。

接続先に繋いだ or 切れた場合は、機械音声でデバイスの接続状況をヘッドフォンから教えてくれるのでそこも体験としては良かった。
なお、発音する言葉は（お察し下さい

そこそこの音質

そこまで音質にはこだわらないが、でも一応の音質は欲しいと思っていたのでここは視聴して聞いてみた。
耳が貧弱なので、どういった音声なのかというのは分からないが、一定以上の音質であることは間違いないと思う。

使ってみた感想

Bluetoothなので不安定

無線の宿命なのか音がぶつ切りになることが多いです。
安定しているときもあるし、不安定なときもあったりと再現条件が謎。
まあ、ここは仕方ないかなと思っている。

バッテリーの持ち

バッテリーはそこそこ持つ印象です。
届いて初日にほぼほぼフル稼働で1日使ってみた結果、およそ40%ぐらい減りました。

物理ボタン

全てアプリというわけではなく、電源と音量調整、再生停止のボタンが物理である。
電源のオン・オフは1秒ほどで出来るので使わない時はすぐにオフにすることが出来る。

実はAudioTechnicaのATH-CKS55XBTというワイヤレスイヤホンを持っていたのですが、
電源のオン・オフが面倒で使わなくなった経緯があった、ここも良かったです。

オーディオテクニカ SOLID BASS Bluetooth ワイヤレスステレオヘッドセット ATH-CKS55XBT

オーディオテクニカ SOLID BASS Bluetooth ワイヤレスステレオヘッドセット ATH-CKS55XBT

所感

ぶつ切りになる事はありますが、どこに行くときでも持ち歩けるぐらいの大きさで、 なおかつワイヤレス、iPhoneをハブにして色んなデバイスに繋ぐことが出来るなど、かなり良い製品だと思います。

Chrome Headless Browserを触った所感と、Flowtype・ES2017構文を使ってChrome Headless Browserを動かすライブラリを作っている話。

Chrome Headless Browser、思った以上に需要ありそうなので書いてみます。

まずは触った所感ですが、社内LTの際に喋った資料があるのでそちらをペタッと。

まとめると

  1. Phantom.jsの死亡
    • 唯一のメンテナが今後はChromeHeadlessに乗り換えるであろうとメンテナを辞任
    • 今後の構想はあるのか、phantomiumというPhantomJS + ChromeHeadlessの単語が組み合わさったレポジトリはある。
  2. Googleが開発している安心感
    • 今後Chromeを手放すことはそうそうないと思うので、今後のベストプラクティスになる可能性が高い。
  3. Production環境への投入は待ったほうが良い。
    • 謎の –disable-gpu Option
    • APIが落ち着いていない。
    • Seleniumなど、各種エコシステムが対応してある程度枯れるのが半年、ベストプラクティスが確立されるのが1年後ぐらいかなと予想。

軽く触ってみた。

Shellでならさくっと触ることは出来ます。

1.HTMLをDumpする

  • $ chrome --headless --disable-gpu --dump-dom https://www.chromestatus.com/

あとはAWS Lambda + API Gatewayに突っ込んで見たりもしました。

  1. キャプチャの撮影
  2. ページをPDFへ変換

Flowtype・AsyncAwait(ES2017)を利用してライブラリを作っている話

Githubとかも見てみたんですが、特にライブラリが無かったので、最近のJavaScriptのキャッチアップを兼ねて自分で作っています。

github.com

Node.jsで作っています。超絶α versionです。

Architectureとしては、

  • Flowtypeによる型付け
  • AsyncAwaitサポート(babel-preset-2017)
  • Eslint、EsdocによるDocument生成

TypeScriptにするかFlowtypeにするか迷いましたが、
現在所属している会社ではFlowtypeを使っているのでキャッチアップを兼ねてFlowtypeにしました。

このライブラリで行っていることは、

  1. Chromeの立ち上げ
  2. Chrome Debugging Protocolへの接続とレスポンスの取得

です。

作った動機としては、JavaScript界隈のキャッチアップも兼ねているのですが、
iQOS2.4 Plusの予約システムがあまりにも(お察し下さい)だったので(お察し下さい)という理由です。

簡単な使い方

examples/ にサンプルを老いてあります。
ここではPDFを出力する例を貼ります。

gist.github.com

実行すると、PDFが生成されます。

$ ./node_modules/.bin/babel-node example/printPdf.js
1497867182283.pdf       LICENSE                 docs/                   lib/                    package.json            yarn.lock
Dockerfile              README.md               example/                node_modules/           src/

f:id:teitei_tk:20170619191438p:plain

ライブラリの中身

  1. Chromeの立ち上げ

lighthouseというライブラリを利用しています。

github.com

ソースコードを覗いてみると、Typescriptベースで、childprosessでchromeを立ち上げているようですね。
https://github.com/GoogleChrome/lighthouse/blob/master/chrome-launcher/chrome-launcher.ts

というわけでこのClassをImportして使っています。

// @flow
import { ChromeLauncher } from 'lighthouse/lighthouse-cli/chrome-launcher';

export default class Launcher {
// do something.
};

処理はココらへんです。

https://github.com/teitei-tk/Chaldeas/blob/master/lib/chrome/launcher.js

  1. Debugging Protocolへの接続

これはchrome-remote-interfaceというライブラリを利用しています。
github.com

簡単な使い方はREADME.mdに乗っていますね。

こちらもソースコードを覗いてみると、Chromeへ対してリクエストを覗いているWrapperですね。

所感

devtools-viewerを眺めてみると面白そうな物はいっぱいあります。

  1. ServiceWorker Chrome DevTools Protocol Viewer - ServiceWorker

  2. Profiler Chrome DevTools Protocol Viewer - Profiler

が、やはり目立つExperimentalの文字。 Production環境への投入はもう少し待ったほうが良さそうですが、触ってみると楽しいことがあるかもしれません。

そしてPullRequestをお待ちしております :) github.com