エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

2019/10/28~11/4週 気づきと振り返り

業務こなしての問題・気づき

APIキーのベタ書き

Github等でソースコード管理している場合、コードにAPIキーをベタ書きするべきではない。
プライベートリポジトリであっても、誤操作で公開してしまうリスクがあるので、なるべく避けるべき。

普段のコードでも、ベタ書きはやらない方がいい。
受け渡しは、環境変数を使うなど、コードから間接的にアクセスするような手間をかけておくと、流出のリスクは減る。

rubyのThreadの生存確認

ライブラリ調査で、サンプルコードを試しているのだが、そのコードがrubyで書かれてあった。

Threadを使う機会があり、コードが動かなかったときにプリントデバックで確認していたら、スレッドの生存確認をしたくなった。
rubyでどうやるのか調べたところ、thread.alive?で確認できる。

最初、使ったときは、?を入れてなくて、実行時エラーになって、相当悩んだ。
最後の?がキモすぎだろ。。。って思ってしまった。

rubyで、Address already in use

rubyでソケット確率の処理を書いていたら、Address already in useが出てきた。
読んだ通り、すでに利用中という意。

macだったので、lsof -wni tcp:{ポート}で調査して対応した。

docker stopで全てのコンテナを止める

docker stop $(docker ps -q)で全て止められる。
何をやっているかと言うと、docker ps -qで起動しているコンテナのIDを取得して、そのIDを docker stop に渡している。
docker stiopは、複数のコンテナIDを指定可能なのでできる。

JenkinsでGithubからソースコード取得するさいのビルド指定子の指定なし

最終コミットを取得するようになる。

webAPIをcurlで叩く

No contents応答であることの確認は、レスポンスヘッダを見ないと分からない。

雑記

docker psのps

プロセスの略だと思われる。

最初見たとき、プレステ?フェイズシフト?とかの発想にしか至らなかった。。。

ブログの更新

毎週書く予定だったのに、1週間飛ばしてしまった。。。
金曜に書くように努力していたのだが、ついつい先延ばしにしてしまう。。。

これは全て、P5Rが悪い。
やり始めると、辞め時が分からない。
気づくとその日が終わってしまっている時がある。

まだ途中までしかやってないけど、オクムラパレス、ニイジマ・パレスのボス戦がキツかった。

シドウパレスは、現在攻略中。

ポケモンの剣盾発売前までには終わらせたい。
今月は、Gジェネもあるんだったな。。。
当分、休みは部屋から出ない日が続きそう。。。

2019/10/21週 気づきと振り返り

業務こなしての問題・気づき

Jenkins Job DSL

最近、Jenkins使ったCI環境の構築をしている。
jenkinsしている途中で、いろいろ動的な処理をしたくて調べていたら、Jenkins Job DSL が使えるんじゃない?ってなった。
でも、やりたいことができなくて、よくよくドキュメントを見ると、Jenkins Job DSLって、ジョブを作るための言語で、ジョブの処理を記述するやつじゃないじゃん!ってことに気づいた。。。

これで、1日潰してしまった。。。。

結局、シェルでガシガシ処理を作ることになった。
シェルが分からないわけではないのだが、いかんせん、記述方法が独特で、実装がかなり面倒くさいんだよね。。。

xcodebuildでBundle identifierを変える

Appleのフリー開発者アカウントで、Jenkinsのビルド設定をしていたのだが、いざビルドするとなると、No profiles for ‘XXXXX’ were found が発生していた。
ローカルでやるときは、勝手に変えてたけど、jenkinsでやるときにどう変えたらいいのか、結構迷った。

xcodebuild 時に、CODE_SIGN_IDENTITYPROVISIONING_PROFILE を設定してやれば、なんとか突破できる。

雑記

twitterの個人アカウントのフォロー

特定の個人のフォローは、情報収集という意味でフォローするのは、やめたほうがいい。
大抵の場合、どうでもいいツイートのほうが多くて、結構なストレスになる。

情報収集するなら、企業か組織のアカウントをフォローするほうが、無難。

呼吸を意識した睡眠

最近、なかなか寝付けなくて困ってた。
夜になると、悪いことばっかり考えてしまうんだよね。。。

いろいろ調べて試した結果、呼吸に集中して眠るって方法が一番自分に合ってた。
寝る前にゆっくりと深呼吸をして、呼吸することだけに意識を集中すると、すんなり眠れる。
呼吸を極めたら、俺も柱に成れるかな?

