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

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

ソースコード読めないプログラマがソースコードを読むために教えてもらったこと

懺悔めいた前置き(長くなってしまった)

今のプロジェクトに入るまでしばらくコーディングから離れていた。
プログラミングが苦手だったので、意図的に実装フェーズに関わらないようにプロジェクトを選んでいたので当たり前なんだけども。

なんで苦手かといえば、

  • ソースが読めない
  • 意図した通りにプログラムを組むことが出来ない

そんなのプログラマとして致命的だし向いてないからエンジニア辞めろ!という感じだが、 辞めず(追い出されずに、と言ってもいいかも)にこの業界に残れているのはひとえに周りに助けられてきたから。

ゴミエンジニアである自分が存在している時点で関わったプロジェクトの迷惑になっていて、それ自体は本当に申し訳ないんだけども、周りのおかげでなんとかエンジニアとして生きながらえさせてもらっていた。

前述の通り実装に不安を抱えていたので、ここ数年はテスト設計フェーズからのプロジェクトに参画していた。

いくつかWEB系プロジェクトのテストフェーズに関わり、そのままテストエンジニア(名前だけで中身は伴ってない)としてエンジニアを続けていければよかったのだけども、WEB系プロジェクトでテスト設計から関わってみて気づいたのが、自分が持つ「標準的なWEBアプリケーションに関する知識」が足りてないという実感。
今まで業務系システム(C言語でオンプレミス)ばかり関わってきていたので、当たり前といえば当たり前なのだけど。

  

WEBアプリケーションの基本部分を知らないと、業務的にWEBアプリケーションとしてテストすべき観点等が 曖昧になり、テスト設計がきちんと出来てこない。

  

知識がないので、確認すべきこと・確認しなくてもよいことの判断も出来ない。
テストとして不足していることにも気づけない。内部の動きがわからないので、きちんと動いているかどうかをWEB画面上で表面的にしか確認できない。
もちろんWEBの知識が不完全でも、テスト設計するのは自分だけではないのでテストケースが出来上がらないということもないし、
レビューで指摘を受ければ足りないことを加筆修正することは出来るので、テスト設計自体が「まったく出来ない」訳ではない。

やはりずっと心理的に「プログラムから離れていると不安である」ということを抱えているのかもしれない。 なので、テスト設計と併せてWEBアプリケーションの実装もさせてもらえるようなプロジェクトを探してもらって今のプロジェクトに入りこんだわけです。

今のプロジェクトはプロジェクト自体はいくつも並行で走っていて、
そのうちの一つに関わっている。周りにいるプログラマはそれぞれ別のプロジェクトに関わっているので、関わりは全くない(全く無関係ではないが、今のところ直接関係してない感じ)。

自分の担当プロジェクトでは、「リーダー」の下に自分だけがいるという構成になっている。久々に実装をしていて、

毎日めちゃくちゃ怒られている。

怒られているし、呆れられている。

(自分の仕事の出来なさに改めて泣きそうになっているが泣いたら終わりだと思うので踏ん張っている。)

  

目的と処理(手段)を分けて考える

前置きが長くなってしまったが、毎日何に怒られているかというと、

  • 変数の目的・役割をきちんと理解・把握出来ておらず、曖昧な状態でわかったふりをしているから。

今更「変数」か、という感じだが、本当にそのレベルなんです。すみません。 ただこれは基本だけどすごく大事なことで、変数だろうがメソッドだろうが、クラスだろうが同じことになる。

例えば、「成績優秀な生徒の名前を表示する処理」というような以下のソースがあった場合に、 (showという名前のメソッドのくせに表示する処理がなかったり、配列一つしかないのにforループしていたり、goodというフラグを作ってフラグを立てたり無駄なコードが入ってますがお気になさらず)

var students = {"name": hime,"testResult":100};

function showStudents(students){
  var good = false;
  var goodStudents = [ ];
  for(var key in students){
    if(students[key].testResult > 80){
      good = true;
      goodStudents[key].name.push({
        "name":students[key].name
      })
    }
  }
}

goodStudentsは成績が80点以上の生徒名が入る変数ではあるけれども、成績が80点以上の生徒名を入れるためではなく

  • 成績優秀な生徒として表示したいから作られた変数であること

