技術関連の覚書

案件でやったり自宅で試したことの覚書

herokuでwebアプリを作る

herokuとは

PaaS=Platform as a Service Webアプリケーションを動かすためのサーバーやDB環境などが既に用意されていて、heroku gitを利用することで、アプリケーションを作成してgitにpushするだけでデプロイまでしてくれる。

無料でも1万行までのDBの利用やheroku gitでのCI/CDができるサービスなので学習用にも十分に使えるサービス。

準備

  1. herokuへの登録

  2. heroku CLIをインストールする

Command Line | Heroku Dev Center でheroku CLIをインストールする。

herokuアプリを作る

  1. 最初にローカルgitリポジトリを作ってcommitまでしておく

  2. heroku cli でheroku上にアプリを作成する

  3. herokuのリポジトリにpushする

  4. アプリを起動する

mkdir herokuapp
cd herokuapp
git init
git add .
git commit -m "first commit"
heroku create -a herokuapp
git push heroku master
heroku open

以後はmasterにpushするとビルドしてデプロイまで行ってくれる。 gradleの設定などにより、テストも行うことができる。 heroku上のgitでデプロイ管理する際は開発中はdevelopなどのブランチで開発し、masterにmergeしてデプロイするようにする。

アプリの削除

heroku apps:destroy -a アプリ名 で削除する。この場合は確認のためにアプリ名の入力が求められる。 heroku apps:destroy -a --confirm アプリ名 と打つと確認を求められない。

heroku apps:destroy -a obscure-peak-42849
 ▸    WARNING: This will delete ⬢ obscure-peak-42849 including
 ▸    all add-ons.
 ▸    To proceed, type obscure-peak-42849 or re-run this
 ▸    command with --confirm obscure-peak-42849

> obscure-peak-42849
Destroying ⬢ obscure-peak-42849 (including all add-ons)... done

C#やってみた

C#

仕事でC#を使う機会ができたのでそのメモです。

C#開発環境 Windowsなら当然VisualStudioを使ったほうがいいけど、Linuxではその環境がなかったのでmonoを使います。 会社のPCではVisualStudio2019を使っています。 www.mono-project.com

そうやって始めてみたものの、やはり業務で使う方がメインなのでVisualStudioでの開発になりました。

C#はJavaのパクリとよく言われます。だからJavaが組めれば大丈夫ということで始めましたが、微妙に違う点はあります。

継承の記述

class Child: Parent
{
}

この書き方はC++っぽい

型パラメータ付き

class Parent<T1, T2, S>
    where T1: Tone
    where T2<Sub>: Ttwo
    where S: Sub
{
    abstract T2<S> func(T1 param);
}
class Child: Parent<T11, T22, SS>
{
    T22<SS> func(T11 param)
    {
        // 実装
    }    
}

こういう書き方はできない。調べてみると意外と書かれていないのでメモっとく

class C<T1, T2<S>>

知っておくと便利なのがDataTableオブジェクト DBテーブルを格納するような方で２時限配列のマップのようなオブジェクトです。

メンバ 機能
Rows 行オブジェクト
Count 行数を返す

とりあえずここまで

Excelマクロでスクショを取る

自分の仕事は主にSESなので案件によってはテストでExcelにスクショを貼り付けて提出するということを未だにやってるところに当たることがある。 できればそういう作業はやりたくないのでツール化すればよいのだけど（本当はもっと有効なテストをしてスクショ貼りなんてものは法律で禁止してもいいと思ってる） 現状、やらざるをえないところはまだ多いです。

スクショの対象となるツールがブラウザだったり、他のアプリケーションだったりと様々なので完全に一般化することは難しいけど、だいたいこのやり方でできるのではないかということをやってみました。

そして、Excelマクロにした理由は

  • 他のツール（PythonやPerlなど）は入れてはいけないところも多い

  • PowershellだとOSの設定によってはファイルから実行できない場合がある

  • Excelにスクショ貼り付けるのでこの場合Excelは確実にインストールされている

送信データの管理などもやりやすいこともあり本来の使い方ではないけれどもExcelを自動スクショ撮りツールにしてみました。

