フリーランス チャレンジ!!

フリーランス チャレンジ!!

現役フリーランスエンジニアが書く雑記ブログ

超一流プログラマーの3つの共通点は「英語」、「公式リファレンス」、「とにかくコード書く」ですね

超一流 プログラマー 共通点 英語 公式リファレンス コード書く

IT業界で働くこと20年弱。

 

今までたくさんのプログラマーに出会ってきた。

 

超一流プログラマー、できるプログラマー、普通のプログラマー、できないプログラマーと大体4つくらいに分けられる。

※ちなみに超一流プログラマーはGoogleとかにいるのかもしれないけど、そんなとことは縁がないので私が会ってきた中でとにかくすごかった人を超一流としてます。

 

それぞれの比率は大体こんな感じだと思う。

02%:超一流プログラマー

08%:できるプログラマー

50%:普通のプログラマー

40%:できないプログラマー

 

そして出会ってきた超一流プログラマーはみんな

・英語ができる

・公式リファレンスをみる

・とにかくコード書く

感じだったんです。

 

自分の中の整理の意味も込めてそれぞれのプログラマーの共通点をまとめてみました。

 

 

超一流プログラマーの共通点

冒頭にも書いたけど、「英語」、「公式リファレンス」、「とにかくコードを書く」の3つ。

 

英語ができるので、情報を入手するのは英語のページから。

日本語だけと違い英語ができると、入手する情報の早さ、正確さが全然違う。

 

技術的な記事で日本語が一番先に出ることはなく、基本英語での記事が一番早いです。

Googleにしろ、Microsoftにしろ、オープンソース系にしろ全部英語記事が一番早い。

 

英語ができれば情報量、情報の早さが格段に違う。

 

 

次に公式リファレンスなんかも基本英語。

日本語訳があるとこもたまにあるけど、基本英語ですよね。

 

英語できる人はちゃんと公式リファレンス見ます。

英語ができない私なんかは、英語のリファレンスを無理やりGoogle翻訳してみるけど、意味をあまり理解できずQiitaとかに頼っちゃう。

 

公式リファレンス以外だと、結構ウソ情報が多いので超一流プログラマーは必ず公式ふリファレンスを見ますね。

 

 

最後にとにかくコード書きます。

できる人って結局、普通の人の何倍も作業してるんですね。

 

平日、仕事終わった後自宅で。

休日、朝から夜まで。

趣味はプログラム。

みたいな。

 

本人も楽しんでやってるので、「趣味はプログラム」って言いそうな。

そのくらい普通の人より何倍もコード書いてる。

 

そりゃ勝てないよって感じです。

 

できるプログラマーの共通点

頭が良くて、作業量多い人ですね。

 

周りを見回しても、他と段違いで頭が良く回転が早い人。

 

その上、作業量も多い。

 

超一流プログラマーと違って自宅でも四六時中プログラム書くことはないが(それでも普通の人よりは書いてる)、会社では人よりも長く残業してプログラム書いてるタイプ。

 

普通のプログラマーの共通点

そこそこプログラム好きで自宅でも多少プログラムするタイプ。

 

プログラムは好きだし、技術的なキャッチアップもするが会社でもそんなに残業しないし、自宅でもたまにプログラム書く程度。

 

できないプログラマーの共通点

 ここまでに書いた共通点が無い人ですね。

 

ただ共通点を挙げるとしたらこれかな?

・多分、そんなにプログラムが好きじゃない。

・分からないことを調べたり解決するのも好きじゃない。

・仕事でお金もらえるからやってる。

 

分からないことは人に聞いて解決したり、意味も理解せずどっかからソースコード持ってきてコピペ済ませたり、とりあえず動けばいいや系。

 

現場によるけど、技術者のレベルが低い現場に行くとこの手の人が結構います。

逆に技術レベルが普通以上だと少数派。

 

最後に

どうですかね??

 

超一流と呼ばれるプログラマーの共通点について違う意見があれば教えて欲しいです。

SEだったら当然知ってるよね? PDCAじゃなくOODAループの事を

ooda pdca

(出典:Wikipediaより)
 

「PDCA知ってる?」、「PDCAやったことある?」ってよく聞かれると思うけど「OODA知ってる?」って聞かれる事はあまりないんじゃないかな〜と思います。

 