という理解が大事だと教えられている。

今まで、

  • studentsは生徒情報を入れる変数
  • goodStudentsは成績が80点以上の生徒名を入れる変数

というように、「なんのため(目的)の変数なのか」ではなく「何をしている(処理)変数なのか」という読み方でコードを読んでいたし、プログラムしていた。 目的が曖昧だと「何をしているか」はわかっても「どうしたいか」の理解があやふやになる(自分の場合)。 このあたりの理解があやふやだった自分は、showStudents()生徒名を表示する処理と中途半端に理解した気になって、 studentsgoodStudentの役割の違いをきちんと言語化出来なかった。

  

ソースを修正したり、修正案を提示するたびに

  • 「これはなんのためにあるの」
  • 「どんな条件で変数に値を入れるの」
  • 「〜したいときはどうするの」
  • 「なぜここで初期化されているの」

と一つ一つ詰められている。答えられないということは理解がまだ出来てないということ。

これは変数に限った話ではなくて、関数だってクラスだってそれぞれ目的がまずあって、そのための手段をどうするかを考えるわけで、 ソースコードを読むときに目的をきちんと理解した上で読めば最終的に何をしたいのかわかる(と思う)。

小さな処理の単位で「何を目的に作られたのか」「なぜここで作られたのか」を理解出来れば どう処理を作ればいいのかも同時にわかる(実現の難易度とは別)。

  

ずっと詰められて頭が真っ白になってストレスでおかしくなる寸前で、 まだ消化できてなくて自分の言葉でわかりやすいようにアウトプット出来てない部分もあるけれど (わかりにくい文章だったらごめんなさい) まずは「目的」をきちんと把握するようにソースコードを読めば、理解できないこともないかなと思い始めている。

  

Code Reading ~オープンソースから学ぶソフトウェア開発技法~ (プレミアムブックス版)

Code Reading ~オープンソースから学ぶソフトウェア開発技法~ (プレミアムブックス版)

はじめてのOSコードリーディング ~UNIX V6で学ぶカーネルのしくみ (Software Design plus)

はじめてのOSコードリーディング ~UNIX V6で学ぶカーネルのしくみ (Software Design plus)

ソースコードリーディングから学ぶ Javaの設計と実装

ソースコードリーディングから学ぶ Javaの設計と実装

プログラマーのためのソースコードを読む技術

プログラマーのためのソースコードを読む技術

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

【基礎】テストエビデンスの取得について

長くて苦しい結合テストがやっと終わった。
テスト設計ではなく、久々に「テスター」として結合テストの最初から終わりまで一人でやり切った。
※わからないことは聞きまくりだったけども

  

しかし、長くて苦しかった訳はほとんど自分にあった。

とにかくテスト実施時の基本的なことをおろそかにしていたのだ...
何が大事だったか、戒めのために残しておこうと思う

  

  

テストを実施することよりも重要なことは、エビデンスをどう残すかということ

テストケースの消化、ということに集中しがちだが、結局納品物として「テストをしましたよ」という証明になるのはエビデンスになる。 「やりました」と口で言ってもエビデンスが残ってなければ話にならないからだ。 単体テストレベルであれば、打鍵のみでエビデンスを残さないケースもあるだろうが、結合テストではカッチリエビデンスに残すことに なるので、そのためにどうやってエビデンスを残すのか?というのは大事。

そして、エビデンスをどう残すかは決まったルールがあればそれに従うだけだが、 もし決まったルールがないのであれば、基本的には以下の4点を基本エビデンスとして残すこと。

  1. WEB系であれば、実行後の画面キャプチャ
  2. 実行前のデータ状態
  3. 実行後のデータ状態
  4. 実行後のログ   

  

エビデンスとテストケースの紐付け

エビデンスを格納した後でテストケースとエビデンスと一致させるために、紐付けが必要になる。
基本的にはエビデンス自体にテストケースナンバーをつけた上で保存しておけば基本は大丈夫。 わかりやすいのは、テストケースの大項目単位でフォルダを作成して、階層的にフォルダ管理をすることで エビデンスの紐付けはしやすくなる。
     

  

テストケースが「絶対」に正しいということはない

