【失敗あり】MQTT（Mosquitto）での接続

今まで色々な開発に携わってきたが、通信に関わるものは多くなく以前半年ほどNGNのプロジェクトに携わったのを最後にもう随分無関係になっていた。今回、MQTTの通信を利用したシステム開発のプロジェクトに携わり、そこで得た知見というかHOWTOを今後のために残しておくことにする。

このエントリーでは、「MQTTとは何か？」という部分にはフューチャーしないことにする。もし、MQTTの基本概念を知りたい方は、参照先サイトでまずは概要を理解しておくと良いと思う。

MQTTとは | かもめエンジニアリング

接続確認の前に、環境について

今回はローカル環境（ローカルPC、もしくはサーバにある環境のみの閉じた環境）だけでなく、ローカルPCからサーバ環境の双方向から通信を確認できるようにしたい。

段階として、ローカルPC内での通信確認、そしてサーバ環境内での通信確認、最後にローカルPCとサーバ環境の接続確認を行う。

まずはローカルPC内でのMosquittoの動作確認

続いて、サーバ環境内でのMosquitto動作確認

最後に（どちらでもいいが）サーバのMosquitto brokerに対してのローカルPCからの通信確認

ローカルPCとサーバにそれぞれMosquittoをインストールする

インストール自体は非常に簡単で、下記のリンクから対象となるファイルを選択すればいいだけです。 https://mosquitto.org/download/

ダウンロードページ

インストールしたファイルを実行すればクライアントPCにMosquittoがインストールされます。 インストールについての詳細は以下のサイトを参考にしてみてください。OpenSSLとpthreadsの追加インストールが必要なことが書かれています。

Windows 7 64bitにMQTT(Mosquitto)を入れるメモ – 1ft-seabass.jp.MEMO

Mosquitto(MQTT Broker)のインストール - Qiita

インストールされたMosquittoの動作確認

これ自体は非常に簡単で、Windowsならコマンドプロンプトを２つ起動（Subscribe実行用とPublish実行用）して、インストール先のフォルダへ移動し、それぞれで

• mosquitto_sub -t test
• mosquitto_pub -t test -m test_message

コマンドを実行してあげると、Subscriber側で「test_message」が受信されたことを確認できるはずです。

ローカルPCとサーバでのMQTT接続確認

上記のように、ローカルPC内とサーバ内でそれぞれBrokerを立ち上げて、内部でSub/Pub自体はすぐに確認ができるのですが、 ローカルPC、またはサーバ側のどちらかにBrokerを立ち上げて、お互いにMQTTの接続を確認しようとすると、なぜか上手くいきませんでした。

サーバ側でBrokerを立ち上げてローカルPC側からSub/Pubを実行する想定です。

• mosquitto_sub -h {サーバのIP} -p 1883 -t test
• mosquitto_pub -h {サーバのIP} -p 1883 -t test -m test_message

上記のようなコマンドを実行してもメッセージを受け取ることができません。 （コマンド自体は正しい）なぜか？

※この段階で、ローカルPC－サーバ間で問題なくMQTT通信の確認が取れていればそれは別にいいです。
自分の場合、ここで引っかかってしまった、という話ですので...

それは、サーバ側（ホスト側）の'ポートが開いていないこと'が原因だったのですね。
環境にもよりますが、TCPのポート1883を開いてあげる必要があります。もしくはファイアウォール、ウィルス対策ソフトが 邪魔をしていることも念頭に置いておいてください。

上記の問題がなければ、ホスト環境とローカル環境でMQTTのpub/subが確認できるはずです。

モノのインターネットのコトハジメ (Shoeisha Digital First)

JavaScriptではじめるIoT いろはの“い" Raspberry Piで楽々試作

つないで つないで プログラミング Node-REDでつくる初めてのアプリ

【CentOS7】gitのインストールと初期設定【備忘録】

ドットインストールにて、色々とプログラムの勉強をしているのだけど、最初の開発環境構築（for mac)の段階は済んだものの、CentOSのバージョンが6でちょっと古いため、ドットインストールが設定している環境とは別にCentOS7をインストールして作業をしている。※yumが使えなかったり面倒なのだ

Git のインストール

まずは何よりGitのインストールをする。
sudo yum -y install git
インストールされたGitのバージョンを確認
git --version

git version 1.8.3.1 とりあえずOK

Git の設定をする

