何かと bash/zsh で作業していると、直近の引数を再度入力したくなることがある。
たとえば、ディレクトリを作って、その中に移動する場合などだ。
実は bash や zsh には直前の引数を再度入力する特殊変数が存在する。
% pwd
/tmpこの /tmp ディレクトリから新規ディレクトリを作成し、そこに移動する場合、
このように表現することで移動することができる。
% mkdir hoge; cd $_
% pwd
/tmp/hoge$_ という変数が特殊変数という扱いになり、直前の引数を再度入力することができる。
今まで fargate で service を動かせていたが、platform 1.4 では動かせないことがあった。その対処法を紹介。
pseudoTerminal option があるが、falase だと起動した後に停止してしまう。解決策としては、
pseudoTerminal を false から true にすること。
そもそも pseudoTerminal とは擬似ターミナル。
Docker Remote API の コンテナを作成する際、セッションの TTy にマッピングして docker run にマッピングするオプション。
1.3 まではこの設定が false でも動かすことができたが、1.4 ではこれを true にしないと動かすことができないようだ。
見て、読んで、買ってもらえるコトバの作り方。
人に読んでもらうための資料を作ったり説明する機会が多く、意図がうまく伝わってなかったり、たまに誤解を生んでしまったり、自分の表現力について課題を持っていた。
たまたまセールスコピー大全を見つけたので、自分の表現力を向上させることができるかもしれないと思い、読むことにした。
セールスコピーライティングとは、求めている人を探し、彼らの心を動かす提案を考え、それを魅力的に語る技術。欲しい人へ欲しいものを売る方法。と定義されている。
自分は「商品を求めている人が、求めているポイントを見つけ出して売ること」と解釈した。
自分の読み始めるモチベーションとしていた自分の表現力について課題についての解決策を語るのが本の趣旨ではなく、いかに売るかがこの本のポイントなので、自分に刺さったところだけをピックアップしてメモとして残す事にする。
どうすれば売れるだろう、何を言えば売れるだろうという考えを排除する。
そうではなく、「お客さんが強く求めているのは何だろう」、「お客さんの興味関心は何だろう」と考え、そこからセールスコピーを書くというアプローチ。
常にお客さん（読み手）を意識してそこに求められていることから考えなさいというポイント。なるほど。確かにそうだ。
つまりこのステップになる。
ベネフィットは読み手が求める嬉しい未来であり、商品から得らえる嬉しい未来。
特徴やメリットはそのベネフィットが叶う理由になる。。特にメリットの部分は引き立て役に過ぎない。
ベネフィットとメリットは混同させてはいけない。
キャッチコピーは訴求を魅力的に表現した短い言葉。訴求を読みやすくわかりやすくするだけで十分。
ベネフィットさえ読み手を織り込んだ要素があれば「xxの悩みを抱えている方へ」などの記載も不要になり、より短い文にすることができる。
意味が伝わるギリギリまで不要な言葉をダイエットする。
ベネフィットを語る部分は、なるべく疑問が似合う表現に変える。
「なぜxxの売り上げがアップするのか。」
「xxの売り上げがアップする理由。」など。
この本で取り上げている例がとても分かりやすかったので、そのまま紹介。
NG: アンチエイジングに興味があるあなたへ
99 ページ
OK: 若かったあのころに、戻りたいあなたへ
99 ページ
心の声に置き換えると読み手の共感を得やすいからが理由とのことだが、上記例で溜飲が下がった。
本書には記載がなかったが漠然とした「広い土地」とかではなく「東京ドームn個ぶん」という表現をテレビのレポータがしているのを思い出した。確かにその方がイメージもしやすい。また、数値表現がレスポンスに大きな影響をもたらし、具体的な数字が信憑性を高めることができる。
また、数字の３には物理的な安定感のある数字であり、３が付くものは受け入れられやすいという特徴がある。
一例として医師も認めた。などがそれに該当。
自分は資料作りの時に説得力あるからということで国の公開資料を使うこともあるが、確かに自分も無意識にやってた。
ちなみに、以下のサイトでは政府が公開している資料の閲覧もできるし、API で利用もできる。
興味深いストーリーならば、たとえ広告であっても、多くの人が興味を持って読み進めてくれる。ストーリーにはメリハリをつける。特にどん底と、最後の成功がポイントとなる。
本書の大半はタイトル通り物をうるために使うセールスコピーだが、人を説得するという店では物を売ることを行わないエンジニアである自分にも使える知識もあるし、資料作りや人を動かす上での説得させる上での武器が多く書かれていた。すぐに実行もしやすいので早速学んだことを使っていこうと思う。
fargate でサービスを運用していて、夜間サービスを停止したい時がある。オートスケールの設定を流用することで、夜間停止を行うことができる。
オートスケール設定
aws application-autoscaling \
register-scalable-target \
--service-namespace ecs \
--resource-id service/{cluster-name}/{service-name} \
--scalable-dimension ecs:service:DesiredCount \
--min-capacity 0 \
--max-capacity 1停止スケジュール
(スケジューリング機能を使い、MinCapacity を 0 にする)
aws application-autoscaling put-scheduled-action \
--service-namespace ecs \
--resource-id service/{cluster-name}/{service-name} \
--scheduled-action-name poweroff-hogehoge \
--schedule "cron(00 10 ? * * *)" \
--scalable-dimension ecs:service:DesiredCount \
--scalable-target-action MinCapacity=0,MaxCapacity=0起動スケジュール
aws application-autoscaling put-scheduled-action \
--service-namespace ecs \
--resource-id service/{cluster-name}/{service-name} \
--scheduled-action-name poweron-hogehoge \
--schedule "cron(30 0 ? * MON-FRI *)" \
--scalable-dimension ecs:service:DesiredCount \
--scalable-target-action MinCapacity=1,MaxCapacity=1AWS では Active Directory / LDAP アプリケーションは大きく３つ存在している。全ての説明は Classmethod 社の記事がわかりやすかったので引用する。
１コマンドで確認することができる。
aws --profile stg elbv2 describe-load-balancers --load-balancer-arns arn:aws:elasticloadbalancing:ap-northeast-1:01234567:loadbalancer/net/tsukadanlb/a1b2c3d4e5結果は以下の通り
{
"LoadBalancers": [
{
"LoadBalancerArn": "arn:aws:elasticloadbalancing:ap-northeast-1:708179590705:loadbalancer/net/tsukadanlb/a1b2c3d4e5",
"DNSName": "tsukada-nlb-a1b2c3d4e5.elb.ap-northeast-1.amazonaws.com",
"CanonicalHostedZoneId": "a1b2c3d4e5",
"CreatedTime": "2019-06-06T11:01:01.615000+00:00",
"LoadBalancerName": "tsukada-nlb",
"Scheme": "internal",
"VpcId": "vpc-a1b2c3d4e5",
"State": {
"Code": "active"
},
"Type": "network",
"AvailabilityZones": [
{
"ZoneName": "ap-northeast-1c",
"SubnetId": "subnet-a1b2c3d4e5",
"LoadBalancerAddresses": []
},
{
"ZoneName": "ap-northeast-1a",
"SubnetId": "subnet-a1b2c3d4e5",
"LoadBalancerAddresses": []
}
],
"IpAddressType": "ipv4"
}
]
}NLB を削除できない場合、
API Gateway に VPC links の設定が残っている場合が多い。
API Gateway で VPC links で NLB を登録していたが、先にその設定を解除（削除）する必要がある。
CodeDeploy で Step 3 で失敗することがある。
The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems.上記エラーの対処をまとめる。
原因を探っていくと、AllowTraffic で 1時間以上も時間がかかって失敗していた。
この処理の Script の中身を確認するものの何も書かれていない。
この原因について調査し、原因がわかったので備忘録として記載すると、
これは LoadBalancer から新しくDeploy されたインスタンスへのトラフィックが流れない事が原因だった。
具体的に言うと LoadBalancer から新インスタンスへの health check が通っていない状況。
LoadBalancer の health check を修正する事で deploy が成功するようになった。
パーセントと、パーセンタイルを比べるとわかりやすい。
一般的な パーセントの場合は、率をあらわす。
50パーセントは全体に対し、半分がという意味になる。
一方でパーセンタイルは似たようでちょっと違う。
全体を 100個に区切り、
小さい方順にソートして 何番目にあるかを表現されている。
p50 (50パーセンタイ)ルの場合は、
下から 50/100に位置しているデータ。
p90 (90パーセンタイル)の場合は、
下から 90/100に位置しているデータ。
p95 (95パーセンタイル)の場合は、
下から 95/100に位置しているデータ。
となる。
機械学習ではなく xray でもこのパーセンタイルを採用しているが、おそらく理由は、
それより遅い異常値を弾くことで精度の高い統計情報にするためだと考える。
CloudWatch の Dimensions を知りたいが、
ブラウザで AWS のコンソール画面に入っても、Dimensions を見ることはできない。
この時の確認の仕方を紹介。
コンソールからNamespaces を調べる。
今回 API gateway 。
クリックしていくと、 Metric Name を選ぶので任意のものを選ぶ。
今回は Count
上記メモとしてひかえ、aws cli を投げる
aws cloudwatch list-metrics
--namespace AWS/ApiGateway
--metric-name Count
以下のようなレスポンスが返ってくる
{
"Metrics": [
{
"Namespace": "AWS/ApiGateway",
"MetricName": "Count",
"Dimensions": [
{
"Name": "ApiName",
"Value": "Tsukada API"
},
{
"Name": "Resource",
"Value": "/info/name/_search"
},
Dimensions を確認することができる