2019/10/14週 気づきと振り返り

業務こなしての問題・気づき

Could not locate device support files

実機にビルド&インスコしようとしたら、Could not locate device support files と出た。
エラー読む限り、デバイスのサポートファイルがないんだろうな~と思ったけど、どうやって対処したら良いのか分からなかったので調べた。

やることとしては、サポートファイルをAppleの公式サイトからダウンロードして、所定の位置に回答したフォルダを置くだけ。
macだからディレクトリって言うのかな?
どうでもいいけど、統一して欲しいよね、OSごとに名称が違うの。

ファイルを取りにく場所は、下記

GitHub - filsv/iPhoneOSDeviceSupport: Xcode iPhoneOS DeviceSupport files (6.0 - 13.2)

解答したディレクトリを置くは、下記

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/

もしかしたら、Xcodeのアプリ名を変えている人がいるかもなので、そこは、適時読み替えて。
自分は、Xcode_<バージョン名>にしていたので、/Applications/Xcode_<バージョン名>.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/ だった。
現場で使ってるやつは、複数人と共有で使っていて、xcodeのバージョンが複数必要だったので、そうしてる。
オンリーワンなxcodeなら、一番最初に紹介したディレクトリでイケるはず。

参考サイト

【Xcode】実機で動かそうとしたらこんなエラーが出た時 - Qiita

callkitの実装

1ヶ月近く悩んでた。。。
ググってもいい情報が出てこないのがシンドい。
全部、一部分の実装だったりする。

いろいろ試して調べた結果、stack overflowで紹介されていたgithubのページで、サンプル実装していたページに辿り着いた。
それが、下記。

iOS-10-Sampler/CallKit at master · naandonov-mm/iOS-10-Sampler · GitHub

この中にある、CallkitManager.swiftを真似して実装した。
そうすると、すんなり実装できた。。。
たぶん、これを参考にする前は、providerやcontrollerのインスタンスをいっぱい作っていたので、制御できてなかったんだろうなと予想。

ググって情報探すってのがデフォルトだが、githubでサンプルコード探すってのも、視野に入れて探さないとダメな気がしてきた。
とくにサンプル実装となると、ブログに上がっているものより、一連の流れが実装されているコードをgithub内を探して方が、正確で実装しやすいものが見つかりそう。
今度からは、ググるで詰まったら、githubを探す習慣を身につけたい。

迷ったら問題を細分化

分かっているつもりでも、いざ実行ができてない。

初期開発で、callkitを入れ込んでたが、なかなか解決しなかった。
本来なら、callkitだけのサンプルプロジェクト作って、動きを学んでから取り込むように動けば良かった。
開発してたプロジェクトが複雑過ぎて、callkitだけを考えていればいい状態ではなかった。
俺の頭の性能の低さを、もっと自覚すべきだった。

雑記

英語ドキュメント読むようになって

swiftだから、基本英語でAPI読んだりしてる。
Google翻訳を使っているせいか、まったく英語のリーディングが伸びている気がしない。。。
なるべくGoogle翻訳使わないほうがいいのかもしれない。
単語調べるレベルで辞めておけば、英語のリーディングは上がるかな?
時間の成約が厳しくないのなら、試す。

週次の更新が滞った。。。

一回怠けてしまうと、そのままズルズル引きずってしまう。。。
習慣化できてなかったと、怠けてしまってから理解した。
特に、日曜に更新しようとすると、いろいろ言い訳を考えてしまい、結果、書かないになる。
記録を残すという習慣も、なおざりだった。
callkitでハゲそうになってたからかも知れないが、ネタのストックをする気が出なかったのがいたいな。

遊戯王デュエルリンクスでキングに昇格

やっとキングに昇格できた。
パーミ型の運命デスペ使ってたけど、すごい頭を使う。
止め時の見極めが面倒くさい。あと、勝ち急ぐと負ける。

キングになったはいいけど、キングで勝利数稼ぐのがシンドい。。。
100勝のウルレアチケットまで、遠いのがツライ。。。

2019/09/23週 気づきと振り返り

業務こなしての問題・気づき

githubでpush済みのコミットの修正

git commit --amendagit push -f

コミットを上書きして、それを強制プッシュするとできる。