流れは

  1. エビデンスを貼り付けるExcelを作成する

  2. 実行するツールを起動

  3. 何かしらのパラメータを入力項目に設定する

  4. 実行ボタンを押す

  5. 結果が出たらスクショをする

  6. 結果の内容に応じてスクロールして全体を貼り付ける

  7. エビデンスのExcelを保存して終了

エビデンス用Excelの作成 フォーマットが決まっていればテンプレートを作ってそこに貼り付けて名前を付けて保存する方法が良いと思います。

実行ツールの起動

Dim excel As Workbook

Application.ScreenUpdating = False ' Excelの画面の変化を表示をしないことで高速に実行できる
Set excel = WOrkbooks.Open("template.xlsx")
' テスト用のツール起動
' テスト実施
' スクショコピペ
Application.DisplayAlerts = False ' 上書きする場合にダイアログを出さないようにする
excel.SaveAs "テスト結果.xlsx" ' 提出するファイル名に合わせてください
Application.DisplayAlerts = True ' 上書き時のダイアログ設定を元に戻す
excel.Close
Application.ScreenUpdating = True ' Excelの表示を元に戻す

テスト用ツールの起動

Dim rc As Long

rc = Shell(テストツール, vbMaximizeFocus) ’最大化して起動する。rcはツールにフォーカスする時にこの値を使う
’ この時点ではツールにフォーカスされている。
' 値の設定などはSendKeysを使って値を送ったり、タブ移動などを行う
’ SendKeys "{TAB}" タブ移動
’ SendKeys "{ENTER}" エンターキー押下
' SendKeys "文字列" 文字列を送る
' SendKeys "{UP}" ↑ボタン押下
' SendKeys "{^a}" ctrl+a ^はctrlキーの同時押しになる
' SendKeys "%{F4}" Alt+F4 %はAltキーの同時押しになる、{F数字}はファンクションキー
’ SendKeysでツール上の操作をしたり、Ctrl+AとCtrl+Cでテキストのコピペができたりする
’ 当然、SendKeysで送るのはツールだけでなくエビデンスのExcelにも送るのでフォーカスはExcelとツールを何度も往復することになる
’ Excelへは上記のコードで定義したexcelでexcel.Worksheets("シート名").cells(2,3) = クリップボードの値
' などとすればテキストは貼り付けられる
' 画面のスクショは次のコードで
AppActivate rc ' ツールにフォーカスする
SendKeys "%{F4}" ' Alt+F4でツールを終了する

スクショの貼り付け

ここを参照して作りました。 ExcelVBAでスクリーンショットを取る方法 - Qiita keybd_eventはOSの環境で64ビットか32ビットどちらかを使います。

まずはスクショを撮るためのサブルーチンを定義する。画面を最大化してあるが、ツールバーが入ると嫌なのでAlt+PrtScでツールだけをスクショする。 SendKeysでも送れるようだけども実際にやってみるとうまく行かなかったのでこちらを使いました。 ライブラリの呼び出しについてはここでは書かないので

' こちらは64ビット版、32ビットの場合は上記URLを参照
Private Declare PtrSafe Sub keybd_event Lib "user32" ( _
    ByVal bVk As Byte, _
    ByVal bScan As Byte, _
    ByVal dwFlags As Long, _
    ByVal dwExtraInfo As Long _
        )

Public Sub アクティブ画面を撮る()
    keybd_event &HA4, 0&, &H1, 0& ' &HA4がAltキー、&H1キーを押す
    keybd_event vbKeySnapshot, 0&, &H1, 0& ' vbKeySnapshotがPrtScキー番号は&H2Cらしい
    keybd_event vbKeySnapshot, 0&, &H1 Or &H2, 0& 'PrtScキー &H2でキーを放す
    keybd_event &HA4, 0&, &H1 Or &H2, 0& ' Atlキーを放す
End Sub

これを組み合わせることで大体のスクショはとれるはず

加速度センサを複数センシングする

ラズパイ I2C通信 センシング 電子工作