が、手段としてOODAループってとても有効だから知らない人はぜひ、この記事読んでOODAループを知ってらいたい。

 

 

OODAとは?

以下の4つのプロセスをループし、意思決定して動く事です。

・観察(Observe)

・状況判断(Orient)

・意思決定(Decide)

・実行(Act)

 

観察(Observe)

状況の観察で改善する事、したい事を観察します。

 

観察とは見て観察するだけでなく、データを収集する事も含まれます。

できれば事前バイアスがかからないよう生のデータを収集することが大切です。

 

状況判断(Orient)

観察結果、収集したデータから仮説を立てます。

 

仮説を立てるのが難しい場合もありますが、無理矢理でもいいので仮説を立ててください。

 

意思決定(Decide)

立てた仮説を元に、どのように実行していくか検討します。

 

収集したデータ、仮説からいくつか実行方法を考え、一番効果的なものを選択するのが良いでしょう。

 

実行(Act)

意思決定(Decide)で導き出した一番効果的と思われる方法を実行します。

 

 

PDCAとの違い

大きな違いは、やる事が分かっているか分かってないかです。

 

PDCAはやることが分かっているのでPlan(計画)を立てることができますがOODAの場合は、やる事が分かってないので観察(Observe)、状況判断(Orient)のやる事を導き出すプロセスがあります。

 

そもそもPDCAとOODAはどちらが良いかというのもなく、それぞれ使われるケースが異なるのです。

 

「方向性の決まってるソフトウェアプロダクト」や、「会社の知名度を上げるため広告を打つ」など明確な方向性が決まってる場合は、PDCAを選択し

 

「顧客満足度を上げたい」や、「ソフトウェアの品質を上げたい」などのゴールはあるが明確な方向性が決まってない場合は、OODAを選択します。

 

このようにPDCAとOODAは使われるケースが全然違うんです。

 

だからPDCAとOODAを比較する事はなく、それぞれにマッチするケースでPDCAかOODAを選択すれば良いのです。 

 

OODAループを使った例

実際に私が関わったプロジェクトを例にします。

 

【ゴール】

開発効率を上げたい

 

【観察(Observe)】

どこに開発のボトルネックがあるか観察しました。

 

観察内容としては月あたりの

・開発チケット数

・予定通りに終わったチケット数

・予定通りに終わらなかったチケット数

・リリースしたがバグになった件数

を観察する事とし、チケットの件数はRedmineから、予定通りに終わらない、バグになった件数は日々のやり取りメールから集計しました。

 

【状況判断(Orient)】

集計したデータを元に以下の判断をしました。

・開発チケット数が開発メンバーに対して多いか少ないかは判断が難しい

・予定通りに終わらないチケットがそこそこある印象

・2週間に1回リリースしてるが5、6件リリースして1件のバグが発生する確率が2回に1回くらいある。(ちょっと多いかな)

・開発プロセスを確認したら、製造者とテスト担当者が同じでソースコードレビューも忙しさを理由に簡単にすませてる事があった。

 

【意思決定(Decide)】

状況を見た結果、開発メンバーに対して現在の開発ペースが速いか遅いかは判断が難しく、バグを減らして、バグに対応する時間を開発に使うのがいいんじゃないかという判断になりました。

 

バグを減らすために考えたことは

「テスト、レビューをしっかりして開発プロセス正す事」

 

テスト、レビューをしっかりすると今までよりも時間はかかるがバグが無くなれば結果的に時間を節約できると考えました。

 

そこで、正しく開発できるプロセスを考え、そのプロセスを開発リーダーにレビューしてもらい実行できるレベルまでプロセスを作り上げた。 

 

【Act(実行)】

 あとは、正しい開発プロセスを適用して開発してもらった。

 

このような施策はすぐに効果が出るわけではなく長い目で見なければいけない。

 

しかも、ここで終わりではなく、プロセスを適用した結果を観察し次のOODAループでどんどん改善していく事が重要です。

 

OODAループがチカラを発揮するケース

「開発効率を上げたい」、「品質を上げたい」などゴールはあるが計画(Plan)が無い場合に大きなチカラを発揮します。

 

計画(Plan)が無いのに無理やりPDCAを適用すれば間違った計画・行動になってしまい効果が出るまで時間がかかってしまいます。

 

