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

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

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

Nxチュートリアルをやってみた(Create Application)

f:id:ksakae1216:20190615173336p:plain

Nxチュートリアルをやってみた!!

 

その前にNxって何?って人もいるよね。

実は私もこのチュートリアルやる前にそんな状態でした。

プロジェクトで使ってるけど、内容理解してなくて。。。

 

まずはそこから調べて、チュートリアルを進めてきます。

 

 

Nxって何?

まずは公式ページを見てみる。

nx.dev

 

Use Modern Tools

Use Modern Tools

Using Nx, you can add Cypress, Jest, Prettier, and Nest into your dev workflow. Nx sets up these tools and allows you to use them seamlessly. These innovative tools offer a lot of advantages and help you work better and smarter.

 

(翻訳)

Nxを使用すると、開発ワークフローにサイプレス、ジェスト、プリティー、ネストを追加できます。 Nxはこれらのツールをセットアップし、それらをシームレスに使用できるようにします。これらの革新的なツールは多くの利点を提供し、あなたがより良くそしてより賢く働くのを助けます。 もっと詳しく知る

 

Cypressはe2eテストランナー、JestはFacebookが作ったテストランナー、Prettierはコード整形(フォーマット)、NestはNodeJsフレームワーク(サーバー側もTypeScriptで書こうみたいな)です。

 

上記で上げたこれらのツールを使えるようにできるってこと。

 

Build Full-Stack Applications

Build Full-Stack Applications


With Nx, you can build full-stack applications using Angular and Node.js frameworks such as Nest and Express. You can share code between the frontend and the backend. And you can use the familiar ng build/test/serve commands to power the whole

 

(翻訳) 

Nxでは、NestやExpressなどのAngularおよびNode.jsフレームワークを使用してフルスタックアプリケーションを構築できます。フロントエンドとバックエンドの間でコードを共有できます。そして、あなたは全体に力を与えるためにおなじみのng build / test / serveコマンドを使うことができます。 

 

さっき出てきたNestの話ですね。

バックもTypeScriptで書けるのでバックエンドと同じようにコードを書くことができるということです。

フロントとバックが同じTypeScriptで書けるのは開発者にとってだいぶ楽になりますね。

 

Develop Like Google

 

Develop Like Google

With Nx, you can develop multiple full-stack applications holistically and share code between them all in the same workspace. Nx provides advanced tools which help you scale your enterprise development. Nx helps enforce your organization’s standards and community best practices.

 

(翻訳)

Nxを使用すると、複数のフルスタックアプリケーションを総合的に開発し、それらの間でコードをすべて同じワークスペースで共有できます。

Nxはあなたがあなたのエンタープライズ開発を拡大するのを助ける高度なツールを提供します。 Nxは、組織の標準とコミュニティのベストプラクティスを強化するのに役立ちます。

 

正直翻訳しても内容が理解できないですがタイトルは「Googleのように開発する」となってるのできっとGoogleのように開発できるんでしょう。

 

長くなりましたが便利なテストランナー、コードフォーマット、サーバー側もTypeScriptで書けてGoogleのように開発できるのがNxのようです。

 

チュートリアルやってみた(Create Application)

 それではようやくチュートリアルです。

下記ページを参考にチュートリアルを実施してみます。

Step 1: Create Application

 

workspace作成

gistb00f694d843ca15731db67ee2a861f36

 

f:id:ksakae1216:20190615215120p:plain

 

途中で、何回か聞かれます、「CSS」と「empty」を選択しました。

完了するとmyorgディレクトリにとその下にいろいろ作成されます。

f:id:ksakae1216:20190615215806p:plain

 

アプリケーション作成

gist5e5038233f91e707f5774ca6cde4e350

 

f:id:ksakae1216:20190615215819p:plain

 

gist4107c6272f3c99353236c9a915cf69f5

 

f:id:ksakae1216:20190615220109p:plain

 

