[私感]Angularの学び方

 さいきん、仕事でAngular 7を使っている。それまでAngularを触ったことはなかった。

 Angularでライブラリを作る場合、それはモジュールにコンポーネント、サービス、ディレクティブの三つをつっこむことになる。三つがつっこまれたモジュールをインポートすることで、そのなかのコンポーネント、サービス、ディレクティブが一気に使えるようになる。そしてその三つ以外を基本的には宣言してはいけない。クラスはおろか、文字列や数値もだ。
decrable(Angular)

 基本はチュートリアルから学べばいい。それに加えてng-container、ng-template、ng-contentを理解しておく。とくにng-content。コンポーネントを使ったら下記のように自作コンポーネントに要素を入れる、というのをやりたくなるはず。これをやるためにコンポーネント定義でディレクティブng-contentを使う。
<my-div>

<span>foo</span>
</my-div>

comment: 0

ブログのバックエンドをKubernetesにしてみた

 去年のいつだったか、会社のエンジニアではない人に「なんでうちのエンジニアたちはKubernetesを使いたがっているの?」と質問された。エンジニアではない人もPaaSなどがわかるように教育されていたおかげでわりと簡単に答えられた。「PaaSはサーバ管理を任せられるし、スケーリングやローリングアップデートなんかもワンクリックで済むぐらいの簡単さがある。だけどそれは各クラウドベンダがそれぞれのやり方で実装しているものだから、ベンダロックインを受けてしまう。k8sは前に挙げた便利機能を持っている。そしてどこで動かしたっていいからベンダロックインを回避できる」と答えた。

 去年の年末、このブログを動かしていたコンテナホスティングサービスからサービス終了の告知が来た。コストなどを少し考えた上でAzureのマネージドのk8s、つまりAKSを使うことにした。
 ぼくの説明は本当に正しかったのか試す機会を得た。この、Dockerイメージ化されてコンテナホスティングサービスで動いていたブログをAKSに移行するのに、どの程度Azure独自のことをしなければならず、どの程度k8sの設定で済むのか。そんなところをやってみた。Dockerイメージ化されたブログを、Let's Encryptで証明書を取得、自動更新しつつHTTPSで配信するという構成。


 k8sに配置するリソースは下記のものを用意した。YAMLの詳細は後に回す。