ユーザ名とEメールアドレスを設定する(Git は保存した人の名前とEメールアドレスを記載することになっているため）

~/.gitconfig　に直接書いてもいいと思うけど、コマンドラインで出来てしまうので今回はそっちの方で
git config --global user.name "(your name)"
git config --global user.email "(your email)"

メッセージの色分けを行う設定をONにする

git config --global color.ui true

vimを基本エディタに設定する

git config --global core.editor vim

※そもそもvimがインストールされてない場合は、以下のコマンドを実行する
sudo yum -y install vim-enhanced

設定内容の確認

git config -l

user.name=設定した名前
user.email=設定したメールアドレス
color.ui=true
core.editor=vim

git init の宣言

対象ディレクトリにて「Gitを使うよ〜」という宣言を行う。
git init

何も問題なければ（？）以下のようなメッセージが出る

Initialized empty Git repository in /home/git initを実行したディレクトリ名/.git/
ちなみにgit iniitを実行すると、.gitというディレクトリが生成され、その中にいろんなファイルが格納される。
どんなファイルが格納されるのかについてはよくわからない。

専門書を読んで本格的に勉強したほうがいいかもしれんね...

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

独習Git

いちばんやさしいGit&GitHubの教本 人気講師が教えるバージョン管理&共有入門 (「いちばんやさしい教本」シリーズ)

サルでもわかるGit入門

去年の夏から見た映画羅列

去年（2018年）の夏頃から週末は映画をレンタルしてきて観ることが自分の金曜日の過ごし方のデフォルトになってきた。それまで映画のレンタルはあまりしてなくて、たまに借りるくらいだったけど、「金曜日は映画を観る日」と決めてから毎週末が楽しみになってきた。

以下、観て来た映画を羅列してみる。覚えていたら感想も。

• 観た映画
  • インスペクション（SF)　映像表現がよかった
  • ジョン・ウィック２（アクション）　愛犬の復讐という目的がある分、１の方がよかった
  • エリジウム（SF)　世界観の設定がよかった
  • シン・ゴジラ（SF）　映画館で見て、テレビ放送見て、やっぱりまた借りてみた。面白い。
  • 独裁者と小さな孫（ドラマ）　よかった
  • 狼たちの処刑台（アクション）　期待した割に面白くなかった
  • ニンジャアサシン（アクション） アクションはよかった
  • ルーシー（SF) 脳の性能を100％発揮したら、というIFが面白かった
  • ザ・ウォーカー（SF)　面白かった。
  • ワンダーウーマン（SF）　期待以上に面白かった
  • Ghost in the Shell(SF) タケシだけ日本語喋ってるの違和感あった
  • グランドイリュージョン（ドラマ）　まぁまぁ
  • PIXELS(SF) SFコメディとして面白かった
  • アンドリューNDR114（SF)　哲学的なドラマ。よかった
  • キングスマン２ゴールデンサークル（アクション）　面白かった
  • スーパーの女（ドラマ）　爽快な展開。伊丹監督はやっぱすごい
  • madmax(アクション)　まぁまぁ
  • madmax2(アクション)　まぁまぁ
  • カリオストロの城（アニメ）　面白い！！最高！
  • madmax thunderdome(アクション)　まぁまぁ
  • madmax furyroad(アクション)　面白い！
  • ジュラシックワールド炎の王国（SF)　面白い！ラプトル可愛い！
  • メッセージ（SF)　難解な要素もあるけど、面白い。
  • リベリオン（SF)　演出に不備はあるものの、ガン=カタ最高！

  アクションとSFを中心に、たまーにドラマ系とアニメも借りてみた感じ。 観初めて思ったのは、「結構みてない映画たくさんあるなぁ〜〜〜」ということ。

  結局劇場で見たのは、「イコライザー２」と「ブレードランナー2049」だけ。 たくさんいい映画があるので、今後も「週末は映画」というスタイルは続けていきたいな。

イコライザー2 ブルーレイ&DVDセット [Blu-ray]

ルパン三世 カリオストロの城 [Blu-ray]

マッドマックス 怒りのデス・ロード [4K ULTRA HD + Blu-ray]

マッドマックス - PS4

Web APIのテストを通して学んだこと（現在進行形）

現在、あるWeb APIのテスト業務に携わっている。「Web API」と書いたが、実はWebAPIとは何か？という部分が実ははっきりとよくわかっているわけではない。漠然とWebアプリケーションと同義と捉えていたけれども、厳密には違うような気もしている。

クライアントサイドとサーバサイドでHTTPでリクエストとレスポンスがあると、WebAPIという仕組みになると理解しているのだけど、合っているだろうか...静的なサイト（Webページは）WebAPIではない、という理解で合っているだろうか...

今回のエントリーではその部分（WebAPIの詳細）については、無関係ではないが書きたい部分では無いので、省略します。

今までやってきたWebAPIのテストは導入に過ぎなかった

これまで3つのWebAPIのプロジェクトに関わってきて、結合テスト（含む単体テスト）をメインに経験を積んできた。 それまで非Webの業務系アプリケーションのみの経験しかない自分にとっては、「これがWebAPIのテストというものか！」と 非常に勉強になったし、この先テストエンジニアとして成長したいと思わせるものだった。