IBAction

SwiftLintを適用して、変数名やメソッド名が大文字始まりだったので、リファクタリングした。
参照だけで動きに変更はないだろうと思っていたが、大文字から小文字始まりに変わったら、実行タイミングが変わった。

動きとしては、ボタンが押されたらsegueが動作するようなボタンだった。
大文字始まりのときは、IBAction→segueの実行になっていたが、小文字始まりに変えたら、segue→IBActionになった。

リファクタリングでメソッド名変えただけでも、きちんと動作確認をしないと、ダメなんだなって思ったのと同時に、なんで動作変わるんだ?ってものすごい疑問に思った。

Jenkinsで bundle command not found

Jenkinsでbundler使って pod install を実行しようとしたら、not found エラーになった。
bundlerは入っているから、見つからないはずないと思って見直したら、先頭行に #!/bin/bash -l がなかった。
追加したら動いた。

未だに #!/bin/bash の意味が分からないのだが、覚えたほうがいいのかな?

githubへのアクセス

sshだけかと思ったら、httpsでもアクセス可能。
今の現場は、sshの接続が制限されているらしく、相当悩んで居たが、httpsgithubからcloneしたら、難なくできた。。。
半日悩んでいたのは何だったんだって思ってしまった。。。

テスト仕様書の作成

開発研究の現場なので、あんまりテスト仕様書を書く文化はない。
だけど、状態を持つようになってテストケースが複雑化したら、作らないと流石にやばい。
いろいろ作って終わらせても、あとで後ろから刺される。

個人的な感覚としては、5ケース以上になるなら、テスト仕様書書いたほうがいいと思う。
僕の脳みそでは、4ケースくらいしか覚えられない。
メソッドの引数と一緒。5個以上になると、途端に、何番目にどの値だったか分からなくなる。

雑記

新型switchの購入

増税前に駆け込み購入。
ゼノブレイド2とセットで購入した。
ホムラ/ヒカリが可愛いなと思って購入したが、いつ出てくるんだ?
出てくる前に挫折してしまいそう。

ポケモン関連の購入

増税前に駆け込み購入その2
6期から3Dになったので、やるのを辞めたけど、やすかったから買ったポケモンXが面白かったから、ウルトラサン・ピカブイ・時の探検隊を買った。
メガシンカは、敬遠してたけど、リザードンXで無双するのは、楽しかった。
まだ、ウルトラサンやり途中だけど、メガシンカ並の楽しみはあるのかな?

ピカブイは、処理落ちが酷いとは聞いていたけど、かなり頻発するから、予約した剣盾がものすごく心配。。。
たぶん、エンカウントとあるき始めるとポケモンに乗るってのが処理落ちを発生させているのではないかと思う。
フィールドがでかいトキワの森は、エンカウントによる処理落ちだと思う。

時の探検隊は、1000円以内で変えるから買った。
不思議のダンジョンは、結構好きで、初代のポケモン不思議のダンジョンが面白かったのを思い出して買った。
まだやり途中。
switchで何か出すのかな?
先にトルネコ4を出して欲しい。

Vue.js + electron + その他もろもろの環境の構築

きっかけ

react + electronにしようか、angular + electronにしようか、いろいろ悩んだけど、一番楽に始められたvue + electron + element-ui に落ち着いたので、まとめる。
なお、自分向けなので、端折ってあるところがある。

環境

Visual Studio Code

バージョン: 1.38.1 (system setup)
コミット: b37e54c98e1a74ba89e03073e5a3761284e3ffb0
日付: 2019-09-11T13:35:15.005Z
Electron: 4.2.10
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Windows_NT x64 10.0.18362

npm

$ npm -v
6.4.1

前準備

vueの環境構築として提供されているCLIを導入する。
自分で1から構築すると面倒なので、楽な手段に頼る。

$ npm install -g @vue/cli

自分は、v3.11.0が入った。

$ npm -g ls --depth=0
C:\Program Files (x86)\Nodist\bin
…
+-- @vue/cli@3.11.0
+-- @vue/cli-init@3.7.0
…

環境構築

プロジェクト作成

$ vue create my-app

いろいろ聞かれるので、お好みで入れる。
僕は、manualでjs形式のプロジェクトを作成した。
前はtypescriptだったけど、最近は、環境構築面倒だからjsでいいやって感じになってる。
jsに慣れてしまうと、typescriptに戻ろうという気が起きないから不思議。