なので計画がない場合は、OODAを適用し何回もループさせて素早くゴールにたどり着きましょう!!

勉強できる人が必ずしも仕事ができるわけではない

勉強できる人 仕事

勉強できる人は、問題を解決できる問題解決力があるから仕事もできると思ってた。

 

仕事はまさに問題を解決する事が目的だから。

 

でも大手SIにいた時、有名大学を卒業した勉強ができてた人をたくさん見てきたが仕事ができない人もまあまあいた。

 

なぜ勉強はできたのに仕事ができないのか?

 

勉強には正解があるが、仕事には正解が無いからではないかと思った。

 

 

勉強には正解がある

勉強の場合、教科書か、参考書か、先生のどこかに正解がある。

 

問題の載っている教科書とテストの答え(解決方法)は、教科書、参考書、先生のどこかにある。

 

答え(解決方法)の無い問題は勉強には出てこない。

 

なので、どんな問題に出くわしても答え(解決方法)が無い事はなく、分からなければ教科書、参考書、先生のどれかに当たれば、必ず解決する。

 

仕事には正解がない

しかし、仕事には正解が無い。

 

会社で問題に出くわした場合、会社の資料、ネット、先輩(上司)に当たると思うけど、正解が無い場合も多い。

 

正解のある仕事もまあまああるけど、正解のない仕事(まずはこれでやってみよう)が結構ある。

 

正解もなければ、パターンも無く、毎度毎度、違うパターンの問題が発生する事も多々ある。

 

勉強できるが仕事できる人、できない人の違い

勉強できる人は往々にして問題解決力があり、分からない事は調べ、考え、応用して問題を解決する作業を多くしてきた。

 

考える時間も多く、難しい問題を解決してきたので勉強できる人の問題解決力は、相当鍛えられてるはずだ。

 

そんな問題解決力がある人がなぜ仕事ができないのか?

 

それは、「正解が無い」事が原因ではないか?

 

仕事には正解が無いので、正解が無いまま突き進む事ができない。

 

有名な大学を出てて仕事ができない人を何人か見てきたが、正解が無い仕事に対して「これでやってみよう」が上手くできない。

 

勉強だったら正解があるので、応用問題も勉強した解決方法を駆使して解けるのだが仕事の場合は、解決方法がないので、自分で解決方法を考え、実践するのが苦手なようだ。

解決方法を考えるのも苦手だし、考えた解決方法も的を得てない。

 

逆に勉強できて仕事ができる人は、自分で解決方法を考え、実践するのが得意だ。 

 

現在分かってる事、分かってない事を整理し、ロジカルに仕事を進める事ができる。

 

勉強できるのに仕事ができる人、できない人の差は、「解決方法を考える事ができるか、できないかの違い」なのではないか。

 

自分は勉強できない方だったので、何で勉強できるのに解決方法考えるのが不得意なのか、勉強できる人に教えてもらいたい。

【A day in the Life of a Engineer】世界のエンジニアの1日に密着

A day in the LIfe of a Enginner 世界 エンジニア

YouTubeを見てたときにたまたま発見したんだけど、エンジニアの1日に密着したシリーズ(?)みたいなのがあって、とても面白かったのでオススメの5点を紹介します。

 

これを見れば世界のエンジニアがどのように働いてるか分かりますよ。

 

A day in the Life of a Engineer

 

 

SAPエンジニア(6分)


one day in life of SAP software engineer

 

【特徴】

・イケメン

・おしゃれ

・仕事楽しそう

 

【1日のタイムテーブル】

06:22 起床

07:00 朝食

09:00 出社してコーディング

10:00 チームミーティング

12:00 外出(トレーニング)

13:10 昼食

14:20 コーディング

16:45 コーヒー飲みながらミーティング

19:00 報告会

19:48 帰宅&友人達と飲み

23:00 Finish

 

フロントエンジニア(7分)


a day in the life of a software engineer

 

【特徴】

・自宅で仕事

・筋トレ多め

・仕事時間少なめ(3時間)、勉強多め

 

【1日のタイムテーブル】

05:00 起床

05:15 仕事(フロントエンド開発)

08:00 朝食

09:00 勉強(Team Programming)

13:00 外出して筋トレ

15:15 昼食

16:00 フリータイム(Flutter勉強)

