IT音痴オーバーフォーティーおやじのストック記事倉庫

ユーザー登録Facebookチャットボットを作ってみました : こんにちは、中村です。 友人から「Facebookのチャットボットはどんなもんなかね。簡単に作れるのかな。」という相談を受けましたので、作ってみることにしました。 はじめに 今回IT系の転職サービスの仮会員登録をチャット […]

スポーツをITする（３）簡単なフォームチェック tensoleflow.js : 前回の記事 より、簡単なフォームチェックのロジックを追加してみました。 ボーン座標のズレ ブラウザのgetusermediaを使って、TensoleJS posenet を適当にVideoタグで表示すると、映し出された映像に描画するボーン座標にズレが生じます。 これは、縦横比の問題であろうと思われ、試行錯誤の結果、iPhone8の場合、横幅340px、縦幅380pxでズレが最小限に抑えられるようです。以下はズレた例です。 フォームチェックのテンプレート 某一流プロゴルファーのボーン座標を写真から取得しました。 ゴルフのアドレス（構え）としては、ちょっとおかしい感じがありますね。 写真を横幅170px、縦380pxにリザイズして、画面上に合うように手作業しました。 フォームチェックのロジック とりあえず最初は簡単な方法で、と思い、 ・テンプレートの目と耳以外の１３箇所それぞれの位置と写した映像のそれぞれの位置の距離を測る。 ・その距離が１０ピクセル以下なら１、でなければ０とする。 ・最大１３箇所中、何箇所が１になっているか、を百分率する。これを一致率としてみる。 var cnt = 0; var max = 13; var temp = Math.sqrt(Math.pow((tb.nose.x - vb.nose.x),2) + Math.pow((tb.nose.y - vb.nose.y),2)); if (temp < 10) { cnt++; } var temp = Math.sqrt(Math.pow((tb.leftShoulder.x - vb.leftShoulder.x),2) + Math.pow((tb.leftShoulder.y - vb.leftShoulder.y),2)); if (temp < 10) { cnt++; } ・・・・・ var rs = cnt / max * 100; $('.pa').html(Math.round(rs)); もっといい判定方法は無いかな、と思っています。 検証 スマホでは手

Wowzaログ解析 : はじめに 業務でWowzaを使うことになり、 これまで触ったことがなかったため、開発環境で動作を確認してみました。 この記事では、ログ出力に関する内容を備忘録的に書き残しておきます。 . ※Wowzaを利用した動画配信方法は 同じチームメンバーの記事に掲載されているため割愛します。 ffmpeg でファイルから4K HEVC疑似ライブストリーミング 構成 今回はこのような仕組みで動画配信を行います。 ＜MP4 → Streaming Server → MPEG-DASH → Player＞ 配信サーバとして使用するのは、 Wowza Streaming Engine（AWS EC2） となります。 今回は、以下のAMIからEC２を作成しました。 WowzaStreamingEngine-ebs-hvm-byol-4.7.5-x86_64-1522956083-668790f8-598f-42d3-ad55-a2670072241b-ami-73e04e0e.4 (ami-84e8f1f8) ログの場所 Wowzaのログはマネージャーとサーバの両方から確認することができます。 １. Wowza Streaming Engine Manager Wowzaにはマネージャーが用意されており、 ほとんどの設定はここから行えます。ログも確認可能です。 http://[Public IP]:8088/enginmanager ・Username：wowza ・Password：EC2のインスタンスID 設定次第で、ログ出力の仕方を変更することが可能です。 Server > Logs 詳しくは、公式ドキュメントを参照ください。 How to view log messages in Wowza Streaming Engine Manager ２. サーバログ Wowzaインストール済みのAMIから作成したEC2では、 ログは下記に出力されます。 /usr/local/WowzaStreamingEngine/logs ログ解析 動画は問題なく視聴できる前提で話を進めます。 上記の場所にあるアクセスログを確認します。 wowzastreaming