問題は「無知ゆえの万能感」だったのかも知れないが、３つのプロジェクトを経験したことで「これでどこのプロジェクトに参加しても大丈夫」と 高を括ったことだろうと思う。

今のWebAPIプロジェクトに参加してわかったが、これまでの２つのプロジェクトは使うツールにしても非常に限定的で 現在のWeb界隈でいえば何も使ってないに等しい状態だったのでは？と今では思う。

• これまでのプロジェクトで利用したツール類

  • SVN
  • Oracle web Developer
  • Internet Explorer(Chrome)のブラウザ
  • Red Mine
  • Excel、WordといったMicrosoftOffice類

• 現在のプロジェクトで利用しているツール類

  • SVN
  • Google Drive★
  • PostMan★
  • Git★
  • Google Spreadsheet★
  • Internet Explorer(Chrome)のブラウザ
  • 上記ブラウザのF12機能★
  • Docker★
  • CentOS − Slack★
  • RedMine
  • Excel、WordといったOffice類
  • XAMPP★
  • AWS★

「★」印をつけた箇所が新しく知ったり使うことになったツール類なのだけども、数えたら9つもあった。

幸い、「使ったことないんですか？w」というようなこちらの無知を笑うような人がいないので助かっているが、 知らない・使ったことのないものが多過ぎて正直しんどい。

GoogleDriveについては私用で利用していたけど、業務的に利用していたわけじゃなかったので、 「こうやって使うと共有してドキュメントが見られるのか」と初めて知ることになっている状態。

XAMPPについては業務利用の経験はなかったが、PHPの勉強を個人的にしていたおかげで、XAMPPそのものについては 知っていたのでよかった。

AWSについては、利用はしているがサーバにアクセスしているだけなので、本質的な意味では何も知らないまま。

テストのやり方に違いはあるか

復習の意味も含めて、これまでのWebAPIテストのやり方を振り返ってみよう。

これまで
⓪. テストソースに更新があればSVNのUPDATEで最新化
①. テストケースに沿って、入力値をブラウザの各項目に入力
②. 登録・更新形であれば、DBを参照しINSERTされているかUPDATEされているかを確認
③. 参照系であれば、事前にDBを参照し参照先のテーブルの値が表示されているかを確認　

そして、現在のテストのやり方はどうだろうか。

現在
⓪. テストソースに更新があれば、SVNかGitにて最新化
①. Dockerに入り、RDBを起動
②. テストケースに沿って、入力値をブラウザの各項目に入力。場合によってはPOSTMAN経由でJSON入力
③. 登録・更新形であれば、DBを参照しINSERTされているかUPDATEされているかを確認
④. リクエストが通っているか、レスポンス結果は想定通りであるかをF12（ブラウザの開発者モード）で確認
⑤. 参照系であれば、事前にDBを参照し参照先のテーブルの値が表示されているかを確認　　
⑥. ④と同じ

眺めてみると基本の部分は変わらないことがわかる。JSON入力のためにPOSTMANを利用したり、 ソースファイルの最新化にSVNと並行してGitを利用している。 リクエストとレスポンスの確認としてブラウザの開発者モードを利用しているのは大きな違いと言えるかも知れない。

実は、「JSON」について現在のプロジェクトで初めて知った。 これまで入力といえば、数値か文字列かくらいで JSONのようなひとまとまりのデータ形式というのは意外なデータ形式だった。 C言語でいえば、構造体のような。

どんな形式かというのはわかったが、受け取り側はこれをどのように処理しているのかまではまだわかってない。 今後の課題である。

WebAPIのテストを通して学んだこと、は何か

ただ現在使っているツールを並べただけのエントリーになってしまった感があるが、 何より「今までテストしたことは方向性として間違っていたわけではないが、ツールの知識がなさ過ぎた」 ということを現在のプロジェクトで痛いほど思い知った。それが学んだことかも知れない。


はっきりいって、今のソフトウェア開発においてツールを知らないということは 開発環境を知らないということと同じだと思う。 C言語の開発環境では、UNIXとエディタ・DB（とDBをみるためのクライアントツール）を知っていればよかったけど Web業界は毎年新しい環境が生まれて利用されているので、せめて標準とされているものくらい 知っておかないといけない。


何よりその知識がないと、「テストができない」ことがよくわかった。

わかばちゃんと学ぶ Git使い方入門

わかばちゃんと学ぶ Webサイト制作の基本

ポストマン (ハヤカワ文庫SF)

Docker/Kubernetes 実践コンテナ開発入門

独学プログラマー Python言語の基本から仕事のやり方まで

AWSをはじめよう　?AWSによる環境構築を1から10まで? はじめようシリーズ

【テスト設計】テスト仕様書を考えるのってこんなに難しかったのか

テスト設計してます！と面談では答えた。経歴上にも確かにテスト仕様書書いたり、テスト計画書書いたり、シナリオ書いたりしてたので、嘘は言ってないつもりだった。

