I decided to write down the helpful features and settings I’ve discovered in Zoom.
Everyone knows that awkward pause. “Bye!” followed by several seconds of figuring out where your mouse pointer is and landing it on the “Leave Meeting” button.
You can make this less painful by using the keyboard to leave meetings.
First, disable the “Ask me to confirm when I leave a meeting” option in the “General” tab of the desktop app settings. This will reduce your time to leave even when you’re using the mouse.
Recently, I ran a poll on twitter asking how people interacted with boto3, the AWS Python SDK (why is called boto3? See the end of the article for an appendix on this). What I wanted to know is how many people used boto3 sessions, and how many people use the module-level functions. I asked which style people use:
s3 = boto3.client('s3')
ddb = boto3.resource('dynamodb')
session = boto3.Session()
s3 = session.client('s3')
ddb = session.resource('dynamodb')
There are myriad APIs in AWS services that allow services to accept large and/or binary content from you. Zip files for your Lambda functions, images for Rekognition, CloudFormation templates, etc. All of them have one thing in common: that content has to be provided as an S3 object. I think this leaves a lot to be desired.
First, accounts do not come with an S3 bucket to use for this purpose. There’s no “default” bucket you can use. If you use the CloudFormation console, your uploaded template file gets whisked away to an AWS-owned bucket. …
Python dependency management is known to be bad. Over time, I’ve decided the only way I’m willing to live is to push my Python environment hygiene to the max. As I’ve recommended my setup to a lot of people, I figured I should write it up as a reference.
This is what I aim to accomplish in my Python setup. You don’t have to agree with these tenets, and if you don’t, feel free to ignore any of the advice that follows as it flows from them.
I see a lot of people who aren’t fully aware of the difference between
~/.aws/credentials. While it is more or less fine to just use one or the other, I think it’s worth understanding their intended purpose. So here’s a short explainer.
The idea is that
~/.aws/config is the main file, where you create profiles with the region, output format, and non-sensitive setup, like a profile that assumes a role based on another profile, an AWS SSO-authenticated profile, or a credential process. It’s a file you can (and maybe should) commit to source control.
InGraph is CloudFormation in Python syntax instead of YAML
I’m on the record as preferring declarative infrastructure as code (IaC) to imperative versions, such as the AWS CDK. I believe that declarative IaC has a lower total cost of ownership (TCO).
But while I prefer declarative to imperative, imperative IaC enables something I consider much worse: infrastructure as imperative programs that generate declarative IaC documents. Almost all imperative IaC frameworks work this way. There are two aspects to this that I consider particularly damaging.
First, these programs are generally not enforced to be deterministic, and when it’s not enforced, people…
1. On the tablet, tap “Meet now”, the top item on the side bar.
2. In small text on the bottom, tap “Call H.323/SIP”
3. Enter the Chime H.323 number: 22.214.171.124
As Richard Boyd says, CloudFormation is not a cloud-side version of the AWS SDK. Rather, CloudFormation is an infrastructure-graph management service.
This week, at Google Cloud Next, GCP announced an interesting new service: Cloud Run. My thoughts about the new Cloud Run service are a bit more complicated than this Twitter thread, so I’ve expanded on them in this blog and welcome your comments.
In this article, I’ll compare Google’s Cloud Run with AWS Lambda and API Gateway because I am most familiar with those services and provider. But my thoughts below are a general critique of Cloud Run relative to FaaS including Google Cloud Functions and managed API services in general — regardless of the provider.
Google’s Cloud Run…
Functions are not the point
If you go serverless because you love Lambda, you’re doing it for the wrong reason. If you go serverless because you love FaaS in general, you’re doing it for the wrong reason. Functions are not the point.
Sure, I love Lambda — but that’s not why I advocate for serverless.
Don’t get me wrong, functions are great. They let you scale transparently, you don’t have to manage the runtime, and they fit naturally with event-driven architectures. These are all fantastic, useful properties.
But functions should end up being a small part of your overall solution…
Cloud Robotics Research Scientist at @iRobot