The ability to create a URL to AWS Lambda functions has existed for a long time - but has never been as easy as it is today. In April AWS announced Lambda Function URLs, and now adding a world-usable non-authenticated URL can happen in the Lambda function creation wizard.
With great power comes great foot-gun though… When the whole world can easily access your Lambda function URL, without authenticating, the whole world can run up your AWS bill easily.
Delete your Lambda function when you’re done with this tutorial
This blog post is a tutorial for creating a simple Hello World application using this new Lambda feature. I’m teaching some folks in my unit how to use AWS, and while there are many Lambda Hello World tutorials out there I didn’t find one that was quite right. This tutorial will go through almost the simplest setup possible, deploying Python code at a URL, then will iterate on the initial code to demonstrate some basic computation.
TLDR: I made a current sensor that reports over cellular network to the Internet, providing a summary webpage and email alerting for when the current dies.
Today I’m smoking brisket, salmon, and lamb. Last night I brined the fish, then got it drying around 10, and started the smoker at 1250. I’ll smoke it until about 1700, then do the lamb to 160℉, then do the brisket overnight. The lamb is 5.7 lbs at $7.99 per lb, brisket 14.2 at $4.99 per lb. Unfortunately the brisket has a ton of fat on it - this was a bad buy. Doing these all at the same time means I only have to clean the smoker once.
Bottom-Line Up Front: I think as should be harder to use for Integer conversion in Rust. I recommend you use TryFrom/TryInto instead. Here’s how I recommend doing it (more complete example of right/wrong at the end):
use std::convert::TryInto;
fnmain() -> Result<(), Box<dyn std::error::Error>> {
let orig: u64=u64::MAX;
let ti_u64: u64= orig.try_into()?;
let ti_i64: i64= orig.try_into()?;
let ti_u32: u32= orig.try_into()?;
Ok(())
}
I’m at an intermediate level with the Rust programming language. I’ve done a year of adventofcode, a medium-sized API server project, and little more. While refactoring some code in my project recently I got rid of some of my explicit string conversions and let the type inference system and From/Into do their jobs. Now that I’m more comfortable with reading code using From/Into patterns I think it’s actually simpler - I can easily understand and trust what the type inference system does in those instances. Before I had intuition about how the inference system worked, I didn’t trust it. I didn’t know what it was doing under the hood.
During this leadership development course one of the instructors quoted one of his previous mentors saying that leaders should have stories ready about:
mission, discipline, loyalty, and safety
This is in line with what one of my former mentors told me more briefly, “you need stories”. Ok - I thought, but stories about what? I have stories… I can tell a story… Typically I’m coming up with something appropriate on the spot. There are pros and cons to that approach.
What I liked about this article is that by describing instances where the topic got steered wrong, and the author’s feedback about what got missed when that happened, the article provides a roadmap to steer conversations back in the right direction. I feel like these examples really resonate with me - as if I’ve been a part of conversations like this.
They asked us to reflect on some of our results from a personality quiz - the one at 16personalities.com. I got an INFJ, but normally I’m INTJ and think I probably still am, really.
How will we apply what we know about our personalities to our interactions with our teams?
I’ll try to be more conscious about how I react to “perceiving” teammates. They may wait a while and not set a plan - that can be ok. It often feels wrong to me, though, in large part because it’s not how I’ve learned to work. As reflected by my personality.
One think I do like about the video is that it provides some solid ways to change organizational culture. By providing a solid definition (even if it’s not the one I’d choose), the video is able to specify how to move the needle against that decision:
clarify
embody
celebrate
Determine what behaviors will be rewarded or corrected in your organization, and clarify that to the entire team. Embody those behaviors and live up to them. As someone in my group said with the embody piece, “you get what you tolerate”, so correct or reward the right things. Find the right things to celebrate and do.
I’m sitting in the Leader Development Course from Air University - distance learning. One of the stories I heard this morning has the crux - the commander needs to walk a line between being too involved and not being involved. The story involved the former commander trying to show he cared by being there when new members arrived, by sitting with folks as they did work, and by visiting them when they were out in the field. Later he learned that folks felt like he was checking up on them, making sure they were doing what they were supposed to.