21:00 読書

22:00 就寝

 

ソフトウェアエンジニア(3分)


A Day In The Life Of A Computer Software Engineer - Vlog

 

【特徴】

・こまめに休憩とってる感じ

・食事しながら仕事してる(ちょっと意外)

・職場に犬がいる

 

【1日のタイムテーブル】

07:00 起床

07:50 自宅出発

08:04 オフィス到着

08:15 朝食&メールチェック

08:35 コーディング

10:00 チームでコーヒータイム

10:13 ワーク

12:03 ランチを取りにいく

12:14 ランチしながら仕事

14:00 ミーティング

15:10 チームでCHAIタイム

15:31 デザイン

17:10 スナックタイム

18:50 帰宅(ジムへ)

22:29 就寝

 

最後に

働いてる時間は日本とあまり変わらないですが、日本と違って出社から退社まで働きっぱなしじゃなく、休憩をちょこちょこ入れてるのが大きな違いですね。

 

うらやましい〜〜

 

 

ログイン画面のレイアウト崩れをGridレイアウトで直す

 

この記事で作成したログイン画面がSafariで開くとレイアウト崩れを起こす。

www.ksakae1216.com

 

Chromeだと大丈夫だったのに・・・

ちなみにFirefoxも大丈夫だった、Safariはダメ(IEは環境ないので見てない)

 

ということでログイン画面をGridレイアウトで崩れないようにします!!

 

 

Grid、Flexレイアウトとは?

そもそもレイアウトにはGrid、Flex、Floatの3種類があります。

 

それぞれ得意分野が違うため、それぞれが得意な部分に適用してあげるのがベストです。

※Grid, FlexがあればFloatを使うことは無いかも。

①Grid

格子状や複雑なレイアウトに適してます。

 

格子状

f:id:ksakae1216:20190414094158p:plain

複雑なレイアウト

f:id:ksakae1216:20190414094217p:plain

 

②Flex

縦並び、横並びに適してます。

f:id:ksakae1216:20190414094236p:plain

 

f:id:ksakae1216:20190414094257p:plain

 

下記の記事がよくまとまってるので詳細を知りたい方はぜひ見てください。

これからのレイアウトはGrid Layoutで決まり?特徴で使い分けたいCSSレイアウト手法 - ICS MEDIA

  

ログイン画面のレイアウト崩れ

次にログイン画面のレイアウト崩れを見てみます。

 

Chromeの場合は綺麗に表示されます。

f:id:ksakae1216:20190413214739p:plain

 

Safariの場合はこんな風に崩れてしまいます。

f:id:ksakae1216:20190413214826p:plain

 

ログイン画面にGridレイアウトを適用

gridレイアウトを適用するのは簡単です。

CSSに以下のように書けばいいだけ。

gistfd9f80272cea4f997cdc100c6afcbdfd

 

そしてイメージは格子状で真ん中にログインをおきます。

f:id:ksakae1216:20190414094404p:plain

 

画面全体をこんな感じのGridレイアウトにする。

f:id:ksakae1216:20190414094528p:plain

 

gist0eae53bcbb9d3e93aaa7a4b2c4101587

 

2行目でGridレイアウトに。

 

5行目のgrid-template-columnsで3列分定義、真ん中を500pxにして左と右は1frにして500px以外の残りを1対1の幅にしてます。

 

6行目のgrid-template-rowsも3分割にして1行目の高さを100px、2行目を300px、3行目は残りとなってます。

 

次に配置です。ログイン部分に"loginBlock"クラスを設定してます。

f:id:ksakae1216:20190414100817p:plain

 

gistf2dcce5fc00bf6c121a6002589e16598

 

"loginBlock"クラスのCSS部分です。

2、3行目が配置についての設定です。

この書き方で2行目、2列目に配置してます。

 

これでsafariで表示し直すとレイアウト崩れが直りました。

 

修正前

f:id:ksakae1216:20190414103848g:plain

 

修正後

f:id:ksakae1216:20190414103910g:plain

 

ソースはこちら

github.com

【JavaScript】知ってた? 変数にvar付けないとグローバルスコープになるって!!

リーダブルコード読んでて結構衝撃的だったので記事にしました。

サンプルコードも書いて実際に動きを確認したので知らなかった人はぜひ覚えてください。

 

 

