なになれ

IT系のことを記録していきます

Angular Form Validation @template-driven forms

Angular公式のForm Validationのコードサンプルがよろしくないと思ったので、
エラーメッセージの冗長部分の排除とバリデーションの汎用化を意識して書き直してみた。

なお、template-driven formsの例を対象としている。

エラーメッセージはバリデーションの内容によって定型化すると思われるので、
定型エラーメッセージの中で個別に変えたい部分だけをパラメータで変えられるようにした。
Javaっぽい感じ。

次回はReactive formsのValidationを検討してみたい。

Angular Update作業 ~Angular4 and Angular CLI~

GWでいそいそAngularのUpdate作業をした。

Angularの環境構築で苦労した

Angular2が正式リリースされてから、ちょこちょこ触っている。
その時に作ったAngular環境は、Angular2+webpackで構成してた。

ちなみにwebpackでの構成は、Angularの公式ドキュメントにも紹介されている。
Webpack: an introduction - ts - GUIDE

ただwebpackが1系だったり、コードカバレッジのための設定を追加していたり、e2eテストを追加していたり、環境のメンテが大変。
このあたりの問題を解消するために、Angular CLIが使えるっぽい。
Angular CLI

既存のアプリをAngular CLI化してみる!


既存のアプリをAngular CLIに移行、さらにAngular4にもUpdateしちゃう

Angular CLIへの移行方法は、公式のドキュメントに書かれている。それを参考に実施した。
stories moving into the cli · angular/angular-cli Wiki · GitHub

Angular CLI内部ではwebpackが使われているようなので、webpack前提の既存アプリがすんなりと起動できた。
公式のドキュメントでも言及されているが、SystemJS前提だとコードの修正が必要になるはず。

v1.0.0のAngular CLIからデフォルトでAngular4のアプリになる。ついでにAngular4にUpdateできちゃう。

ng new awesome-app

アプリ作成段階で、ユニットテスト環境やe2eテスト環境も用意される。
今まで自力で用意したテスト環境がコマンド一発で用意される。簡単。素晴らしい。

コードカバレッジは以下のコマンドで出力可能。

ng test --watch=false --code-coverage

まとめ

Angular CLI優秀だった。
今までwebpack構成を自力でメンテしてきたけど、同じようなことがAngular CLIでコマンド一発でできてしまう。
これは乗り換えない理由はないと思った。

Agile Japan 2017 セッション感想と気付き

Agile Japan 2017に参加しました。

色々なセッションに参加しましたが、印象に残ったセッションを紹介したいと思います。


【心】見える化カイゼン・カンバンが全社に広がった

~口コミで広がった会社見学ツアーへの想い・ボクが仲間を信じれば会社は変わる~

約5年で、社員がいきいきと仕事をする文化を作ることができた。
その結果、社外の人向けの会社見学ツアーが行われるようになったという話です。

まるでジョイ・インクの日本版、サクセスストーリーです。

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

情熱を持って取り組む姿勢に胸熱でした。
こういう風にしたいを実践している事例だと感じました。

タイミングをみて、推進委員会を作ったり、外部の有識者を呼んだりして、 社内の熱を冷まさないように行動する。

こういったファシリテーションを参考にしていきたい。

Fearless Changeのパターンにも通じるところがあります。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

著名人を招く、メンター、正式な推進担当者、そして、みんなを巻き込むのパターンを使っていこう。


【基調講演】 “モダンアジャイル

モダンアジャイルに関しては、以下の4章が参考になります。

「安全を必須条件にする」にも、文化的な側面と、技術的な側面がある。
文化的な側面では、Googleのチームに対する研究成果を例にして、ミーティングにおけるチーム内での効果的な行動指針が紹介された。

説明としては「非難しないこと」になるんだけど、一つの具体例としては、チームメンバーが平等に発言している状態にあることかなと理解した。

What Google Learned From Its Quest to Build the Perfect Team

技術的な側面は、テスト自動化とか、CI/CDなどのプラクティスがある。
間違ってもすぐに気付けるので安全ということ。

心理的安全性という言葉が流行っているけど、ITの世界だと、文化と技術の両方のアプローチが必要なんだということに気付かされました。