I’m doing just a little learning about Digital Engineering, which seems to be almost synonymous with Model Based Systems Engineering (MBSE). The concept of MBSE is that, in contrast to more traditional methods where the team-of-teams creates documents to coordinate all efforts (think long contract-style English text), the team creates a variety of models. Some of those models would be UML-like diagrams, others might be executable. Each model interface provides a view on the underlying data & model - a view useful to some of the development teams for understanding what must get build. All done in digital formats sharable among all teams. Those might even translate automatically into some of the same documents from the contrasted method.
This tutorial will cover the topic of creating Internet-accessible and non-Internet-accessible EC2 instances within the same VPC, by hand within the AWS Console. At the end we’ll have one Internet-accessible Linux box which will be able to talk to a second, non-Internet-accessible Linux box. The instances will be accessible on ports 22 and 4000 from anywhere.
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.
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.