electron-builderの追加

このままだと、ただのvueプロジェクトなので、electronを追加する。
具体的には、下記のコマンド。

$ cd my-app
$ vue add electron-builder

動作確認

ここまでやると、とりあえずデモアプリが動かせるようになる。
なので、テストを兼ねて動かしてみる。

$ npm run electron:serve

コマンドが長いので、毎回打つのが億劫な人は、package.jsonscripts に、"start": "npm run electron:serve",を追加すると、次からnpm start で動かせるので楽かも

その他オススメの設定

element-uiの導入

element-uiは、高機能なUIパーツが使えるようになるコンポーネント詰め合わせライブラリ。
ちまちまコンポーネント作る手間が省けて、かつ、いい感じのコンポーネントが使えるようになるのがいい。

$ npm install element-ui -S

インストールが終わったら、main.jsにelement-uiのコンポーネントを読み込ませる設定を追加する。

import ElementUI from "element-ui";
import locale from "element-ui/lib/locale/lang/ja";
import "element-ui/lib/theme-chalk/index.css";

Vue.use(ElementUI, { locale });

あとは、vueファイルにコンポーネントを追加すれば、使えるはず。

設定ファイルを導入したい

electron-store を導入する。

https://github.com/sindresorhus/electron-store

設定ファイルは、デフォルトだと、C:\Users\<ユーザ名>\AppData\Roaming\<プロジェクト名>直下に、config.jsonができる。

プロジェクト直下にファイルを作って読み書きさせたいのだが、できないのかな?

感想

router.jsが、最初に見たときは、意味分からなかったけど、strutsで言うところのstruts-config.xmlかと思うと、結構、納得した。

element-uiが、意外とデザインが良くて気に入ってる。
最初作り始めると、デザインのダサさで四苦八苦してたけど、これ使えばそこそこの見た目でできるから、不要なところで悩む必要ないなと感じた。

参考サイト

Vue.jsのコンポーネント詰め合わせ「Element」がスゴかった | 綺麗に死ぬITエンジニア

Electron+Vue.jsを使ったデスクトップアプリ開発を始める手順

Electronで設定ファイルを導入 - Qiita

【読書ノート】プログラミング作法

きっかけ

どこかでオススメ書籍として紹介されていたから、ぱら見で良さそうだったので購読することに。

まとめも

スタイル

名前

  • グローバルには分かりやすい名前を、ローカルには短い名前を
    • 命名の統一性を重視
    • 関数には能動的な名前を
    • 名前は明確に

【個人の感想】
重要そうなところを抜き出したけど、ローカル変数名の命名には、若干反対である。
使っていいのは、慣例的に短いのを使うところだけだと思う。(for文のiとか)
ローカル変数でも、ある程度の分かりやすさは必要だと思う。
スコープ範囲にもよるが、だいたいコードは肥大化するものなので、短すぎる名前をつけて後々公開するようなら、最初から明瞭さを重視した方がいいと思ってる。

式と文

  • 構造が分かるようにインデントする
    • インデントがあることで構造が分かりやすくなる
  • 自然な形で式を使う
    • 条件式に否定を使うと、間違いが分かりにくくなる
  • 括弧を使って曖昧さを解消する
    • 演算子の優先度の迷いを断ち切る
  • 複雑な式は分割
    • 演算子が大量にあると、意図が分かりづらくなる
  • 明確に書く
    • 小賢いコードを書くやつはド三流
  • 副作用に注意

【個人の感想】
俺流に味付けしてまとめた。
小賢いコードを書くやつはド三流 は、なかなかのネーミングだと思ってる。
ハガレンの1話の神父に対して言った降りて来いよド三流から発想を得た。
たまに、小賢しいコードをマジで書くやつが居るから、困ったもんだ。
俺は、学生のときにそうなりかけたけど、小賢しいコードのせいでコードが読みづらいことに気づいて辞めた。

一貫性と慣用句

  • インデントとブレースのスタイルを統一する
    • ブレース=波括弧。ここでいいたいのは、if ~ else で、波括弧の位置をどうするかって意味
  • 慣用句を使って一貫性を保つ