AWSとGCP間のインターネットVPN接続のファイル転送速度を計測してみる : はじめに 前回の記事でGCPとAWS間をインターネットVPNで接続しました。 https://qiita.com/TBT/items/2a834e119b10f51d57bf 今回はこの環境を使ってファイルの転送速度を確認してみます。 結論から言うと、 GCP～AWS間のインターネットVPNのファイル転送速度はかなり速いです。 基本環境 実施環境 GCP、AWSそれぞれの環境にWindowsサーバを立てる。 プライベートIPでWindowsファイル共有できるようにする。 2GBのファイル転送にかかる時間を計測する。 参考：ファイル作成Windowsコマンド fsutil file createnew testfile 2147483648 実行パターン 以下の3条件のうち1つだけを変えて計測 1. 時間帯 2. リージョン 3. マシンスペック 時間帯別 朝は09:00頃、昼は16:00頃、夜は23:00頃に計測 朝 昼 夜 1回目 76秒 70秒 64秒 2回目 71秒 65秒 84秒 3回目 74秒 62秒 62秒 転送速度 約220Mbps 約250Mbps 195Mbps～265Mbps 時間帯による大きな差はなかった リージョン別 同リージョン GCPは asia-northeast1 AWSは ap-northeast-1 異リージョン GCPは asia-northeast1 AWSは us-east-1 同リージョン 異リージョン 1回目 58秒 12分35秒 転送速度 約280Mbps 約21.7Mbps 異なるリージョンだと転送速度はかなり遅くなるが、インターネットVPNにしてはそれなりの速度は出ている。 マシンスペック別 最低スペック GCPは f1-micro （vCPU x 1、メモリ 0.6 GB） AWSは t3.nano （vCPU x 2、メモリ 0.5 GB） 中スペック GC

Dev AWSome Day 2018の復習①　～IAM編～ : 2018年10月30日（火）に開催されたAWSのイベント「 Dev AWSome Day 2018 」に参加してきましたので、忘れないように復習してみます。 なお、宣伝チックなお話とか、本筋とは関係ないお話は全てカットします。 ※当日時間が足らなくて、ほとんど写経状態だったので、じっくりと取り組んでみます 準備 AWSでサービスを起動したり設定したりするためには、以下の3つの方法があります。 マネージメントコンソールから操作する（その先でAPIを呼び出している） AWS CLIからAPIを呼び出す AWS SDKsからAPIを呼び出す 今回は使い勝手がよく、プログラムを組まなくてもよく、自動化に展開できる「AWS CLI」を使用します。 ハンズオン中では「Cloud9」からAWS CLIを実行していましたが、もったいないお化けが出てしまいますので、この復習ではローカルなPCにAWS CLIをインストールして実行します。 インストールの仕方は こちら を参考にしてください。 IAM（Identity and Access Management）のお話 アクセス管理には「認証」と「認可」の設定が必要となります。 認証（IAMユーザ） 誰がそのAPIを呼び出したのかを確認する 認証情報（ユーザ名／パスワード）を提示することで確認する 認可（IAMポリシー） APIを呼び出した人（もしくはプログラム）が、そのAPIを実行できる権限を持っているかを確認する 以下の2つの観点でアクセスできるかをチェックする どのリソースに対して どのような操作（＝APIコール） 認証（IAMユーザ） 「IAMユーザ名」と「パスワード」を登録します。 以降、マネージメントコンソールへは「IAMユーザ名」と「パスワード」で認証されます。 AWS CLIとAWS SDKsは「アクセスキー」で認証されます。 「アクセスキー」は「アクセスキーID」と「シークレットアクセスキー」で構成されます。 認可（IAMポリシー） 権限を記述しているJSONのドキュメントになります。 IAMポリシーはIAMユーザ、IAMグループ、IAMロールに割り当てられま

