底辺過ぎてちょっとビビる

26歳からIT業界にいるエンジニアが、まったく成長できてないことを確認するブログ。備忘録的に使いたいとも考えています。

【提案】休日を有効に使うために考えたこと

エンジニアは常に自分の中の技術をアップデートし続けなくてはいけない宿命があります。

  1. 知らないプログラミング言語に対応する必要が出てきた
  2. 知らない開発環境を構築する必要が出てきた
  3. 仕事で関わりはないが、個人的に勉強しておきたい
  4. 資格取得のために学習したい

ドッグイヤーと呼ばれるIT業界では自分の状況がどうであろうと、日々何かしら技術が新しく生まれていて、それがいつの間に開発のデファクトスタンダードになってたりするのです。

もちろん技術的にアップデートしなくても仕事ができるケースはあるでしょう。 Javaのエンジニアは仕事にあふれていて、あぶれることはこの先ないような気もします。

しかし、大半のエンジニアは何かしらのアップデートが必要で、それを平日のプライベートの時間に使うのは難しく(そうでもない?)、勉強するなら休日にという人も多いはず。

まぁエンジニアという風に職種を限定せずとも、何かしら仕事をしていれば誰でもそうかもしれません。

自分は今までサボってきたツケが回ってきて、今さらWEBシステムの開発現場に入り四苦八苦しています。WEBシステムを開発するなら当たり前のような環境も何も知らず、現場の人から呆れられたりすることばかりで心がボロボロになってきてました。

これ以上ボロボロになるのは避けたいので、「休日に勉強して少しでもできるようになろう!」と考えて昨年から週末はファミレスで勉強してきました。 そこで、休日に勉強することを始めて気づいたのですが


休日に勉強していると、他に何もできない...

ということです。ファミレスで4時間5時間くらい勉強(SNSに気をとられることも多いですが)してると他に何もできなくなります。個人的には「勉強した!」という満足感もあるのでそこまで悲観的にならないのですが、一人暮らしで家事(掃除・洗濯)など平日できないことを休日にまとめてやるとしていた場合、結構ネックです。

だいたい午後2時か3時、日によって4時や5時にファミレスに行って4〜5時間勉強しているとその日はもう終わりです。

半年近くこのパターンを繰り返して気づいたのですが


午後から勉強を始めるとその日は他に何も出来ない

ということです。アホですね。 「勉強をしている」から「他に何も出来なくても仕方ない」を当たり前だと思ってました。 図書館に行こうと思っても閉館してますし、買い物行こうと思ってもお店は閉まってます。 そこで考えついたのが


午前中から勉強したら、午後から時間作れるじゃん!

ということです。 休日は12時くらいから始まるのがデフォルト、という生活パターンを変えて、 朝(7時〜9時)に起きて、ファミレスで朝食を食べてそのまま勉強すればいいことに気づいたのです!!

たとえ9時から4〜5時間勉強しても午後3時以降は他のことに使えるし、なんならショッピングとかにも出かけることも可能です!! これまでファミレスで勉強していた時にコーヒーをガバガバ飲んでいたのですが、カフェインが効きすぎて当日の夜は寝つきが悪かったように思います。しかし、午前中にガバガバ飲んでも多分その日の睡眠には影響が薄そうです。

これを実施するには、「休日前の金曜日とかに夜更かしし過ぎない」というヘビーな制約が必要ですが...

ザ・ファミレス

ザ・ファミレス

休日のアコースティック・カフェ のんびり聴きたい洋楽カバーベスト

休日のアコースティック・カフェ のんびり聴きたい洋楽カバーベスト

  • アーティスト: アントニオ・モリナ・ガレリオ
  • 出版社/メーカー: OVERLAP RECORD
  • 発売日: 2016/12/28
  • メディア: MP3 ダウンロード
  • この商品を含むブログを見る

【失敗あり】MQTT(Mosquitto)での接続

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

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

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

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

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

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

f:id:starscream1999:20190214203952p:plain
まずはローカルPC内でのMosquittoの動作確認

f:id:starscream1999:20190214204034p:plain
続いて、サーバ環境内でのMosquitto動作確認

f:id:starscream1999:20190214204116p:plain
最後に(どちらでもいいが)サーバのMosquitto brokerに対してのローカルPCからの通信確認

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

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

f:id:starscream1999:20190219191442p:plain
ダウンロードページ

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

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

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

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

これ自体は非常に簡単で、Windowsならコマンドプロンプトを2つ起動(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の接続を確認しようとすると、なぜか上手くいきませんでした。

f:id:starscream1999:20190214204116p:plain

サーバ側で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が確認できるはずです。

  

JavaScriptではじめるIoT いろはの“い

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

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

つないで つないで プログラミング 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使い方入門〈GitHub、Bitbucket、SourceTree〉

独習Git

独習Git

サルでもわかるGit入門

サルでもわかるGit入門

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

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

 

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

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

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

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

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

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

 

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

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

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

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

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

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

「★」印をつけた箇所が新しく知ったり使うことになったツール類なのだけども、数えたら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使い方入門

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

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

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

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

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

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

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

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

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