【個人の感想】
慣用句って、何をもって慣用句とするのだろうな?
それは、お前の中の常識であって、他の人は違うよ?って言われたら、何を信じていいのか分からなくなりそうな気がしないでもない。
こういうのは考えるのが面倒くさいから、フォーマッタを導入して機械的にやるほうが楽だと思う。

関数マクロ

Cの記述ばっかりだったので、スルー

マジックナンバー

マジックナンバー=プログラム中に登場する数値

【個人の感想】
マジックナンバーは、マジで有害だから、存在させないようにするほうが吉。
あと、マジックナンバーを定数化するときに、two = 2 みたいに命名するアホを見たときは、絶句した。
定数化する意味がないから、名前のところを読めって言いたくなる。

コメント

  • 当たり前のことは書かない
    • プログラムの理解を助長するものを書く
  • 関数とグローバルデータにはコメント
  • 可読性の悪いコードは、コメントで補完するより書き直す
  • コードとの矛盾を避ける

【個人の感想】
日本だと、可読性の悪いコードは、コメントで補完するより書き直す は許されない傾向にある気がする。
必要最低限の改修だけしろとよく言われる。
その流れになったのは、無能なコーダーが上位の役職についているからだと思うんだよね。
もしくは、その可読性最悪のコードの影響を理解していないとか。
どっちにしろ、無能が上にいるってことは変わらないな。

アルゴリズムとデータ構造

  • データ量が少ない→単純なテクニックでやる
  • データ量が増大する→スケールアップ可能な設計にする
  • 高度なテクニックは、実際に計測するまで使わない方が無難

設計と実装

  • 設計=言語によらない

インタフェース

  • サービスを提供するコードと、利用するコードの境界にある
  • 実装の詳細を隠蔽する
    • 利用者への影響を少なくする
    • 実装の交換が容易になる
  • 直行性のある小さな単位を選択する
    • 必要以上の機能を提供するのはNG
      • 管理が面倒になる
      • 使いこなすのが難しくなる
    • 必要十分なものを規定する

デバッグ

  • バグを埋め込みやすいパターンを探してみる
  • バグ対応は、横展開とセットで
  • スタックトレースをよく読み、原因を特定するまでは、修正してはいけない
  • 他人に説明してデバック

バグへの対応

  • 再現させる
  • ログファイルを出力
  • UML書いてみる
  • printデバッグ

テスト

  • デバッグ=テストではない
    • デバッグ=コードに問題があるときにすること
    • テスト=プログラムを破綻させるためにする作業

コーディング時のテスト

  • 境界条件テスト
  • 実行前後の変化を検証する
  • アサーション
  • ありえないケースへの対応も考えておく(防御的プログラミング)

系統的なテスト

  • テストは1個ずつ段階的にやる
    • ビッグバンテスト→破綻する
  • 単純な部品からテストする
    • 複雑な箇所からやると、バグの修正が難しくなる
  • 期待値は明確にする

テストの自動化

大量のテストは、注意力が散漫になり、労力もかかる。
テストを自動化して、いつでも気軽に頻繁にテストできるようにすることは、十分に価値がある。

性能

  • 測定→検証のサイクルが基本
  • ベンチマークの結果は、政治的意図があるので、結果は割り引いて考えておく

移植性

環境に依存することなく動作させる理想のこと

移植性が必要な理由

  • 動作環境が決まっていることが少ない
  • 環境は変化する
  • 移植性があるものは優れたものが多い
    • やりすぎは厳禁

言語

  • 標準にこだわる
    • 移植性を高くしてくれる
  • 王道プログラミング
    • 専門用語が出てくるのは、王道ではない
    • 確率されたスタイルをなるべく使う
  • 言語のトラブルスポットに注意する
    • 演算子の評価順
    • 算術/論理シフト

【個人の感想】
「王」って単語に反応しちゃう

隔離

  • システム依存は別ファイルに移動し、インタフェースで隠蔽

データ交換

  • なるべくテキスト
    • 扱いやすい
    • 見やすい
    • 手作業で変更可能
    • バイナリ使う際は、固定バイト順にする

移植性とバージョンアップ

  • 仕様を変えるなら名前を変える
    • 解釈が変わる→意図的に別のソフトウェアが生まれるようなもの
    • 仕様が変わる=意図しない移植上の問題が発生する可能性が高い
  • 後方互換を維持する
    • 手段が変わる=影響範囲大
    • 非互換性は、コストと相談