- Deployment: アプリのPodをコントロール
- Ingress: http & httpsアクセス
- Service: Ingress - Pod間のネットワーキング
- Certificate: 証明書情報(Let's Encryptで取得)
- Secret: 外部データベース、クラウドストレージなどの接続情報
これらはもちろんk8sの標準的なリソースなのでAzureだから特別な書き方をしなければというのはない。標準的なYAMLだ。

 AKSでk8sを立ち上げてCLIで接続後、唯一Azure上の独自のやり方でやらなければならなかったのはIPの発行。まあここはさすがに仕方がないことだし、コマンドですぐに発行できるし。
az network public-ip create --resource-group [resource name] --name [ip name] --allocation-method static


IPを取得したらもちろん、DNS設定は忘れずに行う。

 デフォルト構成にHelmを加え、CertManagerを入れたが、これはk8s側に用意されたもので、WindowsでもCLIが動くので簡単にAKSのk8sへ入れることができた。
Azure Kubernetes Service (AKS) での Helm を使用したアプリケーションのインストール
helm install stable/nginx-ingress --namespace kube-system --set controller.service.loadBalancerIP="[ip]" --set controller.replicaCount=2 --set rbac.create=false --set rbac.createRole=false --set rbac.createClusterRole=false

helm install stable/cert-manager --namespace kube-system --set ingressShim.defaultIssuerName=letsencrypt-prod --set ingressShim.defaultIssuerKind=ClusterIssuer --set rbac.create=false --set serviceAccount.create=false


 IP取得&それのDNS設定、Helmが準備できれば、あとはk8s上にリソースを配置していくだけだ、YAMLを読み込ませることによって。あとドメインとIPが結びついてなけりゃ証明書取得はできるはずもないので忘れないこと。
apiVersion: apps/v1

kind: Deployment
metadata:
name: app-deployment
namespace: tetsujin
labels:
app: tetsujin
spec:
replicas: 1
selector:
matchLabels:
app: tetsujin
template:
metadata:
labels:
app: tetsujin
spec:
containers:
- name: tetsujin
image: matoba/tetsujin:414
ports:
- containerPort: 80
env:
- name: HASHKEY
valueFrom:
secretKeyRef:
name: tetsujin-secret
key: HASHKEY
- name: MONGO_CONNECTION
valueFrom:
secretKeyRef:
name: tetsujin-secret
key: MONGO_CONNECTION
- name: STORAGE_ACCOUNT
valueFrom:
secretKeyRef:
name: tetsujin-secret
key: STORAGE_ACCOUNT
- name: STORAGE_KEY
valueFrom:
secretKeyRef:
name: tetsujin-secret
key: STORAGE_KEY
- name: STORAGE_URL
valueFrom:
secretKeyRef:
name: tetsujin-secret
key: STORAGE_URL

↑のYAMLはCPUやメモリのリソース制限をかけていないのでよろしくない。自分の環境に合わせて適当に適切な設定をすること

apiVersion: v1

kind: Service
metadata:
name: tetsujin-service
namespace: tetsujin
labels:
network: tetsujin
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
app: tetsujin


apiVersion: extensions/v1beta1

kind: Ingress
metadata:
name: ingress-tetsujin
namespace: tetsujin
annotations:
kubernetes.io/ingress.class: nginx
kubernetes.io/tls-acme: "true"
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/rewrite-target: /
ingress.appscode.com/hsts: "true"
ingress.appscode.com/hsts-preload: "true"
ingress.appscode.com/hsts-include-subdomains: "true"
ingress.appscode.com/hsts-max-age: "100000"
spec:
tls:
- hosts:
- blog.hmatoba.net
secretName: tls-secret
rules:
- host: blog.hmatoba.net
http:
paths:
- path: /
backend:
serviceName: tetsujin-service
servicePort: 80

↑もHSTS有効化はしたけどもう少しセキュアなものにしたい

apiVersion: certmanager.k8s.io/v1alpha1

kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: foo@example.com
privateKeySecretRef:
name: letsencrypt-prod
http01: {}


apiVersion: certmanager.k8s.io/v1alpha1

kind: Certificate
metadata:
name: tls-secret
spec:
secretName: tls-secret
dnsNames:
- blog.hmatoba.net
acme:
config:
- http01:
ingressClass: nginx
domains:
- blog.hmatoba.net
- http01:
ingress: ingress-tetsujin
domains:
- blog.hmatoba.net
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer




 上記のYAMLに加え、Secretを用意してしかるべき順でリソースをk8s上に加えていった結果このブログが動作した。Let's Encryptで取得した証明書でhttps化も問題ない。結局Azureのマネージドk8sサービスであるAKSを使ってWebアプリを公開するにあたってAzure独自でやらなければならないのは、Azureのコンパネに従ってk8sを用意することと、IPの発行だけであった。それらは簡単だったし一度で終わることなので、それ以外のことやこれからの運用はk8sのお作法に従うだけだろう。こりゃロックインは回避できてるなというところ。


 余談。AKSの料金は開始時に設定した仮想マシンリソースの設定に従う。仮想マシンリソース。CPUが何コアのメモリが何コアという、仮想マシンにありがちなアレ。アレはリザーブドインスタンスというものがあり、長期で先に金を払ってリソースを買っておくことで使用料が安くなる。一年分を先買いで40%OFF。断然お得。
comment: 0

転職雑感

 一年前にストレスでぼろぼろになっているところで転職した。転職にあたっては、会社で使っている技術ではアピールにならないと思ったので、OSS、Github、コミュニティあたりが鍵だった。
 それからまあ一年やってきて、身の回りでも転職の話を聞いてきたし、会社の人事ともちょっと立ち話をしてみたりで世間の事情を見て思うことがある。自分の転職から話を始めて、いくつか書いてみる。ニートから身を起こしたなりの二歩目のこととか。


・ちょっとでも会社に疑問を感じたら、転職の準備をしておく

 一年と少し前、メンタルがボロボロな状態に陥った。受注のタイミングから参加したプロジェクトだった。
 受注直後からクライアントとミーティングしつつそのあいま、アプリ改修のタスクをこなしながらもろもろ調べていると、要件漏れしている部分が大きすぎる、アプリ自体もjQueryより前の技術で書かれたSPAという高難易度案件ということがわかった。で、リソース足りないということを会社のえらいひとに相談に行ったところ、ほぼ全部をぼくの責任ということにされた。それでもうそこにいる気は完全になくした。のちに追加投入されたベテランに聞いたところ、まっとうにやるには計画の四倍はリソースが必要だよと笑っていた。

 その会社にいる気はなくしても、転職活動なんてやる気力は当初はほぼなかった。リソースが足りていないので平日はもちろん土日も深夜まで仕事をしていた。転職エージェントに電話を入れつつも、面談予定の日が来ると、都合が合わずに延期の電話を入れていた。
 半年ぐらい前から休日に参加していた勉強会があった。そこのメンバが採用でも動いているという話を聞いていたので、彼に試験を受けたい旨を伝えた。なんとかその面接だけ仕事の合間をこじあけて日程を作った。ここ一番の勝負どころだったが、面接をパスして内定を得ることができた。一次面接はカレー屋で行われた。「カレー、食わなきゃ冷めるぞ」と言われるおかしな面接だった。いい意味で。
 しかしそのカードを持っていなかったら今ごろもうちょっとボロボロになっていたと思う。

 前の会社に入って3か月で疑問を感じ、自分で勉強する内容の精査を始めた。そのときDockerを選んだ。それからさらに一年後に勉強会に参加するようになり、今の会社につなげてくれた彼に出会った。レガシーな技術しかやらないところでは得られないことを自分で学んでブログやOSSに反映していたこと、それを理解してくれる人との縁があったことが救いだと思う。
 前の会社に対して、ぼくもいたらないところはあったとは思う。だけどそこが初めてのキャリアであったが初日から一人で開発者としてアサインされ、メンバーをフォローしながらプロジェクトを回していたこと、誰もフォローしてくれない状況でも口うるさくセキュリティの啓蒙をしたことなどから負い目は感じていない。

・メンタルが傷ついてもその程度が自覚できない
 転職してから半年超、過ぎ去ったことでのいらないイライラが頻繁に湧いてくることに悩んだ。寺に修行に行く必要が出てきたかと思うぐらいにイライラしてくるのがコントロールできず、集中力がかなり落ちていた。忘れるというのはそんなに簡単なことではなかったし、どうにかかなり薄まったが、この先それが0になって消えることはないだろうと思う。


 とりあえずぼくがこれまでに得た教訓は、転職準備は、疑問を感じたなら早めにしておいたほうがいいということ。いつ無理な状況に陥るかというのはわからない。いまは転職のおかげで、そういう心配が薄い状況に移った。

・プログラマ(あるいはその界隈のエンジニア)の転職事情
 このご時世でプログラマの求人倍率は高いという話を聞く。すごい福利厚生のメルカリも目を見張るような採用計画を発表したりと。
 それでも結局企業が本音で欲しがっているのはしっかりしたキャリアとスキルだろう。そういう人はすんなりと有名所にいい条件で決まっていくのを見た。一方で会社に入ったばかりで具体的なスキルを持っていない人は、それなり多くの会社を受けているのを見ている。

 企業も人材不足から贅沢を言ってられないのを認めざるをえないというところで、新卒すら競争が激化しており、第二新卒で将来性を感じさせてくれる人を、という状況になっていると人事から聞いた。とくに東京のプログラマ界隈。
 第二新卒にはそれほど技術スキルは期待しない様子がある。まあそりゃ独学でどこまでいけるかなんて難しいもんだ。それでも内定を得るには、なにかでほかの求職者と差をつけなけりゃならない。やはり求人をかけていれさえすれば、求職者は二人、三人と応募があるだろうからその中での競争には勝つ必要がある。
 ぼくは求職の時、三年後だの将来だのにどうなりたいかなんて、じっさい始めてもいないのにわかるわけないだろうと思っていた。だけど、プログラマという界隈、下手をすればプライベートでも自分の時間や金を使って勉強が必要になるかもしれないようなこの職では、応募の最終競争に勝つため、技術を自分で吸収していけるというスキルを示すためにも、将来というのを具体的に面接で話せるようにしておくのはやっておいたほうがいいのかもしれない。いや実際これ難しいけど。

・Githubアカウントによるアピール

履歴書にはGitHubアカウントを書かない方が良い説

 ↑こんな話が出回ったことがある。
 Twitterで転職したいですと書いている人のGithubを覗くと、なにかの設定ファイルが置いてあるだけってのをいくらか見たことがある。まあ、なにが正しいというのはないだろう。
 個人的な考えとしてアピールとしたいなら、なにかのチュートリアルをやったなら、それをちょっと応用してみたところまではやりたい。たとえばフロントエンドエンジニアの求人に応募するならReactやAngularのチュートリアルをちょっと応用してみましたとか。バックエンドならDockerを使ってデータベース教材を作ってみましたとか。こういうところで、使っている技術を理解した上での、自分の考えを盛り込んでおくとアピールにつながりやすい。
 ただし、Githubをやっている人がそもそも限られた場所にいて、面接官として出会えないことがある。Githubのアカウントを伝えておいたのに内容をまったく見られていないことがある。というかあった。努力は報われないこともある。それでもいい会社に入りたけりゃ、努力はしておいたほうが結果はよくなる。


 プログラマの求人倍率は高いというが、それは大半がしっかりしたキャリアを歩んでいる人に対してであって、そのスタートに立とうとしている状況にいるなら、それは難易度イージーではないというのがぼくの視点から見たところの状況。
comment: 0

分人

 さいきん興味のわく本を教えてもらう機会があってそれを読んでみた。平野敬一郎の”私とは何か――「個人」から「分人」へ”というタイトルで、分人という概念で個人を捉えることを提起していた。そんな「分人」そのものについては書かず、これまでぼくが読んだもの、知ったものとリンクしていた気がするので並べておく。


荒野のおおかみ - ヘッセ
"胸や体はいつだって一つだが、その中に宿っている魂は二つ、あるいは五つでなく、無数である"
 以前に友達の前で一貫性を欠いたことを言ったときに、これを言ってごまかしたことがある。そいつはヘッセが好きだったから納得してくれた。
 この書き方だと「相手によって」という条件に限らず、時と場合によって表に出てくる魂が変わることもあるのかとも思うが、それでも「個人」というのが一つの特徴のみを持つという考えには反している。


ブリタニカ百科事典
"性格とは、気分、態度、意見、対人的態度を含む思考と感情と行動の癖で、遺伝や学習の結果である。性格とは個人差のことであり、環境や社会に対する関係を観察すると把握できる"


ラルフ・ウォルドー・エマソン
"他人とは、自分自身の心を読み取ることのできるレンズである"


アンドレ・ジイド全集〈第14巻〉 - アンドレ・ジイド
"これに対して、ドストエフスキーはわれわれに何を示しているのでしょうか。自分ら自身に対して一貫した関係を保つということをなんら意に介さずに、自分らの固有の性質が受容しうるあらゆる矛盾、あらゆる否定に喜んで降伏する人物たちをです"


オルテガ―人と思想 - 渡辺 修
"ある物の実在は 、それが見られる視点がどこにあるかとは無関係に、それ自体が独自にそこにあるのだ、とする考え方が昔からあったが、それは誤りだとオルテガは断定する。実在は風景のように、すべてが同等に真実で同等に無限のパースペクティブである。唯一無二であると称するようなものが、虚偽のパースペクティブである"


異邦人 - カミュ
 この物語の主人公ムルソーは、殺人による裁判にかけられ死刑となった。ムルソーは人の死を悲しまない残忍な人物として一貫性を押し付けられた。
 ”私とは何か――「個人」から「分人」へ”では下記のような文があって、読みながら裁判で人格を押し付けられていくムルソーを思い出した。
”社会としては、できるだけ不確定要素を取り除きたい。個人が首尾一貫していなければ、社会の基本となる構成要素が不安定になり、方々で機能障害が起きてしまう”
comment: 0

2018: ゆく年くる年

 一年が終わるので今年にあったことをまとめておく。まあ自分のOSSのメンテを継続しつつ、勉強しつつ、転職したりといったところか。

--- OSS
Piexif
 Pythonでexifの編集をできるライブラリ。今年はGoogle CloudのプロダクトマネージャからIssuesが上がってきたり、AWSのあるリポジトリで使用され始めたり。
 機能としてはPNGもexifをメタデータの形式としてサポートという話が出てきたので実装を進めたが、テストに使えるPNGがなくてテストをまだ書いていない。なのでマージはまだ。

piexifjs
 ↑のものをJSに移植したもの。だいぶ前に書き上げたものだったのでソースが一つのファイルで可読性悪かった。仕事でTypeScriptを使ったので、それで得た知識をプライベートプロジェクトに輸入させてもらった。あとはRollup使ったりでかなりモダンな構成にできた。そのあたりの改修が現在ベータバージョン。

 仕事やプライベートでの技術調査をしていると、OSSに費やす時間をひねり出すのがだいぶ難しくなってしまっている。この辺はだいぶ割り切った考えをするようになった。金を取っていなので、最大限のサポートはしなくていいという考え。

 Issuesは具体的、再現可能な報告が来ない限り積極的な対応を控えるようになった。
 重大なバグがあればもちろんできる限りすぐ対応する。しかしIssuesには、それじゃ再現できんやんという情報量で上がってくるものが少なくない。ヒアリングでデバッグできるように情報を聞き出すまで3、4日費やしたりする。しんどい。なので再現可能な情報が来ない限りは積極的な対応はしないで待つ。OSSなのでプルリクを期待して待っている。

--- 仕事
 今年は転職した。職種はプログラマ(あるいはエンジニア)のまま。待遇的にも技術的にもいろいろ良くなった。

 年収が100万円以上200万円未満でアップ。有休がチャットでのメンバへの通知とシステムでの日付指定で取得できる。フレックス。こういうところで守るべきものが守られていて、その上でこっちを信用してくれてある程度の柔軟さを与えてもらえるとがんばっていかねばという気分になる。
 転職後、仕事で学んだ知識をプライベートプロジェクトに活用したというのも、前職にいたときには考えられなかった。前職で使う技術は枯れたもの、あるいはそれを通り越したものばかりだったと思う。それではまずいと思いいくらか変えようとしたが、結局なにも変えられなかった。

 転職活動では会社でなにをしたかを話すのがスタンダードなところだろう。だけどそこで技術的にアピールできるところはかなり少なかったので、プライベートプロジェクトにつっこんだ技術の話をしながら、「会社でこういうことをしていきたい」と話した。

--- 技術
 このブログを動かしているコンテナホスティングサービスがあと一か月もしないうちにクローズという通知が来た。AKSを始めたのでそっちに移植。
 仕事で課題が見えているので、自分のOSSのメンテはほどほどに勉強していきたい。今年はk8sをちょっと触った程度だったのでそこはがっつり。



 今年は定年説のある35歳を目前に転職した。ロールはほぼ変わらないが、周りの開発者からいろいろ学べる環境になった。いい環境になったので邁進していきたい。
comment: 0