今のプロジェクトで、「テスト仕様書のフォーマットを考えてほしい」という要望にも応えられるつもりだったのだけど、いざフォーマットを作り出すと「？」となることが多くて、「今までテスト設計したつもりになってたけど、実はテスト設計なんてしてなかったんじゃ」と不安になってきた。

テストを設計するというと、自分の場合「どんなテストケースを作ればいいか」を重点に考えるけど総合的に設計するとなると「どんなテストケースを作ればいいか」は枝葉と言ってもいいかもしれない。何が幹になるの？というのはまだわかってない。

そもそもフォーマットを作る、となると

• ディレクトリ構成
• テスト仕様書の構成（UTの項目、ITの項目、STの項目）
• エビデンスの管理方法
• ファイルの命名規則

と外側部分で決めておかなくてはいけないことがあることがわかった。なぜこういう部分に意識がいかなかったかといえばそれはだいたい決められていたから、ということに他ならない。

だいたいこういうテスト仕様というかドキュメント管理部分を外注に決めさせるようなSIerはないから。大手なら尚のことだ。

今までは決まった規則に従ってドキュメント（テスト仕様書）を書いていたけど、今回はフォーマット作り、ということなので（作業が合ってるかは別として）考えておかなくていけなかった部分だった。もしかしたら、この辺りのドキュメント管理に関する仕様は決まっているかもしれなくて、余計なことをしてるのかもしれない。

で、ドキュメント管理に関する仕様が（未確認ながらも）完成しているので、実際にUTの仕様書のフォーマットを書いてみたけれど、結局何が「UT」に当たるのか「IT」に該当するのは何？ってなることが多いなと思った。

一旦、どんなことをテストケースに書かなくてはいけないかというのは置いておいて、テストケース（テスト仕様書）のフォーマットを決めておくことを優先作業とした。

UT仕様書のサンプルイメージ

テスト仕様書の各項目は以下のように定義した。過不足あるだろうが、ある程度は網羅出来ているのではないか？ 

・No. 項番

・分類 テスト分類

　初期表示なにも操作せずに表示された状態

　操作項目テスターが行う操作

　非操作項目操作系ではないものの確認すべき項目(データ格納等)

　その他

・テスト項目 テストする項目

・詳細項目 詳細

・対象 画面 | フォームであれば該当のフィールド名

・テスト区分 正常 | 異常

・テスト内容 テストの内容

・再現方法（ テストを実行するための方法

・期待結果 テストで得られる期待値

・参考資料 仕様書などを別紙で確認する必要がある場合は記載（入力規則など）

・エビデンス テスト実施後提出するエビデンスの種類。場合によっては具体的に

・テスト結果 OK | NG

・実施日 実施した日時

・担当 実施した作業者名

・結果コメント テスターからのコメント欄

・エラー発生時は、日付とエラー内容を入力

・追記の場合は上書きではなく、下の行に追加していく。

・備考 テスト設計者からのコメント欄

・チケット 該当チケットのURL（チケット登録後、テストリーダーが入力）

・Web 　null | 〇　ウェブシステムかどうか

・アプリ null | 〇　ネイティブアプリかどうか

実際にテストケースを書く上で必要な土台作りは出来たので、あとはテストの観点がまとまれば問題ないと思う。IT仕様書もほぼ同じ作りで、上記項目の中から「対象」の項目を削除した。結合テストの観点から考えると、ピンポイントで画面項目名が必要とは考えられなかったからだ。

また、上記のようなテストケースではなく、マトリクスを作って一覧的に確認する方法もあると思う。画面項目の活性非活性制御や状態遷移の確認などに有効な気がするが、画面内の項目が多くなるとものすごく大きなマトリクスになってしまい、時間もかかる。いいか悪いかは別として、そういう手段もある。とにかくドキュメントがあると安心するようなSierなんかの場合、「自分が実際にテストする立場じゃなければ」あれば喜ばれるかも知らん。

しかし、いざテストケースのフォーマットと言われても最初の一歩で困惑するのはいまだにテストエンジニアとして全く経験が足りてないことの証左だな〜と改めて自分の今後に不安を覚える次第であります。

季刊S(エス) 2019年 01 月号 [雑誌]

テスト駆動で作る！初めてのAzureアプリ (技術書典シリーズ（NextPublishing）)

Amazon Web Services負荷試験入門 ――クラウドの性能の引き出し方がわかる Software Design plus

アプリ開発チームのためのプロジェクトマネジメント　チーム駆動開発でいこう！

Pepper最新事例に学ぶロボアプリ開発 ?豊かなUser Experienceを生むロボットユースケースデザインとフィールドテストによる現場改革編?

Windows 8プログラミング本格入門　?ストアアプリのUI/UX・実装・テストまで ［Windows 8.1 対応版］