Angular でPipeを作ってみた

一つ何か機能を作ると、あっちでこっちで「使いまーす」宣言。まるでスタンプラリーしているかのようなw ま、ラリーの道筋さえ理解して巡回?すればよいのだろうけれどもねw わかるまでが大変よね。

Angularの便利な機能「pipe

CUIを使う人ならおなじみの縦棒さんね。これをhtmlテンプレートに仕込んでViewを飾れるというイケテルやつ。

こいつを作ろうと思ったのさ。

> ng g pipe pipe01 

さくっとテンプレの1セットを作ってくれるので、うはうはと書く。

  • テストコード
  • メインとなるパイプのコード

そしてここからが import {pipe01Pipe} from hogehoge 宣言の スタンプラリー

  1. app.module.ts の declations に追加
  2. app.module.ts の providers に追加
  3. パイプを使いたい compornent.ts に追加
  4. 3.のテンプレHTMLにパイプを追加

これの1と2の部分が抜けていて、ずっとレッドしまくって苦しんで泥沼になったので、良い子は迷わないでね。

そしてテストがグリーンになって、パイプが使えて、OKOK。

Angularのソースをお片付け

一つ一つの役割が明確で、セットでまとめられてて、かつ、それらが多数発生する細かい環境ってことは引き出しに名前をつけて階層だててお片付けしないと、混乱するよね。一番苦手なことなんだけどな、お片付け<を

Angularで色々とサンプル書いてテストして、を楽しんでるんだけど、ふと、ファイルがごっちゃになりすぎてどうしよう、になっちゃった。なので、ちょっとネットを巡回して見つけてみる。

Angular Folder Structure Best Practices
https://www.tektutorialshub.com/angular/angular-folder-structure-best-practices/

ここを参考に考えると

├── src
│   ├── app
│   │   ├── common
│   │   │   ├── models
│   │   │   ├── services
│   │   │   ├── pipes
│   │   │   ├── modules
│   │   ├── subsystem(named by dev)
│   │   │   ├── models(inherit or original)
│   │   │   ├── services(only subsystem)
│   │   │   ├── pipes(only subsystem)
│   │   │   ├── compornents
│   │   │   ├── interfaces
│   │   ├── shared
│   │   │   ├── layout
│   │   │   │   ├── footer
│   │   │   │   ├── header
│   │   │   │   ├── navigation

でどうかな。

すっきりすると思うの。これでやってみようと思う。

AngularのUnit Test (Karma)を動かしてみた

「こいつ、動くぞ!」play back part 2. なにが衝撃って、そのままにしておいて、ソースコード保存するたびにコンパイルしてブラウザで延々と結果を表示するってなにそれ怖いw

きっかけはね、ここから。

Angular公式のチュートリアル
https://angular.jp/tutorial/toh-pt0

言われた通りに、プロジェクト作って、 ng serve してひゃっはー!したんだけど、スペル間違ってたのね。なので修正したわけさ。

そして、何も考えずに、試しに ng test したら

image

れっどー!! うん、of を off に間違えてたさ。なおしたさ、compornent.ts だけをw

で、 ng test は compornent.spec.ts のテストコードを動かすってことを知って、コードをのぞいてみると、そこにもミスしたときのスペルが残ってることがわかって、修正。

image

グリーンだよ。

Visual Studio Code では、ターミナルあげっぱでng testしておけば、後はガンガン書いて修正して保存して、で行けるので作業集中できて楽しい。

んでもって、まとまってグリーンになったら ng serve するのが私にはあってるみたい。

うん、手軽だわ。最新でさわったのがAngular8だったから、11になってずっと簡単になった印象

細かいところはこれから突っ込んで遊んでく。

de:code2018 に行ってきた

技術や情報、ヒトとモノ、行きかう出会う触る知る、「お土産」は物質だけじゃないから、この手のイベントはやめられないw あ、会場を着物でウロウロしていたのが私ですw

Microsoftさんとこのイベント、de:code2018 今年もアプリ提供で色々と捗りました。

https://www.microsoft.com/ja-jp/events/decode/2018/

Screenshot_20180524-184756Screenshot_20180524-184814

行ったセッションはこんな感じ。

アプリケーション開発(デスクトップ&.NET)を中心にして、興味ある分野(CSIRTとか、オンプレとか)つまみ食い。

体調と相談しながらだったからフル参戦はできなかったorz

今はチマチマと自己満足ライブラリ作ってたり、ときどきコンサルしたり、翻訳したり、だから、べったり開発者です的な活動はしていないけれど、こういったイベントで「何か」を得ること、それは知識や出会いや再会や10%引きの関連書籍やノベルティとかかもしれないけど、私の言葉でいう「お土産」をもって帰ること、はとても大事っていつも思う。

セッションの終了には「Ask the speaker」ってのがあって、セッションしてくれた人と一対一で話せるし、DAY1の最後にはパーティがあって、偶然同じテーブルになって一緒に乾杯して大盛り上がりしちゃうかもしれない。袖すりあうも、で、名前きいたら、知ってるコミュニティの人だったり、とある書籍の作者だったりするかもしれない、掲示板で質問に答えてくれていた人かもしれない、それでいいと思うんだ。市場調査、知識吸収、それぞれの目的があるし、その目的のためにイベント参加もあると判る一方で、きっとそれ以上の「お土産」があるのが「イベント」であり、「勉強会」だと私は思う。その「お土産」に自分の資産(時間とお金)をどこまで使えるのか、最後はそこに尽きるけどw

システム屋って、案外、孤独な時ってあるんよね。私みたいに、おひとり様情シスとか、Sierもどきとか、いろんな業種業界業態で、時には全く異世界な環境でITやってたりとかしてるとね、そんな気持ちをもったりすることあるんだ。そんなとき、そんな大変さを知っている人たちと知り合いでいる、ってことはとても支えになったりすることある。大変さを知らなくても「大変な人もいるんだ」と生で知ることも、きっと、そうならないための試金石になれるし、反面教師にもなれる。私としては、「同じ轍は踏んでほしくない」っていつも思うし。だから、「お土産」を何か持ち帰ってほしいなぁと、その「お土産」に私がちょっとでも手伝えていたらいいなぁ、と思ったりもする。こういうところに現れる時にはねv

といっても、アプリにはまだまだ改善点があるし、会場動線の問題、休憩できる場所が少ない&わかりづらい、とかあるけれど、

んなことはとりあえず置いといて、

今回も、たくさんの「お土産」をありがとう。