変数にvar付けないとグローバルスコープになる

まあ、タイトルのままです。

 

変数宣言するのにvar付けない事はないので知らなかったですが、var付けなくてもエラーにならないのでミスでvarを付けないばかりに知らず知らずグローバルスコープになってしまいます。

 

ちなみに最近だとvarではなくlet, constを使うのがいいでしょう。

Qiitaに良い記事があるので参考までに。(変数の巻き上げもあります)

https://qiita.com/wannabe/items/b2a0d63fc786eab13c48

 

サンプルコード

ということでサンプルコードでvarを付けない場合、グローバルスコープになるか確認してみます。

 

gistfa428d5875ad80df2cc64eaec1a4bb06

 

6行目の初期化'i=0'にvarを付けてないのでグローバルスコープになるため15行目で参照できます。

 

動作確認

それでは早速ブラウザで見てみると、このようにalertに10と表示されますね。

f:id:ksakae1216:20190326094354p:plain


 

次に、6行目を'var i=0'に修正して実行すると・・・

f:id:ksakae1216:20190326094907p:plain


15行目で'i'が未定義だと怒られました。

 

javascriptは手軽に書けますが、こうゆうところがふわっとしてるので大きめのプログラムでバグが出たりすると結構苦労した経験があります。

 

変数にはvarあるいは、let, constを付けましょう。

あと、これ以外にもプログラム書く上で参考になることがたくさんあるのでリーダブルコードを読むのはおすすめですよ。

※40過ぎて初めて読みますが結構勉強になります。

 

すぐ怒る人の4つの特徴

怒る人 特徴

あなたの周りにすぐ怒る人っていないですか?

f:id:ksakae1216:20190323235608p:plain

 

私の周りにはそんなにいないんですが、40年以上生きてるとたまにすぐ怒る人っているんですよね。

 

すぐ怒る人のパターンって下記の4パターンです。

①自分の思い通りになると思ってる

②自分に余裕が無い

③完璧主義

④熱しやすく冷めやすい

 

 

 

自分の思い通りになると思ってる

まずはコレ。

 

本人気づいて無いですが自分の思い通りになると思ってます。

 

仕事にしても、会話にしても、本人は無意識のうちにそうなるだろうと勝手に思い込むので結果その通りにならないと怒ります。

 

困ったものですね〜。

 

このタイプに多いのが子供の心を持った大人です。

思い通りにならない事の方が多いのにそれが分からず大人になってしまった感じです。

 

自分に余裕が無い

これは性格以外の要素も若干あります。

 

仕事や私生活が忙しすぎると余裕がなくなるので普段怒らない人でもついつい怒りやすくなります。

でもこれは一時的な話、普段怒らない人が忙しいと怒りやすくなるって事。

 

ただすぐ怒るタイプの人でいつも余裕が無い人っていません?

勝手に忙しくなって自分で仕事増やして結果余裕がなくなり、怒る人。

 

このタイプの人は

「こんなに忙しいのに、これ以上他のこと出来ない」とか

「あんた私ほど忙しく無いでしょう」とか言うんですよ。

 

これが部下だったらいいんだけど、上司だったら最悪。

残業地獄から抜け出せなくなります。。。

 

完璧主義

このタイプも厄介です。

 

「現実的に考えて品質落としても期限までに終わらせる」とか、「出来ないのはしょうがないね」などの妥協が出来ません。

 

良い意味での完璧主義はOKですが、ここであげる完璧主義は融通がきかず怒る人です。

 

完璧主義は相手に求めるんですよね〜。

 

仕事でも私生活でも自分だけ完璧主義ならいいんだけど、一緒にいるとこっちにまでその完璧主義を求めてくるので、当然こっちはそんな完璧主義に付き合うことが出来ないので怒る。

 

怒る。

 

ホントやめてほしい。。。

 

熱しやすく冷めやすい

これは意外と多かったタイプです。

 

すぐ怒る人、特に激しく怒る人って、怒って少しすると話しかけてきたりするんですよ。

 

さっきあんなに天地がひっくり返るほと怒った(言い回し古いかな?)のに話しかける?

ちょっとおかしくない?って思っちゃう。

 

すぐ怒る人って感情の起伏が激しいのかな?