Dev AWSome Day 2018の復習③　～Amazon S3編～ : 前回 に続き、「 Dev AWSome Day 2018 」の復習として、「Amazon S3」を勉強し直します。 AWSにおいてS3は基本中の基本ですが、今回はアクセス権限の設定がメインのお話となります。 S3について こちらは改めて説明する必要もないと思いますが、インターネット経由でアクセスできる非常にスケーラブルで耐久性の高いオブジェクトストレージになります。 今回は、認証済みのユーザのみがファイルを保存できるようにします。 バケットの作成 S3を利用するには、データ(以下、オブジェクトとします) を格納するバケットを作成します。 マネージメントコンソールを開く 「S3」を選択 「バケットを作成する」ボタンをクリック 「バケット名」を入力し、「作成」ボタンをクリック バケットのCORS（Cross Origin Resource Sharing）設定 今回、公開用のWebアプリ側のコードをS3に置くため、そこから別のバケットにアクセスすることになります。 その許可の設定をCORSで行います。 先ほど作成したバケットを選択 「アクセス権限」を選択 「CORSの設定」ボタンをクリック CORSの構成を入力し、「保存」ボタンをクリック 入力するCORSの構成の例は以下のようになります。 <?xml version="1.0" encoding="UTF-8"?> <CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <CORSRule> <AllowedOrigin>*</AllowedOrigin> <AllowedMethod>HEAD</AllowedMethod> <AllowedMethod>GET</AllowedMethod> <AllowedMethod>PUT</AllowedM

Dev AWSome Day 2018の復習④　～Amazon Rekognition編～ : 前回 に続き、「 Dev AWSome Day 2018 」の復習として、「Amazon Rekognition」を勉強し直します。 今回ハンズオンで作成したサービスは、画像をアップロードし、AIで識別した結果を表示するものになります。 今回は、その裏側の処理であるAI部分の作成の説明になります。 処理の流れとしては、 S3に画像ファイルが登録されると、 それをLambdaが見つけ、 Rekognitionに渡し、 結果をDynamoDBに登録する といった感じになります。 ※実は、Rekognitionは呼ぶだけになりますので、説明の中心はLambdaになります DynamoDBの設定 DynamoDB は、どのような規模のデータも、スループットも満たすことができるフルマネージド型のNoSQL データベースです。 今回は、AWS CLIを使用して、DynamoDBの設定を行います。 まずテーブルの作成を行います。 > aws dynamodb create-table --cli-input-json file://./photos-table.json --region us-west-2 「photo-table.json」に設定されている内容で、DynamoDBにテーブルを作成します。 「photo-table.json」の内容は以下のようになっています。 { "LocalSecondaryIndexes": [ { "IndexName": "username-updatetime-index", "Projection": { "ProjectionType": "ALL" }, "KeySchema": [ { "Key

Dev AWSome Day 2018の復習④　～Amazon Rekognition編～ : 前回 に続き、「 Dev AWSome Day 2018 」の復習として、「Amazon Rekognition」を勉強し直します。 今回ハンズオンで作成したサービスは、画像をアップロードし、AIで識別した結果を表示するものになります。 今回は、その裏側の処理であるAI部分の作成の説明になります。 処理の流れとしては、 S3に画像ファイルが登録されると、 それをLambdaが見つけ、 Rekognitionに渡し、 結果をDynamoDBに登録する といった感じになります。 ※実は、Rekognitionは呼ぶだけになりますので、説明の中心はLambdaになります DynamoDBの設定 DynamoDB は、どのような規模のデータも、スループットも満たすことができるフルマネージド型のNoSQL データベースです。 今回は、AWS CLIを使用して、DynamoDBの設定を行います。 まずテーブルの作成を行います。 > aws dynamodb create-table --cli-input-json file://./photos-table.json --region us-west-2 「photo-table.json」に設定されている内容で、DynamoDBにテーブルを作成します。 「photo-table.json」の内容は以下のようになっています。 { "LocalSecondaryIndexes": [ { "IndexName": "username-updatetime-index", "Projection": { "ProjectionType": "ALL" }, "KeySchema": [ { "Key

