それはそう。
とはいえ、教科書というかベストプラクティスを当てはめてからうまく行かない部分に対して臨機応変に対応するのが定石ではある。
ベストプラクティスという基礎がないとその先の応用を利かせられないので、真剣に取り掛かりたい技術であれば基礎固めを大事にしていきたいと思ってる。
基礎固めを体系的にできるという意味で資格勉強はかなり優秀。ベンダー資格だとまあまあ受験費が高いという難点を除けば、素晴らしい勉強方法だと自分では思ってる。その辺受験費の会社補助がもっとあるといいのになとは思いつつ。
直近でAWSのネットワークの基礎勉強したいので、4月くらいにAWS Certified Advanced Networking - Specialtyを受けたいなと思ってる。ちょうど参考書出ますしね。
EventBridgeでECS Taskの終了ステータスが0以外のとき、つまり異常終了したときのイベントを拾うためにrange関数を使いました。
resource "aws_cloudwatch_event_rule" "main" { name = local.name event_pattern = jsonencode( { "detail-type" : [ "ECS Task State Change" ], "source" : [ "aws.ecs" ], "detail" : { "containers" : { "exitCode" : range(1, 256), "lastStatus" : [ "STOPPED" ] } } } ) }
が、よくよくドキュメントを見ると “anything-but” という比較演算子があるので、これを使えば素直に意図を表すことができそうです。
resource "aws_cloudwatch_event_rule" "main" { name = local.name event_pattern = jsonencode( { "detail-type" : [ "ECS Task State Change" ], "source" : [ "aws.ecs" ], "detail" : { "containers" : { "exitCode" : [ { "anything-but" : [0] } ], "lastStatus" : [ "STOPPED" ] } } } ) }
スッキリとした解法を見つけたのでこれで安眠できますね。
Answer: 使えます
諸事情でECS Taskが失敗したとき、すなわち終了ステータスが1から255の条件のとき、のCloudWatch Event Ruleを書きたかったのですが、ベタに1から255のリスト書くのはつらすぎるので、range関数もしくは範囲記法ないかなあとググったらすぐ見つかりました。ありがたくrange(1, 256) を使わせていただきます。
というか、このルール自体いけてないのはわかってるんですけどね。。。。
正直言うと将来どうなりたいってビジョンあまりないんですよね。
不確実な時代に生きているので、数年後どんな仕事してるかなんて想像もできない。エンジニアとしてキャリアを積んでいたいなといううっすらとした希望はあります。
どうなりたいかよりはどうしていたいかって希望の方が強くて、そのなかで楽しい開発をしていれればなあと思ってます。
楽しいって何かというと、難しい問題なんですが、本質的じゃないことにわずらされないこと、自分がやりたいことをやれてることこれが大事なんじゃないかなと思います。そのための手段として自分自身の専門性、スペシャリティを伸ばしていきたいと思ってます。
そして、仕事ってもちろん一人だけでやるものではないので、他の職種との相互理解が必要だと思ってて、そのために他職種の専門性にもはみ出す必要があるんじゃないかなと思ってます。もちろん仕事を奪い取る必要はないんですが、簡単なタスクであれば専門外であっても自身で巻き取れるくらいのスキルは身につけていたいなと思います。
例えば、パフォーマンスチューニングしてて、イケてないクエリがわかったとして、アプリケーションコードの修正方法が分からないから、修正依頼を投げるより、自身でアプリケーションコードを直して、レビュー依頼を専門性があるエンジニアに依頼する方がアプリケーションエンジニアのわずらわしさを解消できて楽しくできてる気がしてます。こんなふうに少し自分の領域を越境することで、少し少しのまわりの煩わしさを解消することでみんな楽しく開発することにつながっていくのかなと。
よく言われる言葉だとT字型人材っていうんですかね。でもスキルセットとしてはそういう方向で伸ばしいくことでやりたいことがやりやすくなるのかなって思ってます。
あくまで目的は楽しく開発すること。その手段として、自身の専門性を高めること、周辺分野の専門性にもはみ出すことそういうことかなあ。
文字に書き出したらスッキリした気がするけど、まだちょっと粗いのでどっかでもう一回考えをまとめたい。
はてなブログProがいつの間にか切れてて(たぶん数年くらい前)、独自ドメインの設定が無効になってたことを今更気づいた。
— masasuzu (@masasuz) 2022年2月11日
Pro2年間契約したのでブログ真面目に書くぞー
(三日坊主フラグですね)
はい。この関係で、独自ドメイン設定が消えてました。今は復活してるはず。
ずっと更新できてなかったけど、この機会にちゃんとナレッジを記録していきたいなと思いを新たにしたのでした。がんばる
terraformとかでインフラリソースとログリソース(S3バケットとかCloudWatch log groupとか)を一緒のモジュールで管理することはよくあると思う。
一緒にすることのメリットとしては不要になったときに一気に消せることなのだが、逆にそれがデメリットでもある。ログに関してはインフラ自体がなくなっても、一定期間残したいという要件があるかもしれない。そのときにまあまあ困る。
対処作としては
となると思うけど、どっちもすっきりしないな。仕方ないけど。
これ以外にもライフサイクルの違うものを管理するときどうすればいいのか。もうちょっと悩みたい。
結論はまだない。
日本語版のドキュメントを見てたらAurora MySQLは2.10.1が最新になってるんですよね。
— masasuzu (@masasuz) 2022年2月9日
なので、これに上げたんですが、言語を英語に変えてみると2.10.2というバージョンがあるんですよね。。。。。かなしい。上げたあとに気がつく悲しさ。
手抜きして翻訳ドキュメント参照してたぼくがわるいのです。
— masasuzu (@masasuz) 2022年2月9日
AWSの日本語版のドキュメントは古いので、英語版を正として見ましょうという話です。
それと新し目のサービスだと、自動翻訳が怪しすぎてまともに読めないことが往々にしてあるので、英語読まざるを得ないんですよね。がんばる
かなしいのでおにく食べに行きます
— masasuzu (@masasuz) 2022年2月9日
9/15は私の誕生日でした。
$age++;
— masasuzu (@masasuz) 2021年9月14日
一つ年齢を重ねました。何が言いたいかというとiPad miniの新しいやつがほしいです。
何を言いたいかというとiPad miniの新しいやつがほしいです。誰かください。
誕生日なのに朝からAWS SOAの試験を受けに行ってました。ラボ試験が不安だったのですが、なんとか無事合格できていました。セルフ誕生日プレゼントですね。777点は縁起が良いのですが、点数としてはちょっと微妙なので、引き続き精進していきます。
とはいえ、AWS認定のAssociateレベルの試験は全部合格したことになります。初歩レベルの知識はあるということが客観的にこれで証明できるかなと思います。
試験の予約時間を10:30だと思ってたら9:30だったことを今気づいて慌ててたところ。
— masasuzu (@masasuz) 2021年9月14日
今確認しておいてよかった。
朝一でSOA-C02の試験受けてきた。
— masasuzu (@masasuz) 2021年9月15日
選択式は大丈夫だと思うけど、ラボ試験がどうだろうなあ、、、、、
SOA-C02無事パスしてました。777は縁起がいいけど、点数としては微妙なので精進します。
— masasuzu (@masasuz) 2021年9月15日
ラボ試験は普段使わないサービスだと難しいよね。。。という感想でした。
セルフ誕生日プレゼントになりました。 pic.twitter.com/0xm7Fpnu6R
近況なのですが、最近ちょこちょこカジュアル面談受けてます。直近ですぐ転職するつもりはないのですが、いいお話があればとアンテナを張っているのと、自分自身の価値を探索したいという2点からやってます。
改めて、人と話すの苦手だなあってしみじみ感じてます。特に言語化という部分が圧倒的に苦手で、自分がやってきたことをちゃんと自分の言葉で説明できてないというのは致命的だなと感じてます。面接面談なれしてないというのもあるのかもしれませんが、返答する瞬発力が足りなすぎてます。
ここ数年ずっと内向きでやってたことをもう少し言語化して外向きに発信する訓練していかないとまずいなと反省してるところです。足りないところはわかってきたのであとはやるだけです。
改めて人と話すことが苦手だということを再認識した。このままだとだめだなあ。
— masasuzu (@masasuz) 2021年9月15日
言語化が大事だなって思う。
— masasuzu (@masasuz) 2021年9月15日
頭の中ではふわっと理解してるんだけど、言語化してないがゆえに他人に説明するときにつまる。そんなことが多くて、いかに内向きでやってきたのかというのを思い知らされる。
まとまりは何もありませんが、そんな感じでまた一年がんばります。
お約束なのでほしいものリストおいておきます。 www.amazon.co.jp
あるサイトの昔話。
そのサイトはトップページはS3から静的HTML、/app/以下はアプリケーションサーバでサーブされていた。S3はそう簡単に落ちないから監視不要(それは間違いなのだがさておき)として、/app/およびappのヘルスチェックのみ監視していた。
ある日。静的HTMLジェネレータの不具合でindex.htmlが存在しないアーティファクトをS3にデプロイされてしまった。当然トップページ存在しないのでアクセスすると404が返るわけだが、監視がされてないので、誰も気づかない。サイトの主機能であるアプリケーションではないとは言え、しばらくトップページが表示されないのはそれなりまずい事態ではあった。
数十分後にようやく認知し、アーティファクトのバージョンを巻き戻し、CloudFrontをキャッシュをInvalidateして事なきを得るのであった。
大した教訓ではないが、以下のことを心にとめようと思ったのでした。
