TIL (Today I Learned) - Programmatic programming #4

-

Today's 3 Line Summary

  • Don't trust evev yourself. When you think "that could never happen", check it
  • if use resources, check to freed status when finish
  • Always take small, deliberate steps, checking for feedback and adjusting before proceeding.

TIL (Today I Learned) date

2022.03.24

The scope I read today

Chapter 4 Pragmatic Paranoia

What you want to remember in the book

  • But Pragmatic Programmers take this a step further. They don’t trust themselves, either.

Topic 23. Design by Contract

  • Remember, if your contract indicates that you’ll acceptanything and promise the world in return, then you’ve got a lotof code to write!

Topic 24. Dead Programs Tell No Lies

  • Pragmatic Programmers tell themselves that if there is an error,something very, very bad has happened.
  • A dead program normally does a lot less damage than a crippledone.

Topic 25. Assertive Programming

  • Whenever you find yourself thinking “but of course that could never happen,” add code to check it.
  • Don’t use assertions in place of real error handling. Assertions check for things that should never happen
  • Turning off assertions when you deliver a program toproduction is like crossing a high wire without a net because you once made it across in practice.

Topic 26. How to Balance Resources

  • Finish What You Start
  • Because Pragmatic Programmers trust no one, including ourselves, we feel that it is always a good idea to build code thatactually checks that resources are indeed freed appropriately

Topic 27. Don't Outrun Your Headlights

  • Always take small, deliberate steps, checking for feedback and adjusting before proceeding. Consider that the rate of feedback is your speed limit. You never take on a step or a task that’s “too big.”
  • Avoid Fortune-Telling : Much of the time, tomorrow looks a lot like today. But don’tcount on it.

How did you feel reading it today?

  • When I was writing a test case, I sometimes think "Does this situation really happening?". After I read this chapter and the sentence "Pragmatic Programmers don't trust themselves," I thought I should be more assertive in writing a case.

Popular Posts

CloudWatch EventsはAmazon EventBridgeになるらしい

-
イメージ
まえおき 　最近久々にCloudWatch Events(以下、Events)の画面を開いたら、以下のようなメッセージが出ていた。 グーグル翻訳先生に翻訳をお願いすると CloudWatch Events is now Amazon EventBridge Amazon EventBridge (formerly CloudWatch Events) provides all functionality from CloudWatch Events and also launched new features such as Custom event buses, 3rd party event sources and Schema registry to better support our customers in the space of event-driven architecture and applications. CloudWatch EventsがAmazon EventBridgeになりました Amazon EventBridge（以前のCloudWatch Events）は、CloudWatch Eventsのすべての機能を提供し、カスタムイベントバス、サードパーティイベントソース、スキーマレジストリなどの新機能も起動して、イベント駆動型のアーキテクチャとアプリケーションの領域でお客様をより適切にサポートします。 らしい。Amazon EventBridge(以下、EventBridge)がEventsの代わりになるということだった。いつから出たんだろう…。最近、画面のUIが変わりましたのメッセージが常にほぼどのサービスでも同じ感じで出ていたから全然気つかなかった…。今までは、EventBridgeというEventsと似ているサービスがあるということは知っていたけど、Eventsの機能で十分だったので特に気にしてなかった。調べてみると、ちょうど1年前に発表されたサービスだった。( Amazon EventBridge – SaaS アプリケーション用のイベント駆動型での AWS の統合 )   Cloudwatch EventsとAmazon EventBridgeの違い 　全く同じサービスであるというと若...
続きを読む

PythonのDict型をDynamoDB形式のJsonに変換する

-
pythonでDynamoDB関連操作をするとき、難しい点の一つは一つは以下のようなDynamoDBの独特なJSON形式だと思います。 { "id": { "N": 12345 }, "name": { "S": "TanakaTaro" } } Python用のAWS SDKであるBoto3にはDynamoDB形式のJsonをPythonのDictに変換できる TypeSerializer と TypeDeserializer があります。 https://boto3.amazonaws.com/v1/documentation/api/latest/_modules/boto3/dynamodb/types.html TypeSerializer PythonのDictをDynamoDB形式のJsonに変換します。個人的には変換結果で最初の{"M": ...}はなくしてほしいですが… TypeDeserializer DynamoDB形式のJsonをPythonのDictに変換します。こちらも一気に変換はできず、各Keyごとに変換が必要です。 まとめ＆蛇足 TypeSerializerとTypeDeserializerはDynamoDBのデータをpythonで処理したいときや処理後にまたDynamoDBにアップロードしたいときに有効に利用できそうです。 ただ、そのまま利用するよりは、利用しやすくカスタム関数やクラスを作成したほうがよさそうです。 JavaScriptのSDKにもConverterというものがあるようです https://aws.amazon.com/jp/blogs/developer/announcing-the-amazon-dynamodb-document-client-in-the-aws-sdk-for-javascript/
続きを読む

CloudFormationテンプレート内のStep functionsのState machine定義をS3に置けるようになった

-
イメージ
まえおき 今週あったチーム先輩(Aさん)との会話 私　：CloudFormationテンプレートにStepfunctionsを書こうとするとyamlにベタ書きしかできないんですよ。 　　　これが私がCDKを押す理由の一つなんですよ。 Aさん：LambdaみたいにS３バケットに定義ファイルを置いてそのパスをyamlに書けばいいじゃん。 私　：あれ?私が調べたときはそれができなかったので、今あるテンプレートはすべてベタ書きにしているんですが…。 Aさん：うん?これでできないんだけ？(CloudFormationのドキュメントURLを共有) 私　：できるじゃん!? 　送られてきた CloudFormationドキュメント を見ると、 DefinitionS3Location というプロパティがあった。おかしいな…調べたときは本当になかったんだようなーと思いずつ更新履歴を見ると、2020年5月20日更新。私が調べたのは1月ごろだったから、その時はなかったということだ。うーん、What's Newはほぼ毎日見るけど、使っているサービスのドキュメント更新履歴も頻繁にチェックしないといけないのかな…。とりあえず、試してみることにした。   DefinitionS3Locationを試してみる Step Functionsのテンプレートを準備 　State Machineの定義はAWSドキュメントの Getting Started with Step Functions にあるコードから最後のstateを少し変えた簡単な以下のコードを利用する。 DefinitionSubstitutions も使ってみたかったので。 DefinitionSubstitutions はテンプレート内で同時に作成されるリソースをState Machine内で利用する場合に使う。例えば、Lambdaを作成して、それをState machineに入れるとか。(LambdaのARNが必要になる)   　jsonファイルで保存し、S3のバケットに保存する。 　これでStep Functions側の準備は終わり。   CloudFormationテンプレートを準備 　 CloudFormationの StepFunctions::StateMachi...
続きを読む