そんなに怒ることでもなさそうでも、ものすごく怒って怒鳴り散らして周りの空気を最悪にするんだよね。

 

そんな最悪の空気を作り出したのにも関わらず少しすると普通に話しかけてくるのでホントにビックリする。

 

さっきの怒ったアレはなんだったの?って感じ。

 

最後に

できればすぐ怒る人とは関わり合いたくないですね。

 

私はすぐ怒る人と何回も仕事したことありますが全然楽しくなかったですね。

今はフリーランスなのであまりにもひどい人だったらさっさと別の現場探します。

 

私生活だったらそんな人とは付き合わないようにします。

 

こっちがいくら頑張ってもすぐ怒る人は怒るから。

VSCode(TypeScript)でChromeのデバッグ(Debug)をする方法

 VSCodeでChromeをデバッグ(Debug)する方法をご紹介。

 

 

VSCodeにDebugger for Chromeをインストール

まず最初はVSCodeにDebugger for Chromeプラグインをインストールします。 

f:id:ksakae1216:20190318225132p:plain

 

①拡張機能を押下

②テキストボックスに"debugger for chrome"と入力

③Installボタンを押下でインストール完了 

 

launch.jsonの修正

次に、launch.jsonを修正します。

もしlaunch.jsonが存在しない場合は、".vscode"フォルダ配下に作成してください。

gist2352e32a404fe7eafd9c82e421d574bb

 

11行目のURLのみ、自分の環境用に修正してください。 

 

デバッグ(Debug)

 launch.jsonを修正したら一度ビルドして下さい。

VSCodeメニューの「ターミナル」→「Run Build Task」でビルドできます。

 

私はAngular CLI使ってるので"npm run build"でビルドします。

f:id:ksakae1216:20190318230202p:plain

 

次にデバッグしたい場所をクリック。

f:id:ksakae1216:20190318230438p:plain

 

サーバーを起動。

f:id:ksakae1216:20190318230604p:plain

 

デバッガを起動。

f:id:ksakae1216:20190318230812p:plain

①「Debug」を選択
②「Start Debugging」を押下

 

するとブラウザが起動します。

f:id:ksakae1216:20190318231110p:plain

ブレークポイントは「login」ボタン押下したとこにセットしてるのでログインID、パスワードを入力してloginボタンを押下すると

f:id:ksakae1216:20190318231436p:plain

このように35行目で処理が止まって、変数の内容も確認できます。

 

簡単ですね!!

この記事でデバッグしたソースと設定

github.com

横広のディスプレイがあると開発が効率的でサイコーです

f:id:ksakae1216:20190316224512p:plain

最近Visual Studio CodeでAngular(TypeScript)書いてるんだけど、横広の外付けディスプレイがあまりにも開発を効率的にしてくれるのでご紹介。

 

 

横広の外付けディスプレイ

この記事で以前紹介してるディスプレイ。

www.ksakae1216.com

 

23インチの外付けディスプレイで解像度は2560 X 1080なので横はMacbookProと同じだけど、アスペクト比が21:9で通常の16:9よりも横が大幅に広いディスプレイです。

 

どのように効率的か?

基本、外付けディスプレイにVisual Studio Codeをフルスクリーンで表示してMacにブラウザを表示。

 

こんな感じ。

f:id:ksakae1216:20190316225247p:plain

 

これの何が楽かっていうと、ディスプレイに表示してあるVSCode(Visual Studio Codeの事)でコード書いて、結果もそのまま確認できるので便利。

※VSCodeの右に表示されてるブラウザはBrowser Previewっていうプラグイン。

f:id:ksakae1216:20190316225855p:plain

 

それでMacにはブラウザを表示して、調べ物があるときは、Macに表示してあるブラウザで調べる。

 

マウスカーソルは基本、ディスプレイ上に置いてあり、Macのブラウザはキーボードのみで操作。

ブラウザをキーボードで操作できるvimiumプラグインをChromeにインストールしてあるからマウスカーソルを持ってくる必要もなし。

www.ksakae1216.com

 

長時間の作業もマウスカーソル動かすのはディスプレイ上のみなので広い画面を使ってても疲れない。

 

画面が広いのでコード書くのも捗る!!

 

実際の開発

実際、どんな感じで便利かはgifを見てね。

f:id:ksakae1216:20190316232524g:plain