todoアプリケーションが作成されました。

 

アプリケーション起動

gist1a0e3d91902a78fdee481336d907c6f8

 

localhost:4200に接続すると、アプリが起動されてることがわかります。

f:id:ksakae1216:20190615220533p:plain

 

最後に

このチュートリアルでわかったことは、applicationコマンドでアプリが簡単に作成できたことです。

この後続いてチュートリアルを実施していきたいと思います。

 

github.com

簡単、速い、テストの動画保存、Cypressは最高のe2eテストだ!!

www.cypress.io

インストールが簡単、速いe2eテスト、テストを動画で保存するなど、素晴らしいe2eテストツールのCypress!!

 

Cypressとはどんなツールなのか?

実際にインストールしてテスト書いて実行するとこまで紹介します。

 

Githubにもソースを登録するので簡単に試してみたい方はgit cloneしてe2eテストやってみてください!!

 

e2eテストやった事ない人は本当に感動するし、今後テストも書いていこうって思えますよ!!!

 

 

Cypressとは?

以下の特徴があります。

・インストールがとても簡単

・テストが速い(らしい)

・テスト過程を自動で動画保存

・CI連携

・テスト用IDEがある

・テストの補助(selector)がある 

 

ただし、現在Chromeしか対応してないのでクロスブラウザが必須の人は他のテストツールを探してください。

 

e2eテストは動作の保証ができればOKな人は、ぜひこのCypressをお試しください。

いいテストツールですよ!!

 

Cypressインストール

コマンド1つでインストールOK!!

gistd82e4148b16b802246f5c8ad532e9107

 

後、下記のコマンドでCypressの雛形を作成してくれます。

gist86b15f9fa22489ee81b63328a8d962cf

 

作成される雛形、Cypressフォルダが作成されます。

f:id:ksakae1216:20190610230201p:plain

 

ちなみにprotractorのe2eテストがそのプロジェクトにすでにある場合、下記の削除する質問で'Y'を入力すればprotoractorのe2eテストを削除してくれます。

f:id:ksakae1216:20190610230012p:plain

 

テストの書き方 

cypress/integrationフォルダ配下にテストファイルを作成して テストを書きます。

 

まず1つサンプルから、ログイン画面を表示できるか確認するテスト。

gistc25420def06dc01d3ef8d7f5149fd9f5

 

'cy.' + APIでテストを書くことができます。

このサンプルでは'cy.visit(ログイン画面URL)'でログイン画面を表示できる事をテストします。

 

APIは下記を参照してください(英語だけど。。。)

Table of Contents | Cypress Documentation

 

e2eテスト失敗

まずは失敗ケースを見てみましょう。

Cypressはe2eテスト実行すると、画面のスクリーンショットと動画を保存してくれるのでどこで、どのようにテストが落ちたか簡単に確認することができます。

 

'npm run start'しないでテストするので画面が起動できず失敗するテスト。

 

【スクリーンショット】

 cypress/screenshotsフォルダにスクリーンショットがテスト毎にあります。

f:id:ksakae1216:20190611213415p:plain

 

テスト失敗のスクリーンショット

f:id:ksakae1216:20190611220841p:plain

 

【動画保存】

cypress/videosの下にテスト毎の動画。

f:id:ksakae1216:20190611221134p:plain 

 

e2eテスト実行(cypress run)

次は正常のe2eテストです。

こちらは普通のe2eテストを想定してもらえればOKです。

 

実際のテストを実行した動画です。


Cypress e2e run

 

e2eテスト実行(cypress open)

次は対話モード 、こちらも動画で紹介。

テストランナーが起動するまで時間がかかるので起動後の動画です。


Cypress e2e open

 

この記事のソースと実行方法

github.com

 

下記コマンドの通り、cloneしてテスト実行できます。

gist52d280ff4f289d8629922095b9e11bb8

 

超一流プログラマーの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