Dev AWSome Day 2018の復習②　～Amazon Cognito編～ : 前回 に続き、「 Dev AWSome Day 2018 」の復習として、「Amazon Cognito」を勉強し直します。 「Amazon Cognito」とは シンプルで安全なユーザーサインアップ、サインイン、およびアクセス制御の機能をウェブアプリケーションやモバイルアプリケーションに素早く簡単に追加することができるサービスで、以下の機能があります。 Amazon Cognito ユーザープール 認証機能を担当 Amazon Cognito フェデレーテッドアイデンティティ 認可機能を担当 Amazon Cognito Sync デバイス上のデータとCogntino 間でユーザデータを同期 今回のハンズオンでは「ユーザプール」と「フェデレーテッドアイデンティティ」を使ってみました。 ユーザープールの作成 ユーザープールを利用すると、アプリケーションのユーザを管理し、アプリケーションにサインアップとサインインの機能を追加できます。 早速、ユーザープールの作成の仕方を、手順を追って説明していきます。 マネージメントコンソールを開く 「Cognito」を選択 「ユーザープールの管理」ボタンをクリック 「ユーザープールを作成する」ボタンをクリック 「プール名」を入力し、「デフォルトを確認する」を選択 「プールの作成」ボタンをクリック 「プールID」を保存（後で使います） 続けて、「アプリクライアント」というものを作成します。 「アプリクライアント」を選択 「アプリクライアントの追加」を選択 「アプリクライアント名」を入力し、「クライアントシークレットを生成」のチェックを外します ※今回Webベースのアプリケーションを作成するのですが、Webベースアプリケーションでは、クライアントシークレットはサポートしていないそうです 「アプリクライアントの作成」ボタンをクリック 「アプリクライアントID」を保存（後で使います） フェデレーテッドアイデンティティの作成 フェデレーテッドアイデンティティを利用すると、認証を受けたユーザに対して、AWS に対してどのような操作が可能かのアクセス制御機能(認可) を追加でき

AWS CodeCommit から Bitrise に接続する : ０．はじめに → SSH → AWS CodeCommit から Bitrise を経由して、スマホのアプリをデプロイするにあたって、接続する手順を試してみました。 １．SSH 鍵を作成する。 以下のコマンドを実行し、SSH鍵を作成する。 ssh-keygen -t rsa -f id_rsa_bitrise_sample ssh-keygenでファイル名を指定して鍵を生成する - Qiita ssh-keygenでファイル名を指定して作成 - Qiita ※ Bitrise で使う場合は、パスフレーズは入力しない!! $ ssh-keygen -t rsa -f id_rsa_bitrise_sample Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in id_rsa_bitrise_sample. Your public key has been saved in id_rsa_bitrise_sample.pub. The key fingerprint is: SHA256:9oHjSpQ8+FIF8PnaJPCZ9QHJZFQv788qFVkX7vQUkVA y.uekama@HW-GS-029.local The key's randomart image is: +---[RSA 2048]----+ | ...+=o. .oE+| | . +o. . o.o| | . o o o .o +.| | = B o +o o..| | . @ S o .. ..| | + O o o. | | . + o ... | | o . . o | | . ...o | +----[SHA256]-----+ ２．Bitrise から AWS CodeCo