見えやすいようにズームにしてます。

エディタでloginボタンの表示を"login!!!"(ビックリマーク3つ追加)に変更、保存するとブラウザが自動的にリロードされコードの内容が反映されます。

※Angularをnpmで起動するとブラウザが自動的にリロードされます。

※コードは下記の記事を参考

www.ksakae1216.com

 

外付けディスプレイは選べるなら横広

という事で、外付けディスプレイ使うなら横広がおすすめ!!

 

開発はディスプレイ上で完結するし、調べ物はPCにブラウザ開いて操作はキーボードでやるのでマウスカーソルをディスプレイ、PCを行ったり来たりする必要もない。

 

なので横広ディスプレイがおすすめ!!

 

【Angular】Webテスト(npm test)が失敗した時のスクリーンショットを撮る方法

Webテスト(npm test)が失敗し、エラーが発生した時にスクリーンショットを取る方法(コード)をご紹介。

 

※私はMacですが、多分Windowsでもここに書いてある手順でいけるはずです。

 

 

環境(Angular、node、Visual Studio Code)

コードはTypeScriptで書き、フレームワークはAngularを使います。

 

IDEは何でもいいですが、TypeScriptを書くなら早くて便利なVisual Studio Codeがおすすめです。

 

参考にしたページ

www.webdriverjs.com

 

www.webdriverjs.com

 

英語のページですが、Google翻訳で日本語にすれば何をするかは読み取れます。

 

 

実装(コード)

まず、始める前にnodeをインストールしてください。

nodejs.org

 

ディレクトリ作成

Visual Studio Codeを使って説明します。

最初にディレクトリを作成します。

gistd3a009b5327c6a5569c0bd2d59a6a2d0

 

ディレクトリ作成後

f:id:ksakae1216:20190304221732p:plain

 

protoractorとかjasmineとかインストール

ProtractorAutomationフォルダ配下で下記のコマンドを実行。

gistf0b82b720b719ab2b6aa17ddde92fee0

 

package.json作成

ProtractorAutomation配下にpackage.jsonを作成します。

gist6e4d9596967f58d44cc8fd2e130d051a

 

tsconfig.json作成

ProtractorAutomation配下にtsconfig.jsonを作成します。

gist258208ad6b6fce7835e747cad6561da0

 

package.jsonとtsconfig.jsonファイルを作成後

f:id:ksakae1216:20190304223044p:plain

 

テストコード作成

specsフォルダの下にFistSpec.tsを作成

gist3e398abf2965bfbc90fb7a1c3834314c

 

config.ts作成

ProtractorAutomation配下にconfig.jsonを作成します。

gist885f01660570102867038bf021ffba3c

 

正常にWebテスト(npm test)ができる事を確認

selenium起動

gistca62c6518f05da858e6cd48a63bcb928

f:id:ksakae1216:20190304224114p:plain

 

プラスマークをクリックしてコマンドプロンプトをもう1つ開きます。

f:id:ksakae1216:20190304224402p:plain

 

Webテスト実行

gist9944cacb77ce0081cbde6e4e63e48b57

f:id:ksakae1216:20190304224908p:plain

 

テスト1件(1 spec)、エラー0件(0 failures)で無事Webテスト完了です。

 

ScreenShotを撮る仕組み

次にScreenShotを撮る仕組みを作ります。

 

jasmine_reporter.ts作成

ProtractorAutomation配下にjasmine_reporter.tsを作成します。

gist424f8bb734249e26cd924cc69128c302

 

config.tsの修正

以下のコードをconfig.tsに上書きしてください。

gist977e151fc850346470581b6eebb968dd

 

FistSpec.tsの修正

11行目の'3'を'0'に修正

f:id:ksakae1216:20190304230347p:plain

 

Webテスト(npm test)失敗でスクリーンショットを取る

seleniumをもし落としてる場合は、もう一度コマンドプロンプトで"webdriver-manager start"を実行してseleniumを起動してください。

 

その状態で、"npm test"を実行。

"reports/screenshots"フォルダが作成され、スクリーンショット(pngファイル)があればOKです。

Webテスト失敗時のスクリーンショットを撮る事ができました!!

f:id:ksakae1216:20190304231056p:plain

 

Gitにソース登録しました。

github.com