前回http://blog.hatena.ne.jp/boctok-ctpoba/boctoc1969.hatenablog.com/edit?entry=26006613474310903

MPU-6050でセンシングした記事を書いたので今回はそれを複数センシングする話を書きます。

I2C通信では複数の機器を同時に通信することができますが、同じIDの機器はつなげられません。

ここでアナログスイッチ74HC4051を使ってセンサーデータを切り替えながら取得していきます。

http://www.b-system.co.jp/shop/UPD74HC4053G-T2.pdf

アナログスイッチは、電気的に入力された信号に応じて回路のオンオフをするスイッチです。

例えば12MHzのクロックで8ビットの信号を取得する場合、CS信号やヘッダなどで12のクロック分の信号を取得すると考えて1μ秒で１つの信号を受け取ります。 そうしたらスイッチを切り替えてもう一つのセンサのデータを取り、これを繰り返すことで複数の同じセンサの信号を受け取ることができます。

加速度センサ MPU-6050

加速度、ジャイロ６軸センサーのMPU-6050を使ってセンシング。

センサとの接続 センサの駆動電源は3.3Vなのでラズパイの3.3Vピンから電源を取ります。 I2C通信なので接続するのは電源(VccとGND)と信号線２本の合計４本だけです。

ラズパイ3やZEROの場合は 1(3.3V)、3(SDA)、5(SCL)、6(GND)になります。 これを基盤に書かれているとおりに配線します。 センサとの通信は"I2Cなのでまずraspi-confでI2Cを有効化する。

i2c-toolsをインストールしておく。

sudo apt update
sudo apt install -y i2c-tools

接続確認 i2cdetectコマンドで接続されているかを確認。 レジスタは68なので68が検出されればOK

pi@raspi:~ $ i2cdetect  -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

Pythonで値を取るための準備

必要なライブラリをインストール

sudo apt -y install python3-smbus

ラズパイ接続用プリント基盤作成

秋月でいいユニバーサル基板を見つけたので使ってみることにした。 ラズパイ３のGPIO40ピンを接続して使えるようにした基盤なのでこれを使う。

最初、被覆線でやってみたけど、これだと配線がごちゃごちゃするので通電テープを使う。 ８mm幅のテープだと大変なことがわかったけど、2.5mmピッチの基盤でこれ以上の大きさだと切り取りながら使うことが多そうなので8mmをつなぎながら使うことにした。 本当は13mm、25mmも買っておいて用途に合わせて使うのが一番良いのだろうけど、1000円以上するのでもう少し予算があるときにする。

IC、リレーは交換できるようにICソケット、を使うが、リレーの場合ソケットがなかったので丸ピンコネクタで代用することにした ピンコネクタだと抜けてしまって使えなかったので。

ラズパイとの接続は40ピンのGPIOでつなごうとしたけども、４０箇所のはんだ付けは面倒。 実際に使うのも一部だけなので文字回こねくたにしてみた。

本当なら、プリント基板を作るのが良いのだろうけど、廃液処理が大変そうということで断念。

DevelopersIO2019

今年聞いてきたもの

タイトル スピーカー
Developers.IO CAFEのこれまでとこれから 〜顧客体験へのフォーカスから考える技術選択〜 横田聡
「今」のAI技術と「3年後」のAI技術のご紹介 清野剛史（せーの）
AWS初心者が陥りやすい運用アンチパターンから学ぶ成功の法則 JIG-SAW 小嶋一毅 氏
Serverless ー SaaS版 Developers.IO Cafeのアーキテクチャ設計で考えたこと ー 渡辺修司
ITの民主化とユーザー部門によるIoTコトはじめ LIXIL 佐々木義 氏
AWSに超詳しいエンジニアが育つ環境を作る方法 豊崎隆
クラメソ金曜ロードショー「沈黙の分析3」〜スティーブン・セガール映画の邦題に「沈黙」がつくかどうか機械学習で予測してみた 玉井励
全部Excelだけで実現しようとして後悔するデータ分析 Second Edition 小澤祐也（じょんすみす）
ハイブリッド/マルチVPC環境を構成するためのAWSネットワーク完全理解 菊池修治