国際化

  • 英語を前提にしない
    • 漢字等が入れば、文字サイズも変わる
    • エラーメッセージに業界用語や特定言語のスラングはやめる

感想

ところどころ端折ったが、既存の考えと大筋変わらない。
古典っぽい内容だったな~というのが正直な感想。
リーダブルコードで事足りそうな気がしないでもない。

Angular + electron の環境構築

きっかけ

electronでUIフレームワークで何かいいものないかと探して、react/vueにたどり着いた。
しかし、さっぱり動きが分からない。
理解し難い。
それなら、以前使ったAngularならイケるだろうと思い、調査して、とりあえず連携させるまでできたので晒す。

環境

VisualStudioCodeのバージョン情報で事足りそうだったので、逐一コマンドは打って貼付はしない。

バージョン: 1.38.1 (system setup)
コミット: b37e54c98e1a74ba89e03073e5a3761284e3ffb0
日付: 2019-09-11T13:35:15.005Z
Electron: 4.2.10
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Windows_NT x64 10.0.18362

実証

流れ

  1. angularの実行環境準備
  2. electornのインストール
  3. main.jsの作成
  4. Angularの設定変更
  5. 実行スクリプトの準備
  6. 実行

angularの実行環境準備

下記のコマンドを実行

npm install @angular/cli -g

プロジェクト毎にインストールメリットを感じなかったので、グローバルインストール。

インストールが終わったら、Angular用のプロジェクトを下記コマンドで作成する。

$ ng new angular-electron-demo

electornのインストール

Angularのもろもろの準備が終わったので、作成したプロジェクトに移動して、electronを入れる。
セキュリティを考慮して最新版を入れたが、何か特定のバージョンに思い入れがあれば、指定する。
※動作確認はしてないので、問題は各自で解決してね。

$ cd angular-electron-demo
$ npm install --save-dev electron@latest

自分の実行環境では、6.0.9が入ってきた

main.jsの作成

プロジェクトディレクトリ直下(package.jsonがあるディレクトリ)に、main.jsを作成する。

中身は、electronのquick-startからパクったやつ。

const { app, BrowserWindow } = require("electron");
const url = require("url");
const path = require("path");

let mainWindow;

function createWindow() {
  mainWindow = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      nodeIntegration: true
    }
  });

  mainWindow.loadURL(
    url.format({
      pathname: path.join(__dirname, `/dist/index.html`),
      protocol: "file:",
      slashes: true
    })
  );
  // Open the DevTools.
  mainWindow.webContents.openDevTools();

  mainWindow.on("closed", function() {
    mainWindow = null;
  });
}

app.on("ready", createWindow);

app.on("window-all-closed", function() {
  if (process.platform !== "darwin") app.quit();
});

app.on("activate", function() {
  if (mainWindow === null) createWindow();
});

Angularの設定変更

angular.jsonを開いて、出力先のパスを合わせる。

projects → angular-electron-demo → architect → build → options → outputPath の値を、dist/angular-electron-demo から dist に変える

  "projects": {
    "angular-electron-demo": {
      "projectType": "application",
      "schematics": {},
      "root": "",
      "sourceRoot": "src",
      "prefix": "app",
      "architect": {
        "build": {
          "builder": "@angular-devkit/build-angular:browser",
          "options": {
            "outputPath": "dist",

次に、package.json を開いて、実行するjsファイルを指定する。
"main": "main.js", を追記して終わり。

{
  "name": "angular-electron-demo",
  "version": "0.0.0",
  "main": "main.js",

実行スクリプトの準備

Angularのビルド→electornの実行の順で実行するためのスクリプトを下記の通り追加。
※start:electronを追記する

  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e",
    "start:electron": "ng build --base-href ./ && electron ."
  },

実行

さっき追加したスクリプトを下記の通りに実行する。

$ npm run start:electron

そうすると、下記の画面が出てくるはず。

f:id:suzaku0914:20190916180350p:plain

今回のソース

GitHub - suzaku-tec/angular-electron-demo

雑記

react、vueより扱いが簡単だといいな。。。

windows10って、print screen使えなくなった?
キーを叩いてもスクショがとれてなくて、結構、焦った。
snipping toolに移管していくつもりなのだろうか?

参考サイト

Electron with Angular 8|7 Tutorial | Techiediaries

Build Electron Desktop App with Angular 8 | Electron Angular Tutorial