Angular を始める
アニメのこみっくがーるずが好きです。
仕事で Angular を使っていて、その仕事が一息ついたので学んだことをまとめていこうと思います。 Angualr の簡単な紹介は公式に任せます。
一つだけ補足しておくと、過去にAngularJS というものがありました。バージョン的には 1 扱いですが、2 以降との後方互換性はありません。AngularJS については、知る必要がありません。また、Angular（2 以上） について調べるとき、AngularJS の記事がよく引っかかります。参考にならないので、-angularjs を検索ワードにつけることをオススメします。
環境
ここですること
- Node.js のインストール
- Angular プロジェクトの作成
- 簡単なコンポーネントの構成紹介
Node.js のインストール
Angular を使うためには、Node.js を入れないといけません。 Node.js は、こちらからダウンロードしてください。 推奨版と最新版どちらでも好きなほうをダウンロードしてください。
Node.js のインストール方法は特に設定を変更することはないので、省略します。
Angular プロジェクトの作成
作成する前に、Angular をインストールする必要があります。 まずは、ちゃんと Node.js がインストールされているか確認しましょう。
> npm -v 6.2.0 > node -v v10.8.0
次に、Angular CLI をインストールします（プロキシ環境下だとうまくいかないかもしれません。プロキシの設定をしてください）。
> npm install -g @angular/cli
インストールが完了したら、バージョンを確認して、ちゃんと入っているか確認します。
> ng -v
_ _ ____ _ ___
/ \ _ __ __ _ _ _| | __ _ _ __ / ___| | |_ _|
/ △ \ | '_ \ / _` | | | | |/ _` | '__| | | | | | |
/ ___ \| | | | (_| | |_| | | (_| | | | |___| |___ | |
/_/ \_\_| |_|\__, |\__,_|_|\__,_|_| \____|_____|___|
|___/
Angular CLI: 6.2.3
Node: 10.8.0
OS: win32 x64
Angular:
...
Package Version
------------------------------------------------------
@angular-devkit/architect 0.8.3
@angular-devkit/core 0.8.3
@angular-devkit/schematics 0.8.3
@schematics/angular 0.8.3
@schematics/update 0.8.3
rxjs 6.2.2
typescript 2.9.2
以上のような感じで表示されると思います。 では、プロジェクトを作成するので、作成したい場所に移動してから下記のコマンドを入力してください。
ng new my-app
実行が完了すると、プロジェクト（my-app）が作成されます。
my-app > src > app この下に必要なソースや html, css を作成していきます。
作業を始める前に、サーバを立ち上げて、Webブラウザで動作確認をしましょう。
> cd my-app > ng serve ... i ｢wdm｣: Compiled successfully.
最後の一行が表示されたら、Webブラウザを開き、http://localhost:4200 にアクセスします。
Welcome to my-app! という文字と Angular の画像が出たページが表示されると思います。
次に、簡単な変更をしてみましょう。
app.component.ts を開き、AppComponent クラスの title の中身を書き換えます。 自分は、以下のように書き換えました。
export class AppComponent {
+ title = 'The World';
- title = 'my-app';
}
Webブラウザを確認しましょう。先に開いたタブを見ると文字が変わっているのが分かると思います。 何が起きたのかというと、変更を加えて保存をしたときにサーバ側が勝手に再度ビルドし、画面の更新を行ってくれます。 つまり、サーバを立ち上げ直す必要がなく、リアルタイムに動作の確認が出来ます。
簡単なコンポーネントの説明
最後に、コンポーネントを軽く紹介しておきます。 Angular は、一つのコンポーネントにつき、3 つのファイルが必要です（厳密には1つでもいけますが）。 それは、
の 3 つです。HTML と CSS は、TypeScript のファイルの中に直接書くことができるので、ファイルが必ず必要というわけではありませんが、現実的ではないでしょう。HTML と CSS は、Pug や SCSS のようなものも使えます（自分は書けないので使ったことがありませんが）。
.component.spec.ts は、コンポーネントの単体テストのファイルです。そのコンポーネントのテストはここに書くことになります。
Angular では、ルートコンポーネントがあり、そのコンポーネントの中に別のコンポーネントを埋め込んでいくように作ります。 ルートのコンポーネントは、app.component です。例えば、hero というコンポーネントがあり、それを app コンポーネントに埋め込むとします。この場合、app コンポーネントの HTML ファイル（app.component.html）に以下を追加したい場所に記載します。
<app-hero></app-hero>
するとこの <app-hero></app-hero> の場所に hero コンポーネントの内容が追加されるようになります。
ここらへんは、話を聞くより実際に動かしたほうが理解できると思うので、Angular のチュートリアルをすることをオススメします。
Visual Studio Code で Java 8 に対応する
全く更新してなかったけど、小さいことでも更新しようと思います。 苺ましまろ面白いです。アナ・コッポラちゃん可愛いよ。
最近、Java 8 を勉強中です。VSCode でStreamAPIを書くためにラムダ式を練習しようとしたら以下のような赤い波線が……。
ちなみに拡張機能として、Java Extension Pack を入れています。プロジェクトは、Maven で作りました。 で、先の問題を調べると以下を見つけました。
どうやらMavenによって作成される .settings/org.eclipse.jdt.core.prefs の中身が問題のようです。 自分のファイルは以下のようになっていました。
eclipse.preferences.version=1 org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.7 org.eclipse.jdt.core.compiler.compliance=1.7 org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning org.eclipse.jdt.core.compiler.processAnnotations=disabled org.eclipse.jdt.core.compiler.release=disabled org.eclipse.jdt.core.compiler.source=1.7
1.7 を 1.8 に書き換えます。
eclipse.preferences.version=1 org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.8 org.eclipse.jdt.core.compiler.compliance=1.8 org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning org.eclipse.jdt.core.compiler.processAnnotations=disabled org.eclipse.jdt.core.compiler.release=disabled org.eclipse.jdt.core.compiler.source=1.8
VSCode を再起動すると、以下のように消えました。
Team Geek を読んだ。
2013年に出た本ですが、今さら買って読みました。 読み物として読んだのであまりしっかり読んでいないですが、大事な話は1章に集約されている感じだったので、そこだけまとめようと思います。
ミッションステートメント
本書の目的は、プログラマがソフトウェア開発を効果的かつ効率的にするために、他人の理解・コミュニケーション・コラボレーションの能力を向上させることである。
というのがこの本の内容です。はじめに が来る前に書かれてあるのでそれぐらい重要な内容です。ここを理解してから本書を読み進めたほうがいいです。
全部で 6 章ありますが、進み方としては初めに自身の振る舞い良くする方法を提示し、2章でチームの文化を良くする方法、3章でチームリーダー、4章では害悪の人をなくす方法（人を排除するわけではない）、組織操作の方法、最後にユーザの扱い方を説明しています。
1章で説明されている HRT を基本としているので、他の章を読む前に 1 章を読むほうがいいでしょう。
天才プログラマの神話
世の中には、スゴいエンジニアがいるけど、その人たちのスゴさはエンジニアリングスキルではなく（もちろんそれ自体もスゴい）、チームをリードする力がスゴいという話。ソフトウェア開発は一人でするものではなく、チームで行うもの。チームスポーツなのだという。
世の中には、一人で隠れて開発したい人が多い。その人たちは自分の書いたコードやアイデアを人に見せるのが恐い。コードを見てバカにされないか、誰かにマネされて自分より先にプロダクトを世に出さないかが恐い。でも、公開されないソフトウェアは失敗する。相談する相手がいないので、過ちを犯しているのに気づかずに開発を進めているから。
早期発見
早い段階で、高速に、何度も失敗せよ
コードを書くときに全て書いてからコンパイルするだろうか？ 少し書いて、コンパイル。少し書いて、コンパイル。失敗を早く見つけることで早く修正できる。これをコードだけでなくプロジェクトでも行う。環境は唐突に変わる。それに合わせて設計、計画を変えないといけない。じゃあこの失敗を早く気づくにはどうすればいいか。チームで仕事をするといい（人の数だけ早く気づける！）。
バス係数を高める
バス係数とは、プロジェクト関係者がバスにひかれても、そのプロジェクトを続けられる係数のこと。値が高いほどプロジェクトを続けられる。
これは、チームの文化、人の採用を強化することで高めることが出来る。人の採用はただ闇雲に集めればいいわけではない。本書の 3 章を参照。
集中する時間
エンジニアが開発するには、集中する時間が必要。誰にも邪魔されずにコーディングに集中できる時間が必要。邪魔して欲しくないときのルールを作ると良い。ただし、それ以上にチームとの高速で高帯域な連携は重要（たぶん 2, 4 章あたりの話）。
HRT
- Humility（謙虚）
- Respect（尊敬）
- Trust（信頼）
人間関係の衝突は、この HRT の欠如によって起こる 。コミュニケーションの中心に HRT を心がけることが重要。
例えば、個人のエゴをなくす。自分の意見を押しつけない。集団のエゴを考える。それは、チームの功績や誇りなど。
例えば、批判をするときの言葉を選ぶ。相手のコードが間違っていると判断しても、相手に間違っていると言ってはいけない。提案をする。採用されないくてもいいような風に言うと良い。また、性格に対する攻撃的な非難をしてはいけない。コードはその人自身ではない。逆に批判を受けたときに非難されたと思わないこと。自分が書いたコードは、自分自身ではない。これをお互いに理解しておくことが大事。相手を尊敬していれば、非難しようと思わないはず。
信頼については、リーダーやユーザの話を参照（3 章、6 章）。
失敗から学ぶ。反復学習
過ちを犯したら文書化（ポストモーテム）する。文書化するときは、謝罪や言い訳を書かない。何を学んだか、何を変更するかを書く。見えやすいところに置いて、変更を継続できるようにする。
以下のことを書くと良い。
- 概要
- イベントのタイムライン
- イベントの根本原因
- 影響と損害の評価
- すぐに問題を解決するための行動一式
- 再発を防止するための行動一式
- 学習した教訓
文書化されることで、同じ過ちをする人をなくすことができる。歴史を繰り返してはいけない。
チームの文化
チームの文化を強化することで、外部からの悪い文化を排除することができる。その悪い文化は、主に新来者が持ってくる。文化はリーダーが作るのではなく、メンバーたちが作るもの。メンバーたちが持つことで、新来者へ継承できる（バス係数が高まる）。優れたチーム文化は、ソフトウェアを届けることに集中している。
効率的なエンジニアリング文化は、同期コミュニケーションを減らし、非同期コミュニケーションを増やす。会議（同期コミュニケーション）には、必要な人しか集めない。早く終わるように工夫する。決まったことは、メーリングリストで報告する。電話、ビデオ通話、チャット、メールなど（非同期コミュニケーション）を駆使する。あらゆるツール、あらゆる手法を使ってコミュニケーションを強化し、効率的に開発を行えるようにする。
ミッションステートメント
そのプロジェクトのミッションステートメントを決める。何をして、何をしないのか。これを決めないと永遠に肥大化する。また、ミッションステートメントは変化するときがある。会社の環境やプロダクトの方向転換があれば、ミッションステートメントもそれに合わせて変える必要がある。
おわり
この本、ページ数が少なく200ページにも満たないので軽い気持ちで読めました。何か役立てるために読むというより、読み物として読んでいましたが、楽しく、興味深い内容でした。ここにまとめたのは、1章、2章が主ですが、3～6章も大事なのでいつかまた読みたいです。とりあえず HRT を意識できるようにならないといけないかなと思ってここにまとめてみました。
とても上手に翻訳していただいた角 征典（かど まさのり）さんに感謝です。
今回からここに載せている元の文書を Github で管理するようにしてみました。 github.com
ブラウジング回りを整理した
雑記。 今まで Google Chrome を使っていたけど、 Firefox に変えて、ついでに情報収集のためのツールも整理した。
昔（スマフォ普及前）は、Firefox を使っていたけど、だんだん重くなって Chrome に移行した記憶がある。スマートフォンも持つようになってますます離れられなくなった。そのあとVivaldi が出てきて、ちょっと触って消して、入れて、消してと3回ぐらい繰り返して、去年ぐらいに会社で使う分には便利だったので使っていた。勤務先が変わったタイミングで使うのやめたけど。今は仕事では Firefox を使っている。一応 Web 系の仕事をするようになったので Firefox が適切かなと。Chrome は英訳用に入れている。英語スキルがあれば必要ないのだけど……。
Vivaldi も Chrome も Firefox もそれぞれに良いところがあって、これが最強とか決められない。他のブラウザは使ったことがないので知らない。Vivaldi はブックマークのアイコンのみ表示（Edge でも出来る！）とか、URL表示の切り替えやサイトのダウンロード状況表示などが魅力的なのだけど、スマフォで使えないのが痛い。ブックマークの共有が出来ない。この点で日常で使うのは無理だなと思った。
Chrome は特に不満はないけど、強いて言えば閉じたタブを復元するのにタブを右クリックしても最初は選択出来ないのが謎。自分の環境だけなんだろうか。タブの復元は Vivaldi が便利だった記憶。Firefox も特に問題ない。Chrome は、やっぱり Android ユーザとしては離れづらい。Android の Firefox は使いにくく感じる。上のタブの占有率が高いし、下にスワイプして更新が出来ない。Android では、まだ Chrome を使いそう。こうなるとブックマーク管理が面倒臭くなる。ブックマーク部分は独立して別アカウントで管理出来るようにならないだろうか。
Firefox に移行するついでにブックマークを整理した。フォルダに分けて、タグをつけてみた。今まで Qiita とか調べ物で見つけたちょっとしたテクニック的な記事はブックマークしていたけど、それは Pocket に移行しようかなと考えている（ブックマークしていると切りがないし、探すのに苦労する）。その点で Firefox は Pocket が標準で機能に入っているので良いなと思ったのだけど、Pocket のリストを表示 がPocket のマイリストをタブで開きに行くだけの機能で残念。Pocket にログインしておけばブックマークみたいに Firefox 上に表示されるのを期待していた。
あと RSS を使い始めた。Twitter する前はちょっと使っていたけど、最近まで使ってこなかった（サービスとしてほぼ終わっていると思っていた）。ニュース系のサイトを回るのだけど、自分が読みたいような記事が少ないサイトはだんだん見なくなっていた。あとは更新が少ないサイト（postd とか）も見るの忘れてしまったりで、情報収集としてこれはまずいなと感じていた。それを打開するために RSS が優れていると感じたので使ってみた。まだ２日しか経っていないけどなかなか良い。 Inoreader が特に良い。PC はブラウザで済むし、Android のアプリもある。日本語だし、GUIも気に入っている。ただジャンル分けしたいのだけど、そこら辺はまだ使い方がよく分かっていない。RSS はブラウジングとして強力なツールだと思った。
Slack を昔から使いこなしたいと思いつつ、全然使えていない。情報収集ツールとして便利そうなのだけど。今年使えるように検討中。
今までは、いろんなブラウザを使っているとブックマークがごちゃごちゃしていたのが、今回で落ち着いたので次からは気軽にブラウザを変更できるはず。Pocket はどうなるか……。
以上、雑記でした。
Google Cloud OnBoard In Osaka に行ってきた。
GCP の無料トレーニングがあったので、行ってきました。 内容は入門的な内容で GCP 触ったことがない人にはぴったりな内容でした。 ただ、サーバの負荷分散に使われる技術（ツール）とかの用語がびゃびゃっと出てきて理解できないところが多々ありました。
内容は、
ここでは、ストレージとデータベース、機械学習、今後の学習方法の紹介はしません。
本人が理解しきれていないからです……
GCP の概要
まとめると
- Google は完全なサーバ管理不要な環境を作ろうとしている
- GCP は、Google が長年培ってきたインフラを提供している
- GCP のインフラは Google が提供しているサービス（Gmail や Gmaps）と同じ環境で動いているので、セキュリティも同じ。
- お金の計算は、自動で最安になるようになっている。
- GCP のネットワークは、Google のプライベートネットワークと同じなので高速。
事例紹介
- Abema TV は、GKE（Google Container Engine）, GCLB（GC Load Balancing） を使っている
- Spotify は、独自のインフラから GCP に移行。
- airbnb は Cloud Translation API を活用している。
などなど
GCP のサービス概要
GCP には、大量のサービスがありますが、カテゴリに分けると6個になります。
- マネジメント - 権限やログ、リソースなどの管理ツール
- コンピューティング - インフラの提供。
- ネットワーキング - 負荷分散や VPC などを提供
- ストレージとデータベース - MySQL や NoSQL、ストレージの提供
- ビッグデータ - BigQuery, データ解析のサービスを提供
- 機械学習 - TensorFlow, 学習済みモデルの提供
GCP を利用するときは、3つのアクセス方法があります。
- Cloud Console - Web ブラウザ上で GCP にアクセスできる。人用
- Cloud SDK / Cloud Shell - PC に Cloud SDK を入れて使う。機械的作業用
- Cloud API - REST 形式の API インタフェース。プログラム用
ちなみにCloud Shell は、毎回インスタンスを立てているので、前回入れたものは消えるそうです。あと 5 GB まで使えるようです。
基本用語
まずは、クラウドサービスで基本となる用語だと思います。
- リージョン
特定の地理的な位置。日本だと大阪や東京にリージョンがあります。 - ゾーン
リージョンの中にさらに区分けしたロケーション。リージョンによって数は違いますが、大阪と東京にはそれぞれ3つのゾーンがあるようです。
GCP はリージョンを超えてもプライベートネットワークを維持出来るそうです。
リージョン間は海底ケーブルで繋がっているため、回線は速いそうです。
以下は、GCP で使われる用語です。 - プロジェクト
GCP のサービス（Compute Engine, BigQueryなど）やリソース（お金に関係する部分）の作成、管理（有効化や停止、削除）を行う。
まとめると、プロジェクトの中に、リージョンがあり、その中にゾーンがあるイメージです。
また、リソースという用語の意味が理解しきれていないですが、たぶんお金に影響する部分のことだと思います。例えば、Compute Engine だと CPU, メモリ, ディスクであり、BigQuery だと ストレージや長期保存、クエリ（分析）のことだと思います。
サービスは基本的にゾーンごとに作成されますが、モノによっては、プロジェクト単位で作成されるサービスもあります（Cloud Load Balancing）。
管理
Cloud IAM というサービスによって、誰が、どんな役割を、どのサービスに持つかを設定できます。
このサービスは無料で使うことが出来ます。
コンピューティング
主なサービスは以下の4つです。
- Google Compute Engine (GCE)
- Google App Engine (GAE)
- Google Kubernetes Engine (GKE)
- Google Cloud Function (GCF)
GCE (Google Compute Engine)
以下、特徴です。
- VM 上で動く
- 自由度が高い（普段のサーバと変わらない）
- 低コスト、自動で継続利用割引が適用されます。
- メンテナンスでも自動で VM が移動し、再起動が不要（ライブマイグレーション）。
- ネットワーキング機能（Cloud Virtual Network: CVN）の結合
ストレージの SSD は二種類あり、ローカル SSD の方が速いですが可用性は下がります。もちろん普通の HDD もあります。
Cloud Virtual Network というサービスのおかげで、リージョンを跨いだ Virtual Private Cloud ネットワークが構築できます。内部 IP アドレスや、ファイアウォールを自由に設定出来るようです。
GAE (Google App Engine)
- インフラ部分が完全に抽象化
- アプリの使用状況に応じて課金
- バージョンが異なるアプリも簡単に共用できる
お金は、2 インスタンスからかかります。インスタンスの数は自動で変化するので、リクエストが全くないときは、インスタンスの数が 0 になります（お金がかからない）。サーバ管理は一切不要です。
GKE (Google Kubernetes Engine)
- コンテナオーケストレーションシステム
- GCE や CVN と連動して動作
- GKE 自体にお金はかからない（GCE や CVN にかかる）
- 管理する環境を提供（アプリのデプロイ、更新、管理が簡単。自動スケーリング、アップデート）
GCE をコンテナで動かし、管理するサービスです。Docker や Kubernetes を使って、コンテナ管理することが出来ます。
Google Cloud Function (GCF) Beta
- サーバレスアプリケーション
- コードが実行される時間に対してのみ、最も近い 100 ミリ秒単位で課金
- 複数のクラウドサービスを関連付けて拡張
- Firebase のようなサービスと統合できる
まとめ
コンピューティングの 4 つのサービスを紹介しました。それぞれ特徴が異なり、どういうときにどれを使ったらいいか迷ってしまいますが、発表者の方は以下のように分けるといいと話していました。
- GCE -> 現在、物理や仮想上で動いている既存のアプリの移動。
- GAE -> 新しく Web アプリサービスを作る場合におすすめ。
- GKE -> 社内のセキュリティ上 GAE が難しい場合、こちらを使う。
個人的には、Web アプリサービスを作りたい、サーバ管理したいような学生が使うと良いのではないかと思いました。登録一年は、$300 無料で使えるし、ちょっと試すぐらいならお金はかかりません。チュートリアルも丁寧で、何も知らなくても言われたとおりにするだけで動かすことが出来ます（もちろん理解した方がいいですが）。
ここでは、ストレージとデータベース、機械学習を紹介しませんでしたが、これらを使うことで作りたいサービスに必要な技術の壁をなくすことができます。ぜひ、GCP を使って遊んでみてはいかがでしょうか。