DevelopersIO CAFEは去年聞いたものから現状まで ０ヶ月目 (横田社長が)感動する １ヶ月目 とりあえず動くものにしてみる ２ヶ月目 展示する

無謀なスケジュー感だけど思うけど、

  • 動画でやりたいことを見せる

  • 要件定義書や設計書を書いてる時間それらの合意にかける時間を考えずにすむ。

社内だからできたことだけど、この成功事例を広めて無駄に時間をかけて大量の書類を作る文化をそろそろやめてもいいと思う。

できたところと出来上がったイメージを組み合わせてやってみる

  • 出来上がってから試す場合、出来上がりを待つのも時間がかかる

  • 出来上がってないところをダミーにすることで次にやるべきイメージができる

決済部分ができていなくても決済画面を表示することはできる 実際の買い物の決済と違っていてもイメージはできるようになるからそこからまた勧めていくことができる

こういったことが３ヶ月で展示までたどり着いた要因だとは思う。 ここまでは前回の話でも出てきたところで、その続きは 実店舗Developers.IO CAFEを作ってみた。

実際に運用することで、

  • お客様からのフィードバック

  • カフェ店員からのフィードバック

  • エンジニアからのフィードバック

これらを得ることができて次にやるべきことがわかってくる。 ただし、この時点では利益はあまり出ない。

実際に店舗を作ることで問い合わせも来る そうなってくると、量産化、利益を生むための仕組みが必要。

スピード重視の開発から保守性、汎用性を考えた開発 モジュール化、基盤の発注など

まとめると、 紙（パワポ資料）よりも動画 まず作ってみる できてないところはダミーで全部つなげて試してみる やってみて蓄えたノウハウがそのまま事業になる

AWS初心者が陥りやすい運用アンチパターンから学ぶ成功の法則 アンチパターン：監視ができていない、監視しすぎる、稼働目標が高すぎる、想定外を想定していない、運用を意識していない構成

監視についてはお客さんとどのように監視していくか、テスト段階で実際に必要だったかをブラッシュアップしていき最適化していくということはできていたが 稼働目標が高すぎるについては、コストとのバランスを見ないと何でも盛り込みすぎてコストに見合わないような構成が出来上がる。 想定外を想定することは一見難しそうだけど、エスカレーションフローを考える、ユーザーへの障害アナウンス、DR環境の準備 これらは、運用手順として盛り込んでおくことで解消されること。 運用を意識していない構成は、AWSがPaaSであることを意識しないで運用設計をしてしまうこと。 既存のオンプレをそのままリプレースしても構成は可能だし、AWSのサービスを利用しなくてもCloudWatchを利用して変更や追加に柔軟に対応できるようにする。 RDSを導入しなくてもGuardDutyを利用してセキュリティを強化するということもできる。

実際にやってみたことでは、Elasticsearchのバージョンが合わずにElasticCacheを使えずEC2にElasticsearchを入れて動かすといった運用をした。 その時、オンプレの時に出していたログでは足りない部分があったりで導入前に改修 その後も運用していくうちに不要なログや足りないログを調整し、その管理は社内のGerritのmasterにcommitした時にフックしてCLoudWatchで再構築

と言ったことをしていたのでわかりみな部分も多かった。

クラメソ金曜ロードショー AIに詳しくない人がAIをやってみた話

まず本を見る そのとおりにやってみる データパターンを考えてみる データの入手先を探す 実際にそのサンプルが適当か、AIにする合理性があるかは考えず、まずやってみたというところ 実際に正しいかどうかはやってみたあとにわかるというのも横田DeGoに近いかもしれない

サンプル数が５０以下は不可能なので、映画のタイトルという一人の俳優が出演するのに限界があるものではサンプルが集まるかも厳しい ポスターに写ってる面積から割り出してみたけど別の俳優に認識されたり、人として認識されないので手作業で補正するところもあった そういう苦労をしたのに実際にはポスターの面積は関係なかった など、こういうことはやってみないとわからないという典型例です。