これはテストを実施中には実は判別が難しい。
テストケースが正しいか、誤っているかは仕様を理解していないと判別がつかないからだ。 単純にテストを消化するだけだと、テストケースの「期待値欄」とテスト結果が一致しないので、 「テスト結果=NG」としてしまいがち。
なので、テスト結果がNGとなった項目については、テスト実施直後くらいに先に報告をすべき。

※現場によってはRedmine等のテスト結果を管理するためのツールを利用しているかもしれない。  

  

テスト実施前にどんなテスト結果が必要か準備と確認をしておくこと

テスト実施前に手順の確認、という意味合いもあるが、

  • DBダンプを取る必要がある
  • 画像のキャプチャを取る必要がある
  • 実行ログを取得する必要がある
  • クライアントツール等のキャプチャを取る必要がある 等々

これらのエビデンスを取るために「何が必要なのか」を実施前に把握しておくこと。

  

テスト実施のための環境

テストを実施する環境は様々あると思うが、

  • WEBブラウザIEChromeのブラウザ種別の他に、versionも考慮されるはず)
  • ローカル環境(どこで実行するか、ログの出力はどこか)
  • サーバ環境
  • Dockerなどの仮想環境
  • AndroidiPhone等の各種スマホ

それぞれ「テストをするためにどんな環境構築が必要か?」と確認しておくこと。 最初から用意されている場合もあるが、大概何かしらの準備が必要になる。  

  

  

遅れていても余裕を持って(余裕がなくなることがミスを生む)

テストってどうしてもスムーズに進まず、どこかで遅れが発生することがある。 そもそもどんなテストをするのか、漠然と理解していてもきちんと理解できていない状態で、 テストを実施していると順調に進んでいるのか遅れているのかもよくわからなくなる気がする。 順調に進んでいるように見えて、実は確認すべきテスト項目の半分くらいしか確認できていない、 なんてこともあったりする。終わったと思ってエビデンスを格納する段階で「エビデンスが足りてない...」なんてことも。

場合によってはバグが多くてテスト実施はしたものの不完全だったりするなんてこともある。 現状の理解をきちんとをすることで進捗状態を把握できる。 パニックにならないためにも、状況を理解できる余裕を持つようにしよう。

  

  

もし大事はエビデンスを誤って消去してしまったら...

  1. MVコマンドでファイル名を置換しようとしたつもりが、RMコマンドを打っていた...
  2. 誤ってファイルの上書きをしてしまい、元のファイルが消えてしまった

など何かしらの操作により大事なエビデンスが消えてしまった場合の対処方法

RMコマンドで消してしまった場合は、ファイルシステムext3またはext4であること限定ですが、 以下の手段により復旧が可能なようですので試してみる価値はあります。

Linuxの恐怖体験「rmで間違ってファイル消してしまった!」そんな時はextundeleteでリカバリ | Unskilled?

大事なファイルを消してしまったけどextundeleteを使って危ないところで助かった話 - Qiita

Windowsの場合は、ゴミ箱に入っている可能性があるので、探してみよう。 そして、もし復旧ができなかった場合は素直に「すみません消してしまいました」と報告しよう。 何かしら対処を考えてくれるかもしれないし、単純にテストの取り直しを指示されるかもしれない。 おっかないのでRMコマンド打つ前はバックアップを取るのを忘れないようにしよう。

  

  

実施コマンド、投入したデータ、JSON、は念の為残しておこう

テスト実施時に叩いた、コマンドやデータ類、JSONなどの投入データは念の為手元に置いておこう。 だいたいテスト実施前に実行コマンド、データ、JSONなんかは実施前手順書的なドキュメントにあるだろうけど、 手順書に書いてある通りのコマンドなどで実施できない場合に書き換えもありうる。

日付やIDなどがユニークなキー値になっていて、すでに同じようなテストデータが投入されている場合に、 入力が弾かれてしまう場合があるからだ。

そもそも手順書の記載が誤っているかもしれない。

  

  

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

現場の仕事がバリバリ進む ソフトウェアテスト手法

現場の仕事がバリバリ進む ソフトウェアテスト手法

テスターちゃん 1巻

テスターちゃん 1巻

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

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

  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入門