30分でelectronをはじめる : はじめに electronでhello worldを表示させる(linux環境) 環境 takumi@takumi:~$ uname -a Linux takumi 4.15.0-38-generic #41-Ubuntu SMP Wed Oct 10 10:59:38 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux node.js npm Ubuntuに最新のNode.jsを難なくインストールする @seibe さん、ありがとうございます。 takumi@takumi:~$ sudo apt-get install -y nodejs npm ... ... takumi@takumi:~$ sudo npm cache clean takumi@takumi:~$ sudo npm install n -g /usr/local/bin/n -> /usr/local/lib/node_modules/n/bin/n /usr/local/lib └── n@2.1.12 takumi@takumi:~$ sudo n stable install : node-v11.0.0 mkdir : /usr/local/n/versions/node/11.0.0 fetch : https://nodejs.org/dist/v11.0.0/node-v11.0.0-linux-x64.tar.gz installed : v11.0.0 takumi@takumi:~$ sudo ln -sf /usr/local/bin/node /usr/bin/node takumi@takumi:~$ node -v v11.0.0 takumi@takumi:~$ sudo apt-get purge -y nodejs npm ... ... takumi@takumi:~$ node -v v11.0.0 takumi@takumi:~$ npm -v 6.4.1 electronのインストール 作業ディレクトリを作る takumi@takumi:~$ mk

ssh & viしてのリリースを、git管理に移行して、デプロイフローを整備する : ssh & vi してのリリースとは ソースコードは、EC2サーバーの特定の場所に、唯一存在している ソースコードは、EC2サーバーにsshして、viすることでリリースしている を指しています。これをどうにかして、 github管理にしたい githubにあるソースコードをデプロイできるようにしたい 以下、EC2インスタンスの /var/www/cgi-bin/ 以下にソースコードを散らかしてあると仮定して書きます。 サーバーに設置してあるソースコードを手元に持ってくる EC2インスタンス内の /var/www/cgi-bin をまるっと手元にscpしてきます。権限、ログファイルなどなどややこしいことは一旦考えません。 $ scp -i ~/.ssh/hoge.pem -r ec2-user@ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com:/var/www/cgi-bin ./ githubでプライベートリポジトリをひとつ作成する githubで課金しましょう。プライベートリポジトリを作れるようになります。または、bitbucket, gitlabなど他のサービスを使っても構わないです。とにかくプライベートリポジトリです。 github管理する EC2サーバーからscpしてきたときに、実行権限が消失してるかもしれないので、適宜付与してからcommitしてください。 $ git clone git@github.com:hoge-company/hoge-repos.git $ mv cgi-bin/* hoge-repos/ $ cd hoge-repos $ git add . $ git commit -m "initial commit" $ git push デプロイする (初回) いま置いてある cgi-bin をどけます。 $ ssh -i ~/.ssh/hoge.pem ec2-user@ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com $ c

Ubuntu 18.04LTSでAWS EC2のNATインスタンスを構築する : 前提条件（事前準備） Ubuntu 18.04LTS がインストールされたEC2インスタンスを用意します。 インスタンスタイプは最初はt2.nanoやt2.microで問題ありません。（パフォーマンスが出ない場合は、上位のインスタンスタイプへ変更します） ストレージは8GB（デフォルト）で十分足ります。 無くても動きますが、必要に応じてSWAPも追加します。 NATインスタンスを配置するVPCサブネットに関連付けられたルートテーブルの 0.0.0.0/0 には、インターネットゲートウェイをアタッチしておきます。 sysctl.confの設定 IPv6の無効化と、IPフォワーディングの有効化を行います。 # echo "net.ipv4.ip_forward = 1 >> /etc/sysctl.conf" # echo "net.ipv6.conf.all.disable_ipv6 = 1" >> /etc/sysctl.conf # echo "net.ipv6.conf.default.disable_ipv6 = 1" >> /etc/sysctl.conf # sysctl -p iptablesの設定 NAPT(IPマスカレード)の設定を行います。 最初に、iptablesの設定永続化のために、iptables-persistentをaptインストールします。 # apt update && apt install -y iptables-persistent 次に、以下のコマンドを実行します。 iptables -t nat -A POSTROUTING -o eth0 -s <IPv4 CIDR> -j MASQUERADE <IPv4 CIDR> には、VPC全体のIPアドレス範囲を、 IPアドレス（ネットワークアドレス）/サブネットマスク（マスクbit数） の初期で指定します。例えば、 10.0.0.0/16 というVPCが存在する場合は、それを <IPv4 CIDR>